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.
Comments (2)
Dec 16
Ian McNicoll says:
We do have to consider that a Sensitivity marker as transmitted in a message may...We do have to consider that a Sensitivity marker as transmitted in a message may not equate to a local sensitivity within the original data. I think this one of a few areas where the requirements of a piece of information in a very specific message context may differ from those applied to the original data. Policies would be another i.e the policies applied to the messaged data may not directly equate to those applied within the host system.
For the other 13606 attributes, it would be interesting to get feedback on how/if these have actually been used in practical experience to date.
Dec 19
David Moner says:
I agree with Ian. The exchanged data can have its own sensitivity and acce...I agree with Ian. The exchanged data can have its own sensitivity and access policies. Moreover, we only exchange a snapshot of the EHR and then we won't probably need to change the sensitivity of the data during the life of the extract.
Regarding the other attributes, I have always had problems with archetype_id in 13606 and with archetype_node_id in openEHR, both defined as strings. In the first case, the specifications only say that this string follows "the syntax rules of 13606-2" which is the same as saying nothing. This means "at" codes or archetype identifiers?. In openEHR is more clear. It says that it is the "at" code except at the roots where it becomes the archetype identifier. But at the same time we have the archetype_details attributes with this archetype_id information replicated. In my opinion, this mixture of approaches is confusing. For example, if we have an instance that says that the archetype_node_id is "at1006" and there are no archetype details, we will have to go up in the tree to find the archetype identifier, and take care of this information if the node is reused elsewhere. And I don't know if additional problems can arise if we have Slots and internal references all together. So, although we want to keep the RM instances small, we should always have the archetype_id+node_id defined for each node in separated attributes.
The meaning attribute in 13606 is in fact a CV (there is an error in the figure). Here I have always had a doubt. If the RM instance is not archetyped, the use of this attribute is clear: the terminology annotation of the node (how do you represent this case in openEHR?). But if the RM is archetyped, this binding already exists at the archetype. In this case, should the meaning point to the "at" code of the terminology? Moreover, should we only have one way of defining the meaning of a node, pointing to a pure terminology code or to an archetype "at" node depending on the case?
The synthesised attribute (that is mandatory) is a complete nuisance. It indicates if the RECORD_COMPONENT exists at the EHR system or if it has been created to comply with the norm. Since we are always transforming legacy data into 13606, the value is always true. At the very least, this attribute should not be mandatory, if maintained at all.
Finally, I have never used the orig_parent_ref since for us it has never existed an original parent RECORD_COMPONENT. It can be useful, for example, while building a patient summary through inclusion of many existing RECORD_COMPONENTs from the EHR. But probably we could represent this same information with an appropriate LINK, so that this attribute could be removed.