If you are starting out in health information technology, it can be very overwhelming in terms of the sheer number and complexity of the standards that are out there.

Having been active in this space for more than 15 years, I have come to realise that the issue is not about standards or applications as such, but how we think about them and use them.  The current approach to solving the EHR interoperability problem is to go out and build or buy an application.  This is easy and people often suggest that open source applications are the answer but open source applications don’t solve the problem of interoperability.

Why?  Because the problem is not the applications, (over 7,800 clinical apps in the USA alone), but the DATA.  Even open source health applications use a data specification that is unique and the data is captured in a non standard way that is not shareable with any other systems.

The approach to this to date has been to treat all of these applications as ‘black boxes’, where the content is not important.  The energy has been spent on messaging between them and this has been going on for 25 years or more.  In terms of interoperability of complex clinical data, it has been a major failure and we are almost no further ahead with a messaging approach than we were before.

Why?  Because really you can think of each of these systems as having their own ‘health language’ – designed to capture the data required for the particular clinical purpose that it was built for.  Even systems that are built for exactly the same purpose, will have different ways of structuring the data (the information model).  There are many systems that allow you to structure data on an implementation basis, so that even between different implementations of the same system, there is no interoperability.  A lot of data that is captured by applications, relies on the user interface of the particular application for the semantics of the data i.e. the data  captured is relatively meaningless unless displayed in the context that it was created in on the screen.  Messaging data like this requires a constant translation of the information from one system to another and when you add a third system, you need to do the translation again for each of the other systems because the language is different.

So how do we solve this problem ?

• We could use only one application from a single vendor everywhere…and there are some vendors who would advocate this approach!
• We could rewrite every application to use a common data model – ideal, but not realistic in the short term.
• We could try to invent a messaging system that was able to be translated automatically  – this is the HL7v3 approach and has been unsuccessful so far.
• We could create a ‘lingua franca’ that allows a single translation to a universal interoperability language so that any translation only had to happen once – this is the openEHR approach.

So – its the DATA, not the application that’s important and until we can get data that is universal, shareable, flexible, completely open and able to cope with the fractal complexity of health data, we are not going to be able to solve it.  There is a very nice report on semantic interoperability from the European Commission called the semantic health report that suggested that three things were essential for interoperability to occur – a shared information model (such as the openEHR reference model), terminology (such as SNOMED CT) and content models to bring these together (such as openEHR archetypes). You can read the report here: Semantic Health Report

…and if you don’t have a way of clinicians (domain experts) being able to contribute to what the content of an EHR should be, then you won’t get there either.

The problem with almost every clinical system ever built is that the underlying core is based on some fixed data model that has tried to make concrete some part of the clinical domain at some point in time. Often this is a developers attempt to translate the needs of the clinician into a technical environment.

Why doesn’t this work?

Because as soon as you try to nail down the clinical content, then it all needs to change due to changing understanding of health care, different needs of different clinicians etc etc. This means complex and costly engineering and it can never keep up.

We need to realise that the EHR is not the application, its the information and that an EMR is really just one view of an EHR. Another view of the same EHR could be a PHR or some other specialised view of the EHR.   To make this work, we need an approach that allows for flexible, computable clinical information that can change without the need to re-engineer systems and allows clinicians to define what they need rather than relying on technicians.

There are two main approaches to this in the world today:

• One is HL7 v3 which is a messaging standard but is also being used to build EHRs in some places. The main problem with HL7 v3 for clinicians is that it is not approachable in terms of defining content in a non technical way.
• The other approach is openEHR (ISO 13606) which is an EHR standard and is approachable for clinicians as it separates the technical domain from the clinical domain. Systems can be built once, and then new clinical concepts can be introduced without re-engineering the system. Clinical concepts can be defined by clinicians without having to understand any of the underlying systems. See: www.openehr.org and www.openehr.org/knowledge

If we don’t understand this problem, then we are never going to see those outcomes from the computerisation of healthcare that we all know is possible.

Dear all,

Patient Care WG does need help from your collective memories and capabilities to track back in minutes and other documents.

We are currently evaluating the core parts of Care Provision (D-MIM, storyboards and interactions, Care Statement, referral, query and care record, care structures).

Those who implement it and want to participate in an interview about your experiences, please let me know, so we get what you need to be changed.

This week PC WG worked hard on the project planning around all this. One decision made is to prioritize the care statement R-MIM part. This was derived from the clinical statement around 2005. However, several changes where made from the clinical statement pattern 2005 – 2007 to the PC Care Statement. It is exactly this where we
need your help for.

The important question we have for you is:

Do you remember what the exact use cases or reasons where to make changes / adjustment to the clinical statement to adopt it in Care Provision Clinical Statement?

This might be in area of: because of use case x we included / excluded class X form choice box.
because of this we made changes to the recursive relationships etc.

Some of this will probably be in the narratives of the D-MIM / Care Statement.

We need this input in order to determine if we can simply replace Care Statement 2007 version with the current Clinical Statement 2010 version, or that we need to add additional features or constraints first, or that we just include use case by use case features from Clinical Statement 2010 and rework the 2007 version.