How Fast Health Interoperability Resources are enabling true interoperability in healthcare

By 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.

In fact, differences among EHR vendors and systems make data access, sharing, and interoperability nearly impossible.

And interoperability, no doubt, 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 Health Level-7 (HL7) standard data model has helped a lot, but (1) it is too complex and extensive for full adoption; (2) it is, typically, a specific relational or hierarchical implementation, requiring additional transformation; and (3) there are a number of implementation variations.

Regardless of the improvements associated with the HL7 standard data model, the challenges facing interoperability remain. The key obstacles include:

  • Multiple vendors have multiple ways of representing common data.
  • Data may be required from more than one application and associated data sources—and the quality of the data may be poor.
  • There may be no unifying view of data from one or more data sources (e.g., single patient view).
  • There is no ability to write back to/update data sources.

Further, HL7-based Fast Health Interoperability Resources (FHIR) application programming interfaces (APIs) are 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; however, this does not address other shortcomings, such as poor data quality, no federation, and the 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. Still, this introduces additional problems, including latency, security, privacy, and a lack of interactivity.

Fortunately, technologies offering data integration and management can address most, if not all, of these challenges—providing unique, alternative index-based approaches. These technologies can enable high-quality and high-performance query access by applications to almost all healthcare data sources via FHIR API services that leave data stored in sources (to keep it secure); only results data is retrieved when needed. Some attributes of new, alternate technologies such as these include:

  • FHIR-friendly indexes and indexed views, which bridge the gap
  • FHIR-friendly standard data view, which bridges the gap between the standard FHIR data object model and multiple disparate data source models (e.g., enabling legacy data sources to be seen as modern FHIR resources.) This makes it easy to understand the meaning of data and hides query complexities on indexes. It also allows federation levels across multiple data sources to be seen as a single data source and deploys at federation levels or directly on adapters.
  • Data discovery, quality, security, privacy, transformation, and standardization addressed upfront as indexes are built and maintained, and on results data
  • High-performance queries processed against indexes—no load on data sources
  • Additional derived data, event processing, linked data/graph database, and other capabilities
  • Seamless and automatic integration of MDM for a single, comprehensive view of all data associated with entities such as patients (master patient index, or MPI), both for a single data source adapter and across multiple data sources at federation levels
  • Easy-to-use, customer-friendly configuration tools that avoid/minimize coding
  • The ability to run on AWS, IBM API Gateway, and Bluemix, as well as other platforms

Raising Technical Capabilities

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 IBM’s Business Process Manager (BPM), reporting, Microsoft Power BI, and analytics tools.

Examples include new smartphone app-driven BPM workflows running against FHIR API services, such as write-back/updates, on multiple legacy data sources in multiple organizations. Another example is hybrid cloud installations, where multiple data sources are both on-premise and in the cloud.

Suffice it to say that securely managing massive amounts of data will be essential with new regulations and the dramatic increase in the number of cyberattacks on healthcare organizations. Beginning to solve these issues could mean leaving data in sources, and enabling high-performance queries processed against indexes to address fundamental data management issues—which, in turn, imposes almost no load on data sources. Additional important capabilities are derived data, event processing, linked data, and graph visualization.

In conclusion, as hospitals gain increasingly more data from a myriad of sources, technology needs to adapt to help physicians securely access and analyze that data, without them having to sort through it all.

Still, it is an exciting time in healthcare to be able to watch these interoperability solutions develop and solve one of the largest challenges facing the industry. And the results will be improved patient outcomes, lower costs, and increased satisfaction for all stakeholders.

Gavin Robertson is chief technical officer and senior vice president of Dallas-based WhamTech, responsible for product design and development, technical sales, and marketing. Questions and comments can be directed to 24×7 Magazine chief editor Keri Forsythe-Stephens at [email protected].