I have a question about the referencing of archetypes in specialization. And also want to know if there is a limit on the number of specializations of archetypes.
For example:
A is top level archetype
B is specialization of A
C has to further specialize B
and there is possibility that D also has to further specialize C and so on.
So in theory all childs have to conform to A. But the question is in C which archetype will be written in 'specialize' section? A or A & B ? I assume it is currently B. But in theory, possible one in a million, a particular specialized archetype might conform to multiple parents...In my opinion this is perfectly possible. So what happens?
The other question is whether ADL or other limits the number of specializations.
At the moment we have not seen any need for multiple inheritance in
archetypes. Do you have a particular use case? Note that C specialising
B means that C conforms to B and to A. Nothing special needed to do that.
At the moment we have not seen any need for multiple inheritance in
archetypes.
I see this as very similar to multiple inheritance in objects.
There is no *need*, but there is useful things that can be done.
The question is whether the price is justified.
The use case is relatively simple in concept - allowing multiple
inheritance would allow me to "cross-cut" concerns. I could write
an archetype that only dealt a narrow aspect of an information
structure, such as data integrity issues, and then use it across
multiple archetypes, letting them focus on the big picture, not
the minutiae of data integrity, which is mostly overlooked but
ubiquitiously present.
This would surely be useful for some things. The problem is the price.
How do you manage it, how would you use it, what does it mean to
allow "multiple inheritance". The archetype cannot allow anything
not allowed in all it's parents - so they have to "allow" some fairly
generic structures. To actually use it in an instance, the instance
is now making claims that become very much more difficult to
evaluate.
HL7 templates are an approach to solving this problem. HL7 static
models allow for multiple inheritance, though this can be
discovered (some controversy where discovery safe though). Actually,
given the similarity between static models and AOM, it's possible
that the algorithm that HL7 uses would be applicable to AOM too.
Because HL7 models allow multiple inheritance by discovery, it is
also necessary to represent the multiple applicable constraint
models in the instance, greatly complicating the instance and the
processing of the instance. However there are some interesting design
patterns that can arise, and that are arising, in the HL7 space as a
consequence of this.
So, resist any thought of multiple inheritance in openEHR - it will
greatly complicate matters. Let HL7 find out whether templates
represent a great big hole to fall into, or whether they will be
truly enabling. (btw what I have described is not all that
templates are in HL7, so the mere fact that templates are successful,
particularly in CDA, is not evidence that multiple inheritance can be
made to work)
Is multiple inheritance in the use case you presented, the only solution?
I expect it is not.
So why use it.
When ‘data integrity’ is a recurring issue in several archetypes, re-use by inclusion of a ‘data integrity’ archetype in an other archetypes is a better other solution.
I’m not closely following HL7 Templates.
Are the HL7 Templates a separate and diverging piece of work when compared to EN13606-2 or harmonising?
Do both the HL7 Templates and CEN Archetypes share identical requiremenets?
Gerard
– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
Is multiple inheritance in the use case you presented, the only solution?
I expect it is not.
So why use it.
When 'data integrity' is a recurring issue in several archetypes, re-use
by inclusion of a 'data integrity' archetype in an other archetypes is
a better other solution.
It would be better if you didn't have to do that - didn't have to consider
*everything* in each design. But on balance, I believe that multiple
inheritance raises more problems that it solves.
I'm not closely following HL7 Templates.
Are the HL7 Templates a separate and diverging piece of work when
compared to EN13606-2 or harmonising?
There is no simple answer to that. Really, it's the wrong question.
It's like asking whether the icing on the cake is helping make
two totally different cakes the same or not.
Do both the HL7 Templates and CEN Archetypes share identical requiremenets?
again, this is hard to answer. Archetypes and Static models share very
similar requirements - they are both constraint and ontology binding
models. Templates is a way of re-using the constraint models in a form
that the openEHR/13606 community have not tried to investigate; the
design intends to meet those requirements differently. Only time will
tell which is the right approach.
At the moment we have not seen any need for multiple inheritance in
archetypes.
I see this as very similar to multiple inheritance in objects.
There is no *need*, but there is useful things that can be done.
The question is whether the price is justified.
The use case is relatively simple in concept - allowing multiple
inheritance would allow me to "cross-cut" concerns. I could write
an archetype that only dealt a narrow aspect of an information
structure, such as data integrity issues, and then use it across
multiple archetypes, letting them focus on the big picture, not
the minutiae of data integrity, which is mostly overlooked but
ubiquitiously present.
Hi Grahame,
in openEHR at least, data integrity is not defined or solved by
archetypes - it is in the reference model.
A practical example of 'C' that is currently in the archetype repository is
the Histological Diagnosis archetype -
openEHR-EHR-EVALUATION.problem-diagnosis-histological.v1.ad
Problem --> specialised to Diagnosis --> specialised to Histological
Diagnosis - all of which are in the 'Specialisation' field of the Archetype
Editor.
There is no technical limit on the number of specialisations - but from my
experience so far, it will be uncommon to have to specialise more than
twice.
The modelling required to work out the parent, and then each layer of
children becomes increasingly complex and time-consuming, reconciling back
up to the parent once the lowest level of child requirements has been
captured - I have experimented initially with mindmapping for these
problems. To date they have been mainly related to principles of inspection
and palpation in cluster archetypes focused on capturing examination for
re-use eg an initial generic inspection cluster, specialised to inspection
of skin, to inspection of a wound or inspection of a rash.
We are speaking about data integrity issues at different
levels. Of course the reference model assures data integrity
at that level; I was speaking of data integrity at the of
data aquisition - calibration, methodology, attribution, these
kind of things.
We are speaking about data integrity issues at different
levels. Of course the reference model assures data integrity
at that level; I was speaking of data integrity at the of
data aquisition - calibration, methodology, attribution, these
kind of things.
Grahame
ah - 'data quality' in other words - i.e. markers / meta-data relating
to the data capture from the source, not the integrity of the data as
represented on the openEHR system?
So far I would see such things as being catered for using compositions
of archetypes - we currently have a lot of Cluster and Structure
archetypes for this purpose. In all Entry archetypes (Observation etc),
there is a 'protocol' attribute. It would be easy to create an item
under protocol in those Entry archetypes that need it for 'data
quality', which is a slot taking a subset of Cluster or Structure
archetypes which report on data quality / capture. We already do a lot
of re-use of this kind with archetypes.
I would be very hesitant to introduce the equivalent of multiple
inheritance, because the true nature of inheritance is a notion of
substitutability, or IS-A-ness. Using inheritance as a way of doing a
mixin as can be done in software can be confusing.
It is interesting that even the Eiffel language, which has the smoothest
and cleanest implementation of multiple inheritance (which Eiffel
developrs use ubiquitously in application development), has evlved its
semantics to distinguish 'conforming inheritance' and 'non-conforming
inheritance'. The latter does not confer substitutability.
In the archetype space, 'substitutability' really translates to: can I
use a parent archetype to process the data creating using child
archetypes? The answer should (in my view) only be yes when the parent
is ontologically a precursor of the children, e.g. the laboratory
archetype is an ontological parent of laboratory-lipids. I think it
would be hard to push the idea that some archetype containing no
constraints apart from some data_quality items was an ontological parent
of laboratory-lipids or any other archetype.
If we were to go more towards using software constructs in archetypes, I
think I would be more interested in genericity (i.e. template types)
rather than multiple inheritance.
I should note that in the next generation of archetypes and tooling,
archetype 'source' files for specialised archetypes will be
'differential' in nature - i.e. valid ADL, but containing only added and
changed items from the parent, just as for subclasses in an
object-oriented programming environment. This will not affect archetypes
already created, other than to generate warnings for inconsistencies.
Over time, the tools will migrate to working off the differential source
form, not the inheritance-flattened form we use today (with the
difference only manifesting for specialised archetypes).
The current generation of the ADL worbench already shows the inherited
items that are changed or added in specialised archetypes. The next
release will enable the source files to be displayed, and will generate
the appropriate warnings due to more sophisticated validation up the
specialisation lineage. In practical terms, this translates to more
maintainable archetypes and a better ability to see the differences
between a given specialised archetype and the parent.
I should note that in the next generation of archetypes and tooling,
archetype 'source' files for specialised archetypes will be
'differential' in nature - i.e. valid ADL, but containing only added and
changed items from the parent, just as for subclasses in an
object-oriented programming environment.
This is excellent news - I was going to launch into a tirade this
afternoon about how archetype specialisation requires repeating
the whole parent definition, and how much more robust OO subclassing
is because of the differential nature! Good thing I held off on my venting..
A while back there was talk of a confluence wiki being set up
for storing of some of these thoughts?? Is anything happening in
that area? I can help out if any admin is required - I just installed Jira
and Confluence on my own machines..
I should note that in the next generation of archetypes and tooling,
archetype 'source' files for specialised archetypes will be
'differential' in nature - i.e. valid ADL, but containing only added and
changed items from the parent, just as for subclasses in an
object-oriented programming environment.
This is excellent news - I was going to launch into a tirade this
afternoon about how archetype specialisation requires repeating
the whole parent definition, and how much more robust OO subclassing
is because of the differential nature! Good thing I held off on my venting..
we have actually generated differential form archetypes - we are now
adjusting some of the parser semantics, since now it has to check up the
specialisation lineage for codes and a few other things, not just in the
current archetype. A few weeks away from being solid I would say. Also,
the ADL workbench now works more like a compiler - you can see what is
compiled, what is not, and quickly reload anything already compiled.
A while back there was talk of a confluence wiki being set up
for storing of some of these thoughts?? Is anything happening in
that area? I can help out if any admin is required - I just installed Jira
and Confluence on my own machines..
they are both going - as is the new website. All will be available very
soon. For confluence, we will ust put in some minimal structure to save
us from complete disorganisation - it will be an open wki. There will be
plenty of opportunity for experts here to contribute and help shape
these things - we just want them running in a basic reasonable form so
people don't hate us when they see it
Thanks for the example; I agree that increasing the number of nested specializations will make it difficult to maintain models.
Regarding 'multiple-inheritance' the probable use case is related with modeling of cervicco-vaginal smears. There are now two alternative archetypes, one designed for NHS by Ocean which is already a specialization of general histology archetype and the other archetype I am currently modeling, Bethesda System 2001. I have not experimented yet if my archetype can be redesigned as a specialization of NHS archetype (PAP) or be a an alternative archetype for the same purpose possibly for use at a different setting. In the case of having two separate alternative archetypes, I thought of having a further specialized archetype which conforms to both parents. I think this is possible and useful.
In my former message, with the question of writing down B and A for spelicalization section of C, I was proposing to write down the names of all archetypes till the top level in specialization archetype- like an absolute specialization path. This I think is not true multiple-inheritance as in any instance of this specialized archetype, it will conform to only one parent and not inherit non-conforming stuff from both parents, but the applications working at the level of the parent archetypes shall be able to use this data seamlessly. Maybe ridiculous but I want to name it as 'multiple-generalization'
I do not consider myself a good programmer but I am aware of the shortcomings of multiple-inheritance in that domain. However as I explained above I don not feel it really is the same thing...And I can perfectly live without this if the price to pay does not worth the benefit
Interesting discussion. I'm hope we can avoid multiple inheritance in
archetype specialisation. It will be interesting to see how far one
can get just using single inheritance and inclusion (clusters etc).
There are now two alternative archetypes, one designed for NHS by Ocean which
is already a specialization of general histology archetype and the other archetype
I am currently modeling, Bethesda System 2001. I have not experimented yet if
my archetype can be redesigned as a specialization of NHS archetype (PAP)
or be a an alternative archetype for the same purpose possibly for use at a different
setting. In the case of having two separate alternative archetypes, I thought of
having a further specialized archetype which conforms to both parents. I think
this is possible and useful.
What is different and what is in common in the two 'smear' archetype
approaches (Bethesda v.s. NHS)? Sorry if this is a stupid question
coming from a non-clinician.
Can one share important sub-parts without sharing view on process and
structure. If so, will the information entered using the two different
archetypes be computable in a similar way for e.g. decision support
systems.
Perhaps the best will be to agree on one archetype in this case if
possible, but I assume similar cases will surface again. From a
technical perspective it is interesting to discuss how far one can get
in reaching clinical consensus in 'ontological' sub parts. Splitting
things up in too many small 'consensus pieces' without sharing
encompassing structure is also likely to have negative impact on
semantic interoperability.
Lets get the requirements on the Clinical list and have a discussion. I did not see large inconsistencies in the content in the two - rather differences in modelling approaches.
I also think we should avoid multiple inheritance - it is complex enough
the way it is - from a tooling as well as from an archetype design point
of view. We don't need to make it complicated in addition to complex.
Like Erik, I don't know the details of these two archetypes, but I think
a better design than using multiple inheritance would be to
- use a common base archetype for both. Here everything that the two
archetypes have in common (even if it is a little bit more generic than
it would be when only considering one of them) can be located. And also
everything that doesn't largely overlap can be located as optional items
- even if it doesn't have any relevance to the NHS and or Bethesda.
- If really necessary specialise this base archetype for the
environment, but preferably use templates to achieve this (strip out
unnecessary items in your environment, further constrain the archetype
etc.)
Cheers
Sebastian
From: Erik Sundvall [mailto:erisu@imt.liu.se]
Sent: Thursday, 18 October 2007 5:04 PM
To: For openEHR technical discussions
Subject: Re: Multiple parents and max number of nested specialized
archetypes?
Hi!
Interesting discussion. I'm hope we can avoid multiple inheritance in
archetype specialisation. It will be interesting to see how far one
can get just using single inheritance and inclusion (clusters etc).
>There are now two alternative archetypes, one designed for NHS by
Ocean
which
> is already a specialization of general histology archetype and the
other
archetype
> I am currently modeling, Bethesda System 2001. I have not
experimented
yet if
> my archetype can be redesigned as a specialization of NHS archetype
(PAP)
> or be a an alternative archetype for the same purpose possibly for
use
at a different
> setting. In the case of having two separate alternative archetypes,
I
thought of
> having a further specialized archetype which conforms to both
parents. I
think
> this is possible and useful.
What is different and what is in common in the two 'smear' archetype
approaches (Bethesda v.s. NHS)? Sorry if this is a stupid question
coming from a non-clinician.
ard_et_al.pdf
...regarding organisational vs ontological models apply to this or are
the differences of another nature?
Can one share important sub-parts without sharing view on process and
structure. If so, will the information entered using the two different
archetypes be computable in a similar way for e.g. decision support
systems.
Perhaps the best will be to agree on one archetype in this case if
possible, but I assume similar cases will surface again. From a
technical perspective it is interesting to discuss how far one can get
in reaching clinical consensus in 'ontological' sub parts. Splitting
things up in too many small 'consensus pieces' without sharing
encompassing structure is also likely to have negative impact on
semantic interoperability.
In my former message, with the question of writing down B and A for spelicalization section of C, I was proposing to write down the names of all archetypes till the top level in specialization archetype- like an absolute specialization path. This I think is not true multiple-inheritance as in any instance of this specialized archetype, it will conform to only one parent and not inherit non-conforming stuff from both parents, but the applications working at the level of the parent archetypes shall be able to use this data seamlessly. Maybe ridiculous but I want to name it as 'multiple-generalization'
Hi Koray,
now I understand what you want. You want the 'inheritance-flattened'
form of a specialisation archetype - i.e with everything in it due to
all parents. This happens to be the current form of archeypes anyway. We
are converting over to the differential form used in object-oriented
programming very soon (in .adls files), but the flat form will still be
avalable (.adl files), generated and validated rather than directly
created as they are today. In the current form of the .adl file we don't
mention the lineage of parents all the way to the top. It would be easy
enough to do, although I don't quite see what use it would be.
Can one share important sub-parts without sharing view on process and
structure. If so, will the information entered using the two different
archetypes be computable in a similar way for e.g. decision support
systems.
this is why we have Cluster & Structure archetypes that are routinely
shared via slots in various other archetypes - it provides a high degree
of re-use, just as for classes referencing other classes (assocation,
aggregation) in the object paradigm .
My approach would is in synch with Sebastian - ideally one maximum data set
of all content for one pap archetype, from any source or standard, then
constrained in a template for Bethesda's purposes, NHS' needs etc. Then the
data has maximal interoperability and queryability.
In this case you wouldn't need multiple inheritance - I think the key is in
the 'art' of the design of the initial and maximal pap archetype.
Heather
From: openehr-technical-bounces@openehr.org [mailto:openehr-technical-
bounces@openehr.org] On Behalf Of Sebastian Garde
Sent: Thursday, 18 October 2007 8:46 AM
To: For openEHR technical discussions
Subject: RE: Multiple parents and max number of nested specialized
