openEHR ENTRY Types FAQs

What are 'Entries'?

In the openEHR Reference Model, as well as in models like CEN EN13606-1 and HL7 CDA, the 'Entry' type in the model corresponds to a 'clinical statement'. Entries hold the 'hard data' of the EHR Composition or document. Entries may contain only a single (often coded) datum, such as a diagnosis, or more usually, they contain a number of data points in a defined structure, e.g. Apgar result, Barthel index, ante-natal visit. In openEHR the Entry has been specialised into 5 types in the EHR and one generic entry for mapping in future to CEN 13606 structures should these become widely used.

What Entry types are there in openEHR?

The openEHR Reference Model defines 6 kinds of Entry. Five of these are found in the openEHR EHR Information Model, and are illustrated below.

Detailed UML

OBSERVATION - for recording information from the patient's world - anything measured by a clinician, a laboratory or by them, or reported by the patient as a symptom, event or concern
EVALUATION - for recording opinions and summary statements (usually clinical), such as problems, diagnoses, risk assessments, goals etc that are generally based on Observation evidence
INSTRUCTION - for recording orders, prescriptions, directives and any other requested interventions
ACTION - for recording actions, which may be due to Instructions, e.g. drug administrations, procedures etc.
ADMIN_ENTRY - for recording administrative events, e.g. admission, discharge, consent etc

The 6th type is called GENERIC_ENTRY, and is designed for mapping into and out of legacy and integration structures such as CEN EN13606, HL7 CDA, message and relational databases. The UML model of this type is here; it is documented in the openEHR Integration IM. All of these types are extremely generic and archetypes are used to define the specific business/domain content models under each of these types - see archetype mindmap for examples.

Why not just have one Entry type?

The types of information generated in the clinical process are qualitatively different; they have different relationships to time, to actors, and consequently have different structures. There have been various models of these over the years, from Lawrence Weed's POMR "SOAP" headings to more recent models such as the Danish G-EPJ. The openEHR model uses a similar set to some of these models. The exact types used in openEHR are based on an analysis of the process that creates health information. The following diagram illustrates the process metaphor and a more formal definition of the information categories it generates.

observation: information created by an act of observation, measurement, questioning, or testing of the patient or related substance (tissue, urine etc), including by the patient himself (e.g. taking own blood glucose measurement), in short, the entire stream of information captured by the investigator, used to characterise the patient system;
opinion: thoughts of the investigator about what the observations mean, and what to do about them, created during the evaluation activity, including all diagnoses, assessments, speculative plans, goals;
instruction: opinion-based instructions sufficiently detailed so as to be directly executable by investigator agents (people or machines), in order to effect a desired intervention (including obtaining a sample for further investigation, as in a biopsy);
action: a record of intervention actions that have occurred, due to instructions or otherwise;
administrative event: a record of a business event occurring within the administrative context, such as admission, booking, referral, discharge etc.

The various Entry types have differing structural models due to the fact that they record qualitatively different things. See the EHR Information Model and UML for details.

Are there different basic patterns of information?

When clinical modellers are building content models of common things they record, the various Entry types provide help. For example, the Observation type includes a 'History of Events' structure for its data, enabling the time of any observation to be recorded in a standard way. If there are no available Entry types, clinical content is likely to be built in an ad hoc, non-interoperable way, and it is also significantly more arduous. For example, if we try to create an archetype for the concept of 'apgar recording', it is quite easy using the openEHR Observation type because the History structure provides exactly what is needed to represent the samples in time. A further refinement is a clear separation of the data, state and protocol, i.e. the primary values being measured (BP for example), the patient state (exertion, position) and the method of measurement (instrument etc).

Two people independently modelling the same content, such as 'BP measurement' using archetype tools based on the above model of Observation are almost guaranteed to model the timing and separation of values, patient state and methd in the same way, since it is provided in the reference model. Similar considerations apply to recordings of typical things like orthostatic blood pressure (requiring 2 samples), time-based data coming from vital signs monitors and so on. An archetype model of glucose tolerance test is interesting - it needs both a time base (3 samples) and the 'state' attribute on Events to indicate the patient state at each point - after 8 hour fast, after 75mg glucose challenge etc. Without any of this basic support in the reference model, the archetype author, as well as software developers are forced to come up with solutions to the basic patterns of history-of-events and the data/state/protocol pattern. These patterns are so ubiquitous in medicine and science in general that they have been included in the openEHR reference model.

Other universal patterns occur in the Instruction and Action types, enabling the standardised recording of various dates, times, participations and changes of state of Instructions.

How does information 'status' relate to openEHR Entries?

Another issue well known in the recording of information in health systems is that of 'status' of information: is it the actual value X, a negation of X, a risk of X, no/low risk of X, family history of X, fear of X, recommendation to do P, past procedure P, scheduled to have P...? Undifferentiated statements recorded using index terms (often coded) e.g. 'cancer' etc risk confusing automatic processing, such as by query engines, decision support and NLP modules (commonly used on narrative data). We can go a long way toward solving the possible confusion by seeing that all of these statement have sensible mappings into the Entry types used in openEHR (and other similar models for that matter, e.g. the Danish G-EPJ).

Some examples of disease/condition recordings:

Phenomenon	Entry type
measured/observed actual value of X	Observation of X
no/not X	Observation of excluded P or types of X, e.g. allergies
family history of X	Evaluation that patient is at risk of X
no family history of X	Evaluation that X is an excluded risk
risk of X	Evaluation that patient is at risk of X
no risk of X	Evaluation that patient is not at risk of X
fear of X	Observation of Fear, with X mentioned in the description

Examples of intervention-related recordings:

Intervention	Entry type
P distant past/unmanaged/passively documented	Observation of P present in patient
P recent past	Action of P having been done to/for patient
P proposed	Evaluation, subtype Proposal of P suggested/likely for patient
P ordered	Instruction of P for patient for some particular date in the future.

The use of the openEHR Entry types significantly reduces the risk that in querying 'family history of X' can be mistaken for X being observed in the patient, since the former is an Evaluation, while the latter is an Observation. Family history of X and diagnosis of X are both Evaluations, but distinguished by archetype (family history, diagnosis). Similarly, a past hip replacement cannot be confused with a proposed or booked one, since both the Entry types and archetypes will be different. Querying for clinical opinions is easy: it will be Evaluations only, or a subset, determined by archetype.

How are Observations and Evaluations different in openEHR?

In the openEHR Entry model, two types are used for 'observations' and 'evaluations'. As with any general terms, these terms are overloaded, causing confusion for some people. In the openEHR model, these two types have a clear purpose. The Observation type is used to record any information derived from the world outside the clinician's head (or any other clinical reasoning device) - i.e. any kind of phenomemon or state of interest to the clinical investigator in the care of the patient. Accordingly, the design of the Observation type defines its data as a History-of-events structure, since all phenomena observed in the external world are situated in time, and in many cases, there are multiple samples to be recorded. In theory, such information should be repeatably observable using the same protocol and assuming a sufficient level of skill or training on the part of the observer. In contrast, the Evaluation type is used for recording clinical thinking rather than events from the outside world. Consequently, it does not oblige a historical timing structure. This is not to say that 'time' is irrelevant to clinical thinking. Indeed, many typical clinical assessments include all manner of times, as shown by this diagnosis archetype. However, the times in such evaluations are not the primary recording instance of phenomenon or event time of events that may be referred to in the Evaluation, but instead are summarised times, dependent on the kind of assessment being recorded. It may be that no event time is recorded in an Evaluation, such as for the goal archetype, where the only time indicated is future proposed date of achievement.
Thus the Observation type provides the structures for recording phenomena, including statements the patient may make, anything measured or sensed by the clinician, or via using a machine. The history structure provides a standardised way to include the event origin time, and offsets of each event in the series, if it is more than one. In addition, it provides 'state' and 'protocol' (the latter inherited from CARE_ENTRY) which allow the state of the patient (e.g. position, exertion level) and the method (e.g. pulse oximeter) to be recorded alongside the primary data (e.g. heartrate). The history structure of a typical observation is illustrated to the right.		137-OE.html?branch=1&language=1