openEHR ~ 13606 2012 revision - alignment proposals

Owned by Thomas Beale
Last updated: 18-Dec-2011Version comment

Overview

These pages are for capturing ideas for a potential alignment of openEHR RM and ISO 13606-1, for the 2012 ISO 13606 revision. An earlier attempt at mapping the data structures of openEHR and 13606 is here . However the focus of this page is more on what we could change in the ISO 2012 revision of 13606 so as to have a single standard that works for both openEHR and 13606. There are some potential simplifications that could be done in openEHR which would help this. It seems clear that some aspects of 13606 will also have to change. The idea is not necesarily to have exactly the same, single model, because the scopes are different - 13606 is limited to inter-system communications. But if we can manage to arrive at a 13606 model that is either a clean subset or a clean & defined transform of openEHR, that will be great progress, because it will allow a single toolchain to be developed to deal with both.

Core classes

Initial thoughts - TB

The key abstract class in 13606 is RECORD_COMPONENT, the equivalent class in openEHR is LOCATABLE. The following diagram gives an initial idea of possible mappings of the attributes. 

The archetype_id/meaning attributes were specified following openEHR as it was in about 2006; openEHR fixed these attributes, and the current form is on the right. Some thoughts:

  • In openEHR, policies (access control) is not buried in with the data, but specified by reference in the EHR object. It is arguable whether it is a good idea to try and intersperse such things at such a fine level of detail through the data as in 13606.
  • Sensitivity: if you are sprinkling sensitivity values in your data, and the record owner wants to change the sensitivity setting later on (e.g. make 'family health/contraception' less 'sensitive'), then in 13606 you are changing the data to do this - which does not seem correct.
  • Synthesised: this 13606 flag indicates whether the data node had to be created as part of the data conversion process from legacy data. I think it may even have been my fault that this is in 13606. It doesn't appear to be in openEHR any more, although I can't remember why. It could go back in easily enough.
  • orig_parent_ref: in 13606, this iindicates (from memory) an orginal version parent. In openEHR, such references are taken care of in the versioning model, and also in the EHR Extract, but in a different way - using an explicit model of VERSION.

The openEHR approach was to make it so the data could be created, signed, stored and shared intact, with no regeneration of the data with interspersed things like policies and sensitivity. With the 13606 approach, you are really forced to reprocess your incoming data into a different form to create an EHR whose data can be properly versioned, signed etc, or if you want to directly store the 13606 data form, put up with continual revisions on the data whenever a policy / sensitivity preference is changed.

Entry classes

The lower level structures used in openEHR are more complex than in 13606, which just uses a CLUSTER/ELEMENT structure under a single ENTRY type. openEHR on the other hand has 6 concrete Entry class descendants: OBSERVATION, EVALUATION, INSTRUCTION, ACTION, ADMIN_ENTRY, GENERIC_ENTRY. A simplification in the data structure classes used within the openEHR Entry classes will help to bring openEHR and 13606 together - see below. One basic strategy to bring these classes together at the Entry level is for the openEHR types to include factory routines that generate standard CLUSTER/ELEMENT structures from the native openEHR structures.

Data structure classes

This page discusses possibilities for simplifiying openEHR's more sophisticated classes.