During part 6 of this series, John D’Amore discusses the HITECH Act and explains why the Fast Healthcare Interoperability Resource guidelines do not address unstructured data.
Integrated Healthcare Executive: Can you briefly discuss what the HITECH Act is?
John DAmore: Absolutely. The HITECH Act was passed as part of the American Reinvestment and Recovery Act in 2009. This is when the economy was going into a deep recession for it, and the federal government, with Obama just coming into office, wanted to be able to inject stimulus of about $780 billion, into the US economy.
The HITECH Act was a portion of that. In total, it added up over $40 billion for this. The primary use of that money that's within the HITECH Act was to be able to pay providers and health systems. Specifically, they paid physicians, nurse practitioners, and hospitals to adopt electronic health records. That program became known as the Meaningful Use Program.
One of the key backgrounds or fun facts about the program is that a congressman said that when these providers use electronic health records, they wanted to make sure that they didn't just take Microsoft's Word, start putting data in there, and calling it an EHR.
They said you had to meaningfully use the electronic health record in specific ways to improve the quality of care, the sharing, and the interoperability of that information. Those ways clearly eliminated products like Microsoft Word from using it to record digital data.
EHRs got a real turbocharge or a boost out of that program where their adoption of ambulatory market, maybe, was around 15 to 25 percent based upon what survey you looked at back in 2008, 2009 time frame for it. Going forward to today, over the last decade, it's really at 90, 95 percent for ambulatory physician adoption of electronic health records.
A real exciting advancement in terms of how EHRs were widely adopted were there were some other things that came out of the HITECH Act. Several of those were things to advance both the health information exchanges regionally and at state level across the United States for it.
Also, to create advanced research programs for how do we create a next generation of health information technology to power our healthcare ecosystem and get it where, I'd say, from the 20th century into the 21st century. Healthcare has been a laggard in technology adoption. The HITECH Act helped stimulate it.
Integrated Healthcare Executive: What are current examples of Fast Healthcare Interoperability Resources? How are they currently used in healthcare?
Mr D'Amore: One of the things that's been identified in the last five years as people began to use the EHRs is that the Internet was maturing, growing up, and getting used to what's called application programming interfaces to exchange information.
When you'd have an app on your phone and it wants to call Facebook or Twitter for information, it's going to use an API over the Web to be able to retrieve and bring that information back. Fast Health Interoperability Resources, or FHIR, is the way that you can use APIs to access data from electronic health records but more broadly can be used by any health information technology.
It can be used by analytics platforms or quality measurement platforms as well. Today, FHIR is still in its nascent or its starter state. We've seen some EHRs provide the ability to go in there and find a patient using FHIR and to be able to bring back a certain package or content of information on a patient.
Sometimes, those contents are in the form of what's called a clinical document, often known as a CCD or a CCDA, for it. In the future, we'll be looking for more of those packages to be even more granular, like just the medication list, or just the allergy list, or the problem list for a patient. Those are known as resources within the FHIR framework.
FHIR packages together both the way to send that data and to transport it, the transport layer and also the semantic layer of how are you going to package that information when it's received? Today, I'd say it's used primarily to be able to find patients and to be able to pull back a set of data.
Epic has integrated this with Apple's HealthKit where, essentially, on an Apple iOS device you can go in and pull in a set of information to your phone from your medical record from a relatively modest size of providers nationally. It's 20 or 30 very large health systems for that. I look forward to what's happened in the past few months.
At HIMSS in 2019, the OMC and CMS released new guidance around interoperability and set out a lot of the new ways that FHIR will be used and changed the landscape for health information exchange over the next several years. That's a proposed ruling. It's important to take that with a word of caution. Things can change significantly between proposals and final rulings.
We won't expect the final ruling from OMC to come out until later this year or early 2020. We're still a few years out from the widespread adoption of FHIR at every ambulatory office and health system nationally. I look forward to the way that that's going to be happening in the future.
Integrated Healthcare Executive: Can you explain why the FHIR guidelines do not address unstructured data?
Mr D'Amore: Yeah. There's two things to talk about with FHIR. One is the way that APIs have unlocked tremendous information flows on the World Wide Web and the Internet for this. FHIR is going to unlock data flowing through the healthcare ecosystem. It's clearly a better and faster way to get information. However, FHIR doesn't necessarily clean up the information that flows.
When you're using APIs with technology companies like a Google ‑‑ Google has a very large maps API set ‑‑ you always get data back in exactly consistent format. No matter where you are in the world, you can always find your longitude and latitude using Google API service. EHRs are going to be able to respond using the FHIR protocols.
The way that you get that information might still be very divergent. I'll give you one example. When you look at a medication list, you can have medications that are encoded using the National Library of Medicines' RxNorm vocabulary. You can use the FDA's way to refer to that medication which is called the National Drug Classification.
You can use some proprietary libraries, like Medi‑Span, or First Databank, or Molton to record that information. There's a lot of different ways that that information could be codified in a medication list as well as also having the opportunity for a clinician to write down that the patient is taking baby aspirin without using any codes at all.
When you get that information back as part of an API request from FHIR, it's not necessarily going to turn that information into a usable asset. FHIR's going to make it available but won't necessarily make it fully usable.
The analogy with languages is that FHIR's going to make it so that you can hear all the people around you and what they're saying. It's not going to make everyone speak the same language.
There's going to be a need for technology companies to be able to service that middle layer of cleaning up and making that information semantically interoperable for FHIR to achieve its true potential.