Entry Package

Many health information models express observation time as one or more attributes with names like 'observation_time', 'activity_time' and so on. The openEHR model departs from this by modelling historical time inside a History/Event structure defined in the data_structures.history package. In short, this package defines the HISTORY class with an origin attribute, and a series of EVENT instances each containing a time attribute. Instantaneous and interval events are distinguished via the EVENT subtypes POINT_EVENT and INTERVAL_EVENT; interval events have the width attribute is set to the duration of the interval.

One of the aims of the model of Observation described here is to represent in the same way single sample and multi-sample time-based data for which measurement protocol is invariant. It is not intended for measurements in "coarse" time taken by different people, different instruments, or with any other difference in data-gathering technique. In these cases, separate, usually single-sample histories are used, usually occurring in distinct container objects (e.g. distinct Compositions, in the EHR).

Accordingly, in the general practice setting, the use of HISTORY will correspond to measurement series which occur during the clinical session (i.e. during a patient contact). In a hospital setting, nurses' observations might occur in 4-hourly intervals, and there is no well-defined clinical session - simply a series of ENTRYs during the time of the episode. Two approaches are possible here.

Whether time-based data remain outside the record until a series of desired length is gathered, or entered as it occurs is up to the design of applications and systems; the approach taken should be based on the desired availability of the data in the system in question. If for example, it must be visible in the EHR as soon as the appropriate Compositions are written, then it should be represented as Histories in each relevant Composition; if it need only be available at some much later point in time (e.g. because it is known that no-one but the treating clinician is interested in it), then it can be stored in another system until sufficient items have been gathered for committal to the EHR.

In most cases, the times recorded in a History (HISTORY.origin and EVENT.time, width) can be thought of as "the times when the observed phenomena were true". For example, if a pulse of 88bpm is recorded for 12/feb/2005 12:44:00, this is the time at which the heartrate (for which pulse is a surrogate) existed. In such cases, the sample time, and the measuring time are one and the same.

However in cases where the time of sampling is different from that of measurement, the semantics are more subtle. There are two cases. The first is where a sample is taken (e.g. a tissue sample in a needle biopsy), and is tested later on, but from the point of view of the test, the time delay makes no difference. This might be because the sample was immediately preserved (e.g. freezing, placed in a sterile anaerobic transport container), or because even if it decays in some way, it makes no difference to the test (e.g. bacteria may die, but this makes no difference to a PCT analysis, as long as the biological matter is not physically destroyed).

The second situation is when the sample does decay in some way, and the delay is relevant. Most such cases are in pathology tests, where presence of live biological organisms (e.g. anaerobic bacteria) is being measured. The sample time (or 'collection' time) must be recorded. Depending on when the test is done, the results may be interpreted differently.

The key question is: what is the meaning of the HISTORY.origin and EVENT.time attributes in these situations? It is tempting to say that their values are (as in other cases) just the times of the actual act of observation, e.g. microscopy, chromatography etc. However, there are two problems with this. Firstly, and most importantly, all physical samples must be understood as being indirect surrogates for some aspect of the patient state at the time of sampling, which cannot be observed by direct, instantaneous means in the way a pulse can be taken. This means that no matter when the laboratory work is done, the time to which the result applies is the sample time. It is up to the laboratory to take into account time delays and effects of decay of samples in order to provide a test result which correctly indicates the state of the patient at the time of sampling. The common sense of this is clear when one considers the extreme case where the patient is in a coma or dead (possibly for reasons completely unrelated to the problem being tested for) by the time laboratory testing actually occurs; however, the test result indicates the situation at the point in time when the sample was taken, i.e. when the patient was alive. The second reason is that some kinds of testing are themselves lengthy. For example fungal specimens require 4-6 weeks to confirm a negative result; checks will be made on a daily or weekly basis to find positive growth. However, the result data reported by the laboratory (and therefore the structure of the Observation) is not related to the timing of the laboratory testing; it is reported as being the result for the time of collection of the specimen from the patient.

The meaning therefore of the HISTORY.origin and EVENT.time attributes in openEHR is always the time of sampling. Where delays between sample and measurement times exist and are significant, they are noted in the protocol section of the Observation; such times are modelled in the appropriate archetypes, and taken into account in results.

State information is optional, and is not needed if the data are meaningful on their own. If it is recorded, it can either be as a History of its own (i.e. using the OBSERVATION.state atttribute described above), or else as state values within the EVENT instances in the OBSERVATION.data History. Both methods are useful in different circumstances. A separate state history is more likely to be used in a correlation study such as a sports medicine study on heartrate with respect to specific types of exercise. In this method, the state information is a History of Events whose times and widths need not match those of the History in the data attribute. The state data under this approach generally express the condition of the subject in absolute terms, i.e. they are standalone statements about the subject’s state at certain points in time, such as "walking on treadmill 10km/h, 10^o incline".

The other method will be used in most general medicine, e.g. for recording fasting and post glucose challenge states of a patient undergoing a glucose tolerance test. (See the Data Structures Information Model for more details). State values stored within the data History represent the situation in the subject at the time of the Event within the History and usually in relation to it, for example "post 8 hour fast". Recording the latter example in an independent state History would require an Event of 8 hours' duration called 'fast'. The latter would be technically still correct, but would be very unnatural to most clinicians. The figure below illustrates the two methods of recording state.

The Instruction and Action classes are designed to satisfy the following requirements:

The design approach is based on four principles. The first is that the specification of an Instruction as one or more Activities is distinguished from the information representing actions performed as a result. This makes the model and resulting information instances clear to software designers and data users. It also enables workflow engines to determine which parts of the specification have already been executed, and allows for Actions actually performed to differ from those specified. The separation is realised in terms of the INSTRUCTION and ACTION classes and their helpers. Instances of the former specify an Instruction, while instances of the latter describe steps which have actually been performed.

The second principle is the use of a standard instruction state machine (ISM) defining standardised states and transitions for each Activity of an Instruction, no matter what its clinical meaning. The use of standardised states means that the execution state of any given Activity can be characterised in exactly the same way (e.g. 'planned', 'active', etc), and that it is therefore possible to query the EHR and find out all interventions of any kind in a particular state. The ISM is formally modelled in openEHR. The Instruction itself can also be considered to be in a state derived from the states of its Activities. An informal description of this aggregate state machine is given below.

The third principle is to provide a way of mapping steps in any care pathway process (i.e. healthcare business process) to states in the Instruction state machine. A care pathway process covers the entirety of steps required to effect an Instruction, for example prescribing, booking, dispensing, referring, suspension etc. Any such step when performed leaves the relevant Instruction in one of the states of the ISM.

The fourth principle is to support the expression of the formal workflow definition for an Instruction, where full automation is required. It must be recognised that automation of most therapies and drug admnistration, as well as other interventions like biopsies is minimal today, and is likely to remain so for some time. This is for the simple reason that the cost of automating most tasks is prohibitive compared to human execution, particularly when Instruction activities can often be executed by healthcare professionals already present for other reasons (e.g. ward nurses). It also has to be said that serious research into the use of workflow automation in healthcare is only quite recent, and that so far, there are no standard models for clinical workflow. In the openEHR approach to modelling workflow, such uncertainty is dealt with in two ways. Firstly, formal workflow specification of an Instruction is an optional addition to the base model of Instruction and Action classes, and is not required to obtain a basic level of computability, including use of the ISM. Secondly, the formal expression of workflow is in the form of parsable syntax rather than objects. This is a generally appropriate design choice, since the safest and most convenient persistent form of of a complex formalism is the syntax form rather than the parsed fine-grained object form; this both optimises storage and allows for changes in the syntax over time.

Instruction definitions are modelled in terms of the INSTRUCTION and ACTIVITY classes, with optional workflow attributes. These two classes carry the basic information relating to an Instruction, with all formal workflow definition expressed in parsable syntax in the INSTRUCTION.wf_definition attribute. An INSTRUCTION instance includes the narrative description of the Instruction, and a list of ACTIVITY instances. It also includes all the attributes inherited from the CARE_ENTRY class, including subject, participations and so on.

Many Instructions will have only one Activity, usually describing a medication to be administered and its timing. Some will have more than one drug or therapy, such as the typical 3 drug Losec-HP regime for treating ulcers, and multi-drug chemotherapy. The base Instruction model does not explicitly try to indicate the exact order, serial or parallel administration, or other dependencies, since the knowledge of how to administer the drugs is known by the relevant clinicians, and/or contained in published guidelines. However, the timing information in each Activity does indicate times, days and the usual specifications of "with meals" etc. The timing information is also sufficient to specify a three drug chemotherapy regime, by indicating which days each drug is administered on. It is only when the Instruction is to be automated by a workflow engine that the full structure of the Activity graph will be given. Activity instances may be completely absent from an Instruction, in which case only the narrative will be present. This will typically occur with imported legacy data which itself has no structured representation of medications.

There are three possible levels of representation of an Instruction, as shown in the figure below. These are the minimal narrative-only level, a level with formal representation of Instruction activities by ACTIVITY instances, and a level where a formal workflow definition can also be used. It is expected that the vast majority of openEHR systems for the forseeable future will support only the minimal and basic levels.

The following figure illustrates the correspondence between Instruction and Activity structures, and Action objects that are created due to executing the instructions. Each Activity has a standard Instruction State Machine logically associated with it, indicated in blue. When any step in an Instruction Activity is executed within an ICT-supported environment, an ACTION instance describing what was done should be created and committed to the EHR. In some cases, ad hoc Actions are created even when there is no Instruction, such as by self-medicating patients and nurses reacting quickly to patient changes. For such Actions, there is always a notional Activity understood by the health professional.

All ACTIONs include the inherited CARE_ENTRY attributes, along with the time of being performed, a description of what was performed, and an ISM_TRANSITION object indicating the state of the Activity (whether explicit in an Instruction or not). The current state of an Activity is thus found not in the ACTIVITY instance but in the most recent ACTION instance for that Activity.

If the Action did correspond to an Instruction, it will also include an INSTRUCTION_DETAILS instance, which indicates which Activity of which Instruction was executed, including workflow execution details if relevant.

Under this scheme, the state of each intervention happening to the patient can be ascertained by querying, regardless of whether explicit Instructions exist.

Note particularly that Actions are often performed in a different provider location, or the home, rather than the provider organisation responsible for the Instruction. Action objects for a given Instruction can thus easily appear in multiple health record systems.

Timing information may be minimal and simplistic, or highly specified. As a consequence, there is no one method of representation that suits all purposes. The simplest expression of timing information is as informal narrative, as found in a prescription for antibiotics, such as "take 3 times a day, for 7 days, with meals". This may be represented using a text value in INSTRUCTION.narrative.

Formally computable representations can be expressed in two ways. The first is to use the ACTIVITY.timing field, of type DV_PARSABLE, which enables the use of syntaxes such as the ISO8601 'R' syntax. For example, 5 repetitions of the period '10 days' starting on 01 march 2008 is "R5/2008-03-01T13:00:00Z/P10D". However timing in clinical situations varies widely, and numerous other ways of expressing times are commonly required, ranging from simple frequencies, to complex patterns of time, association with events such as meals, menstrual period and so on. To accommodate such variant structures, which are generally beyond the capabilities of the ISO8601 syntax, the ACTIVITY.description attribute may be used to contain these timing structures.

The three approaches are illustrated below.

When an intervention defined by an Activity is unfolding in a clinical context, EHR users want to know things such as the following:

The approach chosen here to support such functionality is to define a standard instruction state machine whose state transitions can be mapped to the steps of a specific care pathway, enabling it to be used as a descriptive device for indicating the state of any Activity. The status of an Instruction is determined algorithmically from the states of the constituent Activities, as described below. The state machine is illustrated below.

This state machine is the result of long term experience with clinical workflows and act management systems. The states are as follows (Note: the SCHEDULED state was inspired by [Van_de_Velde_Degoulet_2003], Fig 5.5).

States CANCELLED, ABORTED and COMPLETED are all terminal states. The EXPIRED state is a pseudo-terminal state, from which transitions are allowed to proceed to any of the true terminal states, due to information being received after the fact (such as a patient reporting that they did indeed finish a course of antibiotics). However it is likely in the EHR that Instructions for many simple medications will finish in the EXPIRED state and remain there.

The transitions are self-explanatory for the most part, however a few deserve comment. The start and finish events correspond to situations when the administration is not instantaneous, as is the situation with most medications. The do event is equivalent to the finish event occurring immediately after the start event, corresponding to an instantaneous administration, completion of which puts the Activity in the completed state. A single shot vaccination or patient taking a single tablet are typical examples. The states PLANNED, POSTPONED, ACTIVE, SUSPENDED, each have a xxx_step transition which return the state machine to the same state. Workflow steps that cause no transition are mapped to these events and thus leave the Instruction in the same state. An example is a medication review, which will leave the medication in the ACTIVE state, if the physician chooses to continue.

In the future, if delegation of an Instruction to another Instruction is required, nesting of a new Instruction state machine within the Active state of a previous one might need to be supported.

The state machine states and transition names are defined in the openEHR terminology groups "Instruction states" and "Instruction transitions" respectively.

Each Activity within an Instruction constitutes a clinically identifiable medication or therapy of some kind, while the Instruction usually corresponds to a grouping or combination of therapies designed to treat an overall problem. Accordingly, the Instruction can be seen as having an aggregate state derived from the states of the Activities, as shown in the figure below. The rules for entering each aggregate state are indicated in terms of the states of the constituent Activities.

This state machine is not formally modelled or coded in openEHR, although it may be useful to do so within an application.

From a health professional’s point of view, a healthcare workflow, or 'careflow', consists of steps and events designed to meet one or more goals. The steps are highly dependent on the particular kind of workflow, and will usually be named in terms familiar to the relevant kinds of clinical professionals, such as "prescribe", "book", "suspend" and so on (note that some of these names may be the same as ISM transitions, but may or may not indicate the same thing). However, the need of users of health information is to know what state the execution of an Instruction is in, regardless of which particular careflow step might have just been executed. This is achieved by defining the mapping between the steps of a particular careflow to the states of the ISM in an Action archetype. When each Action corresponding to a particular Instruction Activity is performed, it will be known both which careflow step it corresponds to and which ISM state the Activity is now in. The following table provides an example of the mapping for a UK GP medication order workflow.

Mappings like this are specified in the ACTION archetypes for the Instruction. When an ACTION instance is committed to the EHR, the ISM_TRANSITION object records the step performed and the ISM state and transition. The careflow step must be one of the steps from the corresponding Instruction.

An optional reason property (of type List<DV_TEXT>) is provided in the ISM_TRANSITION class in order to enable one or more specific reasons for the step having occurred to be recorded.

The following section provides details of how archetypes are used to represent such mappings.

Much of the semantics of particular Instructions and Actions derive from archetypes. Currently, archetypes are used to define two groups of Instruction semantics. The first is the descriptions of activities that are defined in Instructions (ACTIVITY.description) and executed in Actions (ACTION.description). These descriptions are always of the same form for any given Instruction, and it is highly desirable to have the same archetype component for both. An example is where the description is of a medication, commonly consisting of a tree or list of ten or more elements describing the drug, its name, form, dose, route and so on. The same information structure is needed in the Instruction, where it defines what is to be administered, and in the Action, where it describes what has been administered. In any particular instance, there may be small differences in what was administered (e.g. dose or route are modified) even though the archetype model will be the same for both.

In terms of archetypes therefore, definition of say two ACTIVITYs in an INSTRUCTION (see example illustrated below) will actually create separate archetypes of the Activity structures, each of which will be one of the subtypes of ITEM_STRUCTURE (since this is the type of ACTIVITY.description and ACTION.description). The archetypes will then be used by both the INSTRUCTION archetype and the ACTION archetype, via the archetype slot mechanism (i.e. the standard way of composing archetypes from other archetypes; see use_archetype statements in the figure below).

The second category of archetypable semantics is the correspondence between steps in a healthcare business process and the standard instruction state machine, as described above. This mapping is an archetype of the ism_transition attribute of an ACTION attribute, and therefore defines part of the ACTION archetype. Instruction and Action Archetypes shows how logical archetype elements in the archetyped editor environment corresponds to the resulting archetypes.

Consequently, the set of archetypes defining the clinical semantics of a specific kind of intervention will normally consists of archetypes of INSTRUCTION, ACTION and potentially component archetypes of the ITEM_STRUCTURE classes.

The following figure illustrates three heartrate measurements over 10 minutes.

The following figure illustrates a blood pressure observation with protocol.

An oral glucose tolerance test takes the following form, although the number and timing of the blood sugar levels may be slightly different in practice:

OGTT is treated as a single clinical concept, and thus requires only one archetype. A typical instance structure is shown in the figure below. In this example, the three blood sugars are represented by EVENTs, with the fasting and glucose challenges being expressed as states on the relevant events.

The following figure illustrates a partial asthma management plan in which monitoring (peak flow) with dependent actions (review and admission to ER) and therapy (bronchodilator) are shown. In a complete plan, symptom monitoring and other medications might be shown. The parts of the plan are linked to the root EVALUATION node via the links: Set<LINK> attribute inherited from the LOCATABLE class.

Often, a medication order for one drug consists of segments in which one or more of the administration details of route, form, frequency, dose etc is changed. In hospitals, intravenous antibiotics and pain relief drugs may be followed by a tablet form of the same drug to be taken orally. Other examples are common in general practice, such as the following order:

The figure below illustrates the instance structure for this Instruction. Note that the timing attribute of the ACTIVITY instance is shown in human-readable form; in reality it will be a GTS string or similar (see Timing Specification section of openEHR Data Types IM).

A common regime for treating duodenal ulcer and related complaints is using Losec with other drugs, such as in the following combination:

The Instruction for this therapy is illustrated below.