What is an archetype?

An archetype is a re-usable, formal definition of domain level information, defined in terms of constraints on an information model. 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. Archetype design principles and technical specifications.

Archetypes have a number of functions:

they allow domain experts such as clinicians to create a library of data element and group definitions for the data in their information systems
they provide runtime validation of data input via GUI or any batch process
they provide a basis for semantic querying of data.

In health, information, or 'content' that can be modelled using archetypes on 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.

(The formal archetype concept was originally described in detail in a paper published online by Thomas Beale, as well as a 2002 OOPSLA paper, providing a more succinct description. These are a bit out of date now, since it doesn't adequately distinguish between archetypes and templates, but still useful background. For modern descriptions, see the specifications).

What don't archetypes do (that Templates can)?

Archetypes don't define data sets. A data set is defined by a template in openEHR, which is a special kind of archetype that aggregates bits and pieces of other archetypes to form a set of data specific to a particular use, e.g. a screen form or message definition. Data sets almost always contain data points and groups from numerous archetypes.

The above form has been templated from archetypes: each red area contains some specific (usually only a minority of) data elements from one archetype.

Templates primer.

How do Archetypes and Templates work together?

Here is a picture that shows a template constructed from elements of archetypes, to define a specific data set, which is then used to generate various useful downstream artefacts.

What about existing data?

There are two kinds of archetypes the community needs:

'designed' archetypes, which clinicians design from scratch, including the archetypes in the openEHR Clinical Knowledge Manager (CKM).
'legacy' archetypes. These are archetypes which are designed to mimic legacy data, which itself does not follow any ontological 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 import in an openEHR system can now be done as follows:

design an openEHR template that mimics the structure of the data being imported, e.g. HL7v2 message, legacy XML message etc;
generate a 'Template Data Schema' (TDS) with the Template Designer tool;
export data from original source, e.g. RDBMS, HL7v2 messages as TDDs, i.e. XML conforming to the TDS;
import this data into an openEHR system, using a TDD => canonical openEHR converter (currently provided by openEHR vendors, but being standardised).

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. ADL is designed instead 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 the CKM 'Problem' archetype for an example.

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 describe (aspects of) 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 and AOM?

Archetype Definition Language, or ADL, is the formal language for expressing archetypes. 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). 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 'AOM', or Archetype Object Model, is a sibling specification to ADL, defining the object structures and semantics of a parsed archetype. It is primarily used by tool builders.

The openEHR ADL/AOM 1.4 and 2 specifications.

(For math/logic geeks: ADL syntax is congruent with Michael Kifer's Frame Logic 'queries').

Is ADL a Standard?

ADL and the AOM are open specifications of openEHR. The 1.4 AOM release was adopted as ISO standard ISO 13606-2.

Is there a Reference Validator or Compiler for Archetypes?

Yes - the ADL Workbench tool, or 'AWB'. See here for help and download.

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 at a national level within your country or some other organisation.

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":

identify the need: e.g. "we need an archetype to describe the care plan in a discharge summary"
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
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
to actually create an archetype will require an editor; archetypes will be saved in an interoperable format, e.g. ADL
when a draft archetype has reached a point where you want to share it, you will upload it to the archetype library
changes to the archetype will occur with version control and audit trailing, just like in document authoring systems
at some point, your organisation will propose the archetype to a body capable of doing certification - i.e. quality assurance
archetypes certified for use can be injected into an online network of archetype servers, making them available to archetype-enabled systems
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
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. The wiki page on Development and Governance of Knowledge Artefacts gives more details.

How do I develop a new archetype?

You can download various archetype-authoring tools to build one.

But if you are serious, you are probably a clinical professional, and will want to discuss requirements and ideas first with others, which you can do on the openEHR clinical mailing list, and also with others registered on the openEHR CKM.

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 openEHR technical mailing list.

Who is using the openEHR 'archetype' approach'?

Most of the countries, companies, academic institutions and other projects you see here.

How do archetypes relate to CEN EN 13606?

CEN TC/251 has adopted the openEHR Archetype Object Model 1.4 and ADL 1.4 as the means of expressing archetypes to be used in conjunction with EHR data sent as CEN EN13606 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.

The openEHR ADL 1.5 and AOM 1.5 specifications, currently in late draft, will supersede the 1.4 specifications used by CEN and ISO 13606.