openEHR logo

Data Structures Information Model

Issuer: openEHR Specification Program

Release: Release-1.0.3

Status: STABLE

Revision: [latest_issue]

Date: [latest_issue_date]

Keywords: EHR, data structures, openehr

openEHR components
© 2003 - 2015 The openEHR Foundation

The openEHR Foundation is an independent, non-profit community organisation, facilitating the sharing of health records by consumers and clinicians via open-source, standards-based implementations.


image Creative Commons Attribution-NoDerivs 3.0 Unported.



Amendment Record

Issue Details Raiser Completed

R E L E A S E     1.0.3


SPECRM-42. Clarify definition of HISTORY.summary (addresses SPECPR-81.

I McNichol,
G Grieve

15 Nov 2015

R E L E A S E     1.0.2


SPEC-271. Correct minor inconsistencies in ITEM_TABLE specification and example.

R Chen

05 Nov 2008

SPEC-257: Correct minor typos and clarify text.

C Ma,
R Chen, T Cook

SPEC-255. Correct minor error in INTERVAL_EVENT.width documentation.

A Patterson

SPEC-283. Correct spelling of ELEMENT.null_flavor attribute to null_flavour.

H Frankel

R E L E A S E     1.0.1


SPEC-200. Correct Release 1.0 typographical errors. Minor cosmetic changes to diagrams. Correct return types of ITEM_TABLE functions to CLUSTER rather than List<ELEMENT>.

D Lloyd,
T Beale

26 Sep 2006

SPEC-207: Change ITEM_TABLE columns to rows.

S Heard

SPEC-219: Use constants instead of literals to refer to terminology in RM.

R Chen

SPEC-220: Tighten semantics of HISTORY.period and EVENT.time.

A Patterson

R E L E A S E     1.0


SPEC-14. Adjust History. Major simplifcation to package; make Events absolute in time.

S Heard
T Beale

16 Dec 2005

SPEC-155: Summary data.

S Heard

SPEC-183. Remove root node from ITEM_TREE.

G Grieve

SPEC-185. Improved EVENT model.

S Heard

SPEC-155: Summary data.

S Heard
G Grieve

SPEC-192: Add display-as-absolute facility to delta Events in History (added explanation only).

S Heard

SPEC-193: Simplify INTERVAL_EVENT for archetyping and paths. Revert to one math function per INTERVAL_EVENT.

S Heard

SPEC-196: Rename HISTORY.items to events.

S Heard

SPEC-192. Support change, increase and decrease Events in History.

S Heard
D Lloyd

R E L E A S E     0.96

R E L E A S E     0.95


SPEC-48. Pre-release review of documents. Fixed HISTORY UML diagram - remove superfluous T:XXX (no semantic change). Converted parameter types to UML box form.

D Lloyd

22 Feb 2005


SPEC-101. Improve modelling of Structure classes.


10 Dec 2004

SPEC-100. Correct inheritance error in ITEM_STRUCTURE package.

T Beale

SPEC-24. Revert meaning to STRING and rename as archetype_node_id_.

S Heard,
T Beale

SPEC-118. Make package names lower case.

T Beale

SPEC-123. EVENT should inherit from LOCATABLE.

R Chen

SPEC-124. Fix path syntax in data structures IM document.

T Beale

R E L E A S E     0.9


SPEC-19. Add HISTORY and STRUCTURE supertype.

T Beale

09 Mar 2004

SPEC-28. Change name of STRUCTURE class to avoid clashes.

H Frankel

SPEC-89. Remove ITEM.displayed.


SPEC-91. Correct anomalies in use of CODE_PHRASE and DV_CODED_TEXT.

T Beale

SPEC-67. Change EVENT class to enable math function interval A measurements. Renamed EVENT.duration and SINGLE_EVENT.duration to width.

S Heard

Formally validated using ISE Eiffel 5.4.

T Beale


SPEC-41. Visually differentiate primitive types in openEHR documents.

D Lloyd

04 Sep 2003


SPEC-13 Rename key classes - rename COMPOUND to CLUSTER to conform with CEN 13606.

D Kalra,
T Beale

20 Jun 2003


Improved heading layout, package naming. Made HISTORY.is_periodic a function.

T Beale,
Z Tun

18 Mar 2003


Formally validated using ISE Eiffel 5.2. No changes.

T Beale

20 Feb 2003


Minor corrections to terminology_id invariants.

Z Tun

08 Jan 2003


Defined packages properly and moved HISTORY classes from EHR RM. No change to semantics.

T Beale

18 Dec 2002


Minor corrections: SINGLE_S new function.

T Beale

10 Nov 2002


Minor adjustments due to change in DV_CODED_TEXT.

T Beale

01 Nov 2002


Taken from Common RM.

T Beale

11 Oct 2002


The work reported in this paper has been funded in by the following organisations:

  • University College London - Centre for Health Informatics and Multi-professional Education (CHIME);

  • Ocean Informatics;

  • Distributed Systems Technology Centre (DSTC), under the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of the Commonwealth Government of Australia.

Thanks to Grahame Grieve of Kestral Computing, Australia for general input and examples relating to History data.

Special thanks to Prof David Ingram, head of CHIME, who provided a vision and collegial working environment ever since the days of GEHR (1992).

1. Preface

1.1. Purpose

This document describes the common data structures used in openEHR reference model, including lists, tables, trees, and history.

The intended audience includes:

  • Standards bodies producing health informatics standards;

  • Academic groups using openEHR;

  • The open source healthcare community;

  • Solution vendors;

  • Medical informaticians and clinicians interested in health information.

  • Health data managers.

Prerequisite documents for reading this document include:

1.3. Status

This specification is in the STABLE state. The development version of this document can be found at

Known omissions or questions are indicated in the text with a 'to be determined' paragraph, as follows:

TBD: (example To Be Determined paragraph)

Users are encouraged to comment on and/or advise on these paragraphs as well as the main content. Feedback should be provided either on the technical mailing list, or on the specifications issue tracker.

1.4. Conformance

Conformance of a data or software artifact to an openEHR Reference Model specification is determined by a formal test of that artifact against the relevant openEHR Implementation Technology Specification(s) (ITSs), such as an IDL interface or an XML-schema. Since ITSs are formal, automated derivations from the Reference Model, ITS conformance indicates RM conformance.

2. Background

2.1. Requirements

The requirements for structured data in the EHR and other systems are essentially that low-level data can be expressed in standard structures. The structures which are commonly required are as follows:

  • single values, e.g. weight, height, blood sugar;

  • lists of named/numbered elements, e.g. blood test results;

  • tables of values with named columns and/or named rows, e.g. visual acuity results;

  • trees of values, e.g. biochemistry, microbiology results;

  • histories of values, each of which takes any of the above forms, e.g. a time series of blood pressures, glucose levels, or imaging data.

2.2. Design Principles

The design principle which particularly applies to the data structure models described here is the need to provide explicit specifications for logical structures using the same generic representation, such as hierarchy. The logical structures include tables, lists, trees, and the concept of history.

Regardless of whether such structures are treated as pure presentation or as having semantic significance, there are at various reasons for explicitly including the semantics of logical structures which are represented in a generic way such as hierarchy, including:

  • it is essential for interoperability that a structure such as a logical table, list or linear history be encoded into the generic representation in the same way by all senders and receivers of information, otherwise there is no guarantee that any communicating party’s software processes the structures in the intended fashion;

  • software implementors can develop software which explicitly captures the logical structures as functional interfaces which are used as the only way of building such structures. Such interfaces (assuming they are bug-free) guarantee that all application software always creates correct structures - there is no need to rely on caller software each time making low level calls to create a table or list out of hierarchy elements;

  • the use of a functional interface for such types means that application software at the receiver’s end can always process incoming information in its intended form, enabling correct presentation of data on the screen.

One of the motivations for defining logical data structures explicitly is to remove the ambiguity in recording structure and time in previous EHR specifications and standards, such as CEN 13606, GEHR, GEHR Australia, and HL7v3 CDA specifications. The alternative in the past was to simply use generic hierarchical structures; there was no agreement in the standard about how a table might be represented, similarly, time had no standard representation. Where single values were recorded, an attribute meaning 'time of recording' was set appropriately; if a time series was required, there was no clear guideline as to how to model it. One way would have been to build a double list which is logically a two column table, whose first column was time-point data, but many other approaches are possible. The standardised approach removes all such ambiguity, and improves the quality of data and software.

3. Overview

The rm.data_structures package contains two packages: the item_structure package and the history package. The first describes generic, path-addressable data structures, while the latter describes a generic notion of linear history, for recording events in past time. The data_structures package is illustrated in the UML diagram below.

RM data structures
Figure 1. rm.data_structures Package

The data_structures package itself contains a single class, DATA_STRUCTURE, which is the ancestor of all openEHR data structures. Its only feature is the function as_hierarchy, which is implemented by each subtype of DATA_STRUCTURE, in order to generate a physical representation of the structure in CEN EN13606 form. The 13606 form is usually less optimal than the openEHR form, but is compatible with the less semantically rich standard, and is guaranteed (in theory) to be comprehensible to other systems which support CEN EN13606 as an interoperability standard.

3.1. Instance Structures

Diagrams of typical instances of the structures are included throughout this document. Each instance of shown in both physical and logical form. The physical form shows the instances which will occur in data if the structure is implemented using the representation package. The logical form shows the same instance in a logical form only - i.e. hiding the physical implementation. Only the latter form is used in other openEHR documents. In all instance diagrams, the following shorthand is used for well-known attribute names:

  • "m = xxxx" - means "meaning = xxxx", i.e. the meaning of the archetype_node_id attribute inherited from the LOCATABLE class.

  • "n = xxxx" - means "name = xxxx", i.e. the value of the name attribute inherited from the LOCATABLE class.

  • "v = xxxx" - means "value = xxxx", i.e. the value of the value attribute from the ELEMENT class.

3.2. Class Descriptions





Abstract parent class of all data structure types. Includes the as_hierarchy function which can generate the equivalent CEN EN13606 single hierarchy for each subtype’s physical representation. For example, the physical representation of an ITEM_LIST is List<ELEMENT>; its implementation of as_hierarchy will generate a CLUSTER containing the set of ELEMENT nodes from the list.






as_hierarchy: ITEM

Hierarchical equivalent of the physical representation of each subtype, compatible with CEN EN 13606 structures.

4. Item Structure Package

4.1. Overview

The item_structure package classes presented here are a formalisation of the need for generic, archetypable data structures, and are used by all openEHR reference models.

The subtypes of the ITEM_STRUCTURE class explicitly model the logical data structure types which typically occur in health record data, and include ITEM_SINGLE (for single values such as a patient weight), ITEM_LIST (for lists such as parts of an address), ITEM_TREE (for hierarchically structured data such as a microbiology report) and ITEM_TABLE (for tabular data such as visual acuity or reflex test results). Each of these classes defines a functional interface, has an optimal physical representation using the basic types CLUSTER and ELEMENT from the representation package, and can generate a CEN EN13606-compliant hierarchical representation of its data. Any system implementing these types is guaranteed to create data which represents the logical structures of lists, tables and trees identically.

Data values are connected to spatial structures via the value attribute of the ELEMENT class of the representation cluster. This class also carries an important attribute null_flavour, whose value indicates how to read the value. A small domain termlist containing values such as "unknown", "not disclosed", "undetermined", etc, as described in the Flavours of Null vocabulary in the openEHR Support Information Model.

The openEHR class model for spatial structures is illustrated on the right-hand side of the figure rm.data_structures Package. It should be noted that these classes (ITEM_LIST etc) are not equivalents of similarly named classes (such as List<T>) in most data structure libraries - they also include per-node name, archetype_node_id and leaf node value and null flavour, and path capabilities.

4.2. CEN EN13606 Encoding Rules


An ITEM_SINGLE object is encoded in EN13606 as a single ELEMENT object.

4.2.2. ITEM_LIST

An ITEM_LIST object is encoded in EN13606 as a CLUSTER object containing the set of ELEMENTs from the openEHR list.


The ITEM_TABLE encoding rules are as follows:

  • Each row is encoded as a Cluster containing a number of ELEMENTs, each corresponding to the value of a column in that row.

  • An empty/void column value for a row is represented by an ELEMENT containing no value, and with null_flavour set.

  • The names of the ELEMENT in a row are the column names.

  • The names of the containing CLUSTER of each row is the stringified number of the row in the overall table.

4.2.4. ITEM_TREE

Data of an ITEM_TREE instance are simply replicated as is to produce the correct EN13606 hierarchical form.

4.3. Class Descriptions





Abstract parent class of all spatial data types.



4.3.2. ITEM_SINGLE Class




Logical single value data structure. Used to represent any data which is logically a single value, such as a person’s height or weight.












as_hierarchy: ELEMENT

Generate a CEN EN13606-compatible hierarchy consisting of a single ELEMENT.

4.3.3. ITEM_LIST Class




Logical list data structure, where each item has a value and can be referred to by a name and a positional index in the list. The list may be empty. Use Used to represent any data which is logically a list of values, such as blood pressure, most protocols, many blood tests etc.

Misuse: Not to be used for time-based lists, which should be represented with the proper temporal class, i.e. HISTORY.







items: List<ELEMENT>

Physical representation of the list.




item_count: Integer

Count of all items.

names: List<DV_TEXT>

Retrieve the names of all items.

named_item (a_name: String): ELEMENT

Retrieve the item with name ‘a_name’.

ith_item (i: Integer): ELEMENT

Retrieve the i-th item with name.


as_hierarchy: CLUSTER

Generate a CEN EN13606-compatible hierarchy consisting of a single CLUSTER containing the ELEMENTs of this list.


Valid_structure: items.forall (i:ITEM | i.type = "ELEMENT")

4.3.4. ITEM_TABLE Class




Logical relational database style table data structure, in which columns are named and ordered with respect to each other. Implemented using Cluster-per-row encoding. Each row Cluster must have an identical number of Elements, each of which in turn must have identical names and value types in the corresponding positions in each row.

Some columns may be designated key' columns, containing key data for each row, in the manner of relational tables. This allows row-naming, where each row represents a body site, a blood antigen etc. All values in a column have the same data type.

Used for representing any data which is logically a table of values, such as blood pressure, most protocols, many blood tests etc.

Misuse: Not to be used for time-based data, which should be represented with the temporal class HISTORY. The table may be empty.







rows: List<CLUSTER>

Physical representation of the table as a list of CLUSTERs, each containing the data of one row of the table.




row_count: Integer

column_count: Integer

row_names: List<DV_TEXT>

column_names: List<DV_TEXT>

ith_row (i: Integer): CLUSTER

has_row_with_name (a_key: String): Boolean

has_column_with_name (a_key: String): Boolean

named_row (a_key: String): CLUSTER

has_row_with_key (keys: List<String>): Boolean

row_with_key (keys: List<String>): CLUSTER

element_at_cell_ij (i, j: Integer): ELEMENT


as_hierarchy: CLUSTER

Generate a CEN EN13606-compatible hierarchy consisting of a single CLUSTER containing the CLUSTERs representing the columns of this table.


Valid_structure: rows.for_all (items.for_all (instance_of ("ELEMENT")))

4.3.5. ITEM_TREE Class




Logical tree data structure. The tree may be empty. Used for representing data which are logically a tree such as audiology results, microbiology results, biochemistry results.







items: List<ITEM>

The items comprising the ITEM_TREE. Can include 0 or more CLUSTERs and/or 0 or more individual ELEMENTs.




has_element_path (a_path: String): Boolean

True if path a_path' is a valid leaf path.

element_at_path (a_path: String): ELEMENT

Return the leaf element at the path a_path'.


as_hierarchy: CLUSTER

Generate a CEN EN13606-compatible hierarchy, which is the same as the tree’s physical representation.

4.4. Instance Structures

4.4.1. ITEM_SINGLE Instance Structure

The figure below illustrates a ITEM_SINGLE instance, in both physical and logical forms.

instance item single
Figure 2. Instance Structure of ITEM_SINGLE

4.4.2. ITEM_LIST Instance Structure

The following figure illustrates a typical ITEM_LIST structure, in this case for a BP protocol.

instance item list
Figure 3. Instance Structure of ITEM_LIST

4.4.3. ITEM_TABLE Instance Structure

The next figure illustrates a table of visual acuity test results.

instance item table
Figure 4. Instance Structure of ITEM_TABLE

4.4.4. ITEM_TREE Instance Structure

The following figure illustrates te logical and physical form of an example ITEM_TREE instance, representing a biochemistry result.

instance item tree
Figure 5. Instance Structure of ITEM_TREE

5. Representation Package

5.1. Overview

This package contains classes for a simple hierarchical representation of any data structure, as shown on the lower right side of the figure rm.data_structures Package. These classes are compatible with the CEN EN13606 classes of the same names, and instances can be losslessly generated to and from EN13606 instances structures.

5.2. Class Descriptions

5.2.1. ITEM Class


ITEM (abstract)


The abstract parent of CLUSTER and ELEMENT representation classes.



5.2.2. CLUSTER Class




The grouping variant of ITEM, which may contain further instances of ITEM, in an ordered list.







items: List<ITEM>

Ordered list of items - CLUSTER or ELEMENT objects - under this CLUSTER.

5.2.3. ELEMENT Class




The leaf variant of ITEM, to which a DATA_VALUE instance is attached.







null_flavour: DV_CODED_TEXT

Flavour of null value, e.g. indeterminate, not asked etc.



Property representing leaf value object of ELEMENT. In real data, any concrete subtype of DATA_VALUE can be used.




is_null: Boolean

True if value logically not known, e.g. if indeterminate, not asked etc.


Is_null_valid: is_null = (value = Void)

Null_flavour_indicated: is_null xor null_flavour = Void

Null_flavour_valid: is_null implies terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_null_flavour, null_flavour.defining_code)

6. History Package

6.1. Overview

The history package defines classes which formalise the concept of past, linear time, via which historical data of any structural complexity can be recorded. It supports both instantaneous and interval event samples within periodic and aperiodic series. Data recorded in interval events are tagged with a mathematical function, including 'point-in-time', 'mean', 'delta' and so on, as defined by the openEHR event_math_function vocabulary. It also supports the inclusion of "summary" data, i.e. a textual or image item which summarises in some way the entire history.

Regardless of whether the actual data consist of a single sample or many, they are represented in the same way: as a history of events, i.e. as a time series, allowing all software to access data in a uniform way, whether it is a single measurement of weight, a long series of three- or four-dimensional images, or even a series of encapsulated multimedia items.

The model defines the constrained generic (otherwise known as 'template' or 'parameterised') types HISTORY<T>, EVENT<T>, POINT_EVENT<T>, and INTERVAL_EVENT<T> where the type parameter is constrained to the ITEM_STRUCTURE type, and defines the type of the data recorded in an instance of HISTORY. The effect is that repeated instances of spatially complex data can recur in time, corresponding to the way data are actually measured. An aperiodic series of POINT_EVENT instances would typically be used to represent manual measurements repeated in time. Periodic histories of INTERVAL_EVENT instances would typically be used to represent vital signs monitor output (which is usually delivered in averaged form potentially with additional minimum and maximum values).

As with all other parts of the openEHR reference model, the history package is designed for archetyping; archetypes define the domain semantics of HISTORY instances. The history package is shown on the left of the figure rm.data_structures Package.

6.1.1. Basic Semantics

The intention of the History model is to represent time-based data for which every sample in the series is a measurement of the same phenomenon (e.g. patient heartrate) and is obtained using the same measurement method (e.g. pulse oximeter). Samples taken in this way can be reliably treated as representing changes in a phenomenon over time, and accordingly can be safely used for time-based computation, such as graphing, statistical analysis and so on. A History can contain any mixture of POINT_EVENT and INTERVAL_EVENT instances. Clearly it is impossible for the model to guarantee completely correct usage on its own, however there two major safeguards.

Firstly, the use of generic types forces the type of the data in each Event to be the same. A History of type HISTORY<ITEM_LIST> therefore constrains the type of the data at each Event (EVENT.item) to be of type ITEM_LIST and nothing else.

Secondly, the use of archetyping (typically within openEHR Observation archetypes) ensures the actual structure of the ITEM_STRUCTURE subtype is defined in the same way for every sample - e.g. a two-item list representing systolic and diastolic blood pressure.

6.1.2. Timing

An instance of the HISTORY class contains the origin: DV_DATE_TIME attribute, indicating what is considered the '0-point' of the time series, and a series of instances of the EVENT subtype, each containing a time: DV_DATE_TIME attribute representing the absolute time of the event. The relative offset of any Event is computed as the difference between the EVENT.time and HISTORY.origin by the EVENT.offset function. For Interval events (i.e. instances of INTERVAL_EVENT), the time attribute always refers to the end time of the event, since this is the time at which the data (e.g. average) are true.

The origin time of a History does not have to be the time of the first sample - it might be the time of an event such as child-birth with respect to which the samples are recorded, e.g. Apgar scores (Apgar is a 0-10 score indicating the health of a newborn based on breathing, heartrate, colour, muscletone and reflexes) at 1 and 3 minute offsets. Periodicity and aperiodicity are expressed via the is_periodic and period attributes. For a periodic time-series, period is set to the period duration value and is_periodic returns True. The total duration of the History is given by the HISTORY.duration function. The following figure illustrates a number of variations in History periodicity and Event type.

history period
Figure 6. Variation in History periodicity and Event width

6.1.3. Point Events

The simplest kind of Event in a History is a "point" event, expressed by instances of the class POINT_EVENT, representing an instantaneous value. A HISTORY instance may be composed solely of Point events, as would be the case with a number of blood pressure values measured over time as the patient changes position. An Apgar result is a typical example of aperiodic point data, typically consisting of 2 or 3 events, each containing 5 values and a 6th value repersenting the Apgar score for that time point. Point data may also be available from monitoring devices. For fine-granularity (e.g. 1 second) data, the number of samples may be too voluminous for the health record, and more efficient recording in the form of summary Interval events (see below) might be desired. The diagram below illustrates the structure of a HISTORY containing POINT_EVENTs.

history bp
Figure 7. Structure of HISTORY<T> of POINT_EVENTs

6.1.4. Interval Events

Instances of the INTERVAL_EVENT class are used to express values corresponding to an interval in time. The INTERVAL_EVENT.width attribute defines the duration of the interval; and the inherited time value corresponds to the trailing edge of the event.

The meaning of an Interval event in this model is that the values effectively summarise actual instantaneous values of a datum that have occurred during the period of the event interval. The mathematical meaning of the data of any particular interval event is given by the math_function attribute. This is coded by the openEHR Terminology group "event math function", and takes values such as "minimum", "maximum", "average", "delta" and so on. The particular math functions used in each Interval event in a History may vary throughout the History; for example, one 4-hour Interval event might contain data representing average values, while a following event might contain data representing maximum values. Such data can be conveniently used for generating sophisticated graphs of the underlying datum over time. The next figure illustrates a History containing 2 pairs of 4-hour blood pressure Interval events, with each pair containing maximum and mean blood pressure value structures for +4h and +8h timepoints (each of which consist of a systolic and diastolic value).

history bp math
Figure 8. Structure of HISTORY<T> of INTERVAL_EVENTs

Interval events can overlap other interval or point events within the same History. A common situation where this occurs is with measurement of different periods of vital signs, such as 4-hourly blood pressure events, overlapped by a 24-hour event which contains the values over a period of 6 x 4 hour periods. In general a long Interval event can overlap any combination of Point or Interval events, as shown in the following figure.

history event overlapping
Figure 9. Overlapping Events

6.1.5. Change Data

One subcategory of interval data that deserves mention is change data. There are three event math function terms used for indicating changes in data values as follows:

  • "change": this means that the value recorded is the difference between the value now and the value some time previously. It can be positive or negative;

  • "increase": the value recorded for the change is positive. The name (i.e. chosen for the item in an archetype carries the semantic of positivity e.g. "increase of …​.; rise of…​.; …​.gain" etc;

  • "decrease": the value recorded for the change is positive. But the name chosen for the item carries the semantic of negativity e.g. "decrease of …​.; fall of …​.; …​. loss".

The following examples show how the data and these math functions are coordinated.

  • weight last week was 76 kg. Wait this week = 74 kg. Possible instances:

Item Name
in Archetype
Type Math Function

"weight change"

+ 2kg



"weight loss"




"weight loss"




  • weight last week was 80 kg. Weight this week = 83 kg. Possible instances:

Item Name
in Archetype
Type Math Function

"weight change"




"weight increase"




"weight gain"




The use of these math function indicators allows the correct representation of change values, no matter how they were captured, in a computable form.

6.1.6. Summary Event Data

A relatively common situation particularly in laboratory testing is the existence of a "summarising" event which accompanies more detailed historical data. Examples where this arises include:

  • a series of exams with a single radiologist report for all of them (the report might include one or more key images);

  • graphical summary of a dynamic challenge test such as Glucose tolerance test;

  • some comment about the pattern of values on a set of observed values in series.

Such data are accommodated within the model via the optional HISTORY.summary attribute, which is itself a structure, archetypable separately from the structure of the main data. In the first example above, the summary data might consist of an ITEM_SINGLE object containing a textual report; in the second, an ITEM_SINGLE object containing a image within a DV_MULTIMEDIA instance.

6.1.7. Efficient Representation of Fine-grained Device Data

A useful practical consequence of the of Interval Events is that it allows long periods of relatively stable data to be represented with a single Interval event, while interesting perturbations will be represented with a number of fine-grained Interval or Point Events. In the example in the next figure, Event instances are used represent 4 hours of data consisting to 14,400 x 1 second samples from a blood pressure monitor. The optional INTERVAL_EVENT.sample_count attribute can be used to record the number of original samples summarised in the event. In the illustration, the math_function is shown as mean; clearly in the first long period, the monitored datum was not absolutely flat. The implication is that the recording software was configured to regard variations in a small band (e.g. 5mm Hg) as insignificant, and only to create new Event objects when the underlying values moved outside the band. Another approach woould have been to create two Interval Event objects for each long period, one giving minimum value, the other maxium value, still based on the principle of generating one such pair for periods when the underlying data remained within specified limits. Regardless of the details, this general approach provides a way to include hours of fine-grained data from devices like vital signs monitors in very little space; the data simply need to be transfomed into equivalent openEHR History form first.

history data compression
Figure 10. Data compression effect of History with Interval Events

6.1.8. State

A feature particular to a model of recording historical data for scientific and clinical use is the ability to record 'state'. In openEHR, 'state' is understood as information pertinent to the correct interpretation of the primary data. A simple example is where the primary datum is heartrate; useful state data would be the level of exertion of the subject (resting, after 3 minutes cycling etc). In clinical recording situations, the state data is often crucial to the safe use of the primary data, since the latter might be normal or abnormal depending on the patient state. In openEHR there are two ways of recording state. One is via the use of a separate HISTORY structure within the OBSERVATION class (see ehr.composition.content.entry package). The other is via the use of the state attribute of type ITEM_STRUCTURE defined in the class EVENT itself. Experience with openEHR archetypes and systems has shown that the latter method corresponds to the most common clinical need, which is to be able to record the state at the time of the event (the other method allows for the recording of independent state events). A simple example is the recording of 3 glucose levels during a glucose tolerance test. The state information for each event is, respectively (in a typical test):

  • 0-minute sample: "post 8-hour fast";

  • 1-hour sample: "post 75g oral glucose challenge";

  • 2-hour sample: "post 75g oral glucose challenge".

The History structure for this example is illustrated in the following figure.

history ogtt
Figure 11. State in HISTORY

6.2. Class Descriptions

6.2.1. HISTORY Class




Root object of a linear history, i.e. time series structure. For a periodic series of events, period will be set, and the time of each Event in the History must correspond; i.e. the EVENT.offset must be a multiple of period for each Event. Missing events in a period History are however allowed.







origin: DV_DATE_TIME

Time origin of this event history. The first event is not necessarily at the origin point.



Period between samples in this segment if periodic.


duration: DV_DURATION

Duration of the entire History; either corresponds to the duration of all the events, and/or the duration represented by the summary, if it exists.



Optional summary data that aggregates, organizes, reduces and transforms the event series. This may be a text or image that presents a graphical presentation, or some data that assists with the interpretation of the data.


events: List<EVENT>

The events in the series.




is_periodic: Boolean

Indicates whether history is periodic.


Events_valid: (events /= Void and then not events.is_empty) or summary /= Void

Periodic_validity: is_periodic xor period = Void

Period_consistency: is_periodic implies events.for_all (e: EVENT | e.offset. to_seconds.mod(period.to_seconds) = 0)

6.2.2. EVENT Class


EVENT (abstract)


Defines the abstract notion of a single event in a series. This class is generic, allowing types to be generated which are locked to particular spatial types, such as EVENT<ITEM_LIST>. Subtypes express point or intveral data.








Time of this event. If the width is non-zero, it is the time point of the trailing edge of the event.



Optional state data for this event.



The data of this event.




Post_condition: Result = time.diff(parent.origin)

Offset of this event from origin, computed as time.diff(parent.origin).


Offset_validity1: offset /= Void and then offset = time.diff (parent.origin)

6.2.3. POINT_EVENT Class




Defines a single point event in a series.







Defines a single interval event in a series.








Length of the interval during which the state was true. Void if an instantaneous event.


sample_count: Integer

Optional count of original samples to which this event corresponds.


math_function: DV_CODED_TEXT

Mathematical function of the data of this event, e.g. maximum , mean etc. Coded using openEHR Terminology group event math function.




interval_start_time: DV_DATE_TIME

Start time of the interval of this event.


Math_function_validity: terminology (Terminology_id_openehr).has_code_for_group_id (Group_id_event_math_function, math_function.defining_code)

Interval_start_time_valid: interval_start_time = time - width

6.3. History Instance Structures

6.3.1. Single Sample

The following diagram illustrates a single weight measurement. The Event objects contain the timing information, which in this case is simply the time of measurement (the origin).

history single sample
Figure 12. Single sample Instance Structure

6.3.2. 5-minute Blood Pressure Averages

The next figure illustrates two Interval events representing 5 minute blood pressure averages, the first at 5 minutes' offset from an initial event and lasting 5 minutes, the second 5 minutes later.

history bp series instances
Figure 13. Blood Pressure Series History Instance Structure



  1. [Anderson_1996] Ross Anderson. Security in Clinical Information Systems. Available at

  2. [Baretto_2005] Barretto S A. Designing Guideline-based Workflow-Integrated Electronic Health Records. 2005. PhD dissertation, University of South Australia. Available at

  3. [Beale_2000] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. 2000. Available at .

  4. [Beale_2002] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the Customer (Seattle, Washington, USA, November 4, 2002). Edited by Kenneth Baclawski and Haim Kilov. Northeastern University, Boston, 2002, pp. 16-32. Available at .

  5. [Beale_Heard_2007] Beale T, Heard S. An Ontology-based Model of Clinical Information. 2007. pp760-764 Proceedings MedInfo 2007, K. Kuhn et al. (Eds), IOS Publishing 2007. See

  6. [Booch_1994] Booch G. Object-Oriented Analysis and Design with applications. 2nd ed. Benjamin/Cummings 1994.

  7. [Browne_2005] Browne E D. Workflow Modelling of Coordinated Inter-Health-Provider Care Plans. 2005. PhD dissertation, University of South Australia. Available at

  8. [Cimino_1997] Cimino J J. Desiderata for Controlled Medical vocabularies in the Twenty-First Century. IMIA WG6 Conference, Jacksonville, Florida, Jan 19-22, 1997.

  9. [Eiffel] Meyer B. Eiffel the Language (2nd Ed). Prentice Hall, 1992.

  10. [Elstein_1987] Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press 1987.

  11. [Elstein_Schwarz_2002] Elstein AS, Schwarz A. Evidence base of clinical diagnosis: Clinical problem solving and diagnostic decision making: selective review of the cognitive literature. BMJ 2002;324;729-732.

  12. [Fowler_1997] Fowler M. Analysis Patterns: Reusable Object Models. Addison Wesley 1997

  13. [Fowler_Scott_2000] Fowler M, Scott K. UML Distilled (2nd Ed.). Addison Wesley Longman 2000.

  14. [Gray_reuter_1993] Gray J, Reuter A. Transaction Processing Concepts and Techniques. Morgan Kaufmann 1993.

  15. [Hein_2002] Hein J L. Discrete Structures, Logic and Computability (2nd Ed). Jones and Bartlett 2002.

  16. [Hnìtynka_2004] Hnìtynka P, Plášil F. Distributed Versioning Model for MOF. Proceedings of WISICT 2004, Cancun, Mexico, A volume in the ACM international conference proceedings series, published by Computer Science Press, Trinity College Dublin Ireland, 2004.

  17. [Ingram_1995] Ingram D. The Good European Health Record Project. Laires, Laderia Christensen, Eds. Health in the New Communications Age. Amsterdam: IOS Press; 1995; pp. 66-74.

  18. [Kifer_Lausen_Wu_1995] Kifer M, Lausen G, Wu J. Logical Foundations of Object-Oriented and FrameBased Languages. JACM May 1995. See See

  19. [Kilov_1994] Kilov H, Ross J. Information Modelling - an object-oriented approach. Prentice Hall 1994.

  20. [Maier_2000] Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at

  21. [Martin] Martin P. Translations between UML, OWL, KIF and the WebKB-2 languages (For-Taxonomy, Frame-CG, Formalized English). May/June 2003. Available at as at Aug 2004.

  22. [Meyer_OOSC2] Meyer B. Object-oriented Software Construction, 2nd Ed. Prentice Hall 1997

  23. [Müller_2003] Müller R. Event-oriented Dnamic Adaptation of Workflows: Model, Architecture, and Implementation. 2003. PhD dissertation, University of Leipzig. Available at

  24. [Object_Z] Smith G. The Object Z Specification Language. Kluwer Academic Publishers 2000. See .

  25. [Rector_1994] Rector A L, Nowlan W A, Kay S. Foundations for an Electronic Medical Record. The IMIA Yearbook of Medical Informatics 1992 (Eds. van Bemmel J, McRay A). Stuttgart Schattauer 1994.

  26. [Rector] Rector A L. Clinical terminology: why is it so hard? Methods Inf Med. 1999 Dec;38(4-5):239-52. Available at .

  27. [Richards_1998] Richards E G. Mapping Time - The Calendar and its History. Oxford University Press 1998.

  28. [Sowa_2000] Sowa J F. Knowledge Representation: Logical, philosophical and Computational Foundations. 2000, Brooks/Cole, California.

  29. [Sottile_1999] Sottile P.A., Ferrara F.M., Grimson W., Kalra D., and Scherrer J.R. The holistic healthcare information system. Toward an Electronic Health Record Europe. 1999. Nov 1999; 259-266.

  30. [Van_de_Velde_Degoulet_2003] Van de Velde R, Degoulet P. Clinical Information Systems: A Component-Based Approach. 2003. Springer-Verlag New York.

  31. [Weed_1969] Weed LL. Medical records, medical education and patient care. 6 ed. Chicago: Year Book Medical Publishers Inc. 1969.



  1. [bfo] Institute for Formal Ontology and Medical Information Science (IFOMIS). Basic Formal Ontology (BFO). .

  2. [FMA] .

  3. [Horrocks_owl] Patel-Schneider P, Horrocks I, Hayes P. OWL Web Ontology Language Semantics and Abstract Syntax. See .

  4. [IAO] Information Artefact Ontology. .

  5. [OBO] The Open Biological and Biomedical Ontologies. See .

  6. [OGMS] Ontology for General Medical Science (OGMS). .


  1. [cov_contra] Wikipedia. Covariance and contravariance. See .

e-Health Standards

  1. [ENV_13606-1] ENV 13606-1 - Electronic healthcare record communication - Part 1: Extended architecture. CEN/ TC 251 Health Informatics Technical Committee.

  2. [ENV_13606-2] ENV 13606-2 - Electronic healthcare record communication - Part 2: Domain term list. CEN/TC 251 Health Informatics Technical Committee.

  3. [ENV_13606-3] ENV 13606-3 - Electronic healthcare record communication - Part 3: Distribution rules. CEN/TC 251 Health Informatics Technical Committee.

  4. [ENV_13606-4] ENV 13606-4 - Electronic Healthcare Record Communication standard Part 4: Messages for the exchange of information. CEN/ TC 251 Health Informatics Technical Committee.

  5. [Corbamed_PIDS] Object Management Group. Person Identification Service. March 1999.

  6. [Corbamed_LQS] Object Management Group. Lexicon Query Service. March 1999.

  7. [HL7v3_ballot2] JL7 International. HL7 version 3 2nd Ballot specification. Available at

  8. [HL7v3_data_types] Schadow G, Biron P. HL7 version 3 deliverable: Version 3 Data Types. (2nd ballot 2002 version).

  9. [hl7_v3_rim] HL7. HL7 v3 RIM. See .

  10. [ICD10AM]. WHO / ACCD. International Classification of Diseases, 10th Revision, Australian Modifications. See

  11. [IHTSDO] International Health Terminology Standards Development Organisation (IHTSDO).


  13. [NLM_UML_list] National Library of Medicine. UMLS Terminologies List.

  14. [SNOMED_CT] IHTSDO. Sytematised Nomenclature for Medicine. See

  15. [WHO_ICD] World Health Organisation (WHO). International Classification of Diseases (ICD). See: .

  16. [ISO_18308] Schloeffel P. (Editor). Requirements for an Electronic Health Record Reference Architecture. (ISO TC 215/SC N; ISO/WD 18308). International Standards Organisation, Australia, 2002.

  17. [ISO_20514] ISO. The Integrated Care EHR. See .

  18. [UCUM] Schadow G, McDonald C J. The Unified Code for Units of Measure, Version 1.4 2000. Regenstrief Institute for Health Care, Indianapolis. See

e-Health Projects

  1. [CIMI] Clinical Information Modelling Initiative (CIMI) Project. See

  2. [EHCR_supA_14] Dixon R, Grubb P A, Lloyd D, and Kalra D. Consolidated List of Requirements. EHCR Support Action Deliverable 1.4. European Commission DGXIII, Brussels; May 2001 59pp Available from

  3. [EHCR_supA_35] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 3.5: "Final Recommendations to CEN for future work". Oct 2000. Available at

  4. [EHCR_supA_24] Dixon R, Grubb P, Lloyd D. EHCR Support Action Deliverable 2.4 "Guidelines on Interpretation and implementation of CEN EHCRA". Oct 2000. Available at

  5. [ Lloyd D, et al. EHCR Support Action Deliverable 3.1&3.2 “Interim Report to CEN”. July 1998. Available at

  6. [GEHR_del_4] Deliverable 4: GEHR Requirements for Clinical Comprehensiveness. GEHR Project 1992

  7. [GEHR_del_7] Deliverable 7: Clinical Functional Specifications. GEHR Project 1993

  8. [GEHR_del_8] Deliverable 8: Ethical and legal Requirements of GEHR Architecture and Systems. GEHR Project 1994

  9. [GEHR_del_19_20_24] Deliverable 19,20,24: GEHR Architecture. GEHR Project 30/6/1995

  10. [GeHR_AUS] Heard S, Beale T. The Good Electronic Health Record (GeHR) (Australia). See .

  11. [GeHR_Aus_gpcg] Heard S. GEHR Project Australia, GPCG Trial. Available at

  12. [GeHR_Aus_req] Beale T, Heard S. GEHR Technical Requirements. See

  13. [Synapses_req_A] Kalra D. (Editor). The Synapses User Requirements and Functional Specification (Part A). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1a. 6 chapters, 176 pages.

  14. [Synapses_req_B] Grimson W. and Groth T. (Editors). The Synapses User Requirements and Functional Specification (Part B). EU Telematics Application Programme, Brussels; 1996; The Synapses Project: Deliverable USER 1.1.1b.

  15. [Synapses_odp] Kalra D. (Editor). Synapses ODP Information Viewpoint. EU Telematics Application Programme, Brussels; 1998; The Synapses Project: Final Deliverable. 10 chapters, 64 pages.

  16. [synex] University College London. SynEx project. .

General Standards

  1. [OCL] The Object Constraint Language 2.0. Object Management Group (OMG). Available at .

  2. [IANA] IANA.

  3. [IEEE_828] IEEE. IEEE 828-2005: standard for Software Configuration Management Plans.

  4. [ISO_8601] ISO 8601 standard describing formats for representing times, dates, and durations. See e.g. and

  5. [ISO_2788] ISO. ISO 2788 Guide to Establishment and development of monolingual thesauri.

  6. [ISO_5964] ISO. ISO 5964 Guide to Establishment and development of multilingual thesauri.

  7. [Perl_regex] Perl Regular Expressions. Available at .

  8. [Protege] Stanford University. See .

  9. [rfc_2396] Berners-Lee T. Universal Resource Identifiers in WWW. Available at This is a World-Wide Web RFC for global identification of resources. In current use on the web, e.g. by Mosaic, Netscape and similar tools. See for a starting point on URIs.

  10. [rfc_2440] RFC 2440: OpenPGP Message Format. See and

  11. [rfc_3986] RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. IETF. See .

  12. [rfc_4122] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace. IETF. See .

  13. [rfc_2781] IETF. RFC 2781: UTF-16, an encoding of ISO 10646 See

  14. [rfc_5646] IETF. RFC 5646. Available at

  15. [sem_ver] Semantic Versioning. .

  16. [Xpath] W3C Xpath 1.0 specification. 1999. Available at

  17. [uri_syntax] Uniform Resource Identifier (URI): Generic Syntax, Internet proposed standard. January 2005. see .

  18. [w3c_owl] W3C. OWL - the Web Ontology Language. See .

  19. [w3c_xpath] W3C. XML Path Language. See .


  1. [Template_Designer] Template Designer. Ocean Informatics.

openEHR Resources

  1. [openehr_18308] The openEHR Foundation. Conformance of openEHR architecture to ISO TS 18308, "Requirements for EHR Architectures". See

  2. [openEHR_ADL_workbench] The openEHR Foundation. The openEHR ADL Workbench. .

  3. [openehr_am_overview] The openEHR Foundation. The openEHR Archetypes Technical Overview. See

  4. [openehr_am_adl14] The openEHR Foundation. Archetype Definition Language 1.4 (ADL1.4). Available at

  5. [openehr_am_aom14] The openEHR Foundation. Archetype Object Model 1.4 (AOM1.4). Available at

  6. [openehr_am_adl2] The openEHR Foundation. Archetype Definition Language 2 (ADL2). Available at

  7. [openehr_am_aom2] The openEHR Foundation. Archetype Object Model 2 (AOM2). Available at

  8. [openehr_am_identification] The openEHR Foundation. Archetype Identification specification. Available at

  9. [openehr_am_def_pri] The openEHR Foundation. Archetype Definitions and Principles. (deprecated) Available at

  10. [openehr_am_sys] The openEHR Foundation. The Archetype System. (deprecated) Available at

  11. [openehr_am_oap] The openEHR Foundation. The openEHR Archetype Profile. .

  12. [openehr_CKM] The openEHR Clinical Knowledge Manager (CKM). See

  13. [openehr_odin] The openEHR Foundation. Object Data Instance Notation (ODIN). Available at

  14. [openehr_overview] The openEHR Foundation. The openEHR Architecture Overview. See

  15. [openehr_query_aql] The openEHR Foundation. The openEHR Archetype Query language (AQL). See

  16. [openehr_rm_data_types] openEHR. Data Types Information Model. See

  17. [openehr_rm_data_structures] openEHR. Data Structures Information Model. See

  18. [openehr_rm_common] openEHR. Common Information Model. See

  19. [openehr_rm_ehr] The openEHR Foundation. The EHR Information Model.

  20. [openehr_rm_ehr_extract] The openEHR Foundation. The EHR Extrct Information Model.

  21. [openehr_rm_integration] The openEHR Foundation. The Integration Information Model.

  22. [openehr_rm_support] openEHR. Support Information Model. See

  23. [openehr_terminology] The openEHR Foundation. The openEHR Terminology

  24. [openehr_terminology_resources] The openEHR Foundation. The openEHR Terminology project (GitHub)