FHIR based interoperability has been tantalizingly close for over 5 years. Interoperability that has rendered data coming from EHRs and claims into a commodity, has de-risked connecting to hospitals, and has enabled a company to focus on the use case and value prop of the product remains out of reach. I think that those companies that offer data integration services are safe.
With the recent federal RFI on FHIR, digital transformation, and interoperability, I have been thinking a bit on whether I would make a “FHIR-first” healthcare company if I was a new founder.
In full disclosure, I’ve been skeptical about the impact of FHIR on the industry in the past few years. In a larger sense, I would say I have developed a deeper cynicism about standards based data exchange in healthcare. This has been the result of 15 years in public health and clinical informatics in which I have seen the promise and later disappointment of multiple iterations of standards. The barriers to success are often similar: lack of adoption; overly complex standards; variable implementations; addressing the letter, not the spirit, of new rules; and a lack of business models to support change. I would not, in 2009 at the start of meaningful use, have thought that in 2025 this would be unsolved.
Josh Mandel has been on a tear on Linked In, describing the many current barriers to true interoperability. His publicly available response to the federal RFI is a great read.
Here are some of the things that are still risk points for digital health companies, and will cost extra money and time if not thought through. For a new startup or business seeking to address a healthcare problem, what is the ease of implementation and risks of use of FHIR? Can I reliably count on a QHIN to have data coverage in the population I may have of interest, and what will the cost be? Will the data be sufficiently standardized across the participants in that network that I can minimize the transformation work I may need to do? And, what is different now compared to the eras of HIEs to make QHINs more likely to be successful?
Thinking about provider customers, can my integration team count on a healthcare system or provider to be a strong partner to make FHIR worthwhile? Will they be USCDI v3 capable? Will my company’s support of FHIR standards be seen as a positive or value proposition by my CIO leaders?
Perhaps information blocking has made data exchange necessary and available for EHR vendors, enabling a market for integration and clean and standard data to exist.
There also remains the issue of write access to the EHR. Providers want workflows that are in the EHR and seamless. How does a company deliver it to them? Given that FHIR write capability is really at the prototype stage in EHRs, this means that FHIR APIs really represent just a data source. Will CDS Hooks be available or will we be the first implementation for a customer? Given all the tasks we need to do, I’m not sure I want to be the first unless a) it scales broadly in the industry and b) it makes integration into workflow easy.
But having said all this, I must note that there has been slow and steady progress. Information blocking and TEFCA have improved the landscape of data sharing. Epic has a path for rapid app distribution. There is a generational change in available technology and customer expectations occurring, and persistent progress across administrations.
So for a healthcare technology company, there could be value in putting some time and expertise on the table as an investment into a FHIR based future. If the cards are dealt correctly, it could become a differentiator, an accelerant, and a means to leap ahead if data is a key asset. But you won’t be able to give up on HL7 2.x just yet.
Leave a Reply