Why is eHealth interoperability so hard?

As pressure continues to grow on the healthcare system to become more efficient and to provide safer care at a lower cost, health IT is usually touted as the most obvious driver of transformative change in the way healthcare is practised and delivered.

The hopes are high, but in reality the promise is rarely achieved. One of the major barriers is the problem of how hard it is to move data between systems, and one of the major reasons behind that barrier is the incredible complexity that characterises healthcare data.

As interoperability expert Grahame Grieve puts it, the technical capabilities required to transmit health data are quite simple these days – what is hard is making sense of the content.

Mr Grieve gave a presentation on the different architectural approaches to exchanging information at the eHealth Interoperability Conference in Sydney recently, arguing that the healthcare system was at a Mexican standoff at the moment between political and clinical needs and technical capabilities.

Clinicians need technologists to help them solve their problems, but before technologists can do that, they need to agree about what is the right clinical workflow. And technologists are finding it hard to work together because no one can agree on what the right solution is.

“Moving data from A to B is easy,” he said. “It's interpreting the content that’s hard. We have to agree about our basic words … but the people who do the basic words can’t even agree about what the basic words to describe the basic words are. I’ve given up hoping that that will ever resolve itself.

“We have lots of different terminologies with lots of different designs doing lots of different things, and the users have this fantasy that they will be able to all work together. That’s what we actually need to do in practice, but it’s really hard.”

Mr Grieve outlined what he calls the three laws of interoperability. The first is that in healthcare, it's all about the people. Moving data is quite easy, but to make it useful, people have to agree on what it means, he said.

Number two is that system designers can try to hide the complexity of health IT, or they can make it worse, but they can't make it go away. And the third is what he calls a 'trilemma': “you can have cheap, flexible and interoperable, but you can only have two of the three.”

He also outlined the six requirements that allow health information to be exchanged:

  • Transmission of data: a transmission channel between the two, so they can exchange symbols of meaning
  • Common terminology: a common set of terms with meanings that both parties understand
  • Identification policies: some way to identify instances of things that are being talked about
  • Information structures: a common method to assemble the terms or words into a coherent larger structure
  • Behavioural models: a conversation protocol about who says what when, and then what happens next
  • Common understanding: a common understanding of the context in which the discussion is taking place.

“Those six things drive what we need in order to deliver stuff that works,” he said. “The more we can get common understanding, the cheaper it is to interoperate. The less we have common understanding, the more it’s going to cost. But we don’t have enough common understanding.”

Complexity

To illustrate the complexity of healthcare interoperability, Mr Grieve pointed to identification policies. “Lately, I’ve had a running conversation with some pathologists in America about how to consistently identify pieces of a person, potentially after they are detached from the person. We need to identify metastases and distinguish the linearity of the inheritance. It’s complicated.”

There is also the complexity of data elements in information structures, including how data elements are defined and work together with others. The many different ways allergies can be recorded is an example, he said.

“Data elements never exist in a vacuum,” he said. “How a doctor uses [fields for recording allergies] varies depending on what data elements she’s got to pick from.

“If you give her a space for comments, she’ll use the slot for the substance differently than if you don’t give her space for the comments. Data elements are never a vacuum, but the presence of them affects each other. It’s easy to argue about how to do this and so it gets way too much attention.”

Then there are the behavioural frameworks required for agreement about who moves what data when. “One thing that is very often not specified is how errors are handled. People die because errors aren’t handled properly, yet we’re very poor at specifying how errors are handled and that deserves way more attention than it gets.”

And a lack of common understanding has further ramifications. “The less people agree, the more exchanging meaning costs. That’s just a fact that we have to deal with.”

Potential solutions

A number of different groups, standards and methodologies are working on the problem of interoperability, such as HL7 with v2 and clinical document architecture (CDA), OpenEHR and Mr Grieve's own creation, Fast Healthcare Interoperability Resources (FHIR), which has gained a huge amount of interest in the eHealth world and is currently a draft standard for trial use (DSTU).

All of these approaches to interoperability have their challenges and often lead to the practice of split-level modelling, in which developers define the basic structure or reference model that is shared, along with profiles describing how those structures should be used.

“I mostly only see these in healthcare,” he said. “For instance, [the World Wide Web Consortium (W3C)] specifications all start out with a blunt statement. 'You can customise or extend these standards but for all of your customisation extensions, you still have to interoperate. You can’t do anything that stops you from interoperating globally.'

“Healthcare just doesn’t work like that. We can’t accept constraints on our behaviour that means we have to interoperate with the Russian healthcare system or the Chinese one or the American one, because we don’t have consistency between those systems. So, to deal with this variability, we get pushed to do the split-level modelling.

“The thing is, the reference modelling stuff is something that engineers can understand and make work, but the profiling structures – that’s hard, that’s just hard. There’s not many people that can actually work at that level. We get driven to do split-level modelling, but not that many people can make it work well, so that’s an on-going challenge for all of us.

“That’s a major source of complexity that we can’t get rid of, and it frustrates everyone.”

Local extensions to specifications – or allowing variability into specifications for particular institutions or national programs like the PCEHR – are also problematic, he said. This led to HL7 confronting an enormous amount of variability when developing version 3, which unfortunately resulted in a standard that is too complex to be used.

To make up for the shortfalls of v3, the industry began working with CDA, which has been used for the PCEHR. Unlike v2 or v3, which are ways to move data around, CDA is conceptualised as a clinical document, which has its own problems.

“The collection of documents may have some kind of logical, coherent relationship with each other, but that’s not explicit within the documents,” Mr Grieve said. “If you choose a document strategy, which NEHTA chose for the PCEHR, it commits you to having a low coherency patient record. There’s very little ability to leverage data in the PCEHR. There will remain very little because it’s a document repository, but we don’t have enough agreement.”

What Mr Grieve is trying to achieve with FHIR is to create a scenario in which information can be exchanged easily and cheaply, but which can also help to standardise clinical practice. “Right now, standardising clinical practice is a thing that hangs in the wind without any IT support,” he said.

Mr Grieve believes there is a “huge tsunami of change” that is coming in healthcare as the pressure rises for the system to transform, but IT cannot do that transformation.

“The health professionals need to transform it, but they’re stuck right now because we can’t give them the support they need. It’s going to be an iterative process, but we’ve got to take the first step, and it will be risky at times.”

A second DSTU release of FHIR is due this May.

Posted in Australian eHealth

Comments   

# Vincent McCauley 2015-02-06 10:07
An excellent summary by Kate McDonald of a complex and challenging area. Grahame has become an Internationally recognised wizard in this area and his development of FHIR is an all Australian initiative which is taking the eHealth Standards world by storm Its a shame he and his work are relatively unknown in Australia and this initiative receives zero government support. Maybe a knighthood would help :-)
# Chris Mount 2015-02-06 13:04
Don't you have to be prince before you get knighted?
# Klaus Veil 2015-02-06 14:55
Good Point, Chris. But that rule might change after next Tuesday ...

The HL7 FHIR Standard has gained world-wide recognition as a pragmatically successful healthcare data exchange standard in an unprecedented short time.

As recently as last week US A/Secretary for Health National Coordinator for Health Information Technology Karen DeSalvo publicly pushed FHIR to be ready for wide-spread implementation by May *this* year! See https://twitter.com/dsusanto/status/562971662392770561
# Grahame Grieve 2015-02-06 15:26
Vince - thanks for the kind words, but, please, no

Chris / Klaus - lol. Especially about May.

Simon/Kate - thanks, keep up the good work!
# Birk Frankvoort 2015-02-06 20:14
Nice article on a notoriously sticky subject. In the Netherlands we have been working towards a certain form of interoperabilit y for years now with little succes. The current initiative fortunately has gained a lot of traction and FHIR is the standard agreed upon by all major eHealth providers like ourselves. It's slow going, but we're getting there!
# Ken Martin 2015-02-07 02:10
(universal codes: SNOMED, LOINC, RxNorm) -> HL7 FHIR -> Electronic Health Records

LOINC's RELMA tool can map universal codes to local databases. Universal codes are the starting point for enabling eHEALTH interoperabilit y.
# Grahame Grieve 2015-02-07 08:23
Ken - yes, agreement about our basic words is that place to start. Progress there is disappointing.. .
# adrian eland 2015-02-07 10:56
Great article.
Yes Australia is somewhat behind at picking up new technlogies. FHIR seems to be what we need right now given the boom and problems with interoperabilit y and the advancement of the PCEHR.
# Richard Dixon Hughes 2015-02-10 10:39
I add my congratulations to those of others for Grahame's further insights on the field and Kate's summary.
# Michael Lawley 2015-02-11 11:15
Quoting Ken Martin:
(universal codes: SNOMED, LOINC, RxNorm) -> HL7 FHIR -> Electronic Health Records

LOINC's RELMA tool can map universal codes to local databases. Universal codes are the starting point for enabling eHEALTH interoperability.


Ken, the problem with "mapping" is that most approaches adopt a simple lookup-based approach and assume that such a map can be used across contexts.

Grahame's "Data elements never exist in a vacuum” applies equally here; mapping a code in abstract is not the same as mapping it in use.

We need to stop using local, ad hoc, and proprietary code systems and develop scalable and responsive approaches to fixing the problems with the 'universal codes'

[+1 Kate on an excellent article]
# John Scott 2015-02-16 15:20
The article is a good one and should remind us all that we are fundamentally dealing with a complex human system with myriad social networks involved in the process of care delivery. The digitization of healthcare is hugely disruptive and is certainly not of the same order as agreeing on standards for a national rail gauge or banking or telecommunicati ons.

The difficulty rests in the conflation of three different issues--issues which need to be progressed often independently.

First, clinicians when they want to work differently may need clinical assistance to surface and resolve a range of normative issues that arise within healthcare itself. A new way of working together can bring new or different rights, responsibilitie s and obligations.

Second, independent and trusted assistance is often required to enable the crossing the various non-clinical boundaries of healthcare. The major boundaries are geographic, organisational and economic. In the economic sphere, healthcare needs fair and clear gain and cost sharing arrangements if investment is to be forthcoming that encourages and enables new ways of working together.

Third, there is the question of how to connect the the physical human 'Health' sphere and the electronic 'E' sphere. The two spheres are not incompatible but require very special attention. Some issues can only be resolved by Health; some issues can only be resolved by IT. Some issues can only be resolved by government and are best advanced on advice from the two spheres working together. The progressive resolution of issues brings into reality a new way of thinking about ourselves and our proper relations to each other.

Governance that is fit-for-purpose is required if we are to make significant and sustainable progress.

After over a decade of endeavour and hundreds of millions of dollars of investment, our first priority should be to get information flowing that delivers value apparent to stakeholders. Otherwise the decline in public trust and confidence in the digitization of healthcare could suffer possibly irreparable harm.
# David Guest 2015-02-18 11:42
Quoting John Scott:
After over a decade of endeavour and hundreds of millions of dollars of investment, our first priority should be to get information flowing that delivers value apparent to stakeholders. Otherwise the decline in public trust and confidence in the digitization of healthcare could suffer possibly irreparable harm.


GP2GP fulfils these criteria.

http://nrgpn.org.au/index.php/56-hot/305-gp2gp-electronic-patient-notes-transfer-in-new-zealand

Can we do it?

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.

Copyright © 2017 Pulse+IT Magazine
No content published on this website can be reproduced by any person for any reason without the prior written permission of the publisher.