An archetype or a template?

By Heather Leslie
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?

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. 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 (of archetypes) 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 the '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 (for example all inspections of skin). 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.

A Template?

Templates are use-case, region-, provider- or enterprise-specific. They almost always 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 usable for the local clinicians, including making optional data points mandatory and binding data points to terminology subsets appropriate for that given clinical setting.