Burning for interoperability
Connected care needs technical standards and interoperability, otherwise there is a risk that it becomes a kafkaesque bureaucratic nightmare. This is especially true when the patient enters the connected care equation, and here is where the HL7 standard FHIR comes in. Healthcare IT News sister publication HIMSS Insights has talked to Grahame Grieve, the person who knows FHIR better than anyone else because he invented it, about a standard that might turn healthcare IT upside down.
Q: We are rapidly entering a new era in healthcare, with complex care networks and connected care scenarios that reach as far as the patients’ homes. What type of standards do we need for that?
Grieve: It is in fact a range of standards. We need basic IT standards that allow you to exchange information about patients, their schedules, and their drugs. This is where FHIR fits in. On top of that, we need a level of agreements about who has got access, about how access is administered and about security. We also need to make an agreement about how core clinical concepts that we have never formalised before are going to be formalised; we need agreements from the clinical parties, and also from the patients, about who has got what obligations in the system. And finally, we need to reach out to the payer and standardise the relevant processes on this side. The difficulty is that a lot of what I have just described is actually about having costs upfront to minimise overall costs in the end.
Q: In what way can FHIR, the HL7 standard that you helped create a couple of years ago, be a bridge between professional healthcare systems and digitally empowered consumers and patients?
Grieve: One of the key things for us was that we wanted to have the same specification for consumer-to-business channels and for business-to-business channels. So we sat down and thought we should try to take the same frameworks that are used for consumer engagement in other industries for healthcare and see what it looks like when you do clinical care over those. The fact that FHIR is based on a sound, consumer-world-proven technology makes it a big bridge. But what actually made it a bridge was that it created and still creates huge interest. FHIR really drives the engagement towards starting to get long-term interoperability problems on the table and solve them.
Q: Do you think FHIR could help to improve health outcomes?
Grieve: If you look at the typical healthcare systems we have around us in the world, you will find that many pieces of the pie are of very high quality. A GP, a surgeon, everybody is running at world class. But between them are gaps. And although we know about these gaps, it happens again and again that they turn into big chasms that a patient falls into. Dis-coordinated care can hurt patients really badly. FHIR doesn’t solve anything, it is just IT. But it makes it possible – and reasonably straight-forward technically – for information to be at the right place in the right time; and thus healthcare providers can ask the right questions or draw the right conclusions. When you look at people involved in FHIR, you see two different types of conversations going on. One is about what is technically possible, and the other is the noise and advocacy around it. What we have done is actually not that big a deal, but people are making it a big deal by increasing the pressure on healthcare systems to start addressing dis-coordination in healthcare. And this, not FHIR in itself, will improve outcomes.
Q: Success and failure of new standards depend on the uptake on the side of IT providers and on the demand on the side of the customers. What about the provider side, how satisfied or unsatisfied are you with the uptake of FHIR by healthcare IT companies?
Grieve: It is really running way ahead of what we had hoped. More or less all healthcare IT engineers look at FHIR these days. Yes, development cycles are slow, some people are frustrated. But having run an IT company myself, I know what turnaround times are and I know that companies are pushing as hard as they can. So overall, we are pretty happy with that. I think some companies can rightfully be accused of avoiding the really structural stuff and only dealing with the stuff on the edge. But others have dived in really deeply. It is a mixed bag.
Q: In the past consumer IT platform providers were not really interested in HL7, because they found it too complex, too difficult to integrate in their platforms. Is that different with FHIR?
Grieve: That was the goal. We took industry standard web APIs to healthcare, so we made it much easier for them. FHIR is what these companies wanted: It is a web API that does healthcare because our digital world is built on web APIs. And yes, the big IT platform providers love it. In fact, what I hear internally is that they say they would have built something like FHIR anyway if we hadn’t built it.
Q: Can you give an example for a real-life implementation of FHIR that you find particularly convincing?
Grieve: I can give an example of a real life implementation that is starting in the past. Beth Israel Deaconess are running a program in which they send patients home early with full monitoring systems that are integrated on an iPad which is connected to their IT system by FHIR. This is a kind of connected care scenario, because patients are going home but remain part of the hospital’s care system and connected to the hospital’s IT system. But it is just the first step. In the long-term I could imagine that platform providers become an active part of such frameworks. In elderly care, for example, really good consumer amends management programs could be provided through platforms that see everything that might happen medically and that help to prevent events or at least help to recognise problems early. I could imagine a lot of stuff that becomes possible once you have such a platform, but there is still a way to go.
Q: Are healthcare institutions aware of the merits of FHIR and actively asking for it in procurement processes?
Grieve: This is very much work in progress. There are some early adopters, but for many others, FHIR is still somewhat on the horizon only. Then there is a few on the other side of the tail who say FHIR is a bad idea and that they don’t want anything to do with it. It is a matter of waiting for maturity to come out of the early adopters. Until it gets to this point, people will continue to be a bit frustrated in the healthcare system, I guess. On the other hand, the number of adoptions for some features is rising rapidly. I know people in real life who love it to run through their data on Apple Health Kit, for example. It is coming.
Q: Don’t you see a risk that there won’t be enough demand? There are examples of consumer-oriented healthcare standards that had difficulties on the demand side.
Grieve: There is always a risk that you don’t meet the market requirements. This is an ongoing challenge for us to be responsive and to make it matter what people say. It is not about how clever we are, but about how easy a standard is to deploy for everybody else. In the end, it is a cultural question. In standard development, the challenge is always to be open for feedback and to be willing to react. We always say: feedback is king.
Q: What is your key recommendation to healthcare executives responsible for connected care scenarios?
Grieve: What I would highly recommend is to pick small cases, pilot them, and see how it works. There is some really big systemic risk in connected care for medical institutions. An organisation might start creaming out really profitable patients and dumping the less profitable patients, for example. We have seen that, it is something that can happen. So go slowly, and analyse thoroughly.
This interview was published in the latest issue of HIMSS Insights, which looks at connected care and interoperability. Healthcare IT News and HIMSS Insights are HIMSS Media publications.