Introduction to Archetypes and Archetype classes

The Concise Oxford Dictionary defines an archetype as "an original model, prototype or typical specimen". In openEHR, an archetype is the model (or pattern) for the capture of clinical information - a machine readable specification of how to store patient data using the openEHR Reference Model.

Archetypes are the keystone of the openEHR architecture, allowing clinician and domain expert involvement in the design and collaboration of standardised clinical content specifications for electronic health records.

Each archetype is a computable definition, or specification, for a single, discrete clinical concept. It is inclusive of all data elements that make clinical sense about that concept and designed for all imaginable clinical situations. The definition is kept broad and constraints minimal in order to maximise interoperability by being able to share and re-use the archetype across many types of healthcare and the broadest range of clinical scenarios. The specification is expressed in Archetype Definition Language (ADL), which is an ISO standard, but able to be viewed and reviewed in 'clinician-friendly' formats, as structured definitions and mind maps. By design, they provide structure and specify content which means that archetypes can be both clinically meaningful AND interpretable by EHR systems. Archetyped data will have the same meaning no matter what context it is used within the EHR and, similarly, no matter which EHR system it is used or what language is used.

Archetypes should ideally be designed for stability and longevity – so the computable definition is able to withstand all types of use that can be imagined. However, it will never be possible to determine all use cases, and so while there is the potential to revise archetypes it is desirable to keep the revision process to a minimum. Hence the need to engage broadly with a wide range of domain experts - especially clinicians and any individuals or organisations who might potentially use the data for secondary purpose - at the time of reviewing and agreeing that an archetype is ready for use and publication to be inclusive of all requirements. This is a critical component of good archetype design when interoperability is the goal. The resulting stable pool of published archetypes will support health information and standardised implementation within systems.

There are 4 main categories of archetypes, each defined as part of the openEHR Reference Model. It is important to understand the differences between these classes, as each of these classes of archetype are used for different parts of the clinical recording and workflow processes. Each has specific attributes that support the recording and re-use of clinical information.

Archetype Classes

COMPOSITION Class

A COMPOSITION is a container class in the openEHR reference model and it is the unit of committal to the EHR. That is to say, all information stored within the EHR will be contained within a Composition.

Compositions correspond to commonly used clinical documents or events and typical examples include a Discharge Summary, Antenatal visit, Operative Notes or Prescription. Think of them as the equivalent of a blank piece of paper in a paper record (or computer screen) conveying some high level contextual information and into which the detailed clinical information will be added.

Compositions can contain SECTIONs - or organising classes, which themselves contain the clinical content details in ENTRY archetypes.

SECTION Class

A SECTION is an organising class, usually contained within a COMPOSITION. Sections correspond to the headings that you might find on a blank piece of paper. There is not usually any semantic meaning carried in these Section archetypes, but are most commonly used to provide a framework in which to place the smaller Entry and Cluster class archetypes which hold most of the detailed clinical content..
Examples of Sections are:

SOAP(E) organisation of the EHR
Physical examination - organised by System
History - organised by presenting complaint, social history, review of systems etc
Vital Signs

In summary, if you are attempting to standardise the organisation of information within a document, progress note or any other Composition, then you probably need to create a SECTION archetype.

ENTRY Class

An ENTRY is a standalone 'semantic unit' of information. If you are trying to represent information that can be grouped together usefully and re-used in many different settings - then you are probably want to use an Entry. The information within an Entry will mean the same thing no matter where it is used - this is a fundamental design feature of the openEHR architecture.
Examples of Entries are:

Blood pressure - systemic arterial blood pressure
Intravascular pressure - pressure at a point within the vascular system
Weight - the weight of the whole body
ECG measurement
Pulse
Medication order
Diagnosis

In the openEHR reference model a 'composition' or document contains one or more organising 'sections' - which themselves contain 'entries'. The ENTRY class of the openEHR reference model contains the information - the blood pressure, the assessment, the diagnosis, the medication order. Importantly, 'entries' can be interpreted independent of the composition or the section within which they are located - this is a key principle of the openEHR methodology and is very important for automatic processing of EHR data.
ENTRY, which is an abstract type (and does not exist in openEHR compatible data) has 4 concrete subtypes:

1. OBSERVATION

Observations are the 'uninterpreted' or raw information - ie the clinical observations or 'the evidence' - which includes anything reported by the patient as a symptom, event or concern; examination findings; and measurements/test results.
Thus an OBSERVATION is used when the information is derived from a direct observation, measurement, or experience of the patient or data subject.

Features of data that should be recorded using the observation class are:

Data may be repeatedly collected and/or recorded over a period of time, including within one composition.
The concept of an interval measurement is sensible - that is to say a maximum, minimum, or at least a modal value makes sense.

All Observation classes contain:

a DATA part which contains the core information e.g. the systolic and diastolic pressures when measuring a blood pressure.
a STATE part which contains information about the subject of data at the time the information was collected, and this information is required for safe clinical interpretation of the core information. An example is the position of the patient at the time of measuring a blood pressure.
a PROTOCOL part which contains information on how the information was gathered or measured, and any other information that is not required for safe clinical interpretation of the core information. By default, this information will not be displayed in the primary view of the EHR.
a HISTORY part which contains information about the timing of the observation and the 'width' of the information.

Examples of observations are:

Blood pressure
ECG
Weight
Height
Story
Laboratory Result

2. EVALUATION

Evaluations are used to capture and record clinically interpreted findings, opinions and summary statements. They are 'meta-observations' - ideas, labels or views which arise within the clinician's mind, which involve interpretation of observations and formulation into a new form. These data do not require a time model, and there is no valid concept of average, maximum or modal values of this concept when considering an individual data subject.
An EVALUATION is used when the information the data has the following characteristics:

The key data relates to information generated by the clinician
The key data is based on other information which has been directly observed or measured
The key data is usually based on some sort of clinical extrapolation or assessment
It is not sensible to have a time series of such data
It is not logical to have an interval measurement of such data
The concept of a 'modal value' makes little or no sense in relation to a single patient or data subject, particularly within a single composition

Examples of evaluations are:

Risk Assessment
Problem/Diagnosis
Goal
Adverse reaction

As EVALUATIONs have no history model (see observation), all dates and times must be expressed within the archetype. Hence, a diagnosis archetype will have 'date of onset', 'date of resolution' etc as specific data points in the evaluation archetype.

3. INSTRUCTIONS & 4. ACTIONS

Instructions are statements about what should happen in the future - such as clinical orders for care or the initiation of a workflow process, such as a medication order.

Actions are statements about what was actually done - they record clinical activities e.g. administration of the medication in the above Instruction.

Commonly, Instructions and Actions are designed so that Actions complement the Instruction and Actions can record the ensuing state of the Instruction, such as 'scheduled', 'completed', or 'cancelled'. When an Action corresponds to a known Instruction, they can provide anindication of the current status of the Instruction. It is not always necessary to have an instruction preceding an Action, nor having an Action to follow an Instruction.

CLUSTER Class

CLUSTERS are reusable archetypes for use within any ENTRY or other CLUSTER, and are particularly of value where recursiveness is important. They tend to represent common and fundamental domain patterns that are required in many archetypes and clinical scenarios - for example size, symptom, inspection and relative location. In recording clinical examination and history details, they are useful in capturing those ubiquitous 'first principles' of examination and history, and it could be said that they are best sourced from a first year clinical student's textbook eg a checklist for a thorough inspection would consist of size, shape, location, texture, edge, temperature, surface, surrounds, etc etc - a re-usable component for capturing inspection detail in many, if not most, clinical examination scenarios.

As an example, consider a Medical History OBSERVATION archetype which can contain a Symptom CLUSTER (eg to capture data about a presenting complaint of Headache). This Symptom CLUSTER can, in turn, contain further symptom clusters to capture Headache-associated symptom details (eg vomiting or photophobia).

CLUSTERS have no inherent event/timing, protocol or state attributes - these come from the ENTRY archetype that contains the given cluster, where appropriate.

Specialisation

An existing archetype can be refined in order to meet special or specific clinical requirements e.g. the 'weight' archetype has been specialised to create a 'birth weight' archetype. The Specialised archetype inherits all the features of the pre-existing archetype plus can have new elements added, or can narrow down the pre-existing constraints to suit the specialised purpose.
The advantage of specialisation of an archetype is that data based on the specialised archetype may be returned in a query based on the parent archetype. Examples of this are:

diagnosis is a specialisation of problem, so all diagnoses will be returned when seeking all the problems from which a person is or has suffered
as the birth weight is a specialisation of weight, so all birth weights will be returned in a query seeking all recorded weights. The converse is not true i.e. a search for all birth weights will not find all weights.