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 attributes are available by virtue of the fact that the parent archetype says nothing about them. Something in an archetype can never 'add' an attribute. All archetypes can do is constrain. And the specialised archetype can never remove a constraint of the parent surely? For example, an observation archetype that says nothing about the 'State' attribute imposes no constraints on that attribute. A specialisation of the archetype could impose extra constraints on 'State', but can't add the attribute in. I mean, there is either a 'state' attribute there in the RM or not - the archetype can't add attributes. Of course this all leads to a much more interesting theoretical question - aside from the immediate syntactic differences, what exactly is the difference between a template and a specialisation? Andrew, this is indeed a very interesting question. It seems to me that all the constraints done in templates can be done with archetypes. The 'artificial' divide between templates and archetypes are probably to do with their different intended uses. Archetypes are semantically coherent and are supposed to be shared between systems. Templates are, on the other hand, created to meet local specific requirements, therefore not supposed to be shared across sites. But the line of distinct seems to be blurred. How local is a local requirement and thus justify the use of a template? Can one start with a template for local use, and later convert the template into an archetype for shared use? Also if all constraints can be expressed using the AOM semantics (which is already very generic and powerful), we perhaps could re-use the same object model to represent template constraints, which would facilitate the conversion between archetypes and templates. Cheers, Rong Andrew _______________________________________________ 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/20071019/741a1444/attachment.html>
