A simple overview follows... For more detailed information refer to the Health Information Models index on the openEHR wiki.
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 a keystone of the openEHR architecture. Each archetype describes a complete clinical knowledge concept such as 'diagnosis' or 'test result'. 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.
A COMPOSITION is a container class in the openEHR reference model - it is the unit of committal to the EHR. That is to say, all information within the EHR is contained within a Composition. Any Composition, once committed, is retained as part of the EHR - if it is edited or changed in any way then the changes are committed as a new version of the Composition. Further, all information transferred from one EHR to another is transferred as Compositions.
Compositions contain SECTIONs - or organising classes, which themselves contain ENTRYs.
A SECTION is an organising class, contained within a COMPOSITION. Archetypes of Sections standardise the organisation of information within a Composition.
Examples of Sections are:
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.
An ENTRY is the '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:
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:
Observations are the 'uninterpreted' or raw information - the clinical observations. These may be reported by the patient, found by a clinician or by an instrument.
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 measurements, reports of symptoms, and examination findings will be stored in as an Observation.
All Observation classes contain:
Examples of observations are:
Evaluations 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:
Examples of evaluations are:
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.
4. ACTIONS
Instructions are statements about what should happen in the future - they record 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.
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'. It is not always necessary to have an instruction preceding an Action, nor having an Action to follow an Instruction.
CLUSTERS have been part of recent archetype design evolution, particularly because experience in modelling history and examination archetypes indicated the need for an additional level of flexibility to capture clinical data well.
CLUSTERS are reusable archetypes for use in any ENTRY, and are particularly of value where recursiveness is important. 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.
CLUSTERS 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.
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: