openEHR: interoperability or systems?

Thomas Beale (CTO of Ocean Informatics and chair of the Architecture Review Board of the openEHR Foundation) posted these two paragraphs as part of the background for his recent Woland’s Cat post – The Null Flavour debate – part I.

It is an important statement that I don’t want to get lost amongst other discussion, so I’ve reposted it here:

An initial comment I will make is that there is a notion that openEHR is ‘about defining systems’ whereas HL7 ‘is about interoperability’. This is incorrect. openEHR is primarily about solving the information interoperability problem in health, and it addresses all information, regardless of whether it is inside a system or in a message. (It does define some reference model semantics specific to the notion of ‘storing information’, mainly around versioning and auditing, but this has nothing to do with the main interoperability emphasis.)

To see that openEHR is about generalised interoperability, all that is needed is to consider a lab archetype such as Lipid studies in the Clinical Knowledge Manager. This archetype defines a possible structure of a Lipids lab test result, in terms of basic information model primitives (Entry, History, Cluster, Element etc). In the openEHR approach, we use this same model as the formal definition of this kind of information is in a message travelling ‘between systems’, in a database or on the screen within a ‘system’. This is one of the great benefits of openEHR: messages are not done differently from everything else. Neither is interoperability of data in messages between systems different from that of data between applications or other parts of a ‘system’.

6 thoughts on “openEHR: interoperability or systems?

  1. I have only one concern about openEHR interoperability, and it is the coded_text part. Assuming the existence of a terminology service only makes interoperability harder, as there isn’t a single official way of writing terminology bindings when qualifiers are involved. Having to figure the format of those terminology bindings is a bad thing.

    • Have you seen the SNOMED constraint language being used in the English NHS LRA project?

      It is not an IHTSDO standard but does give some pointers to the likely approach.

      I think it could be adapted to take the ‘source’ of the qualifiers from the output of an archetype node.

  2. In theory, IHTSDO are supposed to come up with the answer here. In practice, certainly today…. it’s a mess. But for openEHR to take on that responsibility wouldn’t be acceptable to anyone, so we are waiting like everyone else for now…

  3. Even if IHSTDO one day decides to give a recommendation, the systems currently in production won’t change their format.
    Most current standards have support for codes with qualifiers (HL7, ISO13606, DICOM… even japanese MML or the infamous 21090 data types). Going from that structure to a string is trivial when the format is known (even if it is not standardized).
    If you want to generate clinical documents for your system (doesn’t already exist in openEHR a CDA generation? How does it deal with this?) not having the possibility of separating that only makes things artificially harder.

  4. Hi Diego,

    Just to be clear – is it the absence in openEHR of an equivalent to the HL7 CD datatype, with explicit support for qualifiers, that you see as the issue here?

    Thomas will probably violently disagree but since CODE_PHRASE/code_string is a simple string, I would assume this could carry a SNOMED-CT post-coordinated expression such as

    Starting term: carcinoma of hepatic flexure
    413350009 | finding with explicit context | :
    { 246090004 | associated finding | = ( 312114001 | carcinoma of hepatic flexure | :
    47429007 | associated with | = 422985007 | carcinoma of colon, stage IV |
    , 47429007 | associated with | = 55446002 | genetic mutation |
    , 47429007 | associated with | = 94381002 | metastasis to liver |
    , 263502005 | clinical course | = 255227004 | recurrent |
    , 408729009 | finding context | = 410515003 | known present |
    , 408731000 | temporal context | = 410512000 | current or specified |
    , 408732007 | subject relationship context | = 410604004 | subject of record |

  5. Pingback: ICMCC News Page » openEHR: interoperability or systems?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s