When two federal health agencies released proposed rules in February that affirmed their previous commitments to the FHIR (Fast Healthcare Interoperability Resources) standard and application programming interfaces (APIs), it was a mixed bag of emotions for senior executives at HL7 International, the standards organization tasked with accelerating FHIR.
On one hand, HL7 was “thankful and gratified” to see this commitment to FHIR start to become a reality, but at the same time, the quick acceleration of the standard “on such a grand scale” was somewhat scary, says Wayne Kubick, chief technology officer of HL7. “Our job is trying to make sure we keep things moving, while also keeping expectations realistic, recognizing that this is a long journey,” Kubick notes. He adds that HL7 “is not the biggest organization in the world by any means. We rely on a relatively small circle of experts who help us move things along compared to the broader world of the impact we are exposing.”
Nonetheless, federal health leaders at CMS (the Centers for Medicare & Medicaid Services) and ONC (the Office of the National Coordinator for Health IT) were ambitious in their separate, but aligned proposals around FHIR and APIs. In its rule, CMS proposed to require Medicare Advantage plans, state Medicare and CHIP managed care entities, Medicaid managed care plans and qualified health plans in the federal exchanges to implement, test, and monitor an openly-published FHIR-based APIs to make patient claims and other health information available to patients through third-party applications and developers. ONC, meanwhile, also proposed that FHIR must be the standard by which health IT developers certify their APIs.
Kubick says that while HL7 was not surprised at all at ONC’s commitment—as it is directly tied to the 21st Century Cures Act and because ONC and HL7 have been working together—CMS’ was unexpected. CMS has been doing work on its own with the Blue Button [2.0] API initiative that uses the FHIR standard to make healthcare data more readily available to millions of Medicare beneficiaries. But just days before CMS publicly released its proposed rules, HL7 executives got word that the federal agency would be pushing forward to make FHIR a requirement. “It was unexpected, but it’s clear that CMS is going all in. They [believe] that if they are going to change how they pay for healthcare and get costs more under control, then we need to have this infrastructure in place. And there’s no other approach that can accomplish this [goal] that is available today, beyond FHIR,” Kubick contends.
Kubick believes that the industry is quickly progressing on its FHIR journey, noting that the first step “was to change the way we do standards,” which was accomplished with the launch of FHIR Release 4 earlier this year, he attests. The second step is to commit to health IT developers’ use of it, and “these rules established a baseline expectation across EHR [electronic health record] vendors and other vendors supporting the payer system.” The third step involves “changing the way we conduct and provide healthcare. That’s the next challenge—where healthcare information actually touches patients and their providers,” Kubick says.
The impact of the proposals
Stakeholders believe that FHIR will allow healthcare to work in much the same way as other modern internet applications do. They say that the FHIR standard will enable developers to build standardized “browser” applications that allow access to data no matter what EHR system underpins the user’s infrastructure. Part of the allure is that this effort can get away from document-centric approaches and expose discrete data elements as service. For example, a clinician may want to retrieve an entire document about what’s going on with the patient, or he or she may just want the patient’s allergies information. The flexibility of the standard opens up a wider variety of use cases. What’s more, with its use, patients can more easily access their own medical record via a common web portal or mobile app, usually provided by a third party.
Micky Tripathi, Ph.D., president and CEO of the Massachusetts eHealth Collaborative, and a well-positioned industry thought leader on interoperability and standards, believes that because healthcare is so fragmented in the U.S., FHIR being pushed forward as an agreed-upon standard is a great sign. “There is a real surge toward making data available to patients and giving them the ability to access that data through tools that either the provider provides to them or that the market itself will provide. FHIR-based APIs and requiring this kind of access is fundamental to that,” says Tripathi.
On the payer side, he notes that up until now, the burden of HITECH was mostly being placed on providers. While that was needed, CMS, through this proposal, is upping the ante for payers, too, he adds. “Even though CMS doesn’t have the authority to [require] this for all its commercial programs and payers, it’s great that the [agency] is taking as expansive a perspective as it can by saying that anything it does have authority over in terms of healthcare payment, and all of the API and information blocking elements, applies to [public payers] as well. So you have to expose FHIR-based APIs, expose FHIR-based patient-facing APIs, and you have to share information across health plans when patients go from one plan to another. That’s really terrific,” Tripathi expresses.
Regarding the progress that has already been made, CMS touted in its proposed rule that approximately 32 percent of certified health IT developers have published, via the Certified Health Products List, that they are using FHIR Release 2, as of mid-September 2018. ONC officials have pointed out that while the 32 percent figure may seem “low” at face value, the estimated market share of the health IT developers using FHIR is quite large since the 10 certified health IT vendors with the largest market share across hospitals and clinicians all use at least the FHIR Release 2 as their API standard. These vendors include some of the biggest industry names such as Epic, Cerner, Allscripts, athenahealth, and others. In its proposal, CMS stated that the industry is well prepared to adopt the FHIR standard, and it proposes to adopt FHIR Release 2 as the baseline standard.
Tripathi, however, points out that for the hospitals that ONC touts as using products that have FHIR-enabled capabilities, “Almost 99.99 percent of the capability that’s available right now is basically a FHIR-based API for patient access,” he says. “The data the patient gets through that API is no different than what they could have gotten three years ago through the view/download/transmit button on their patient portal. So on one hand it’s great that FHIR is available in these systems, but the functionality of it is pretty narrow,” Tripathi expresses.
He explains that each certified health IT vendor publicly publishes its development platform with which APIs it has available. Each vendor has enabled very specific APIs for different functionalities; for instance, almost all the big vendors have the basic Argonaut profile for patient-facing APIs exposed. “But say you wanted to use that FHIR-based API for provider-to-provider exchange, you wouldn’t be able to do it right now because most of the vendors have yet to expose that,” Tripathi says.
To this end, Ben Moscovitch, project director of the health information technology program at The Pew Charitable Trusts, cautions that the proposed rules, even if finalized as they are, won’t take effect right away, as the effective date for the requirements would be two years from the finalization of the rules.
Not a silver bullet for interoperability
Although stakeholders are bullish on FHIR’s potential, many will also convey that adopting the standard on its own won’t accomplish much broader information sharing and cost-cutting goals. Tripathi believes that even by providing patients better access to their data, “It won’t upend how the healthcare market works and flip the economics so that this industry [suddenly] works like every other efficient sector of the U.S. economy. Healthcare is just fundamentally different in so many ways,” he says.
Another area of concern for some is just how much knowledge C-suite healthcare leaders have about FHIR, but Kubick doesn’t think it’s overly important for hospitals and health systems to know the mechanics of how the standard works. “But they do need to feel comfortable that it is a part of the baseline architecture that we are all going to be working with, and the proposed rules make that clear. Organizations will have to support FHIR, which makes it an enabling technology that can unleash all kinds of innovation they might not have previously thought about,” he says.
Tripathi adds that it’s his “hope and dream” that hospital executives don’t need to know much about FHIR at all, but rather they focus on having an enterprise strategy based around interoperability for their providers—most of which happens in the EHR—layered with the ability to expose APIs that can enable apps to connect to their system.
“Grahame [Grieve, the founder of HL7 FHIR] says that FHIR is the web for healthcare,” adds Kubick. “Go back 25 years to when the World Wide Web first started becoming available. People had browsers and could look at information in totally different ways than they previously could with the older character-based terminals. Look at what web browsers did for things we do every day such as shopping and travel. That’s what we are trying to do with FHIR, and we need people to buy into it and help us conceive what that next generation will look like. That’s the message we need to get out to senior hospital executives,” he says.
