Posted by: schrodingers cat | May 21, 2010

Why don’t EMRs solve the EHR problem?

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: and

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.



  1. […] This post was mentioned on Twitter by Sebastian Garde, hugh leslie. hugh leslie said: schrodinger's cat – Why dont EMRs solve the EHR problem? #EHR #healthit #openEHR […]

  2. Still the case? It seems that some EHR/EMR companies are now developing more flexible / simple / adaptative services. Like Scionis’ Espresso, for example:

    • Hi Matthieu

      While this post is now about 2 years old, I don’t think anything has changed much. I don’t know the espressomd product, however there are probably about 7500 clinical applications in the USA alone, all with different information models and many of them designed to be adaptable and flexible. Sometimes its the very adaptability that is the issue – for instance, in the UK where there are multiple instances of one of the large US vendors, all of which have been installed and configured differently, it is difficult, if not impossible to share information between them.

  3. Hello.
    I just read today this article that illustrates perfectly what you say:

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s


%d bloggers like this: