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.

Some basic Entry examples

Below are various examples of Observations and Evaluations. Experience has shown that it is easy to tell the difference for most types of information, but that there is a grey zone in the middle of recordings that might be of either type. We deal with the more obvious ones first.

Clinical Statement	Entry type	Example archetype	Comments
simple measurement	Observation	Body mass index Dimensions	The simplest 'point' measurements are still situated in time: there is always at least one 'event' or time-point. The openEHR model guarantees that the event-time information in single-point measurements is the same as for mult-sample measurements.
time-series measurement	Observation	Blood pressure measurement Apgar score Body Temperature Glucose Tolerance test	Many phenomena have the potential form of a series of samples in time
difference over time	Observation	Body weight	The History part of the model accommodates changes over time.
maxima, minima, rolling averages etc	Observation	Body Temperature	The 'math function' attribute in the INTERVAL_EVENT class accommodates all kinds of time-based averages and finite duration states.
diagnosis	Evaluation	problem-diagnosis	Times of some events may be mentioned, but the structure of the Entry is not the time-history of an observed phenomenon, but a report or summary, often of several phenomena, supporting a conclusion, which is the point of the Entry.
adverse reaction	Evaluation	Adverse reaction	Adverse reaction assessment is an assessment of condition or propensity of the patient to react to particular substances.

Grey-zone examples

Some of the examples below have confused people. One reason for confusion is that a single health event may lead to a recording of an instance of the phenomenon, and a diagnosis of a condition - in other words, 2 Entries.

Clinical Statement	Entry type	Example archetype	Comments
Physician: "I hear mitral regurgitation"	Observation	Auscultation	There will be an observation since it is a real-world phenomenon that has been observed e.g. by listening. There seems to be an element of 'inference' about it; this is the clinician's assessment of the heart sounds heard to be leaking of blood through the mitral valve of the left side of the heart.
	Evaluation	problem-diagnosis	A diagnosis of mitral valve disease may be made; this will usually describe the severity, indicate what studies were done to establish the nature of the disease etc. This is not the same statement as any of the original observations, but would normally summarise them.
Patient: "I have been diagnosed with diabetes"	Observation	Story	Anything interesting the patient says may be recorded in the story, depending on the clinician and system.
	Evaluation	problem-diagnosis	The clinician may or may not record a 'story'; if his assessment is that the patient is indeed diabetic, he would normally record a diagnosis; this has the same status as any other diagnosis recorded by a clinical professional.
Allied health professional: "The patient is incontinent"	Observation	Barthel Index	Facts about the patient's capabilities in living independently are recorded as Observation(s), and gathered according to a protocol, such as a questionnaire, functional test by occupational therapist etc. How good the information is may depend on the protocol, but in all cases, the result is an observation of various phenomenon in time.
	Evaluation	problem	An assessment will be made about the subject based on all the information gathered; some of the evidence might lead to the establishment of a problem of incontinence.

Summary

The Observation type provides the timing structure that is universally applicable to all phenomona sensed from the real world; it also provides the data/state/protocol combination that characterises many measurement situations. These features mean that some basic aspects of software and data schemas can be standardised for such information. The Evaluation type provides a free-form structure which is completely structured by archetyping. The distinction in types helps ensure queries do not mix up different 'statuses'. The key criterion for distinguishing Observations from Evaluations is whether the recording is of information being captured from the outside world (in a repeatable way), or not.

Using only a single unstructured type would lose these advantages. It doesn't prevent such information being expressed, but it means that even the universal aspects such as time, events, math functions, interval widths etc, are likely to be expressed differently in each instance. This is not useful for a standardised EHR environment, although it can be useful for an integration environment, where data from various source systems is being federated into a standardised EHR, and each source's idea of e.g. observation time is different.