FHIR Had A Good HIMSS
In January, when I asked Wayne Kubick, HL7’s chief technology officer, whether FHIR would be a highlight at HIMSS yet again this year, he said we would have to wait until February to find out, but that “the good news is that FHIR has now become an accepted part of the ecosystem.”
Well, I would say that FHIR had a very good HIMSS. Beyond FHIR-based apps on display on the show floor and in panels, the Office of the National Coordinator and the Center for Medicare & Medicaid Services used the conference to follow through on their previous commitments to the FHIR standard and application programming interfaces (APIs). As Premier Inc. has pointed out in its initial response, APIs will enable a proliferation of consumer and provider apps using EHR data. “This will make EHRs more usable and flexible for providers and will democratize data to consumers. We’ll be hosting a webinar on the proposals in the coming weeks.”
On one hand, releasing the “information blocking” proposed rule during the busy HIMSS conference was bound to get CMS maximum publicity, but on the other hand, it did leave health IT executives with little time to read and digest the 724 pages and form opinions. Most probably had 12 hours of meetings already planned for those days!
But in the API section, the document just reiterates that the commitment to FHIR is clear. CMS touted industry adoption that already has taken place, noting 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. Additionally, 51 percent of health IT developers appear to be using a version of FHIR and OAuth 2.0 together.
CMS also estimates that approximately 87 percent of hospitals and 57 percent of clinicians are served by developers with a FHIR Release 2 API. Pointing to the Argonaut Project and Apple’s iOS 11.3, which includes a new “health records” app for the iPhone based on these specifications, CMS states that the industry is well prepared to adopt the FHIR standard, and it proposes to adopt FHIR Release 2 as the baseline standard in a new API standards section of its rules.
CMS noted that FHIR Release 4 has now been published and includes FHIR resources designated as “normative” for the first time. “This will lead to a cycle of more mature U.S. FHIR Core profiles aligned with Release 4 and additional implementation guidance that explicitly specifies how to handle populations of patient data (batch exports) via FHIR to more efficiently enable population and learning health system-oriented services,” the proposed rule states.
Stating that FHIR Release 4 will be the next de facto version the industry would move to coalesce behind, CMS asks for guidance from stakeholders about which version of FHIR to adopt for certification purposes and when.
It wouldn’t be a CMS proposed rule without some new acronyms. CMS proposes a set of 15 FHIR resources that Health IT modules certified to the proposed criterion would need to support. It is referring to this initial set as the API Resource Collection in Health or “ARCH.” It would align with and be directed by the data policy specified in the proposed US Core Data for Interoperability. CMS notes that it is including a DocumentReference FHIR resource to support sharing clinical notes in ARCH Version 1 responds to request from providers to include a focus on the access, exchange, and use of “clinical notes” as part of certification.
The next implementation specification for the FHIR standard CMS proposes to adopt is the Argonaut Data Query Implementation Guide version 1 hosted by HL7. It has been pilot tested and is now being put into production use by health IT developers.
During HIMSS, Charles Jaffee, M.D., Ph.D., HL7’s CEO, released a letter from CMS Administrator Seema Verma in which she outlined her organization’s priorities for the upcoming year, including a focus on bulk data access. She noted that CMS is following the FHIR Bulk Data Access draft specification in a new API that will deliver Medicare claims data to ACOs faster than the current CMS Claims Line Feed (CCLF) approach. “We are looking forward to helping mature this specification. Although not part of the Argonaut project, we wanted to highlight our work in this area and welcome opportunities for collaboration in the future,” she wrote.
Other areas she mentioned include:
• ADT for Discharge Notification, Patient and Physician
• Claims Data from Payers
• Real-time Benefit Check (RTBC)
• Provider Directories.
• Price Data from Payers and Providers
• Quality Data
• Access to Expanded Clinical Data
