Data Structures Information Model

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

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:

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

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

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

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

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

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.

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.

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.

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).

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.

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:

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

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

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:

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.

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.

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):

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

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).

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.