Why Is The Shared EHR So Hard?

'Provision of the right data to the right provider at the right time' is the mantra we commonly hear in eHealth. It sounds deceptively simple! Some promise it; some hope for it; but pretty much no-one has it. The collective desire for a seamless and efficient shared electronic health record (EHR) which actually provides that data to the provider at a particular time is widespread and yet the EHR remains elusive. If we know what we want, why is the shared EHR so hard to achieve? Why is it taking so long? And what's more, if the financial sector can do it, why not health?

The progress that we have made in the past 10-20 years of eHealth development has been glacially slow compared to other industries and domains. The approach to health IT, and in particular the shared EHR, has been primarily linear in nature with modest incremental successes achieved. Sure, progress has definitely been made, but despite investing enormous amounts of money and resources, the solution has been more difficult than most ever anticipated. Healthcare doesn't appear to fit the same data interoperability model that has been successful in other domains such as banking or financial services. In a world where connectivity reigns and personal data can flow freely, it is not yet the norm for our health information to be connected nor to flow!

In trying to understand the problem more fully, there are 3 broad headings we need to explore:

  1. Technical
  2. Human interaction and activities
  3. Information exchange

Let's explore some of these issues:

1. Technical

There is little doubt that traditional EHR development has been driven by technology requirements and engineering processes, so many of the typical aspects we consider when thinking of the EHR are actually quite manageable, if not solved - consider storage and retrieval of data, security, role-based access, audit trails, repository storage etc. It is not the technology holding us back here. Some even suggest that the technical aspects of the standalone EHR are the (relatively) easy part, and they may well be right!

With over 7000 EHR vendors in the United States alone, we have proof that building a standalone EHR is undoubtedly achievable. Our EHRs that are in use are traditionally rugged individuals, each created in splendid isolation with the finest data structure, processes and user interfaces! Unfortunately, building proprietary silos of health information is the almost universal approach to EHR development adopted by vendors and does not make it easy for health data to be shared.

I have seen and heard some say that we already have all the standards that we need for eHealth. This is still somewhat controversial and perhaps depends on what part of eHealth that you are trying to make work. For a coordinated eHealth system the desire is for each standards to not only achieve its purpose and goal, but to harmonize with all the others in existence to create a unified whole. Can this vision be achieved? There are certainly some examples of very successful standards.  There are also some examples of tweaking of standards for local use... which makes them non-standard again. There are also some examples of standards that have never yet been implemented... what? Let me refer you to the blog post from my colleague - The Crisis in eHealth Standards, by software engineer, Thomas Beale - for an erudite discourse on the strengths and weakness of standards and the standards processes.

2. Human interaction and activities

There is no doubt that some EHR technological achievements have been delayed or even diverted by the human, political and regulatory issues arising from practical implementation - and in most instances, rightly so.  We can develop a technological solution, the 'what', but in many jurisdictions the 'how' still has everyone tied up in knots.  For example we have technical solutions for unique patient identifiers, data security, and role-based access to data - but 'how' to apply these in practice is more elusive, often crossing into moral and ethical arguments (including confidentiality and privacy), requiring broad social and political agreement and sometimes supportive legislation. These issues have received a disproportionate amount of attention, particularly in the media, and perhaps at the expense of issues that follow which are not so well understood, yet!

Healthcare is not primarily a technical business - it is about people. Yet in our rush towards EHR development we seem to have focused on the EHR being a technical solution rather than merely a tool or medium to support the practical application of health knowledge and provision of healthcare to real people.  Some of the most underestimated and misunderstood problems in EHR development are related to:

  • the scope and dynamic nature of our health knowledge domain;
  • the nature of the human-human interaction that underpins quality health care;
  • the approach to capturing and storing the essence of a clinical encounter; and
  • the changing clinical requirements, processes and approaches to healthcare provision.

None of these are trivial concepts.  They are in the metaphorical 'EHR too hard basket', but we need to address them...

Health is possibly (more likely, probably) the most complex knowledge domain.  The extent and scope of health-related knowledge that needs to be represented in an EHR is enormous - it has huge breadth and depth, plus a fine web of complex relationships.  Most commonly underestimated is that health knowledge is dynamic - requirements distilled from a clinician and built into an EHR application by a software engineer today can be out-of-date by the time the product is launched.

An encounter between a clinician and a patient is a very complex pas de deux, an intricate communication dance between two parties.  Interestingly we clinicians have developed surprisingly effective written methods to capture the information exchange from these encounters, with all the required subtleties and nuances. Capturing the essence of this encounter into a format that can be stored, re-used, queried and shared on a computer is a daunting task and more complex than first appears. Attempting to represent both the data and our clinical processes via the user interface on a computer screen is definitely also an advanced task.

The nature of healthcare provision is also in flux. Consumers/patients/clients/citizens/individuals are increasingly mobile, more now than ever before, demanding healthcare from a range of providers in varying geographical locations.  Gone is the old-fashioned notion of the local family physician providing all our needs for all generations of the family; the local physicians are morphing into our health coordinators and facilitators in a world of collaborative and distributed models of care. Our ability to diagnose, treat and prevent conditions are moving with the assistance of new technological advances - in particular, watch out for the potential tsunami-like impact of personalized medicine/genomics on healthcare in the next few years.

3. Information exchange

There are many differing approaches to sharing health information. Why? The plain answer is that it is hard and there is no clear way forward; there are also many differing requirements and starting points:

  • Logically, the technical task of sharing health information would be easier if the data was in a common format. Conversely sharing seems to become more difficult by orders of magnitude if our collective data structure is in chaos.
  • Practically, some require only the simple exchange of a readable document such as a PDF or semi-structured documents. At the opposite end of the scale, there is need for EHR systems to share detailed and structured health information, so that not only can clinicians and patients read it but the meaning of each piece of data is clearly understood and it can be directly integrated into the computer and utilized in clinical decision-making - this is known as semantic interoperability.

In many places, national eHealth programs and the myriad of 'ruggedly individual' EHR vendors are pursuing technical approaches to data exchange through the set-up of information exchange hubs, message mapping and data transformations.  In this instance the focus is on exchange of complete or semi-structured documents as readable health information. Europe and some other parts of the world are taking a different approach, focusing on the exchange of standardized, atomic data  and reflected in the European decision to adopt ISO/EN 13606 as its standard for EHR extract exchange.

Exchange of unstructured health-related documents as 'blobs' of data is a great starting point, but in the long term it is a dead end. In reality it is not a sound basis for a shared EHR, nor interoperability, as we can only read them and then store them passively within the EHR. Personally, I want a dynamic, lifelong EHR for myself and my patients - one that can actively create, receive, integrate and re-use my atomic health information and put it to work for me to improve my current health and to provide the basis for future health decisions.

'Provision of the right data to the right provider at the right time' - can this actually be achieved? Clearly the relatively safe, comfortable and incremental technical innovation that has underpinned our EHR development to date hasn't provided the shared EHR solution we hoped for. So at this point let us draw from the wisdom of Einstein: “We can't solve problems by using the same kind of thinking we used when we created them." Indeed, perhaps it is time for a different approach to the shared EHR; one in which we divert our focus and are encouraged to push boundaries; to seek transformational change in our approach to eHealth.

In future posts, I hope to explore some of these issues in more depth and, in turn, some opportunities that arise...

Acknowledgments: Dr Sam Heard and Dr Hugh Leslie