EHR Extract Information Model

The assumed operational openEHR environment for openEHR Extracts is shown in the following figure. In this figure, a Request for "information from the records of one or more 'subjects'" is created by a Requesting system. A subject record may be a patient EHR, a Person record in a demographic system, or any other logically meaningful top-level entity. Responding system(s) reply in the form of one or more Extracts. The Request/Response interaction is enabled by a transport mechanism and possibly other services. This be be in the form of comprehensive middleware, web services, or simple point-topoint protocols such as SMTP (email) transport.

Information in Responding systems is assumed to be in the following form.

The above relationships reveal a hierarchy of potential 1:N relationships in the information accessible to the requesting system, with Contributions forming an alternative view of the content. At each level of the hierarchy, a system of identifiers is needed, e.g. to distinguish Subjects, to distinguish Versions and so on. In some specific circumstances, some of these may be reduced to 1:1 relationships, e.g. there may be no versioning, removing the need for specific identifiers for versions of an item.

The openEHR Extract defined in this specification can be used in non-openEHR environments, where the aim is to define messages whose content is expressed as templated archetypes. In general, not much can be assumed about the internal data architecture of such systems. For the purposes of this specification, the existence of two levels of information is assumed:

Regarding versioning in non-openEHR systems, it is assumed that some systems may support basic concepts including:

A typical environment in which Extracts can be used to send legacy information in archetyped form is one in which cross-enterprise communications are required, including discharge summaries and referrals. The content of such messages may be defined in terms of archetypes, and then templated in order to define the total content of the message.

In more advanced environments, there may be a health information location service which obviates the need for any knowledge on the part of the requestor about which systems contain information on a particular Subject of interest (e.g. a certain patient); in simpler environments, the requesting system may need to explicitly identify the target systems of the request. The diagram below illustrates a direct request and a request mediated by a location service.

This specification assumes that the EHR Request and Extract is between the Requesting system and each Responding system, even if the list of relevant Responding systems has been generated by a location service. In other words, this Extract specification does not encompass the idea of a compendium of Extracts from multiple Responding systems.

In the figure Figure 1 the lowest level of information shown in a Responding system is simply marked 'content'. This corresponds to top-level information structures such as Compositions, Folder trees, Parties etc in openEHR. Each such content item potentially contains a whole hierarchy of information items, only some of which is generally of interest to the Requestor. The typical database idea of a "query result" is usually expected to return only such fine-grained pieces. However, the Extract specification here only allows for a granularity of Compositions ('documents' etc), rather than fine-grained query responses which are dealt with by other means. This is because the primary use case of an Extract is to make parts of an EHR available somewhere else, rather than to intelligently query the record in situ and return the result.

Versioned health record systems are 'bitemporal' systems, because they include two notions of time. Times mentioned in the data relate to real world events or states, such as the time of diagnosis of diabetes, or the date of discharge of a patient from a hospital. Real world time is distinquished from system time, which is the time of events in the information system itself, such as committal of Contributions. Both real world time and system time may need to be specified in a Request.

A key clinical use case is the need to obtain some or all of a patient’s EHR from a remote system or systems. The request is most likely to be made due to the patient having been referred to another provider (including discharge to tertiary care), but other reasons such as falling ill while travelling will also figure.

The request might be made to an identified system, such as the system of the referring provider, or it may be made to all systems containing data on the given patient, if a health information location service is available.

The contents of the request may be specified in different ways, either by the clinician and/or the software, as follows:

The meaning of time is content-dependent. For Observations in an openEHR EHR, the sample times might be specified; for an Evaluation that documents a diagnosis, times for date of onset, date of last episode, date of resolution could all be specified.

A very common requirement for pathology laboratories is to be able to send result data for tests done for a number of patients, on a periodic batch basis, to a known receiver such as a hospital, clinic or state health system. The batch send is usually seen as a "standing request" by the receiver, and may be on a periodic basis (e.g. send all the results available every hour), an "as-available" basis, or according to some other scheme. Such data are currently often sent as HL7v2, Edifact or other similar messages.

In some circumstances, a request may be made for versions other than the latest of certain content. This might happen due to a study or medico-legal investigation that needs to establish what information was visible in certain systems at an earlier time. For example there may be a need to determine if the problem list, list of known allergies, and patient preferences were all compatible with the medications list at some earlier time.

As part of querying for previous versions, the revision histories of Versioned containers might be requested, in order to allow a user or software agent to determine which Versions are of interest.

In larger healthcare delivery environments such as state and regional health services, patients are routinely treated by multiple providers, some or all of which are part of a large distributed clinical computing environment. They may visit various clinics, specialists and hospitals, each of which has its own patient record for each patient. However, there is usually a need for centralised aggregation of patient data within the overall health authority, with updating required on a routine basis.

In such situations, the general requirement is for a request for update, typically for more than one patient, to be made once, and for it to be acted upon repeatedly until further notice. Specific requirements may include:

For these situations, the request can be persisted in the server. Even for one-off ad hoc requests, the requestor may require the request to be persisted in the server, so that it can be referred to simply by an identifier for later invocations.

There will be a need to be able to request information from openEHR systems and services other than the EHR, such as demographics and workflow, as they are developed. One likely purpose for such requests is for import from openEHR systems into non-openEHR systems, for example from an openEHR demographics service to an existing hospital Patient Master index.

It should be possible to use the same general form of request as used for an EHR. However, instead of specifying Extracts of patient records (EHRs), the data shared in these other cases will be whichever top-level business objects are relevant for that kind of service, e.g. PARTYs for the demographic service and so on.

One of the major uses of an openEHR system is as a shared EHR system, aggregating data from various existing systems in a standardised form. Data from such systems may be provided in different ways, including various messaging forms (HL7, Edifact), various kinds of EMR document (CEN EN13606, HL7 CDA), and other formats that may or may not be standardised.

The developers of some such systems may decide to provide an openEHR-compatible export gateway, capable of serialising various data into openEHR structures, particularly the Composition / GENERIC_ENTRY form (see openEHR Integration IM) which is highly flexible and can accommodate most existing data formats. Types of non-openEHR systems that may supply openEHR Extracts in this fashion include pathology systems and departmental hospital systems, such as radiology, (RIS), histopathology and so on.

Extract Requests might be specified in openEHR form (i.e. according to this document) or in some other form, such as web service calls or messages; either way, the logical request is the same, i.e. which patients, which content, which versions, and the update basis. The responses must be some subset of the openEHR Extract presented in this document.

Direct access by patients to their own health data outside of clinical encounters is a common aspiration of e-health programmes around the world. It seems clear that there will be various modes by which such access will occur, including:

Both the USB stick and email scenarios involve asynchronous access of EHR information, and can be addressed by the EHR Extract.

In the case of a portable device, the most obvious need is for the device to act as a synchronising transport between a home PC containing a copy of patient / family EHRs, and the EHR systems at various clinics that the patient visits. To achieve this, when changes are made at either place (in the home record or in the record held at a clinic), it should be possible to copy just the required changes to the device. In openEHR terms, this corresponds to copying Contributions made since the last synchronisation.

The email attachment scenario is more likely to involve Extracts containing either information requested by the patient in a similar manner as for the ad hoc clinical requests described above (e.g. most recent test result) or laboratory information in the form of an openEHR Extract, destined for integration into an openEHR EHR. In the latter case, the information is likely to be in the form of Compositions containing GENERIC_ENTRIEs, built according to legacy archetypes, although it could equally be in "pure" openEHR form (i.e. Compositions containing proper openEHR Observations).

A patient’s entire EHR may be moved permanently to another system for various reasons, due to the patient moving, a permanent transfer of care, or re-organisation of data centres in which EHRs are managed. This is known as change of custodianship of the record, and is distinct from situations in which copying and synchronisation take place.

The record is deleted (possibly after archival) from active use at the sending system. In these situations, the usual need is for an interoperable form of the complete EHR (including all previous versions) to be exported from the existing system and sent to the destination system, since in general the two systems will not have the same implementation platform, versioning model and so on. In some cases, the implementations may be identical, allowing a copy and delete operation in native representation could be used.

Since the openEHR Extract represents a generic, open standardised specification for representing clinical information, there is no reason why it cannot be used for systems that not otherwise implement openEHR. In this case, the Extract content is most likely to consist of Compositions and Generic_entries, and may or may not contain versioning information, depending on whether versioning is supported in the generating systems.

Content is specifiable in terms of matching criteria. This can take two forms: lists of specific top-level content items, or queries that specify top-level items in terms of matching subparts.

Queries are expressed in the Archetype Query Language.

The openEHR Extract supports detailed access to the versioned view of data. Which versions of the content should be returned can be specified in a number of ways:

Information transferred in an EHR Extract needs to be self-standing in the clinical sense, i.e. it can be understood by the requestor without assuming any other means of access to the responding system. In general, this means that for references of any kind in the transferred EHR data, the Extract needs to either contain the reference target, or else it must be reasonable to assume that the requestor has independent access, or else doesn’t need it.

Security becomes one of the most important requirements for the EHR Extract for the obvious reason of its exposure in potentially uncontrolled environments outside the (supposedly) secure boundaries of requesting or responding systems. The general requirement is that the contents of an Extract are based on:

Digital signing should be used based on the (preferably certified) public key of the requestor. Notarisation might also be used to provide non-repudiable proof of sending and/or receiving Extracts, although this is outside the scope of this specification.

In addition to specifying the content a basis for update also needs to be specified. The simplest possible case is that of an ad hoc one-off query. More complex cases are periodic update and event-driven update.

The EXTRACT_REQUEST class consists of an update_spec specifying rules for update (one-off, periodic, event-driven etc), and an extract_spec, indicating what information from the target repository is required. The latter consists of an optional version_spec, indicating which versions (default is latest) and a manifest, specifying which entities (records or subjects, and optionally which items from those entities should be included.

A key difference between an 'extract' or in fact any kind of message carrying information out of a system environment is that the Extract combines in one place information typically found in multiple services in the original environment. Two kinds of information routinely included in Extracts are clinical (i.e. EHR / EMR or similar) and demographic data regarding participations of the subject and other parties in the activities documented in the clinical information.

Within the openEHR EHR model, a 'participation' is defined by the PARTICIPATION class in the rm.common.generic package. Actual participation instances include a performer object (a subtype of PARTY_PROXY), and optionally an external reference object (type PARTY_REF). The latter contains a reference to the demographic entity within a demographic service, provider registry or similar. Within the Extract, participations occur in two places. In the EHR_EXTRACT class, participations are used to provide information about parties related to the Extract. These are created new with each Extract (i.e. they are not EHR data that is part of the Extract content. Accordingly, a simplified form of the PARTICIPATION class is used: EXTRACT_PARTICIPATION. The only difference is that the performer reference is a simple string, allowing it to contain a GUID reference to a demographic party included elsewhere in the same Extract.

Participations also occur in the actual content of the EHR, and in this case, they original structures are copied faithfully, including any in-line performer information. If there was an external_ref present, pointing to a demographic entity that is also to be included in the Extract, this reference is rewritten to point to a local copy of the demographic entity (using a GUID), within the Entity chapter of the Extract.

The result of this is that for source data whose original external references are to external demographic entities, the logical structure is completely preserved within the Extract, with just the reference being rewritten to the GUID values used in the Extract (which may well come from the original demographic database or service).

A typical arrangement is to dedicate a single chapter to all demographic entities referenced within the Extract, optionally with an internal Folder structure. Some example arrangements are illustrated in the EHR and generic Extract sections below.

Items from an openEHR sytem included in an EHR Extract are always top-level objects (Composition, Directory, EHR_EXTRACT, PARTY, etc, and descendants) are expressed in the serialisable form of descendants of X_VERSIONED_OBJECT<T>. This type provides a standard interoperable way to serialise all or part of VERSIONED_OBJECTs for lossless transmission between systems, regardless of the likely implementation differences in versioning at each end. Accordingly, X_VERSIONED_OBJECT turns most functional properties of VERSIONED_OBJECT into data attributes. The two attributes of most interest are revision_history, which enables the optional inclusion of the complete revision history from the original VERSIONED_OBJECT, and versions, which allows any or all of the versions to be included form the original. The revision history can be requested on its own using by setting the includes_data flag of the version specification to False.

In most scenarios, versions will be included, and revision_history excluded. Each item in X_VERSIONED_OBJECT.versions consists of a wrapped copy of an ORIGINAL_VERSION from the corresponding VERSIONED_OBJECT object in the source system.

The overall structure of the openEHR EHR for a subject can be replicated with an archetyped Folder structure that creates the groupings of directory, compositions, ehr_access, and ehr_status that are found in an openEHR EHR. This use of folders is not mandatory, but is likely to be useful in most cases, and is the structure shown in the figure Figure 10 above.

Within the content an EHR Extract, wherever PARTICIPATION and PARTY_PROXY structures occur (for the latter, the PARTY_SELF and PARTY_IDENTIFIED descendants), they are preserved intact, for reasons of fidelity. However, the final 'pointer', i.e. the OBJECT_ID.value may be rewritten within the Extract to correctly refer to the intended demographic. A typical S_PARTICIPATION structure is illustrated at the bottom of the figure Figure 10. In this figure, the OBJECT_ID.value has been rewritten to refer to the uid (11111111) of the first OPENEHR_CONTENT_ITEM object shown in the figure.

The GENERIC_CONTENT_ITEM subtype of EXTRACT_CONTENT_ITEM defines meta-data more or less of which can be populated by typical legacy systems, as well as document sources such as IHE/XDS repositories. Various groups of meta-data are defined: document type / status information, commit audit details and document lifecycle information.

The document meta-data items are as follows:

The next group of items defines details of creation of the original information. In some systems, this is the same as 'committal', i.e. the act of creating and committing the original data to the system. In other cases, the information in the extract is being assembled for the first time for the purposes of the extract, and the audit information therefore corresponds to this act. The audit details are as follows:

All of these items are optional, reflecting their varying availability in different source systems. An archetype or template of the Extract may force some or all to be mandatory for specific kinds of Extract.

The item attribute carries content which may be any openEHR LOCATABLE structure, including things like COMPOSITION, any kind of ENTRY including GENERIC_ENTRY, ITEM_TREE, or even CLUSTER. This is assumed to have been converted by some data transformation process from data within the original system.

The MESSAGE object may include a digital hash (i.e. digest or digital finderprint) of the serialised content, made for example using the SHA-1 or MD5 algorithms. The purpose of the digest is to provide an integrity check on the data. This protects against non-malicious changes to the data (e.g. due to software bugs, incorrect transaction management). Often this will be acceptable within secure, closed environments, such as a private hospital or community health network.

Protection against malicious modification can be provided by encryption.