In Part II of her FHIR Dev Days wrap-up, J2 subject matter expert Ayesha Lefevbre tells us what’s next for FHIR. We have work to do, but it’s going to be worth it. (Or start with Part I: What’s New With FHIR?)
Let’s talk about data
In particular, let’s talk about bad data. FHIR presents us with a remarkable opportunity, but where’s the value if it only shuffles around incorrect or incomplete information? Even though FHIR is key to healthcare IT innovation, there’s work to do. At the recent HL7 FHIR Dev Days conference, Beth Israel Deaconess Medical Center CIO Dr. John Halamka addressed the risk of FHIR overhype, the need for a patient tracking system, better metadata, and the importance of policy initiatives to support the technical advances made with FHIR.
“People think FHIR does more than it does at the moment. The trajectory is excellent, but we need to temper expectations.” – Dr. John Halamka, FHIR Dev Days 2018
One of the key issues holding back interoperability in the United States is the lack of a national identifier to track patients as they move through various healthcare systems. Other countries have a more centralized repository of patient data. Dr. Halamka was not hopeful that the US would move towards any centralization of healthcare data, but stressed the need for alternative solutions to uniquely identify US patients. Another key issue is that each state has different data sharing policies which hampers care coordination across state borders because clinicians and hospitals are unable to freely share data. And finally, the third major factor contributing to the bad data challenge is the lack of standardization in healthcare data, i.e., right now it’s hard to contextualize readings coming from a Fitbit vs. a pacemaker.
Dr. Halamka’s keynote pointed out several key questions that we still need to address:
- What is the best way to provide EHR data to application developers who need it?
- How can we convince vendors to be more open?
- How do we harness the promise of machine learning?
- How will we make apps FHIR-enabled to sit on top of transactional systems to enable delivery of personalized healthcare?
Dr. Halamka left the stage with a call to the FHIR developer community and private sector to continue innovating, because FHIR is not being fully utilized. Only about 300 of the 3000+ HL7 health record elements are currently mapped to FHIR. Plus, even with policy constraints and lack of clean data, there are improvements that we can make in the areas of data sharing policy and data context that can help the US healthcare industry get closer its interoperability goals.
Consensus on the data quality challenge
Regarding the issue of messy data, Google Brain’s Eyal Oren gave a response in the same vein as Dr. Halamka’s:
“Healthcare data is messy and complicated, and nothing is going to change that…In Translate, for example, if you need to translate English to Chinese we don’t go around and ask you to write your English in such a way that is easier for us to translate into Chinese. We just take whatever is there and try to make our best out of it.” –Eyal Oren, FHIR Dev Days 2018
Both keynote speakers closed with an obvious message: There are no silver bullets, and those who adopt FHIR will see benefits in the form of improved workflows but there will be data quality and data sharing challenges. It is promising to see Google working with HL7 International to expand FHIR. We believe Google has the market clout to help push US interoperability as they incorporate FHIR into their platform, but whether they will simply mine data or work with the EHR vendors directly is not yet clear.
Is bad data FHIR’s fault?
It’s important to remember that FHIR is a data standard whose purpose is to move healthcare data around. FHIR is not going to solve data entry mistakes, patient record inaccuracies, data siloing, or miscommunications between clinical departments. FHIR also isn’t responsible for cleaning up protectionist maneuvers by vendors. Data quality problems have been with us forever, and we’re making progress. Still, as we pursue the promise of FHIR we must maintain parallel efforts to improve data quality.
Even though we’re shining a light on a challenge, it’s not our intention to start a FHIR pros/cons debate. There are too many pros to list for FHIR, but the cons boil down to it being an evolving standard and its current inability to handle huge data transactions. Both of these issues are being addressed in future FHIR versions.
We are confident that FHIR is the way to go to meet interoperability goals. It already has the best of HL7v2, HL7 v3 and CDA as well as REST and JSON. We’re watching its evolution closely, and developing our own solutions using FHIR – and we like what we see.
What do you think? Do you agree? We’d love to hear your comments!
