Proposed ONC rule requires FHIR interoperability standard
If the Office of the National Coordinator for Health IT has its way, HL7’s Fast Healthcare Interoperability Resources will be the standard to which developers must certify their application programming interfaces.
In ONC’s proposed rule, released on Monday, the agency for the first time has said that it intends to make FHIR a requirement.
Congress required developers participating in the ONC Health IT Certification Program to publish APIs allowing healthcare data to be accessed, exchanged and used “without special effort” as a provision of the 21st Century Cures Act.
“While there are a variety of relevant healthcare standards for connecting labs, images, claims processing systems, and other pieces of the provider world, when we look at the app economy and the clear trends in modern computing, one API approach seems to clearly emerge–Health Level Seven’s Fast Healthcare Interoperability Resources standards,” wrote National Coordinator for HIT Don Rucker in a blog post regarding ONC’s proposed rule.
“We believe this approach could lead to industry standard interfaces—interfaces where app developers can develop effective apps that use API technology ‘without special effort’ to access a patient’s data,” added Rucker.
App developers, health IT vendors, and providers have widely embraced FHIR to help solve the interoperability challenges confronting the healthcare industry as it seeks to increase access to electronic health records and data sharing.
“The important issue is that we have come to a point where it’s time to agree this is how we’re going to share data,” says Chuck Jaffe, MD, HL7’s CEO, who adds that he wasn’t surprised by ONC’s proposed rule. “The critical mass has already been achieved—that is, there are enough people who are committed to FHIR that it is a reality. It’s not a draft, an experiment, or an academic concept. It’s real.”
“The ONC rule not only emphasizes FHIR as the API standard of choice, but it prohibits charging for API access and restricts data blocking,” observed John Halamka, MD, chief information officer at Boston’s Beth Israel Deaconess Medical Center. “The entire package will accelerate interoperability across all stakeholders.”
“They should have required FHIR in the first place—it’s about time that they did,” observed Graham Grieve, FHIR’s product director. “I’m pleased to see FHIR written into the regulations with testing.”
In its proposed rule, ONC specifically would make FHIR Release 2 a requirement, according to Steve Posnack, executive director of ONC’s office of technology.
Posnack said that the agency decided to require FHIR Release 2 given that its research late last year indicated that 87 percent of hospitals and 57 percent of Merit-based Incentive Payment System-eligible clinicians are served by health IT developers with products certified to FHIR Release 2.
“We’re trying to meet the market where it’s best prepared to accelerate the use of FHIR,” commented Posnack. At the same time, he acknowledged that last month HL7 published FHIR Release 4—the normative version of the interoperability standard.
However, Posnack insists that ONC “has a number of different options in terms of what we can finalize (in the rule) to allow industry leaders to perhaps take a step forward and go directly to FHIR Release 4.”
According to HL7, the most significant advancement with FHIR Release 4 is that the base platform of the standard has passed a normative ballot and has been submitted to the American National Standards Institute as such.
“In addition to the ONC rulemaking, the recent progress for FHIR to become normative allows folks who might have been waiting on the sidelines to start to participate,” said Jocelyn Keegan project manager for the Da Vinci Project, a payer-provider led initiative to leverage FHIR to exchange critical data required for value-based care delivery.