Multiple parents and max number of nested specialized archetypes?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071022/fb05b0eb/attachment.html
Multiple parents and max number of nested specialized archetypes?
I haven't followed this whole thread, in particular I haven't seen Rong's emails about templates and aggregation archetypes but I thought I would provide a little input about the future of the template specifications. If you have a look at the Template Object Model as published as a draft in R1.0.1 you will find two packages. The first is the TEMPLATE_SPEC package. This provides a mechanism to specify a template using references to archetypes and aggregating them together. In addition it provides a series of constraint rules of various kinds to do things like constrain cardinalities or specify default values. We have been recently comparing this with the current proprietary template definition used within the Ocean Template Designer and have found that there are very few required template semantics that cannot be expressed using the R1.0.1 TEMPLATE_SPEC draft. The second model is the operational template model. We have actually implemented this and have needed to augment and change this model slightly, but the principles expressed in the R1.0.1 draft (a Template object with definition specified by a C_COMPLEX_OBJECT and list of path and default value pairs) has work fine. This implementation experience will be feed back into the openEHR community for the next release. So in summary, Rong's premise that we can express templates using the AOM is true, but what he calls an aggregation archetype is an operational template. The TEMPLATE_SPEC is just another representation of the same template where it references the existing archetype artefacts and constrains them using rules. The TEMPLATE_SPEC is used to store and maintain the template definition within an authoring environment while the operational template is derived from the TEMPLATE_SPEC and is used within software at run-time. We are just completing the testing of a new export function in the Ocean Template Designer that generates an operational template from its proprietary template definition. This operational template will be used for all sort of purposes including the generation and validation of RM objects that conform to the template. Hope this helps keep you up to date with progress in this area. If you have interest in this area from the technical perspective I suggest that we progress this further in a collaborative manner. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.biz From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Lisa Thurston Sent: Monday, 22 October 2007 1:32 PM To: For openEHR technical discussions Subject: Re: Multiple parents and max number of nested specialized archetypes? Hi all I think that in the absence of a template specification it is indeed difficult to see, from a technical viewpoint, the difference between templates and aggregation archetypes (which is what I think Rong means by all the constraints done in templates can be done with archetypes). Heather and Hugh point out that such archetypes would not be universal in their applicability and therefore less shareable. This still leaves a blurry line between where the archetype ends and the template begins. There are some features of templates that do make this line clear, however. The best example I can think of is default values (not to be confused with assumed values). At some point you'll want to be able to say things like the default temperature scale is Centigrade or the default number of foeti is 1. If the default value is free text or even a coded term, this implies that the template is targeted to a specific language/culture, thus NOT universal. Therefore the template specification, when it arrives, is likely to include ways to define default values and the target language/culture of the template. A template is language/culture-specific. There is provision made for default values in the AOM's archetype constraint model but the TYPE of a default is left open. Since the TYPE of these values cannot be constrained by the AOM, default values can never be meaningfully applied in ADL. Rather they can only be applied in the template (which knows about the reference model and target language/culture of the data). This connects to Rong's point about expressing template constraints in AOM semantics. I fully agree the template specification should make use all useful parts of the archetype constraint model or build on top of the AOM. If a template was ever suddenly considered to encapsulate a structure which was universally (or near-universally) applicable, as Hugh suggests, the default values would have to be discarded (as well as other culture-specific structures or assumptions). And for the archetype to be practical
Multiple parents and max number of nested specialized archetypes?
Thanks all for the excellent explanations on the differences between archetypes and templates both from functional and technical point of view. I agree with Sebastian, these rather educational comments should be included in our FAQ page. On the technical side, I will be glad to review the early draft of TEMPLATE_SPEC specification. It can even be implemented by the Java community to provide feedbacks for further refinement. Cheers, Rong On 10/22/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: I haven't followed this whole thread, in particular I haven't seen Rong's emails about templates and aggregation archetypes but I thought I would provide a little input about the future of the template specifications. If you have a look at the Template Object Model as published as a draft in R1.0.1 you will find two packages. The first is the TEMPLATE_SPEC package. This provides a mechanism to specify a template using references to archetypes and aggregating them together. In addition it provides a series of constraint rules of various kinds to do things like constrain cardinalities or specify default values. We have been recently comparing this with the current proprietary template definition used within the Ocean Template Designer and have found that there are very few required template semantics that cannot be expressed using the R1.0.1 TEMPLATE_SPEC draft. The second model is the operational template model. We have actually implemented this and have needed to augment and change this model slightly, but the principles expressed in the R1.0.1 draft (a Template object with definition specified by a C_COMPLEX_OBJECT and list of path and default value pairs) has work fine. This implementation experience will be feed back into the openEHR community for the next release. So in summary, Rong's premise that we can express templates using the AOM is true, but what he calls an aggregation archetype is an operational template. The TEMPLATE_SPEC is just another representation of the same template where it references the existing archetype artefacts and constrains them using rules. The TEMPLATE_SPEC is used to store and maintain the template definition within an authoring environment while the operational template is derived from the TEMPLATE_SPEC and is used within software at run-time. We are just completing the testing of a new export function in the Ocean Template Designer that generates an operational template from its proprietary template definition. This operational template will be used for all sort of purposes including the generation and validation of RM objects that conform to the template. Hope this helps keep you up to date with progress in this area. If you have interest in this area from the technical perspective I suggest that we progress this further in a collaborative manner. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.comheath.frankel at oceaninformatics.biz *From:* openehr-technical-bounces at openehr.org [mailto: openehr-technical-bounces at openehr.org] *On Behalf Of *Lisa Thurston *Sent:* Monday, 22 October 2007 1:32 PM *To:* For openEHR technical discussions *Subject:* Re: Multiple parents and max number of nested specialized archetypes? Hi all I think that in the absence of a template specification it is indeed difficult to see, from a technical viewpoint, the difference between templates and aggregation archetypes (which is what I think Rong means by all the constraints done in templates can be done with archetypes). Heather and Hugh point out that such archetypes would not be universal in their applicability and therefore less shareable. This still leaves a blurry line between where the archetype ends and the template begins. There are some features of templates that do make this line clear, however. The best example I can think of is default values (not to be confused with assumed values). At some point you'll want to be able to say things like the default temperature scale is Centigrade or the default number of foeti is 1. If the default value is free text or even a coded term, this implies that the template is targeted to a specific language/culture, thus NOT universal. Therefore the template specification, when it arrives, is likely to include ways to define default values and the target language/culture of the template. A template is language/culture-specific. There is provision made for default values in the AOM's archetype constraint model but the TYPE of a default is left open. Since the TYPE of these values cannot be constrained by the AOM, default values can never be meaningfully applied in ADL. Rather they can only be applied in the template (which knows about
Multiple parents and max number of nested specialized archetypes?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071021/680fc2cd/attachment.html
Multiple parents and max number of nested specialized archetypes?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071019/86ceb3ed/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071019/86ceb3ed/attachment.png
Multiple parents and max number of nested specialized archetypes?
The demarcation between templates and a specialisation are very clear to me - very different entities. Let me start at the beginning, although it may be so obvious to most that you have overlooked it to focus on the constraint issues, but I thought I'd state it for completeness. At the simplest and most obvious level, an archetype is a data specification for a single clinical concept. A specialisation is a type of archetype. A template is an aggregation of archetypes, some of which may be specialised, that are combined to carry out a particular clinical purpose eg a discharge summary. In the following discussion, I will assume that our goal is to design internationally interoperable archetypes, and excludes the specific archetype that is used only for a niche purpose and has no intention of being shared at design time... An archetype, whether specialised or not, in the purest methodological sense, is a MAXIMAL data set for that given single clinical concept - something that seems to often get overlooked when trying to model clinical concepts. It is also a data set that should have the MINIMAL constraints on it, in order to MAXIMISE interoperability. Any constraints that are included in an archetype should be only added when it applies UNIVERSALLY. For example the current Blood Pressure archetype contains constraints for both the Systolic and Diastolic readings, but they are obviously not in keeping with accepted clinical practice - in the realm of 0-1000mmHg or so. Why? - to exclude the real extremes that are clearly and absolute errors, but at the same time giving the freedom for later constraint to practical and usable levels in, preferably and most likely, a template, but also possibly in a specialisation. It is universally acceptable that a systolic blood pressure will not exceed 1000mmHg but there is debate at what is the most reasonable figure, so at design we went for a number that was easy and unlikely to be exceeded - 10 too low, 100 too low, 1000 will work! Could have picked 500 - very unlikely to get a BP over 500, but could never say it was impossible to record - this is a grey zone, so to be universally acceptable, and interoperable, we avoided it. An archetype should be designed for stability and longevity - so it is able to withstand all uses that can be imagined. It will never be possible to imagine all, and so there is the potential to revise archetypes, but it is desirable to keep the revision process to a minimum. Hence the need to consult widely at the time of designing an archetype - across specialties, organisations etc etc to try to gauge all needs. This is a critical component of good archetype design when interoperability is the goal. STABLE archetypes should be the result and that stability is needed to support implementation. Good initial design will minimise impact downstream from having to revise archetypes in systems. The constraints have to be considered as part of this process. Specialisations are used to resolve issues related to the archetyping of overlapping concepts with slightly different information requirements. The reference model allows for new data points to be added in a specialisation (the most common use), and to a lesser degree, permits further constraint on existing data points and for optional data points to be dropped. An example is inspection cluster, specialised to inspection-skin, and further specialised to inspection-skin-rash or inspection-skin-wound - where additional data points have been added to capture the depth and breadth of the more specific aspects of inspection. Note that all still have the original (most unconstrained and generic) inspection archetype in common - and this is important to facilitate effective archetype-enabled querying. Specialisation of an archetype should still hold true to the rule of keeping the archetype as unconstrained as is possible so as to ensure interoperability. Templates are use-case, region-, provider- or enterprise-specific. They comprise multiple archetypes. The beauty of templates is that they are FLEXIBLE - it is a key feature. Combine the stable archetypes in ways that achieve various purposes. Constrain the stable archetypes down to make them more practical and useable for the local clinicians, including making optional data points mandatory and binding data points to terminology subsets appropriate for that given clinical setting. My 20c (more words than a 2c commentJ) Heather From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: Friday, 19 October 2007 2:26 PM To: For openEHR technical discussions Subject: Re: Multiple parents and max number of nested specialized archetypes? On 10/19/07, Andrew Patterson andrewpatto at gmail.com wrote: Templates are the main means of constraint on archetypes - Specialisations are mainly about adding attributes. Sam, surely those
Multiple parents and max number of nested specialized archetypes?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071019/5ef1c143/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071019/5ef1c143/attachment.png
Multiple parents and max number of nested specialized archetypes?
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.. Andrew
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). On 10/17/07, Koray Atalag atalagk at yahoo.com wrote: 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. Does the reasoning in the paper... http://www.openehr.org/publications/archetypes/templates_and_archetypes_heard_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. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579
Multiple parents and max number of nested specialized archetypes?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071018/3535f029/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanC_small.png Type: image/png Size: 4972 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071018/3535f029/attachment.png
Multiple parents and max number of nested specialized archetypes?
Hi, 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 -Original Message- From: Erik Sundvall [mailto:erisu at 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). On 10/17/07, Koray Atalag atalagk at yahoo.com wrote: 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. Does the reasoning in the paper... http://www.openehr.org/publications/archetypes/templates_and_archetypes_ he 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. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Multiple parents and max number of nested specialized archetypes?
Koray Atalag wrote: 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' :D 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. - thomas
Multiple parents and max number of nested specialized archetypes?
Erik Sundvall wrote: Hi! 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 . - thomas
Multiple parents and max number of nested specialized archetypes?
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 -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at 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 archetypes? Hi, 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 -Original Message- From: Erik Sundvall [mailto:erisu at 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). On 10/17/07, Koray Atalag atalagk at yahoo.com wrote: 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. Does the reasoning in the paper... http://www.openehr.org/publications/archetypes/templates_and_archetypes_ he 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. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical __ NOD32 2599 (20071017) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Multiple parents and max number of nested specialized archetypes?
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? I would like to expand that to data quality assurance. How can one objectively and according to locally accepted standards establish that data is of good quality, i.e. (re)usable, or should be rejected/ ignored. IMHO this is one of the crucial points for a functional EHR. What's the use of a centralized system to store and retrieve semantically interoperable data if the data is of poor/unknown quality. It also has a legal aspect. When one uses data provided by a third party one also takes over/ shares responsibility from/with that third party if one willingly accept data of poor quality. My guess is that not many people want to do that. Cheers, Stef
Multiple parents and max number of nested specialized archetypes?
Hi Erik, Yes, clusters used in the way you describe can be queried upon just like any other class of archetype. It is one way to handle these issues, but still the 'purer' methodology for a Pap smear report, in this case, would be to aim for a maximal Pap report archetype and use the template to constrain it for specific purpose. Clusters are in use all through the NHS archetypes/templates. I have found them especially useful in examination-related archetypes for very simple and universal concepts eg dimension, inspection, etc. These clusters will pop up amongst a large range of archetypes. So you will be able to query for a width or length in whatever part of the EHR a dimension cluster is used. I guess that it could follow that it is possible to consider using the cluster as the common 'child' archetype within 2 distinct 'parent' entry archetypes to mimic multiple inheritance. But it is not recommended. The cluster class has limited functionality compared to entry classes - eg it is limited without event model etc - a cluster has just data and no state, events, protocol associated with it. These data elements would be necessary in a Pap report - I don't think you could get away with these being in each parent. After all you are already losing some of the commonality - the very thing that you are trying to use the cluster for - if you have to put the same event or state data back up into each 'parent' entry archetype. Hope this helps clarify rather than confuse. Heather -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 18 October 2007 1:00 PM To: For openEHR technical discussions Subject: Re: Multiple parents and max number of nested specialized archetypes? Hi! I know that it is technically possible. ;-) I was trying to ask if it was clinically possible to identify clusters etc in this specific case. Sorry for not being specific enough in the question. After I asked some good suggestions regarding template use have been posted as a good reminder that there is usually more than one solution. Thanks! // Erik Erik Sundvall wrote: 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. On 10/18/07, Thomas Beale thomas.beale at oceaninformatics.com wrote: 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 . ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical __ NOD32 2600 (20071018) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Multiple parents and max number of nested specialized archetypes?
On Oct 18, 2007, at 5:51 PM, Heather Leslie wrote: Hi Erik, Yes, clusters used in the way you describe can be queried upon just like any other class of archetype. It is one way to handle these issues, but still the 'purer' methodology for a Pap smear report, in this case, would be to aim for a maximal Pap report archetype and use the template to constrain it for specific purpose. I agree. Clusters are in use all through the NHS archetypes/templates. I have found them especially useful in examination-related archetypes for very simple and universal concepts eg dimension, inspection, etc. These clusters will pop up amongst a large range of archetypes. So you will be able to query for a width or length in whatever part of the EHR a dimension cluster is used. In other words there are 'atomic archetypes'. These 'atomic archetype's re-appear in normal archetypes to be finally constrained in Templates. The Template is the profiling tool to make things explicit in a defined healthcare context. I guess that it could follow that it is possible to consider using the cluster as the common 'child' archetype within 2 distinct 'parent' entry archetypes to mimic multiple inheritance. But it is not recommended. The cluster class has limited functionality compared to entry classes - eg it is limited without event model etc - a cluster has just data and no state, events, protocol associated with it. These data elements would be necessary in a Pap report - I don't think you could get away with these being in each parent. After all you are already losing some of the commonality - the very thing that you are trying to use the cluster for - if you have to put the same event or state data back up into each 'parent' entry archetype. Here I need some explanatory elaborations to make things very explicit. Hope this helps clarify rather than confuse. Heather -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Erik Sundvall Sent: Thursday, 18 October 2007 1:00 PM To: For openEHR technical discussions Subject: Re: Multiple parents and max number of nested specialized archetypes? Hi! I know that it is technically possible. ;-) I was trying to ask if it was clinically possible to identify clusters etc in this specific case. Sorry for not being specific enough in the question. After I asked some good suggestions regarding template use have been posted as a good reminder that there is usually more than one solution. Thanks! // Erik Erik Sundvall wrote: 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. On 10/18/07, Thomas Beale thomas.beale at oceaninformatics.com wrote: 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 . ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical __ NOD32 2600 (20071018) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071018/528f1fc7/attachment.html
Multiple parents and max number of nested specialized archetypes?
Dear Graham, 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 -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On Oct 16, 2007, at 11:44 PM, Grahame Grieve wrote: 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. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071017/d5d147e3/attachment.html
Multiple parents and max number of nested specialized archetypes?
Grahame Grieve wrote: 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. - thomas
Multiple parents and max number of nested specialized archetypes?
Hi Koray, 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. Regards Heather _ Dr Heather Leslie Director of Clinical Modeling Ocean Informatics M +61 418 966 670 (in Australia) M +44 7722 064 546 (in UK) Skype - heatherleslie -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Koray Atalag Sent: Tuesday, 16 October 2007 4:34 PM To: openehr-technical at openehr.org Subject: Multiple parents and max number of nested specialized archetypes? Hi, 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. Best regards, Koray Atalag, MD, Ph.D. Freelance consultant and developer http://koray.pathos-web.org skype: atalagk _ ___ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical __ NOD32 2594 (20071016) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com
Multiple parents and max number of nested specialized archetypes?
Andrew Patterson wrote: 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 ;-) - thomas beale
Multiple parents and max number of nested specialized archetypes?
Hi Koray, 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. - thomas beale Koray Atalag wrote: Hi, 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. Best regards, Koray Atalag, MD, Ph.D. Freelance consultant and developer http://koray.pathos-web.org skype: atalagk Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- please change your address book entry for me to Thomas.Beale at OceanInformatics.com *Thomas Beale* /Chief Technology Officer/ Ocean Informatics http://www.oceaninformatics.com/ Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * *
Multiple parents and max number of nested specialized archetypes?
Hi, 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. Best regards, Koray Atalag, MD, Ph.D. Freelance consultant and developer http://koray.pathos-web.org skype: atalagk Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
