This is an excellent article by Kate McDonald of PulseIT, featuring an interview with Grahame Grieve on the problems we face in achieving interoperability and how Fast Healthcare Interoperability Resources (FHIR) could address some of the problems.
I strongly suggest anyone interested in ehealth to take some time to go through the article, it will be well worth your time.
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 practiced 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 too.”
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.
BinaryHealthCare (BNHC) 