Jul 25
2017
Fighting Fire with FHIR: Enabling True Interoperability in Healthcare
Guest post by Gavin Robertson, CTO and senior vice president, WhamTech.
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.