Interoperability with HL7

Hello Charlie,

The biggest issues with inter-operability relate to the use of Semantic attributes in both HL7 and openEHR.

They are not really semantic in the SNOMED-CT sense in either format, and because they are different, inter-operability between openEHR and HL7 is difficult. OpenEHR has attributes such as “data”, “state” etc and HL7 has Act Relationships that are supposed to be semantic rather than just compositional. OpenEHR also has a lot of specific CLUSTERS such as ITEM_TREE and subclasses of ENTRY such as “EVALUATION” which have semantics that are in the implicit in the model, rather than pure clinical knowledge.

This makes a DCM (Detailed Clinical Models) format that both agree on a difficult proposition. There are other differences, such as the ability of HL7 Observations to have both a value and child acts via Act Relationships, where as openEHR does not have CLUSTERS with values.

The best way to resolve these is to accept that openEHR and HL7 cannot use the same models without adding extra information to the format ie extending ADL or adding attributes to the RMIM.

If the clinical knowledge was modelled in ISO-13606 there are only compositional attributes ie “items” and only one of them and the data structures defined require the terminology to impart the meaning and not semantic attributes. This could be translated into openEHR and HL7 in a loss less way. There are obviously some issues with the 13606 reference model, but the pure clinical content is then representable with a tree of Name=Value pairs, with the meaning in the terminology rather than the attribute names. It is also an international standard that gives a degree of certainty and stability to the format, even if its not a perfect fit for every system.

I think in most cases the demographic content is able to be mapped, as people have a lot of practice at that. A bigger issue is things like Medication, which has specific classes in HL7 V2 and 3. However the ability to model clinical knowledge outside the contentious areas and represent the clinical knowledge in a standards based format that can be adapted to other formats would be a huge leap forward. It is even possible to represent this in a loss less way in HL7 v2. For things like Medication and Allergies an archetype that can be mapped to HL7 V2 and V3 Segments/classes is needed for interoperability.

The use of Semantic or “named” attributes specific to a format is the major barrier to a common DCM format. The HL7 V3 assessments and scales RMIM is and example of a HL7 V3 format that is adaptable to an archetype, although it does have a cluster with a value, which would have to be mapped to the “value” ELEMENT of an archetype.

The formula for calculated values is also undefined, but GELLO, which is a standard could be used for this and this is what we use with ISO-13606 archetypes.

I cannot see how openEHR archetypes can be used for a general DCM format, but ISO Archetypes could, as long as they were modelled in a fashion that is neutral to final implementation format.

A common format would require both sides to either map the generic structures into their own specific classes or adopt a more generic model with the semantics in the terminology. The overlap between the information model and the terminology model is probably at the heart of the conflict.

Andrew McIntyre

Monday, February 1, 2010, 7:33:09 PM, you wrote: