EHR Information Model

From the European GEHR project 1992-5 (Ingram, 1995), the following broad requirements areas were identified:

The original deliverables can be reviewed in detail at the GEHR page at CHIME, UCL.

The GEHR Australia project (1997-2001; Heard (2001), Beale & Heard (2000)) introduced further requirements, including:

GEHR Australia produced a proof of concept implementation in which clinical archetypes were developed and used. See Beale (2000) for a technical description of archetypes.

Following the original Good European Health Record project the EU-funded Synapses (1996-8; Grimson & Groth (1996)) and SynEx (1998-2000; Sottile Ferrara Grimson Kalra & Scherrer (1999)) projects extended the original requirements basis of GEHR to include further requirements, as follows:

This EU Support Action project ('SupA'; Dixon Grubb Lloyd & Kalra (1998), Dixon Grubb & Lloyd (2000), Dixon Grubb & Lloyd (2000)) consolidated the requirements published by a wide range of European projects and national health informatics organisations as a Consolidated List of Requirements (Dixon, Grubb, Lloyd, & Kalra, 2001).

The above requirements publications and the recent experience of openEHR feed into the definition of a set of EHR requirements authored by ISO Technical Committee 215 (Health Informatics) - ISO 18308. This has been reviewed and a mapping to openEHR developed.

New requirements generated during the development of openEHR included the following:

These models have been influenced by and have also influenced the models in ISO 13606 (2005 revision); accordingly, relationships to 13606 have been documented fairly precisely. Particular areas of openEHR which have been changed due to this process include:

Implementation experience with Release 0.9 and 0.95 of openEHR has further improved these areas significantly. Nevertheless, openEHR is not a copy of CEN, for two reasons. Firstly, its scope includes systems, while ISO 13606 defines an EHR Extract; secondly, ISO 13606 suffers somewhat from 'design by committee", and has no formal validation mechanism for its models.

Correspondences to some parts of HL7 version 3 (ballot 5, July 2003) are also documented where possible, however, it should be understood that there are a number of difficulties with this. Firstly, while the HL7v3 Reference Information Model (RIM) - the closest HL7 artifact to an information model - provides similar data types and some related semantics, it is not intended to be a model of the EHR. In fact, it differs from the information model presented here (and for that matter most published information models) in two basic respects: a) it is an amalgam of semantics from many systems which would exist in a distributed health information environment, rather than a model of just one (the EHR); b) it is also not a model of data, but a combination of "analysis patterns" in the sense of Fowler (1997) from which further specific models - subschemas - are developed by a custom process of "refinement by restriction", in order to arrive at message definitions. As a consequence, data in messages are not instances of HL7v3 RIM classes, as would be the case in other systems based on information models of the kind presented here.

Despite the differences, there are some areas that appear to be candidates for mapping, specifically the data types and terminology use, and the correspondence between openEHR Compositions and parts of the HL7 Clinical Document Architecture (CDA).

In general, the openEHR information models represent a more recent analysis of the required semantics of EHR and related information than can be found in the information viewpoint of the OMG HDTF specifications (particularly OMG PIDS and OMG COAS. However, the computational viewpoint (i.e. functional service interface definitions) is one of the inputs to the openEHR service model development activity.

The root EHR object records three pieces of information that are immutable after creation: the identifier of the system in which the EHR was created, the identifier of the EHR (distinct from any identifier for the subject of care), and the time of creation of the EHR. Otherwise, it simply acts as an access point for the component parts of the EHR.

The system_id attribute is used to record the identifier of the logical EHR repository to which the data containing the audit are committed. What constitutes a 'system' in this context is described in more detail in the Architecture Overview.

References rather than containment by value are used for the relationship between the EHR and VERSIONED_X objects, reflecting the vast majority of retrieval scenarios in which only selected (usually recent) items are needed. Containment by value would lead to systems which retrieved all VERSIONED_X objects every time the EHR object was accessed.

Access control settings for the whole EHR are specified in the EHR_ACCESS object. This includes default privacy policy, lists of identified accessors (individuals and groups) and exceptions to the default policies, each one identifying a particular Composition in the EHR. All changes to the EHR Access object are versioned via the normal mechanism, ensuring that the visible view of the EHR at any previous point in time is reconstructable.

Because security models for health information are still in their infancy, the openEHR model adopts a completely flexible approach. Only two hard-wired attributes are defined in the EHR_ACCESS class. The first is the name of the security scheme currently in use, while the second (settings attribute) is an object containing the access settings for the EHR according to that particular scheme. Each scheme is defined by an instance of a subclass of the abstract class ACCESS_CONTROL_SETTINGS, defined in the Security Information Model.

The EHR_STATUS object contains a small number of hard-wired attributes, and an archetyped other_details part. The former are used to indicate who is (currently understood to be) the subject of the record, and whether the EHR is actively in use, inactive, and whether it should be considered queryable. As for elsewhere in the openEHR EHR, the subject is represented by a PARTY_SELF object, enabling it to be made completely anonymous, or alternatively to include a patient identifier. The subject is included in the EHR Status object because it can change, due to errors being discovered in the allocation of records to patients. If the anonymous form is used, the change will be made elsewhere in a cross-reference table; otherwise the EHR Status object will be updated. Because it is versioned, all such changes are audit-trailed, and the change history can be reconstructed.

Other EHR-wide meta-data may be recorded in the archetyped part of this object, including runtime environment settings, software application names and version ids, identification and versions of data resources such as terminologies and possibly even actual software tools, configuration files, keys and so on. Such information is commonly versioned in software configuration management systems, in order to enable the reconstruction of earlier versions of software with the correct tools. One reason to store such information at all is that it adds to medico-legal support when clinicians have to justify a seemingly bad decision: if it can be shown that the version of software in use at the time was faulty, they are protected, but to do this requires that such information be recorded in the first place.

The main data of the EHR is found in its Compositions, i.e. instances of the COMPOSITION class in the RM. Composition is based on the notion of a unit of information resulting from the interaction of a healthcare agent (subject or healthcare professional) with the EHR. It is designed to satisfy the following needs, which include the well-known ACID characteristics of transactions (Gray & Reuter, 1993).

The Composition concept originated from the 'Transaction' concept of the GEHR project (Lloyd, 1992), (Lloyd, 1993), (Heard, Kalra, & Ingram, 1994), (Beale, Lloyd, Heard, Kalra, & Ingram, 1995). In openEHR, it was renamed to 'Composition' (the name of the equivalent concept in ISO 13606-1), and it has been expanded and more formally defined in openEHR in two ways. Firstly, the idea of a unit of committal has been formalised by the openEHR model of change control (see the openEHR Common Information Model); how this applies to the EHR and Compositions is described below.

Secondly, the informational purpose of a Composition is not just to capture data from a passing clinical event such as a patient contact, but also to track longitudinal significant patient state, such as problems, allergies and medications. Accordingly, openEHR Compositions are temporally classified using a small number of broad categories recorded in the COMPOSITION.category attribute. Categories include event, episodic and persistent. From a scientific realist ontological point of view, the kind of information recorded in a persistent Composition approximates a description of some continuant aspect of the patient (see Arp Smith & Spear (2015), Sowa (2000)). This is in contrast with event Compositions, which record occurrents, i.e. events or states that occurred or were true at some moment in time. The episodic category corresponds to information that is relevant for the period of time of a care episode.

As Compositions accumulate over time in the EHR, they form a long-term patient history. The folders structures can be used in the EHR to index Compositions using one or more versioned hierarchies of FOLDER objects. In the openEHR model, Folder structures do not contain Compositions, only references to them. More than one Folder can therefore refer to the same Composition or other target object. If folders is not Void, the directory attribute always contains a reference to the first member, for backward compatibility with pre-Release 1.1.0 systems.

Structurally, each reference in folders points to a logical tree of FOLDER objects each potentially containing references to COMPOSITIONs, or possibly just more FOLDERS. Each such tree is versioned, i.e. each version of one folder tree contains a modified version of the previous state of the tree. Folder trees consist of FOLDER objects, which inherit from the LOCATABALE, enabling archetypes to be used to define specific folder tree structures. Within a Folder archetype, the details attribute may be configured to contain meta-data specific to the purpose of the Folder (tree).

The directory reference may be considered by convention as referring to a folder hierarchy that is shared by all users of the EHR to which it is attached, e.g. all medical specialities, departments or settings. It might thus be used to represent episodes. In this case, the other Folder hierarchies referred to by folders might be created, maintained and used by different departments, specialities etc. However, completely different usage of the folder structures is possible. Use of Folder archetypes should be considered for communicating the intended usage in a particular system.

In any Folder hierarchy, regardless of specific use, Folders may be added or removed contemporaneously or subsequently to the committal of the referenced Compositions, including after substantial time has passed. Contemporaneous additions would normally be included in the same Contribution as the referenced Compositions. Similarly, at any time, an entirely new Folder hierarchy may be added, which will be referenced by a new member of the EHR.folders attribute.

Semantically, Folders may be used to manage a simple classification of Compositions, e.g into Event and Persistent, or they might be used to create categories based on episodes or other groupings of Compositions.

A Folder structure containing references to Compositions is shown below, in which the following Folders are used:

This structure separates out Compositions on the basis of likely access by applications. Persistent Compositions remain relevant, usually for the patient lifetime, consequently need to be quickly accessible by numerous applications views. Event Compositions contain information whose relevance may fade quickly (e.g. vital signs measurements) or which are effectively indexed by various persistent compositions (e.g. diagnoses). They are indexed in this example by a Folder structure that makes it easy to find Compositions on the basis of problem type (diabetes etc), and then by type of visit.

Neither the Folder names nor the Composition names illustrated above are part of the openEHR EHR reference model: all such details are provided by archetypes; hence, EHR structures based on completely different conceptions of division of information, or even different types of medicine are equally possible.

The Folder hierarchy in each member of the folders attribute is maintained in its own versioned object, ensuring that changes to the indexing structure are versioned over time in the same way as changes to the EHR content itself.

Items in the EHR may be tagged using openEHR tags, which are lightweight annotations that may be used to thematically classify previously committed data items for convenient subsequent retrieval. They are described in detail in the Common IM Tags section.

Tags are associated with an EHR via the EHR.tags attribute, but have no direct association with the objects they annotate. This has the following consequences:

The last point implies that if there is a tag "clin-proj-27a" and it is used on 13 EHR content items, there will be 13 separate tag instances with key = "clin-proj-27a". If one is modified or deleted, it has no effect on the others.

According to the model, all tags reside within one logical list, i.e. EHR.tags. No grouping is used. In order to achieve efficient access of all tags with the same key, indexing would be required.

The primary use of tags post-creation is in querying, and their use is supported directly in the openEHR AQL query language such that a query mentioning a tag (either by key, or key/value pair if applicable) will return all items of any RM type annotated by the tag in question.

Versioning of Compositions is achieved with the VERSIONED_OBJECT<T> type from the Common IM change_control package, which in the composition package is explicitly bound to the COMPOSITION class, via the class VERSIONED_COMPOSITION which inherits from the type VERSIONED<COMPOSITION>.

The effect of version control on Compositions is visualised in the figure below. The versions (each version being an ORIGINAL_VERSION<COMPOSITION>) shown here in a VERSIONED_COMPOSITION are the same versions shown along each vertical line in Figure 8, this time shown with their associated audit items. The set of versions are understood as a set of successive modifications of the same data in time.

The VERSIONED_COMPOSITION can be thought of as a smart repository: how it stores successive versions in time is an implementation concern (there are a number of intelligent algorithms available for this), but what is important is that its functional interface enables any version to be retrieved, whether it be the latest, the first, or any in between.

The following scenarios for creating new COMPOSITION versions have been identified as follows.

In summary, the AUDIT_DETAILS is always used to document the addition of information locally, regardless of where it has come from. If there is a need to record original audit details (via the COMPOSITION.feeder_audit), they become part of the content of the versioned object.

openEHR EHRs are created due to two types of events. The first is a new patient presenting at the provider institution. An EHR may be created due to this event, without reference to any other openEHR EHRs that may exist in the broader community or jurisdiction. In this case, the EHR will be allocated a new, globally unique EHR id. This establishes the new EHR as an intentional clone of the source EHR (or more correctly, part of the family of EHRs making up the virtual EHR for that patient).

On the other hand, an openEHR EHR may be created in an organisation as a logical clone (probably partial) of an EHR for the patient that exists in some other system. This might happen as a normal part of the front-desk registration / admission process, i.e. the local EHR system is able to interrogate an EHR location service and discover if any other EHR exists for this patient, or it may occur due to purely electronic communications between two providers, i.e. the EHR is created because an Extract of an EHR has been sent from elsewhere as part of a referral or similar communication. In this second case, the EHR id should be a copy of the EHR id from the other institution. In all cases, the EHR.system_id value should be set to the value that would normally be used for locally created EHRs. In the case of creating a cloned EHR, the system_id is from the receiving (cloning) system.

In theory such a scheme could guarantee one EHR id per patient, but of course in reality, various factors conspire against this, and it can only approximate it. For one thing, it is known that providers routinely create new EHRs for a patient regardless of how many other EHRs already exist for that patient, simply because they have no easy way to find out about those EHRs. Ideally, this situation would be improved in the openEHR world, but due to reliance on such things as distributed services and reliable person identification, there are no guarantees. The best that can be said is that the EHR id allocation scheme can help support an ideal EHR id-per-patient situation if and when it becomes possible.

When an EHR is created, the result should be a root EHR object, an EHR Status object, and an EHR Access object, plus any other house-keeping information the versioning implementation requires. In a normal implementation, the EHR Status and EHR Access objects would be created and committed in a Contribution, just as any Composition would be. The EHR Status object has a special status in the EHR, indicating whether the EHR should be included in querying, whether it is modifiable, and by implication, whether it is active. Flags might be set to indicate that it is test record, or for educational or training purposes. The initial creation operation has to supply sufficient parameters for creation of these two objects, including:

The EHR id will either be a new globally unique identifier, in the case of first time EHR creation for this patient in the health system, or else the same identifier as an existing EHR for the same subject in another system, in the case of an EHR move or copy. The effect of EHR copying / synchronising between systems is that EHRs with the same identifier can be found within multiple systems. However if the same patient presented at multiple provider locations with no EHR sharing capability, a new EHR with a unique identifier will be created at each place. If a later request for copying occurs (e.g. due to a request for an EHR Extract) between two providers, the requesting institution will perform the merge of the received copy into the existing EHR for the same patient.

The main consequences in a distributed environment are as follows:

Note that the first situation is not a problem, and is not the same as the situation in which two EHRs are identified as being for different patients (i.e. subject id rather than EHR id is different) when in fact they are for the same person.

The openEHR EHR model takes account of a systematic analysis of "context". Contexts in the real world are mapped to particular levels of the information model in a clear way, according to the scheme shown in FIGURE 12. On the left hand side is depicted the context of a data-entry session in which the information generated by a "healthcare event", containing "clinical statements", is added to the EHR. A healthcare event is defined as any business activity of the health care system for the patient, including encounters, pathology tests, and interventions. A clinical statement is the minimal indivisible unit of information the clinician wants to record. Clinical statements are shown in the diagram has having temporal and spatial structure as well as data values. Each of these three contexts has its own audit information, consisting of who, when, where, why information.

On the right-hand side of Figure 15, the EHR recording environment is represented. The EHR consists of distinct, coarse-grained items known as Compositions added over time and organised by Folders. Each Composition consists of Entries, organised by Sections within the Composition. The audit information for each context is recorded at the corresponding level of the EHR.

The composer is the person who was primarily responsible for the content of the Composition. This is the identifier that should appear on the screen. It could be a junior doctor who did all the work, even if not legally responsible, or it could be a nurse, even if later attested by a more senior clinician; it will be the patient in the case of patient-entered data. It may or may not be the person who entered and committed the data. it may also be a software agent. This attribute is mandatory, since all content must be been created by some person or agent.

Since in many cases Compositions will be composed and committed by the same person, it might seem that two identifiers COMPOSITION.composer and VERSION.audit.committer (which are both of type PARTY_PROXY) will be identical. In fact, this will probably not be the case, because the kind of identifier to represent the composer will be a demographic identifier, e.g. "RN Jane Williams", "RN 12345678", whereas the identifier in the audit details will usually be a computer system user identifier, e.g. "jane.williams@westmead.health.au". This difference highlights the different purposes of these attributes: the first exists to identify the clinical agent who created the information, while the second exists to identify the logged-in user who committed it to the system.

In the situation of patient-entered data, the special "self" PARTY_PROXY instance (see Common IM generic package) is used for both COMPOSITION.composer and VERSION.audit.committer.

An example of an section tree representing the problem/SOAP heading structure is shown below.

All information which is created in the openEHR health record is expressed as an instance of a class in the entry package, containing the ENTRY class and a number of descendants. An ENTRY instance is logically a single 'clinical statement', and may be a single short narrative phrase, but may also contain a significant amount of data, e.g. a microbiology result, a psychiatric examination, a complex prescription. In terms of clinical content, the Entry classes are the most important in the openEHR EHR Information Model, since they define the semantics of all the 'hard' information in the record. They are intended to be archetyped, and in fact, archetypes for Entries make up the vast majority of important clinical archetypes defined.

The design of entry package is based on the Clinical Investigator Recording process and ontology, described in Beale & Heard (2007). The process is shown in following figure.

This figure shows the cycle of information created by an iterative, problem solving process undertaken by a "clinical investigator system", which consists of health carers, and may include the patient (at points in time when the patient performs observational or therapeutic activities). Starting from the patient (right hand side of figure) observations are made, which lead to opinions on the part of the investigator, including assessment of the current situation, goals for a future situation, and plans for achieving the goals. Personal and published evidence and knowledge almost always play an important part in this process. The latter lead to instructions designed to help the patient achieve the goals. A complex or chronic problem may take numerous iterations - possibly a whole lifetime’s worth - with each step being quite small, and future steps depending heavily on past progress. The role of the investigator (and associated agents) is normally filled by health care professionals, but may also be filled by the patient, or a guardian or associate of the patient. Indeed, this is what happens every time a person goes home from the pharmacy with prescribed medication to take at home.

The process illustrated in Figure 19 is a synthesis of the 'problem-oriented' approach of Weed (1969) and the "hypothetico-deductive model" of clinical reasoning described by Elstein Shulman & Sprafka (1978). However, as pointed out in Elstein & Schwarz (2002), hypothesis-making and testing is not the only successful process used by clinical professionals - evidence shows that many (particularly those older and more experienced) rely on pattern recognition and direct retrieval of plans used previously with similar patients or prototype models. The investigator process is compatible with both cognitive approaches, since it does not say how opinions are formed, nor imply any specific number or size of iterations to bring the process to a conclusion. As such, the openEHR information model does not impose any process model, only the types of information used.

On the basis of this process, a Clinical Investigator Recording ontology is developed (Beale & Heard, 2007), as shown below. From this ontology, the openEHR class model for Entries is derived. The openEHR Entry class names are annotated next to their originating ontological categories.

The key top-level categories in the ontology are 'care information' and 'administrative information'. The former encompasses all statements that might be recorded at any point during the care process, and consists of the major subcategories 'history', 'opinion' and 'instruction', which themselves correspond to the past, present and future in time (ISO TC215 uses the terms 'retrospective', 'current' and 'prospective'). The administrative information category covers information which is not generated by the care process proper, but relates to organising it, such as appointments and admissions. This information is not about care, but about the logistics of care being delivered. Categories that relate to the patient system as observed and understood are shown as white bubbles, while categories that relate to intervention into the patient system are shown as shaded. The opinion category has features of both passive analysis and active intervention.

There are two key justifications for using the ontology in Figure 20 as a basis for class design. Firstly, although for all categories in the ontology there is a meaning for 'contextual' attributes of time, place, identity, reason and so on, each category has a different structure for these attributes. For example, time in the Observation category has a linear historical structure, whereas in Instruction it has a branching, potentially cyclic structure. The separation of types allows these contextual attributes to be modelled according to the type. Secondly, the separation of types provides a systematic solution to the so-called problem of "status" or "meaning modification" of clinical statement values, as described below.

A well-known problem in clinical information recording is the problem of assigning "status", including variants like "actual value of P" (P stands for some phenomenon), "family history of P", "risk of P", "fear of P", as well as negation of any of these, i.e. "not/no P", "no history of P" etc. A proper analysis of these so called statuses [4] shows that they are not "statuses" at all, but different categories of information as per the ontology. The common statement types mentioned here are mapped as follows:

In general, negations of the kind mentioned above are handled by using "exclusion" archetypes for the appropriate Entry type. For example, "no allergies" can be modelled using an Evaluation archetype that describes which allergies are excluded for this patient.

Another set of statement types that can be confused in systems that do not properly model information categories concern interventions, e.g. "hip replacement (5 years ago)", "hip replacement (planned)", "hip replacement (ordered for next tuesday 10 am)". Ambiguity is removed here as well, with the use of the correct information categories, e.g. (I stands for an intervention):

Related to the problem of clinical status is the need to differentiate between diagnoses that have been made in the present from those that were made in the past, and are reported by the patient. In openEHR, diagnosis and indeed all opinion category types are modelled as Evaluations, regardless of when they were made. Time information for diagnosis and other opinions is simply handled within the archetype for Evaluation, enabling a diagnosis (say of diabetes) that was made 15 years ago to have the same status as one made during the period when the EHR was actually operating, and the patient was under the care of the physician using it. Archetypes for the opinion categories tend to have quite a number of times, including "time first noticed", "time of onset", and so on.

Correct use of the categories from the ontology is facilitated by using archetypes designed to map particular kinds of clinical statement to particular ENTRY subtypes. In a system where Entries are thus modelled, there will be no danger of incorrectly identifying the various kinds of Entries, as long as the Entry subtype, time, and certainty/negation are taken into account.

Commonly used types of clinical information are directly representable using the openEHR Entry types. As described in Section 4.2.4, two kinds of Composition are identified: persistent and event. The persistent kind corresponds to information that characterises the patient in the long term, and is maintained by clinicians - it can be thought of as a proxy "model of the patient". Most of the following are examples of Entry level data belonging inside persistent Compositions:

The remaining vast majority of remaining clinical information is recorded inside event Compositions, and includes the following:

The above concepts are defined in terms of archetypes of Entry and other reference model types in openEHR; their definition is therefore completely separate from the reference model.

The general approach of openEHR is to enable the complete separation of demographic (particularly patient-identification information) from health records, both in the interests of privacy (in some cases required by national legislation) and separated data management. The Demographic IM therefore defines demographic information. However, there is nothing to prevent certain demographic information occurring in the EHR, and in some cases this is desirable. The two main cases for this are:

The model of all information intended for a separate openEHR demographic service (itself usually a front-end to an existing hospital master patient index or similar) is defined in the openEHR Demographic Information Model.

All Entries have a number of attributes in common. The language and encoding attributes indicate how all text data within the Entry are to be interpreted linguistically and at the character set level. Normally, the language will be the same throughout the entire Entry (if not Composition), but in cases where it is not, the optional language attribute of DV_TEXT can be used to override the value in the enclosing ENTRY (or other enclosing structure, if a DV_TEXT is being used in some other context). Character encoding can be overridden in the same fashion by the encoding attribute within DV_TEXT.

The other attributes common to all Entry subtypes are as follows:

Note that the term 'provider' as used here should not be confused with the more specific healthcare term used in many english-speaking countries meaning 'health care provider', which is usually understood to be a physician or healthcare delivery enterprise such as a hospital. In the model here, it simply means 'provider of information' in the context of an Entry. The information provider is optional, and in many cases will not be recorded, since it will be obvious from the composer and other_participations of the enclosing Composition. In many cases, it is not sensible to record a provider, e.g. in the most mundane case where a GP asks "where does it hurt" and the patient says "here" - in such cases, it can only be considered mutual. It is expected to be used only when the composer of the Composition really needs to specify the origin of specific statements, such as in the following circumstances:

A basic division occurs between clinical and non-clinical information. The CARE_ENTRY class is an abstract precursor of classes that express information of any clinical activity in the care process around the patient, while ADMIN_ENTRY is used to capture administrative information. The division may occasionally seem ambiguous at a theoretical level, but at a practical level, it is almost always clear. Administrative information has the following characteristics:

Conversely, every instance of a CARE_ENTRY subtype is clinically significant, even if it also carries information which might be of interest to other health management functions billing (e.g. ICD10 coded diagnoses), practice management (e.g. date, time and place in an order for day surgery). The CARE_ENTRY type includes two attributes particular to all clinical entries, namely protocol and guideline_id.

These attributes allow the 'how' and 'why' aspects of any clinical recording to be expressed. Protocol is often recorded for Observations, e.g. staining method in microscopy, and Instructions, e.g. Bruce protocol for ECG test.

Instances of the OBSERVATION class record the observation of any phenomenon or state of interest to do with the patient, including pathology results, blood pressure readings, the family history and social circumstances as told by the patient to the doctor, patient answers to physician questions during a physical examination, and responses to a psychological assessment questionnaire. Observations are distinguished from Actions in that Actions are interventions whereas Observations record only information relating to the situation of the patient, not what is done to him/her.

The significant information of an Observation is expressed in terms of 'data', 'state' and 'protocol'. The first of these is recorded in the data attribute, defined as follows:

State information can be recorded in the state attribute of Observation, or within the state attribute of each Event in the Observation data attribute (see below and also Data Structures IM for more detailed explanations). The state attribute in Observation is defined as follows:

The inherited protocol attribute is defined as follows:

The detailed semantics of Observation data are described in the following subsections.

According to the ontology described in Beale & Heard (2007), the Opinion category covers a number of concrete concepts, as follows.

The approach taken to modelling these concepts in openEHR is heavily based upon the development of archetypes for assessments such as "diagnosis" (various kinds), "goal", "adverse reactions", "alert", "exclusion", "clinical synopsis", "risk based on family history" and so on. Experience has shown that the Opinion category is too variable for safely modelling its sub-categories directly in the reference model. Instead, a single class EVALUATION is used for all instances of the Opinion category. (The name Evaluation has been present in openEHR for some years, and is retained for reasons of continuity).

The design of the EVALUATION class is very simple. In addition to the attributes inherited from ENTRY and CARE_ENTRY, it has only one attribute, data: ITEM_STRUCTURE. This structure is intended to be archetyped so as to model all the details of any particular clinical information in the Opinion category. No timing attributes are included, since there is no time associated with creation or capturing of Evaluation information as such, only times included in the information. The only times of generic significance are (potentially) the time of a patient consultation during which the Evaluation was created (recorded in COMPOSITION.event_context.start_time and end_time) and the time of committal to the EHR system (recorded in VERSION.commit_audit attribute).

The general meaning of the inherited attributes is as for all Entries. In Evaluations, the provider is almost always the physician, while the protocol may be used to indicate how a particular assessment was made. The other_participations attribute is not as likely to be used for Evaluations representing diagnoses, since a diagnosis is usually the result of thinking on the part of the physician; an exception to this would be a case conference or if an expert system were used. However, Plans for complex patients may well be constructed by multiple physicians.

Instructions in openEHR specify actions to be performed in the future. They differ from information in the Proposal sub-category of Opinion in the ontology (i.e. instances of Evaluation in the class model) in that they are specified in sufficient detail to be directly enacted without further clinical decision-making related to the design of the Instruction, e.g they can be performed by the patient or a nurse. Any decisions that could be made during the performance of an Instruction are either constrained by the Instruction itself (e.g. dose range; suspend if adverse reaction) or else are assumed knowledge of the expected performer. For example, an Evaluation may say that "oral cortico-steroids are indicated at a peak flow of 200 l/m". A corresponding Instruction would indicate the actual drug, route, dose, frequency, and so on. The informed patient might be reasonably expected to be able to vary the dosage on his or her own within a dosage guideline explained by his/her GP.

In the ontology shown in Figure 20, Instructions are further categorised as Investigation and Intervention. However, as for Evaluation, only a single key class, INSTRUCTION, is used to model all types of the Instruction category, with archetypes defining the details of the Instruction. A second Entry subtype, ACTION, is used to model the information recorded due to the execution of an Instruction by some agent.

The following subsections describe Instruction and Action in some detail.

Clinical workflows exist at multiple hierarchical levels, from the health system level (reduce diabetes costs; manage obesity) to the fine-grained (asthmatic medication prescription for a particular patient). At all levels, there are goals, actors and tasks designed to satisfy the goals. At a coarse-grained business process level, workflows may be enacted by more than one actor, and may encompass the whole cycle of Observation, Diagnosis, Instruction and Action. For example a workflow describing the steps "prescribe", "dispense", "administer", "repeat", "review" and so on, around a medication order might include GP, pharmacist, patient as actors. At the finer level of an actual drug or therapy administration, there is usually a single agent or group that performs a specific task, usually within one provider institution, or at home. The correspondence between workflows at these different levels and particular patients, rather than just categories of patients (e.g. all insulin-dependent diabetics), typically increases at finer levels of granularity. Thus from the point of view of automation, it is likely to be fine-grained workflows that have patient-specific definitions which would reasonably appear in the EHR. Most typical medication administrations are in this category. How automated workflow definitions at higher levels of organisational hierarchy are represented and coordinated with lower-level automated workflows is known to be a difficult problem generally, and given that health computing is generally more complex than most domains, implementation of distributed, coordinated (or "orchestrated" or "choreographed", to use the terms of the workflow community) clinical workflows is likely to be some years off.

In this context, the possible scope for formal workflow definition in openEHR appears to be as follows:

There are various technical challenges with proposing a standard workflow formalism for clinical use. Firstly, executable workflow definitions are essentially structured programs, similar to programs in procedural languages, but with the addition of temporal logic operators, including alternative paths, parallel paths, wait operations, and also references to outside data sources and services. Recent work in clinical workflow modelling e.g. Müller (2003), Barretto (2005), Browne (2005) appears to favour a structural (i.e. parse-tree) approach to representation, due to the need to compute potential modifications to an executing workflow, including dropping, replacing and moving nodes. (Whether such "live" modification of executing workflows is realistic from the designer’s point of view might be questionable, since it means that the design of each workflow has include every possible exceptional case at a detailed level.)

Secondly, the need to connect workflows to the outside world, i.e. data sources and services like notification and worklist management is crucial in making workflows and guidelines implementable. This problem is probably the main weakness of all guideline and workflow languages to date, including Arden, GLIF, and the various workflow languages such as those mentioned earlier.

The approach taken by the current release of openEHR in representing computable workflow is the following.

The entire definition of a workflow is expressed as an optional parsable string, in the wf_definition : DV_PARSABLE attribute of the INSTRUCTION class. Any syntax may currently be used. A workflow syntax is under development by the openEHR Foundation, which is designed to incorporate the relevant features of current workflow models and research, while integrating it into the openEHR type system and archetype framework. In particular, early versions of this syntax will show how patient data access and service commands can be expressed.