A couple more questions (by the way Leslies description was awesome and makes total sense).
Interfaces a) When creating a generic outbound or inbound interface with an extrernal system - do you build based upon the archetypes only - i.e. provide as many values possible? or your specializations? or is this all mute and we stick with HL7? Templates, as a collection for a use case. I looked out in Subversion but only see one out there: http://svn.openehr.org/knowledge/templates/dev/html/ b) Do templates or specializations or archetypes define workflow e.g. record results, based upon results collect additional information or not?' In the case were a doc just wants to replicate a paper form but not improve it would I build a template or stick with Archetypes? So implementing a form like this: http://home.cogeco.ca/~epiphany/FPDoctor-Perfect-Progress-Note-2.0.pdf thanks! Greg Caulton Boston, MA http://www.patientos.org On 10/19/07, Heather Leslie <heather.leslie at oceaninformatics.com> wrote: > > > > 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-bounces at 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 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
