Health Level Seven International (HL7), announces the launch of the HL7 FHIR Accelerator Program. The program is based on a model piloted by the HL7 Argonaut Project and, more recently, the HL7 Da Vinci Project. The goal is to strengthen the FHIR (Fast Healthcare Interoperability Resources) standard and enhance market adoption through a programmatic approach available to myriad stakeholders.
Charles Jaffe, MD, PhD
“HL7 FHIR has achieved remarkable adoption on a global scale,” said Dr. Charles Jaffe, CEO of HL7. “An ever-growing community of implementers has emerged across a broad spectrum of health care, eager to participate in an agile onramp for FHIR adoption and implementation. The HL7 FHIR Accelerator Program provides the framework for that community to leverage the technical capability, management expertise and experience gained during the creation and growth of the Argonaut and Da Vinci Projects.”
Building on the success of current projects – Argonaut (provider-provider and provider-patient) and Da Vinci (payer-provider) – The CARIN Alliance has recently been approved as an HL7 FHIR accelerator project (payer-patient). The three projects are complementary initiatives.
“On behalf of the CARIN Alliance, its board and membership, we are grateful for the opportunity to work more closely with HL7 as part of the FHIR Accelerator Program as we work to develop additional FHIR implementation guides so consumers can get access to more of their health information,” said Ryan Howells, CARIN Alliance Project Manager and Principal at Leavitt Partners. “Consumers and their authorized caregivers are requesting more access to health care data with less friction to empower them to become more informed, shared decision-makers in the care they receive.”
The original concept behind accelerating HL7 FHIR began approximately four years ago with the advent of the Argonaut Project.
Guest post by Gavin Robertson, CTO and senior vice president, WhamTech.
Gavin Robertson
As technology continues to permeate healthcare in different ways, it is becoming increasingly important for providers to have access to the data generated and retained by these technologies. With insurance providers, hospitals and clinics using a variety of electronic health records (EHRs), patient portals and databases, it can be difficult for all providers to have access to all relevant and most recently updated patient information. Differences among EHR vendors and systems make data access, sharing and interoperability nearly impossible.
Interoperability is a hot topic in healthcare today. Healthcare providers want to move beyond conventional Healthcare Information Exchanges (HIEs) that generally exist as single application to single application (P2P) data formats. The HL7 standard data model has helped a lot, but (i) it is too complex and extensive for full adoption, (ii) it is, typically, a specific relational or hierarchical implementation, requiring additional transformation, and (iii) there are a number of implementation variations.
Regardless of the improvements associated with the HL7 standard data model, the challenges facing interoperability remain; in that (a) multiple vendors have multiple ways to represent common data, (b) data may be required from more than one application and associated data sources, (c) poor data quality, (d) there may be no unifying view of data from one or more data sources, e.g., single patient view, and (e) there is no ability to write back to/update data sources.
HL7-based FHIR (Fast Health Interoperability Resources) APIs is a recent attempt to standardize access to data sources, but most vendor systems are nowhere close, as it is a different way of representing data from most vendor data schemas; i.e., object vs relational data representation. Also, some FHIR APIs need access to multiple tables in a single data source or in multiple data sources.
To implement FHIR APIs, one approach is to convert between the data source schemas (relational, hierarchical or flat) and the FHIR object model on-the-fly, but it does not address other shortcomings (poor data quality, no federation and lack of master data management (MDM)/single patient view). Another approach, which improves on just converting formats, is to copy and transform data into FHIR-friendly data stores and enable data services on top. However, this introduces additional problems, including latency, security, privacy, no interactivity; e.g., no write back/update to operational systems, additional storage and systems, and time and cost to implement.
Regardless of the approach, FHIR APIs open up interoperability and raise capabilities to new levels. New workflows can be developed and run using simple power end-user applications, such as BPM, reporting, BI and analytics tools. Examples include new smartphone app-driven BPM workflows running against FHIR API services, include write back/updates, on multiple legacy data sources in multiple organizations. Another example being hybrid cloud installations where multiple data sources are both on premise and in the cloud.
