Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

What is an archetype?

An archetype is a re-usable, formal definition of domain level information. The formal concept was originally described in detail in a paper by Thomas Beale. The key feature of the archetype approach to computing is a complete separation of information models (such as object models of software, models of database schemas) from domain models. Thus, archetypes are not part of the software or database of a system. Archetypes can be specialised, and also aggregated, via 'slots', enabling fine-grained re-use. A short document on archetype principles is here. Technical specifications: ADL 1.4; ADL 1.5 draft.

Archetypes have a number of key purposes:

  • they allow domain experts such as clinicians to create the definitions which will define the data structuring in their information systems
  • they provide runtime validation of data input via GUI or any batch process
  • they provide a basis for intelligent querying of data.

In health, information, or 'content' that can be modelled using archetypes includes things like:

  • Observations: weight measurement, blood pressure, microbiology results
  • Reports: discharge referral
  • Orders: prescription
  • Assessments: diagnosis

and many others. From the user's point of view, these are the kinds of data which occur in health information systems. Each archetype is a text file, expressed in either ADL syntax or its XML derivative.

What about existing data?

There are two kinds of archetypes the community needs:

  • 'designed' archetypes, which clinicians design from scratch. There are many examples in Australia, and a growing library in Europe. These kind of archetypes are based on what we have called the  "Domain Base Concept Model" (presentation about this\). This sounds complicated, but in fact it just means "the UML model of invariant concepts in the domain, on which archetypes can be safely based". Currently this is the openEHR Reference Model, since it is the openEHR community doing most of this work at the moment. But in the future, we hope that this model will be adopted by others for this purpose, possibly with some additions, simplifications and so on. For example, the Danish Board of Health might want to propose some G-EPJ concepts should go in there. But note: this model is not meant to be large at all; our experience is that the openEHR model of Observation and Evaluation is about right for all archetypes so far developed as observations and diagnoses etc. We are redeveloping the Instruction Entry subtype in openEHR, which will provide a very powerful basis for archetypes for medication, interventions, orders etc.
  • 'legacy' archetypes. These are archetypes which are designed to mimic legacy data, which itself does not follow any ontologica design - typically is is flat, or else tree-like. This could be data from a hospital database, HL7v2 messages etc. The GENERIC_ENTRY type was added to the openEHR Reference Model to provide a basis for legacy archetypes (technical specification of GENERIC_ENTRY type).

Data processing in an openEHR-enabled context can now be done as follows:

  • export or convert data from original source, e.g. RDBMS, HL7v2 messages to an intermediate XML or comma-separated value format
  • import this data into an openEHR system, as instances of GENERIC_ENTRY, according to archetypes based on 13606
  • convert the data to a form based on desired archetypes, and openEHR ENTRY subtypes, i.e. OBSERVATION, ACTION, EVALUATION, INSTRUCTION. This conversion can be done based on the use of "archetype interfaces", i.e. definitions of the interfaces of archetypes, regardless of their internal structures.

Data can also be easily accepted into such a system in the form of EN13606  Extracts, and output in the form of EN13606 Extracts. A simple presentation\ shows this graphically.

Do archetypes replace terminology?

No. Archetypes are designed to provide systematic interface with terminologies. They are, in themselves, terminology-neutral, because there is no (and probably will never be) single terminology or ontology which describes the whole of medicine in the myriad points of view needed in clinical information systems. For a discussion of the problems with terminology, see the ADL specification (section: The Problem of Terminology). ADL is designed to have bindings to terminologies, and any given archetype can include bindings to more than one. A binding is the set of mappings from archetype local term and constraint codes to terminology codes and query expressions respectively. See this archetype for an example (scroll to the ontology section).

What is the difference between archetypes and ontologies?

An easy way to think about archetypes and ontologies is based on understanding what they say. Archetypes model information, while ontologies model reality. For example an archetype for "systemic arterial blood pressure measurement" is a model of what information should be captured for this kind of measurement - usually systolic and diastolic pressure, plus (optionally) patient state (position, exertion level) and instrument or other protocol information. In contrast, an ontology would describe in more or less detail what blood pressure is. This archetype tutorial (PPT) provides a detailed example on slide 12.

If in your philosophical view of the world, "information" is part of "reality" (and this is the strictly correct way to understand the world), then archetypes themselves constitute an ontology, whose subject matter happens to be information. Other "ontologies", as one tends to use the word today, have as their subject matter "reality" (other than information).

See the openEHR Wiki ontology page for more on ontologies and openEHR.

What is ADL?

Archetype Definition Language, or ADL, is a formal language for expressing archetypes, and can be categorised as a knowledge description language. It provides a formal, abstract syntax for describing constraints on any domain entity whose data is described by an information model (e.g. expressed in UML/OCL). The syntax is congruent with Frame Logic (PDF of original paper by Michael Kifer) queries. It is primarily useful when very generic information models are used for representing all data in a system, for example, where the logical concepts Patient, Doctor and Hospital might all be represented using the class Party, Address, and related generic classes. Archetypes are then used to constrain the valid structures of instances of these generic classes to represent the desired domain concepts. In this way future-proof information systems can be built - relatively simple information models and database schemas can be defined, and archetypes supply the specific modelling, completely outside the software.

The official specification of ADL 1.4 is available here (640k PDF).

How can I see what ADL archetypes already exist?

The openEHR Clinical Knowledge Manager (CKM)\ contains the archetypes managed internationally at openEHR.org. Other archetypes may be managed within your organisation.

Is ADL a Standard?

ADL and the AOM are open specifications of openEHR. They have been adopted by CEN TC/251, the European standards agency Health Telematics Committee for use in its revised EN 13606 Electronic Health Record standard. They are now in the process of being standardised by ISO.

What about governance? (Multiple authors, versions, replication...)

It is important to understand the big picture of archetypes and templates. For archetypes to really work, there does need to be some large scale organisation, in order to allow sharing and quality control. The following is one model of how archetypes should be used "in-the-large":

  1. identify the need: e.g. "we need an archetype to describe the care plan in a discharge summary"
  2. determine if there are already archetypes for this purpose: logon to an archetype library and interrogate it. Study the archetypes which already exist and determine if they can be used, or else specialised for your purpose
  3. if you need to build a new archetype, you will most likely have professional colleagues (perhaps international) with whom you should discuss the problem and consider the design
  4. to actually create an archetype will require an editor; archetypes will be saved in an interoperable format, e.g. ADL
  5. when a draft archetype has reached a point where you want to share it, you will upload it to the archetype library
  6. changes to the archetype will occur with version control and audit trailing, just like in document authoring systems
  7. at some point, your organisation will propose the archetype to a body capable of doing certification - i.e. quality assurance
  8. archetypes certified for use can be injected into an online network of archetype servers, making them available to archetype-enabled systems
  9. systems using archetypes, such as EHRs will retrieve the archetypes they need from a local archetype server, and may well convert them to a locally efficient form
  10. at runtime, locally defined templates will cause archetypes to be invoked and put into action, performing their main job, i.e. data structuring and validation.

As can be seen, it is not simply a matter of editing an archetype and putting it into your hospital information system! A draft document describing some features of an "archetype system" with the above features is available here\.

How do I develop a new archetype?

How do I develop Software which Processes Archetypes?

The Archetype Object Model\ provides a standardised object model of archetypes which can be used as the basis of software. Most likely you will want to capitalise on the work already done in various languages. See the implementation project pages (home page\, then "projects" button).

Who else has used an archetype-like approach'?

Who is using the openEHR 'archetype' approach'?

How do archetypes relate to HL7 v3?

HL7has a special interest group (SIG) for templates, which is the HL7 word for archetype (approximately). Currently HL7 does not differentiate between the notions of archetype and template as defined in openEHR. HL7's main need appears to be for a templating method for RIM-based objects; apparently it will use something called MIF, an HL7-specific formalism designed to represent HL7 models.

In fact, ADL archetypes can be written against any UML model, and it would be possible to write archetypes directly against the HL7v3 RIM (Reference Information Model), and also the CDA specification (using a UML expression derived from its XML-schema). Thisis the HL7v3 Lab Obs RMIM from ballot 5 as an ADL archetype (raw ADL form here). HL7 has chosen not to follow this path.

How do archetypes relate to CEN EN 13606?

CEN TC/251 has adopted the openEHR archetype model and ADL as the means of expressing archetypes to be used in conjunction with EHR data sent as CEN EN13606 (revised) EHR Extracts; these specifications are snapshotted in the revised EN13606 part 2. Archetypes created directly based on the EN13606 part 1 model fall into the category of legacy archetypes as defined above.

  • No labels