Grahame Grieve - the future of healthcare interoperability (part 2)

Question 1 (Mohan): Can you talk about the rationale behind the creation of FHIR?

“I believe that it was necessary to create a new set of standards that actually solved the problems people have. Fundamentally, that’s why we did it.”

Question 2 (Mohan): What problems was FHIR designed to solve, or that HL7 couldn’t solve before?

“HL7’s context was not around exchanging data, or if it was, it was very limited circumstances; it was hard to leverage and wasn’t flexible. I wanted to set that flexibility free so people could write apps to do interesting things with data that other people held.”

Question 3 (Mohan): FHIR seems to be very patient centric and all the associated resources around it. Is that how you are thinking about it — that the patient should be at the center of all the data models and data exchanges?

“With FHIR, what’s been clear from the very beginning is that it is capability-based. So, FHIR is not necessarily patient centric, in fact there are other kinds of views to take of the record, a practitioner centric view, as well. The key changes that it is capability focused.”

Question 3 (Mohan): So it can be practitioner centric; it is almost resource centric as you see fit, based on the workflow that you want to enable. Is that the correct way to look at it then?

“We look at healthcare as a Web of information. And although there are some central navigational points around patient/provider — the patient’s relationships with other people, the physical locations where care is provided, the teams that provide care — all of those are key navigational points, but none of them are unique and special.”

Question 4 (Mohan): Is it correct that you could essentially string together these resources in various ways, or flow it in different ways to make up a workflow?

“As we grappled with the consequences of people taking different perspectives, we started to understand the wider context of how to string together workflows; now we are grappling with how to relate an exchange workflow with a real world workflow and obligations and how to actually administer the process through FHIR.”

Question 5 (Mohan): When people talk about interoperability, should people talk about it in the context of workflows or should they talk about it in the context of data?

“I think there’s a duality….from some perspectives it’s not necessarily thinking about it as anything more than data. From other perspectives, thinking about it as data and ignoring the ramifications of workflow just leads you down dead ends and creates problems for you. I think you have to think about what people are trying to achieve and make sure that they’ve thought about all the ramifications. That’s where experience comes to the fore, so that you know where people are likely to go to make short term decisions that will create really bad technical debt later.”

Question 6 (Mark): Was there anything that you had learned working with IHE queries that you wanted to change or avoid when you were designing FHIR?

“The work that IHE does is really a key important work and I wanted to make that easier. Some people have said, well, FHIR does all that. But people still need to make their specific agreements and figure out their actors and obligations and their due certification. I wanted to make that a thing with process.”

Question 7 (Mark): Do you see that FHIR would work with the IHE to build some of those testing harnesses, or validations, or do you see that it’s something HL7 would begin doing, or governmental agencies?

“Within the FHIR project we have a good validator that does detailed depth validation of the content. We are beefing that up and working with the IHE testing to incorporate that code inside the IHE testing tools. So they will use our code for validation as the seamless part of their overall testing workflow. I’m really pleased that we are going in that direction.”

“As for testing, I think HL7 has a role in testing where some things are specified completely by HL7. IHE gets to do testing when IHE is doing the certification, the specification and agreements. Then governments and other agencies should do their own testing for their own decisions. There’s clearly going to be a lot of work through the U.S. government in the next three to four years, providing U.S. centric solutions to U.S. government problems and the government will be doing the certification. Or, at least running the certification process.”

Question 8 (Mohan): Given the way enterprises look at interoperability…if they make an investment then that investment should be future proof. How has this lack of current backwards compatibility been received?

“One of the great things about FHIR is that it is not fixed in stone, so we can make changes to the specifications in response to user experience. One of the hard things about FHIR is that we can make changes to the specifications in response to user experience. That’s a double edged sword. All of the institutions that I’ve worked with have on the one hand felt good that if they raise issues, those issues can be addressed. All have also felt the risk associated with that.”

“Initially there are some organizations that stand back saying that they won’t engage until it is stable. But increasingly, organizations are saying they can’t afford to wait. Either they want to influence the specification or they have to solve problems now. They understand the fact that It’s still not settled in stone is both good and bad; they have to figure out how to manage the risk and leverage the advantage of that.”

“So far that has proved less of a problem than we expected. What we expected was for more people to stand back and say they wouldn’t get involved until it’s stable. But, that hasn’t happened.”

Question 9 (Mohan): Is the patient model the one that is evolving the most, based upon the kind of feedback you get from customers? Or, based upon usage? Or, is it the medications model?

“Our team has focused heavily on the conformance resources, the validation related resources. Tending the implementors, there’s the patient provider, encounter, institution set that everybody has to engage with. Then there’s the patient summary stuff. Problem lists, medication lists, observations, vital signs. Those are things that come first for everybody.”

“There’s enough breadth of understanding in the community about why we’ve made the choices that we’ve made. There’s a few elements to add and a few trimmings to make around codes, but it’s pretty stable now. We are getting towards probably the next version after the one coming, so later next year, I guess we’ll be having active discussions about calling them being done — fixed and actually backwards compatible from now on.”

Question 10 (Mohan): So that is towards the end of this year is when you think about the first long-term support LDS version of FHIR beginning to come out?

“Probably October next year, as a guess.”

Question 11 (Mohan): It seems to be very health system oriented. I know that in the spec of FHIR that you also had models around claims and payments. Are you seeing more interest from the payors participating in this, or is it still being driven by the health systems primarily?

“I would characterize the payors interest in FHIR as extremely strong. In fact, critical. They aren’t so fussed about running the payment through FHIR, although there’s a project running for that and that has strong engagement. What they are really interested in is MACRA. Because it seems likely, given the standards environment that when it comes to guidelines and gathering data for guideline evaluation and evaluating guidelines, it’s going to be using FHIR.”

Question 12 (Mohan): Do you mind talking a little bit more about how they intend to leverage FHIR to do the evaluations that MACRA requires?

“There are three parts:* One is to provide an API by which you can ask a data repository to make assessments a healthcare measure, and give you some answer about the measure. Then there’s the actual specification of what the measure is. It’s basically a clinical decision criteria. So it is the same technical infrastructure as clinical decision support. Then there’s the specification of the kind of data that the measures can assume and rely on being available, both in terms of what data is present and as how it is represented.”

Question 13 (Mark): So it would be the health system that would have the API or to expose it, saying, “You can ask about patients who have HbA1c or Metformin, or whatever the metric is, and the payors would be doing the queries strictly of the health system in that regard? Or, would the health system in this kind of vision still be pushing that data to the payors, using FHIR to run their own analytics?

“It could be that the payors ask the healthcare system to run the evaluation. But I think it’s more likely to be a mixed world.”

Question 14 (Mohan): Because of all the breaches about national security implications of healthcare data are you seeing more conversations focused around security and feed level security around FHIR?

“The point about national security is interesting. I’ve had discussions about the ramifications of the OPM breach. Clearly the OPM breach is breaching data of national security interest. Whereas, your healthcare data is probably less directly linked, but your healthcare data is just like OPM data—not changeable. It is anchored in your reality.”

“As precision medicine gets more pervasive and everybody gets sequenced, and as the sequence hooks up so that your DNA sequence becomes part of your care, then everybody has as part of your record — really deep information about you. Then presumably, it becomes an even bigger magnet for various kinds of malpractice and malfeasance.”

“We pay attention to the contextualization of the security frameworks to healthcare, but we are not providing the security. However, we’re starting to notice that we need a good security bulletin framework, which we’ve never needed before. We need to pay attention to more of the security concerns. So, I expect this will be a growing concern for us. I do think that it is a social problem and society will have to adjust to the risks of big data. I expect that it will be messy.”

Question 15 (Mohan): As we try to implement FHIR, should we plan for the security layer to reside outside of FHIR?

“The spot on FHIR is the explanation of how to bridge the security problem and the security frameworks to the information that is available through FHIR. I think it’s going to be an important part of exercising FHIR. We delegate the hard work of security to the internet security standards. Our main concern is how to map the security information consequences into the information new exchange, or not. We did a fairly deep security audit of it last year and found some security falls in the model. So we beefed up the model, but I routinely do Oauthentic integrations with other providers using OAuth2, who haven’t taken those preventive measures that HL7 has or that spot on FHIR has actually.”

“I think perhaps we might need a little bit more depth in the security analysis. You could imagine a single company with single server with lots and lots of clients, well it’s even a challenge for them. Say you have clients that need to be updated through the Apple App Store. You’ve got a problem, but it’s even a bigger problem if you’ve got many servers and many apps; they are all interoperating with each other. Introducing a security change, driven change to the API, that is urgent, is a real nightmare in that circumstance.”

Question 16 (Mark): Do you think FHIR will have an affect on the type of personnel that hospitals, software vendors are going to want to have on staff to be working on integrations? It seems like we are going to have a new skillset versus the implementations that we did with HL7 v2, so how do you see that transforming within organizations within the next few years?

“When I talk to implementors in the FHIR community about this is there’s this thing that goes around about RESTful APIs — the 5-5-5 rule — 5 seconds to find the API, 5 minutes to understand what it was doing and 5 hours to have something working. But to that I add, 5 years to begin to understand healthcare. That is the key driver that the people you have that understand healthcare can easily learn to understand FHIR and RESTful APIs. So, that won’t drive change because it’s the people you have that understand healthcare and understand what can be done in interop that are the key great limiting step in any integration that you do.”

“The big new skill is around what we’ve just been talking about –– security. I’m starting to see more security specialists coming into the interop space, because with version 2 it was all like, ‘we just secure the channel and forget about security, pretty much. With FHIR, it is much more complicated than that. You can’t secure the channels, you have to secure the API itself.”

Question 17 (Mohan): And from that regard, you can share OAuth keys all the time, but there’s always more detail that is required, client-side, authorization, authentication, which portions of the data are you allowed to share, should share, authority to access. It becomes much more complicated.

“There are commercial providers of cloud services, Apigee, Akana, and others, working with our community to provide bullet-proof surface APIs. So, you put up an API, but the only service the API talks to is the cloud responder. That simply provides surface security on your Web presence. You might put up something on Linux, on Apache and there’s a new security briefing for some obscure part of that, are you even running it? How do you acknowledge that? You don’t have to worry about that because the only service that your server talks to is the cloud service and that’s not your business to worry about it. You’ve never heard of anything like that in the version 2 world.”

Question 18 (Mohan): Is there anything that you wish you had thought of when you started designing FHIR?

“There are some things that we set out to do that we haven’t done and that have fallen by the wayside a bit and then implementers are starting to notice some of the underlying definition or quality work that we had in mind to do. But, people don’t really ask for that. But the overall design, the agile standards development process, the RESTful API, the pragmatic focus on what implementers need to do in the free licensing, I think those things have held up really well and are driving the overall adoption process. Perhaps in a few years time, we’ll start accumulating more regrets around technical decisions, but we can keep changing those at the moment, so we don’t particularly regret them yet.”

Question 19 (Mark): One of the things I think we have on the agenda to talk about in the future is the economics of integration. Notably, preliminary thoughts or feelings that you are getting from vendors or hospital organizations about how FHIR would be priced. Will it be like many REST API vendors now by volume, or by licensing, like interfaces are today, or how that might work?

“At the patient portal level the government’s made it quite clear that there will be no charge to the patients, but someone has got to pay for it somehow, somewhere. The vendors may treat it as core infrastructure so that it’s in the overall cost; it’s a competition-based thing. Certainly developing a real FHIR solution is not cheap.”

“Whoever it is that’s going to host the server needs to have the security agents in place. That’s going to cost you some money, however you do the deployment. All those things cost real, solid, large amounts of money. It’s got to come from somewhere. I don’t know where the different kinds of services will come because in principle you would just say that we’ll just charge for them directly, but this is healthcare where we prefer indirect, obscure ways of charging for things.”

Question 20 (Mohan): perhaps it will be this indirect kind of model is what ultimately evolves from making the data available, and if it is valuable, you are able to make money off of it.

“Certainly in terms of the EHR plug-ins it seems likely that the major vendors will have their own app stores and that will be a revenue opportunity to cover the costs of the overall program. That’s certainly one very small part of the overall ecosystem.”

“That’s always a challenge with interop because very often the people paying the cost for it are disconnected from the benefits. So it doesn’t happen very well.”

Question 21 (Mohan): Which also ties back to the MACRA conversation. So if we have the entire model shift to value-based care, then something like FHIR, something like interoperability, something like pricing becomes a very different proposition. And that is exactly the conversation that I think we’d like to have next time.

“Could be really interesting, because right now is the MACRA preparations start rolling up and suddenly this whole business of economics is not a theoretical concern any more.”

(Mohan) I appreciate you taking the time. I’m glad that you are in the states; at the same time I’m sure you can’t wait to get back home in a couple of weeks. Thanks a lot. Have a good day.