openEHR to ISO 13606-1, ISO 21090 mapping

Introduction

This page provides information on which a technical solution to bidirectional openEHR / ISO 13606 conversion can be based. Since ISO 13606 uses the ISO 21090 pre-standard for data types, this mapping necessarily involves an openEHR datatype <-> ISO 21090 mapping as well. Key points to note:

• there is currently no profile of 21090 (data types) for use in 13606; this means that 13606 currently uses the 'vanilla' 21090 schema and semantics. However many of these don't apply, and guidance now needs to be developed for them in the 13606 context.
• the requirements for round-tripping faithfully between 13606 and openEHR have not yet been defined. This will essentially be up to users.

ISO 13606-1

ISO 13606-1 is the model of an EHR Extract, designed to enable data to be shared between EHR systems. Technically it resembles the openEHR reference model, but in a simplified way. In particular , the ENTRY types of openEHR are mapped to a single ENTRY type in 13606, but this is not the only difference. A mapping algorithm is being developed that shold allow a bidirectional transform between openEHR and 13606. The algorithm uses two types of mapping:

• pre-defined class and attribute conversions, such as for the 13606 AUDIT_INFO class and the openEHR AUDIT_DETAILS class
• a generic algorithm that can be applied between ENTRYs

Predefined conversion rules

Common IM structures

Section & Entry structures

Sub-ENTRY structures

ENTRY Conversion Algorithm (algorithm #1)

To convert between any openEHR concrete ENTRY type, such as OBSERVATION, a generic approach is required. The lack of appropriate meta-data items in 13606 makes this more difficult than it should be. The principle problem is that to convert an instance of any openEHR ENTRY class like OBSERVATION, EVALUATION, etc, we only have ISO13606 ENTRY as a possible target. The same is true for instances of HISTORY, POINT_EVENT, ITEM_TREE etc - they only possible target is CLUSTER. Ideally, ENTRY and CLUSTER (at least) would contain a meta-data attribute 'type_name' or similar which would record the original type name (note this is not quite the same as a class name, e.g. 'HISTORY<ITEM_TREE>' is a type name, not a class name).

Without this attribute, the best that can be done to avoid losing structure and information is to make special use of the ISO13606 RecordComponent 'name' attribute. This is illustrated in the following suggested structuring of openEHR data in ISO13606 form.

COMPOSITION
  +-content
      +-SECTION
          +-items
              +-OBSERVATION
                  +-data
                      +-HISTORY<ITEM_TREE>
                          +-origin
                          |   +-DATE_TIME
                          +-events
                              +-POINT_EVENT<ITEM_TREE>
                                  +-data
                                      +-ITEM_TREE

COMPOSITION
  +-content
      +-SECTION
          +-members
              +-ENTRY (name = '{OBSERVATION}')
                  +-items
                      +-CLUSTER (name = '{data:HISTORY<ITEM_TREE>}')
                          +-items
                              +-ELEMENT (name = '{origin:DATE_TIME}')
                              +-CLUSTER {name = '{events:POINT_EVENT<ITEM_TREE>}')
                                  +-items
                                      +-CLUSTER (name = '{data:ITEM_TREE}')

ISO 21090 - Data Types

The 21090 data types are largely derived from HL7v3 data types, and as such contain things not needed by EHR systems. Currently there is no profile for 13606's use of 21090; if it existed it would state which things would not be used in 13606, and for others, how they should be used. Once a profile is developed, it should be used to build a new, simpler XML schema for 13606.

The following table is a list of notes relating to some of the attributes from abstract classes including ANY that need to be dealt with somehow in 13606/openEHR - the QTY data type has been used as the example here. These come either from the standard or from Grahame Grieve, its principal author. These could be used to develop a 13606 profile.

The following table is a map of data types.

Mismatches

Model mismatches

Some ISO 13606 data attributes do not currently exist in openEHR, and might be candidates for addition to the reference model. We should make two key points clear here. Firstly openEHR is designed as a high-quality health record architecture, rather than a one-size-fits-all interchange standard. Thus, design decisions in 13606 which are typically taken to accommodate data structures from the largest number of possible source systems do not necessarily make sense in openEHR, which is designed as a coherent EHR, and could be considered one possible 'source' system. Of course, its structures are also extremely useful for intersystem interchange. Accordingly, the relevant question to ask here is: can 13606 accommodate what is in openEHR, rather than the other way around. (ISO 13606 has sometimes been used as a design basis for some EHR systems, rather than for its intended purpose as an interchange format; in such circumstances, due to the above reasons, problems may be encountered in such projects).

Secondly, ISO13606 is an extract, which means its information instances are constructed by processing existing data (which might be relational, objects, XML, etc) and generating the output. Thus the normalisation (i.e. 'factoring') and structure of data items in the 13606 Extract makes sense (hopefully) for sharing data in a context-free manner (i.e. the receiver of the extract can use it as-is, without needing to refer to the source system), but may not be good design for the source system, and in fact may be quite different from the latter. We can thus think of some 13606 attributes as being 'refactored' attributes - they model data that is likely to be located elsewhere in the source system.

The following is a list of information attributes from ISO 13606 not currently supported in openEHR. Recommendations are made as to what to do about these attributes.

ISO 13606 RECORD_COMPONENT.policy_ids

This attribute is defined as follows in the ISO 13606-1 standard:

Recommendation

This is the case for openEHR systems. The 13606 policy_ids attribute would therefore by populated by extracting the list of policy identifiers (where this makes sense) from the openEHR source system EHR ACCESS_CONTROL object and/or policy service. For conversion in the 13606 -> openEHR direction, the policy_ids found in the 13606 data would have to be matched to policies either in a service in the receiving system, or in a shared policy service. This would rely at least on the presence of a widely standardised policy identification scheme.

ISO 13606 RECORD_COMPONENT.sensitivity

This attribute is defined as follows in ISO 13606-1

Recommendation

xxx

ISO 13606 ENTRY.mode

This attribute does exist in openEHR where the PARTICIPATION class is used. However, in the ENTRY class, the attributes subject and provider are 'hard-modelled', and do not use the generic PARTICIPATION value, since the function and performer are implicit. This does however mean that the mode attribute is also not available for the two principal participants.

Recommendation

This attribute is a candidate for addition to openEHR.

Data mismatches

This category of differences is where the models do map more or less directly, but are used in different ways, resulting in data instances that may not be populated in the same way.

ISO 13606 RECORD_COMPONENT.rc_id, orig_parent_ref

This attribute is probably the biggest challenge of the ISO 13606 model. ISO 13606-1 says the following.

• Extract nodes (i.e. RECORD_COMPONENT instances) must be uniquely and consistently identified across multiple EHR_EXTRACTs (rather than just within a given extract).

Two strategies for populating rc_id are proposed:

• use an organisation OID + locally constructed internal identifiers for the nodes in the Extract
• create rc_id values (probably GUIDs) on the fly and make both source and target systems keep a record of them.

The second approach implies a serious impost in data management overhead, since it requires an entirely new GUID-based indexing capability to be added to all systems sharing data using 13606, with concomitant costs, even though they have no use for such a capability within the system, or for other sharing methods, such as HL7v2. As a result, the only approach that can realistically be used in EHR systems, including those based on openEHR, is the first. It is assumed for both the rc_id and the orig_parent_ref attributes.

Recommendation

To implement the first approach above in openEHR, ids of the form used in openEHR URIs are used, i.e. COMPOSITION.uid + node path, since COMPOSITION.uid is globally unique (other approaches could be used involving a system identifier as well). COMPOSITION.uid is of type OBJECT_VERSION_ID, described as follows in the specification:

F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC::87284370-2D4B-4e3d-A3F3-F303D2F4F34B::2

Note that the uid (first and second segments can also be of type ISO Oid, or a reverse internet domain name. This 3-part id globally identifies a versioned openEHR Composition in a distributed network where multiple institutions can create their own local updates from an initial common copy e.g. of medications list. To get to an interior node, a path will be required, of the typical form used in openEHR, from the root node down to the node in question. An example of such a path is:

/content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1 and name/value='Pulse']/data/
events[at0003 and name/value='Any event']/data/items[at1005]

So the identifier to each node in a structure could be something like:

F7C5C7B7-75DB-4b39-9A1E-C0BA9BFDBDEC::87284370-2D4B-4e3d-A3F3-F303D2F4F34B::2/content[openEHR-EHR-SECTION.vital_signs.v1 and name/value='Vital signs']/
items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1 and name/value='Pulse']/data/events[at0003 and name/value='Any event']/data/items[at1005]

(Note that 'Pulse' and 'Vital signs' could also be represented by Snomed or other codes).