 |
| Grahame Grieve of Health Intersections, PTY LTD – photo credit HiMSS 19 |
Mr. Grieve conceived of the idea of establishing such a standard after working as a laboratory scientist performing clinical tests and later as a developer for a laboratory information systems vendor. He has since started Health Intersections, Pty Ltd. and works as an interoperability consultant. He is the project lead and product director for FHIR, an HL7 Standard. He is a Fellow of the Australian College of Healthcare Informatics and co-chair of the Modeling and Methodology Work Group at HL7. He is the national Subject Matter Expert for clinical data exchange for the Australian National Health Record Program. Based in Melbourne, PARCA eNews spoke to him during a Skype interview.
Q. Briefly to get to the basics, how is FHIR different than HL7. And or how does it extend HL7?
A. OK, HL7 is two things. First of all is a standard which is a 1970s based messaging standard to push information around between backend business enterprise systems. It's also an organization that grew up around the standard that writes a variety of healthcare standards around data exchange both the most widely used of those standards is what's usually called the HL7 standard and it's very old technology very old ways of managing information, but it has very high market penetration and for what it does it does it really well.
FHIR arose about eight years ago when a small group of us said, yeah, HL7 understands the business space really well and has really good connections, but it's time for us to go with something that's 40 years more recent in terms of a technology for understanding how to manage information and understanding of how to build community, which was the web. So, we basically said let's take the web and marry an open community with the web to all of HL7’s strengths and establish a presence and community and deep understanding of healthcare. It’s really how do you adapt the set of technologies and information management styles that are the web to healthcare.
The result is FHIR seems to have really hit the sweet spot, being the right thing at the right time. It sprung rapidly and got a lot of attention and I think most people regard what we are doing as the future of healthcare data exchange. The existing messaging will be around with us for a long time, but almost all new work favors focusing on how to use the web, which in most cases pretty much means how to use FHIR.
I think I should talk about DICOM because DICOM is walking this road with us. DICOM has a similar strategic issue in that they have old technology that's very well established, but now they're looking at it and saying there's better ways to do this. So DICOM themselves are making their own transition to web-based technology information management, they're doing that in a partnership with us, their standards are influenced by ours and vice versa and we work together on the overlap and the connection points between FHIR the wider healthcare community and the digital imaging community.
We're not intent on taking on the core of digital imaging and they are not intent on taking on the wider community. We're trying to figure out you know how to draw the right relationships. For instance, we have an ongoing project with the PACS vendors around extending our consumer level access to healthcare data to also provide for consumer level access to healthcare images. That's joint work between the HL7 and DICOM.
Q. So FHIR and DICOM and HL7 all kind of work together. Is it a synergistic process?
Yeah, that is pretty much the plan. It's a work in progress, but organizationally and technically things are working together better than we've managed in the past. And you know, I'm really hopeful that things will play out for a lot more seamless integration as we go forward into the future.
Q. What are the technical challenges to this becoming a widely adopted standard like say a Windows or something like that. I mean getting to a point where everyone just assumes this is the standard?
Well, pretty much the issue is market inertia. There are still plenty of enterprises and consultants and Industry influential people who take the attitude that they know their own paradigm really well and since their own paradigm is theirs that’s the one that matters. They take the attitude that FHIR is really nice technology, but it's not for the important use cases because the important use cases they have already handled.
I look at that, I think that's misunderstanding the position. FHIR is not so much a technology as a framework for handling information that's extensible in all sorts of ways that the other technologies are not. And that business in other Industries, and it will happen in healthcare, has transformed the business to that of being a service provider.
And the idea that you've already done the important stuff totally misunderstands the business transformation that this brings about and I think a lot of the players will be left flat-footed once those business arrangement start changing and they'll find that the old services are just part of a much wider ecosystem.
I’m as much commenting about diagnostic services, you know diagnostic services primarily, in my observation, are sitting there thinking we know our business, but there's plenty of companies that sat there going we know our business while someone else disrupted them by constructing a different business that people actually want to use and left them in the dust. I think the diagnostic service providers should be facing up to the fact that the service will change.
Q. By players are you talking about the vendors of medical devices or you talking about organizations and institutions?
I'm talking now about the actual providers of imaging services and their customers which are either institutions or patients or researchers or GPs or whatever that the nature of the business that they provide will transform rapidly. And that will be enabled by technology and information management but driven by bottom-line dollar concerns just the same way Uber disrupted taxis for instance.
Q. One of the things I keep hearing over and over about FHIR is that it's not yet mature. What are they talking about? What do they mean by it's not mature?
Let me give you some background and then I will put some context around it. Classically standards were one shot. We published it, now its the rules everywhere. But with the kind of complexity of the standards, we're building, you just can't do that and get it right. Consequently, what we do is we publish a draft standard and in the early phases of its life it changes very quickly as we respond to learned experience from using the standard over time. The rate of change slows as more and more people have used it and experienced it and tested it, and eventually we call a last and final call for changes and then we make it fully 'normative.' 'Normative,' which is a code word for standards people that means to have full unchanging standard. That process can take five or six years for each of the little bits of the standard so when you talk about maturity we have a formal process for tracking the progression through that stack.
When talking about maturity, people are talking about that process where we will still make changes to reflect learned experience. But a lot of people hear that and say the standard is not ready for use. It's not ready for final call because we're still learning the edges of the use cases, but it's thoroughly ready for mainstream adoption. Of course, it comes at a technical risk, which is that we're still potentially changing the APIs over time.
So really the question is what do you mean by maturity? FHIR’s mature and way more mature than the alternatives because we've had so much use experience that we've reflected back into the standard. Of course, older standards tended to be pretty frozen and it was very hard to reflect experience back into the standard.
If you say well we'll make up our own since FHIR is not fully mature yet. Well anything you do will be way less mature because you don't have that exposure that we do. But still we are in the process of making breaking changes and that does mean that risk-averse vendors say they will sit out the process and wait for everybody else to grab control of the specification to make it do what they want. And then we'll just take whatever we get at the end of that process. So they yield control by yielding involvement.
I think that it's technically true that the standard is still maturing. But I think that saying just bluntly the standard is not mature conveys the wrong idea about when you should get involved.
Q. So that leads to another thing I've heard is that if you implement one version of FHIR, then it might not be compatible or interoperable with say a later version of FHIR. Is that an obstacle or is that a misunderstanding?
That's exactly the truth that's quite true, and that's what we were just talking about that we will make changes as we learn that previous decisions that we had made were suboptimal or you know stops people from solving particular problems. So as you go from version to version, they're not compatible with each other, but we are heading towards the ability and compatibility and we have published Release 4, which the rules require as a base and the basic API and the core functionality that is stable from Release 4 going forward. So we won't be making breaking changes.
Our goal is that the next release will be stabilizing the core clinical resources, but you know, we have to make sure that we meet the use cases. We don't do things that are wrong and when you've got maybe two or three hundred thousand decisions in the specification you just can't get them right the first time, but it is true that we make breaking changes to the API and Release 2 implementation is not compatible with Release 4 and what we've said all along is that's how it works and everybody needs to build a framework into the way they approach the specification to solve that problem. Maybe the framework is we will pick a version and never change, or maybe the framework is that we make our work adaptable. People make different decisions for different reasons.
Q. How does this kind of standard differ from the kind most people are familiar with, which is Windows operating system. It's gone through a lot of versions, but people all adopted it and they update and upgraded as they go. With the FHIR standard it seems to be whole different kind of process.
Well, the change control process is different because Microsoft Windows is a commercial product that people have adopted so they can run other software. If Microsoft released a version of Windows that broke other software that wouldn't work.
Over time FHIR will get to that point but FHIR is maintained by an open transparent standards organization. We can propose changes and people can argue about their merits. For any given change some people in the community will be arguing that it's not worth making the change while other people will be arguing that it's critical and necessary to make a change and if it breaks the API, it's just a price of doing business.
So there's the community aspect of it, but the other is as we said where you can trust that we will figure it out and get it right, but Microsoft has a different kind of a problem, which is that they were called out for security and they really needed to make some breaking changes to the operating system, but it took them many years to pull that off because they had to tailor the change that would let everybody get to the point that they could make the change, but in the meantime, we were all insecure. So the basic issues that drive forward making changes breaking changes going forward that will come out one way or the other.
It's really a question of moving the deck chairs on the Titanic. In a word, change is painful and we as a community spend a lot of our time arguing about how to manage change by making the least worst impacts.
Q. Another one that I've read about is the tendency of vendors to pick and choose FHIR APIs and that has a tendency to undermine the goal of interoperability. What's the solution to that?
From my point of view interoperability is an incremental process, unless the government or the market independently, suddenly rapidly changes course and says we are going to abandon all our existing solutions and go to a single new piece of software that doesn't yet exist, we will continue to have multiple vendors making lots of different decisions because their market engagement is different and the market itself demands very different solutions and that a customers that buy the large EHRs spend hundreds of millions of dollars adapting their EHRs to the organization not the other way around.
So those market realities mean that the kind of interoperability that we dream about that we would love to have is an incremental process over many years as people realize that the price of making those kinds of customizations to the software is that they can't have the consistent information management that they need in order to build the wider healthcare processes that run across multiple organizations.
In the end it's not a technology problem it’s a people and information management problem. And for me we keep chipping away at identifying solvable problems solving them and this is an iterative process with the regulations. We talk a lot to the ONC about what they can, and what they should regulate, what they can regulate, and then what they propose is, you know interacting with the markets and they end up with less than we hoped for but, you know it still it's an incremental process.
If the government or the market tries to jump too far it won't work. Everybody's impatient and everybody wants better access to data and better services, but you know the healthcare industry is so big that nobody can just take it on and build a better alternative. And so we're going to keep moving along as we are.
Q. To that point, the ONC just this week mandated that Medicare Advantage, Medicaid CHIP, and other federal health coverage plans in the US are required to support a standardized API based on HL7 and FHIR that will give patients access to claims and other cost information as well as medical information related to a clinical encounter. Is that the kind of push or mandate that will solve that problem of vendors bending the rules and using it the way they want?
Well, you know, I mean vendors use it the way they have to, driven by their business engagement. I think that by and large the vendors I deal with believe that exchange of patient data, the patient record should be exchangeable. It doesn't serve the vendor business for it not to be. I think that the providers are a lot less sure about that, but the vendors are very interested in sharing patient records, there’s no reason not to share them.
On the subject of that particular ONC regulation. That's the kind of regulation that encourages the sharing of what we want to see, but that particular regulation is focused on sharing financial data. I think financial data is very widely recognized to be relevant, but not particularly clinically compelling. There's a bunch of reasons for that.
But I think that most patients will find the outcomes of that primarily useful when it comes to billing problems with the health care system and not particularly useful for their own actual healthcare outcomes. Although there's some interaction between the two but I think most patients will find that data not that exciting, but I think it's still necessary as part of building out a fully open healthcare ecosystem so that people can start delivering services to the patient. So I think it's a really good regulation it is the kind that you need in terms of pushing standards. You need a central authority with a big stick to push the market towards the right place to be. This market often gets stuck in a sub optimal place for society as a whole.
Q. In part of the press release the ONC seemed to be pushing this idea of open financial data as a way of increasing the ability of patients to shop around for their care. I have some doubts about whether they were actually going to be able to do that and whether they want to do that. Do you think that a free market healthcare system might have a harder time creating or developing interoperability than say a single payer system where when one payer is calling the shots?
Okay it's possible that some patients will benefit from that financial data, but I think that most of the beneficiaries will be the actual institutions who are engaged in the ongoing price setting wrangle between the payers and the providers and the government as the major payer who stands to benefit. So I think Congress's interest in price transparency is more about the real beneficiaries.
Q. On a national level, has FHIR taken hold and become kind of nationally adopted in in any other country. Is it in Australia or Netherlands?
Every country around the world has an ongoing national infrastructure and architecture and building program that has variable penetration through the healthcare system. In some countries the national architecture is the healthcare system in others it's only informative.
And in every one of those architectures a slow rolling over you don't abandon an architecture midway through a 20-year build process. So when you look around the world, you'll see every country's thinking about FHIR and how to adopt FHIR and where to adopt FHIR and how that influences their national program and as they come to decision making points in their national program, they will take significant steps to adopt FHIR.
Whereas others are like, you know, we're still rolling out and leveraging what we've already done. We don't want to go back to the drawing board, and we recognize we’ll have to at some stage but the time is not now.
So around the world there is a very strong focus on FHIR as the future but they have a very variable take on when the future actually alters the present work, but there's a number of countries very focused on FHIR. The English National Health System has identified FHIR, and they came to that decision point last year and is very much focused on FHIR as the interoperability base to take the system forward in all the new design work. Whereas for instance Australia, the national program is still at the end of the we're rolling out a national document-based infrastructure, and we're still not ready to lay down a new infrastructure at this time. Of course, it started to get pretty controversial because a lot of the system would rather get into the new infrastructure, but it's up to the politicians to choose to fund that.
Q. Is there any other alternative to FHIR? I mean, it sounds like there's enough momentum behind FHIR that it should eventually get to the to the breakpoint when everyone will adopt it.
Initially there were some competing initiatives because people were pretty frustrated with the standards organizations that they weren't responding to what was evidently the need, but because we have an open community and a welcoming community and we've built this is and we've leveraged that to build the right kind of relationships, and everybody's come on board and there's not really any directly competing alternatives.
The nearest thing to a competitor is a really interesting and great open source project called Open EHR, which is not directly competitive. They worked on interoperability because they had to but it wasn't really their focus. Their real focus was shared system and information design for healthcare systems, which you know is still a very pressing problem. Whereas we're focusing on a layer down on interoperability, but there's still a lot of people who very vested in the notion of a shared system.
So we say that's nearest thing that we would have to an alternative, but it's not what we are doing, which is why they are still around and being relevant, and it is my hope that community does well because that's an important problem that we’re not taking on.
Over time, I think we will need to get more aligned (with Open EHR) because it's relevant. The trouble for us is its (Open EHR) active and relevant and very active and relevant in a few countries, but not many countries, so it's kind of hard for us to think about them and to engage with them in the way that we need to because we have different market prioritization.
Q. What are the next goals for FHIR? What would you see an immediate next two to three years?
We're kind of at the standards level consolidating the standards development process. We're busy growing our capacity to support implementations to provide open software that helps institutions and vendors build working solutions. We’re getting more involved in patient-level advocacy, supporting the patient community and to helping people build really innovative solutions on social media.
I think that at the moment the healthcare system is still too institution-focused and I think we're going to really get involved in the advocacy of making it people-focused and that is staff-focused as much as patients, and provider-focused rather than institutionally driven. I think that we still have a long way to go around those things.
And the other thing that we're building as new a standards space is care management guidelines and the exchange of guideline assessment so that we can start automating the learning healthcare system. But I think that's a lot of work to go in building an automated learning healthcare system, and we are just a very small part of the overall work that’s needed.
Q. I think our time is up. Is there something I've left out that you would like to make sure to include?
Can I have one last pitch? The foundation of the work of FHIR is to build open public knowledge and public treasure that we all are in and we are all richer because we all wanted it. This the underpinning of what a civil society is built on and right now it's evident that the concept of civil society is under attack and I encourage everybody who is, you know, reading this to spend a few hours of every week giving to some civil society that builds public open knowledge because that's the foundation of the happy open society that we are all a part of and that's why we build FHIR as an open solution and it's critical that everybody participates and spend some of their time giving to it.
Postscript Mr. Grieve added after the interview: The Covid-19 epidemic is a massive crisis, but one good outcome is an absolute outpouring of collaboration to build better IT systems to empower us to deal with the challenge – that’s civil society I called for stepping forwards.
No comments:
Post a Comment