LICENSED FOR DISTRIBUTION

Best Practices for Healthcare Provider CIOs to Select the Right Patient Data Interoperability Platform

Published: 03 November 2017 ID: G00328006

Analyst(s):

Summary

Every major healthcare provider IT project involves acquiring, exchanging or sharing patient data. Incorrect platform decisions for patient data interoperability can waste time and money, and put projects at risk. Healthcare provider CIOs should use this research to guide their platform selections.

Overview

Key Challenges

  • It is becoming increasingly difficult to clearly identify the best technologies and platforms required to address the myriad of patient data acquisition, exchange and sharing requirements (patient data interoperability) the healthcare provider CIO currently faces.

  • The impact of a wrong platform decision can be considerable in terms of wasted time and money, compromised initiatives and lost opportunity.

  • Vendor messaging can be misleading and occasionally exaggerated. This does little to provide the healthcare provider CIO with what they really need — a proper perspective on data-sharing platform capabilities and how they align with their business requirements.

Recommendations

Healthcare provider CIOs evaluating real-time health system data interoperability platforms should:

  • Examine high-level patient data interoperability exchange patterns to determine the most recognizable data-sharing patterns (e.g., pushing and pulling data) among interoperability partners. There are many variations on these two fundamental themes that complicate matters.

  • Determine the messaging, encoding and communication requirements to identify the capability alignment gaps that exist between various interoperability partners, which in turn, highlights important data-sharing platform requirements.

  • Analyze patient data interoperability enrichment requirements. Take into account more complex data-sharing relationships that require data enrichment capabilities to transform, normalize, standardize and augment the message payload.

  • Use the above requirements to select the most appropriate patient data interoperability platform. Spend the time to understand each platform's intended uses, strengths, and the data-sharing and interoperability requirements it best addresses.

Introduction

Interoperability and data acquisition, exchange and sharing go hand in hand. Interoperable systems facilitate data acquisition, sharing and exchange, and systems are made interoperable through standards-based data acquisition, exchange and sharing. For the purposes of this research, we will simply refer to patient data acquisition, exchange and sharing as "patient data interoperability."

Patient data interoperability requirements are complex but critical activities related to the operational and clinical success of the healthcare provider. Different data payloads require different messaging standards, encoding and enrichment approaches. Despite vendor messaging to the contrary, it is not always possible for a single data interoperability solution to satisfy every healthcare provider use case. It is an ongoing challenge for the healthcare provider CIO to gain a clear perspective on the capabilities and appropriateness of the various platforms available today.

As investment increases, healthcare has become an attractive vertical for data interoperability vendors. They view healthcare as fertile ground and are eager to assist the industry with its so-called "interoperability problem." Vendors new to the healthcare space often underestimate the complexity of healthcare data, while at the same time, they have the courage to go beyond legacy thinking and offer new approaches to health information sharing.

Figure 1 illustrates important messaging standards and protocols that work together to facilitate patient data interoperability. It is useful and revealing to map these technologies to the venerable Open System Interconnection (OSI) reference model (see Note 1) for a clearer understanding of their roles within an interoperability infrastructure.

APIs, Digital Imaging and Communications in Medicine (DICOM), Direct, Fast Healthcare Interoperability Resources (FHIR), FTP, HL7 (Health Level Seven), HTTP, Integrating the Healthcare Enterprise (IHE), SMTP (email) and web services reside at the application level of the OSI model. This seventh and uppermost layer of the OSI model is where healthcare applications and systems gain access to interoperability services. OSI application layer interoperability services in turn rely on lower-level transport, session and presentation level services to complete their work. TCP and IP are transport- and network-level protocols, respectively.

All patient data interoperability platforms must support the messaging standards and protocols associated with the various layers of the OSI model. Platforms are often differentiated by the support they provide at the application level, particularly the support they provide for more modern technologies such as APIs and web services.

Figure 1. Interoperability Standards and Protocols for Patient Data Interoperability
Research image courtesy of Gartner, Inc.

NCPDP = National Council for Prescription Drug Programs

Source: Gartner (November 2017)

Analysis

Examine Patient Data Acquisition, Exchange and Sharing Patterns

There are any number of ways in which IT systems can acquire, exchange and share data, and there are a few fundamental patterns that routinely take shape. At the most basic level, data is pushed or pulled from an interoperability partner. While these are the most elementary types of data acquisition, sharing and exchange use cases, variations on these two themes abound such as:

  • Broadcast

  • Fire-and-forget

  • One-way pull

  • One-way push

  • Publish/subscribe

  • Request/response

  • Synchronous vs. asynchronous

  • Two-way push/pull

Despite the numerous variations, there are a limited number of data acquisition, exchange and sharing use cases that form the basis of most healthcare provider requirements. A data acquisition, exchange and sharing platform must be able to scale from the simplest of use cases to the more complex and sophisticated and, in some cases, the arcane.

Understanding your most common data acquisition, exchange and sharing scenarios, and the requirements and capabilities of your interoperability partners is fundamental to identifying the right platform.

Determine Messaging, Encoding and Communication Requirements

Sharing health data involves determining the required messaging standards, communication protocols, trust relationships and networks.

The Cartesian product of the various messaging standards, communication protocols, data types and encoding and enrichment requirements demands a great deal of agility on the part of the data-sharing or interoperability platform. As with data-sharing patterns, messaging, encoding and communication requirements are the common denominator between interoperability and data-sharing partners. These relationships often reflect the capabilities of the least sophisticated partner in the data-sharing arrangement.

Industry messaging standards include DICOM, Direct, HL7, IHE and X12. APIs and web services can also be used to exchange these messaging payloads. To complete their work, APIs and web services rely upon application and lower-level protocols such as FTP, HTTP, SMTP, SOAP and TCP/IP.

Discrete health data is more often shared or exchanged using HL7 messaging or as HL7 documents based on the HL7 Continuity of Care Document Architecture (CCD-A). Pushing CCD-A documents can be accomplished via secure email, secure FTP or with Direct (a form of secure messaging or email done within a trusted network). Discrete health data and documents can also be shared using secure web services, HL7 FHIR and proprietary APIs. FTP is often used for sending health data in scheduled batches.

Much like understanding information exchange patterns, having a good grasp of the messaging, encoding and communication requirements reveals the capability alignment gaps that exist between various interoperability partners. This, in turn, highlights important data-sharing platform requirements, particularly those related to data transformation and enrichment requirements.

Analyze Data Transformation and Enrichment Requirements

Just as it is necessary to move data items as is or aggregated in some manner, it is often necessary to transform and enrich the data in some manner before it is transmitted. Enrichment transforms, normalizes and improves the quality of the message payload. All data-sharing platforms provide transformation and enrichment services to varying degrees through:

  • Enrichment — validating, expanding and substituting message content

  • Normalization — standardizing syntax and semantics, disambiguating and codifying content

  • Transformation — reformatting and input/output mapping message content

Data transformation and enrichment capabilities are key to adding context to message payloads, so they can be more easily shared with and consumed by receiving systems. Data transformation and enrichment examples include:

  • Consolidating multiple patient identifiers to a single unique identifier

  • Mapping sending message format to receiving message format

  • Substituting clinical concepts with industry standard nomenclature and classification codes

  • Transforming HL7 messages to XML documents

  • Validating message content using external resources

Use Interoperability and Enrichment Insights to Select a Patient Data Interoperability Platform

Use data exchange patterns along with messaging, encoding, communication and data enrichment requirements to create a capability matrix for evaluating the appropriateness of existing and prospective data-sharing and interoperability platforms.

Revisit your enterprise data-sharing and interoperability requirements to determine how your existing interfacing platforms compare to newer market offerings. You may find that your current vendor platform has capabilities you were not aware of. You may also find out that their roadmap to satisfy your requirements may put your data-sharing project in jeopardy.

Don't fixate on the platform category a particular vendor seems to fall within. The lines between these platform and solution categories are blurring and there is considerable functional overlap. Some newer vendor platforms almost defy categorization. Rather, spend time to understand each platform's intended uses strengths, and the data-sharing and interoperability requirements it best addresses.

Gartner defines five basic types of patient data interoperability platforms (see Table 1). The venerable interface engine has always been and continues to be at the center of healthcare provider intraorganizational transactional interoperability and health data sharing. But, it has begun to extend its reach outside the enterprise. A number of interface/integration engines (Orion Rhapsody, InterSystems Ensemble, Infor Cloverleaf) serve as the technical underpinnings of HIE platforms.

With the increased interest in APIs and the hype surrounding HL7 FHIR, the API management platform has begun to garner more industry attention. APIs are a way to acquire and share clinical data and fill in the interoperability gaps not served well by message brokering.

Data interchange platforms and networks are relatively new and innovative approaches to sharing health data. They address interoperability and data-sharing use cases for population health, accountable care organizations (ACOs) and HIEs, and clinical data interchange between providers and payers. This new category was created because these vendors currently do not fit neatly into the other data-sharing and interoperability platform categories.

IoT platforms perform a particular type of data sharing and interoperability — between devices, applications, equipment, appliances and controls that possess the intelligence and technology to interoperate with other things using standards and protocols. This should not be confused with more general purpose data-sharing platforms.

Some vendor platform and service offerings that illustrate differentiating and disruptive data-sharing capabilities are worth further scrutiny:

  • DataMotion Health is particularly adept at Direct messaging and secure email data sharing. This vendor implements its own healthcare information service provider (HISP) on the DirectTrust network.

  • Diameter Health aggregates, cleanses and enriches clinical data for sharing and analytics. Clients include ACOs, HIEs, healthcare providers and payers, and vendor partners.

  • Healthjump's jumpSTART platform is used to gain access to all manner of health data that resides in disparate health information systems. It extracts, transforms and transmits this data to satisfy interoperability and analytics use cases.

  • IMAT Solutions extracts, aggregates, normalizes, cleanses, maps and indexes health data (regardless of source, volume or type) in real time from across the entire continuum of care for HIEs, ACOs, hospitals and payers.

  • PNT Data is billed as a data coordination specialist. Its services enable flexible system interfaces and secure data access and communications, as well as data mapping, translation, validation, end-to-end process monitoring and reporting.

  • Redox is a secure, VPN-accessed network for sharing health data. Healthcare providers subscribe to the Redox data-sharing network to gain access to partner data through industry messaging standards and protocols such HL7, DIRECT and Redox-specific APIs.

  • Sansoro Health offers a near-term alternative to creating FHIR resources. Sansoro Emissary is the reusable, scalable and secure API plug-and-play solution for EHR integration.

  • Verinovum is a health data enrichment and interchange platform. This real-time platform was built to address industry gaps in clinical and claims data integration, content acquisition, terminology management, decision support, and analytics for HIEs, payers and other data aggregators.

Table 1.   Patient Data Interoperability Platforms

Platform

Description

Representative Vendors

API Management Platform

  • Application programming interfaces enable modern user experiences, offer new ways to integrate and orchestrate systems, and open new business channels and business models by exposing functionality and data to consuming applications and business processes.

  • API management platform capabilities enable the successful delivery, promotion, operation, measurement and continuous improvement of APIs.

  • API management capabilities apply to REST-based APIs, messaging APIs, Simple Object Access Protocol (SOAP)-based APIs, and custom and proprietary APIs.

Apigee

Axway

CA Technologies

Datica

IBM

MuleSoft

PokitDok

Red Hat

Sansoro Health

TIBCO Software

Data Interchange Platforms and Networks

  • A data interchange hub is the orchestration platform that brings together data from across the consumer/citizen/patient health and wellness continuum and prepares the data for delivery to downstream consumption platforms, applications, analytics and "things."

  • It automates the ingestion of data — both structured and unstructured — from all identified and permissioned sources, provides tracking and traceability, and manages identity, compliance and security.

DataMotion Health

Diameter Health

Heathjump

IDS

IMAT Solutions

PNT Data

Redox

Verinovum

HIE Platforms

  • A health information exchange platform and trust alliance facilitates the exchange of patient-related information among independent healthcare organizations.

  • Participants in an HIE are organizations that, by prearrangement, exchange data through the HIE for the purpose of improving care and patient safety.

  • The HIE market includes software and technology services to create and operate an HIE.

Allscripts

Cerner

Epic

Forcare

IMAT Solutions

Infor

InterSystems

RelayHealth

Orion Health

Verinovum

Interface and Integration Engines

  • An interface/integration engine enables healthcare applications and systems to share and exchange electronic information.

  • Interface/integration engine platforms provide capabilities for interface development; a message mapping environment for standards such as HL7, CDA, X12, APIs and web services; testing; versioning; message routing; troubleshooting errors; and a runtime performance monitoring environment.

  • The venerable interface engine continues to evolve and now plays more heavily in interorganization data-sharing arrangements.

Allscripts

Cerner

Corepoint Health

Epic

eTransX

Halfpenny Technologies

Infor

Interfaceware

InterSystems

MDI Solutions

Microsoft

Mirth

Oracle

Orion Health

PilotFish Technology

Qvera

IoT Platforms

  • The Internet of Things (IoT) is a collection of "things" — devices, applications, equipment, appliances and buildings — that possess the intelligence and technology to connect, communicate and interoperate with other things using standards and protocols.

  • An IoT platform is a software system that facilitates IoT endpoint management, operations and monitoring.

  • The platform monitors event and data streams, enables specialized application development and analysis, and integrates with back-end IT systems.

Connexall

IBM

Lenovo Health

Mesa Laboratories

OpenText

Oracle

Philips

Qventus

ThoughtWire

Vivify Health

Source: Gartner (November 2017)

Note 1
Open Systems Interconnection (OSI) Model

Figure 2. OSI Model Layers and Responsibilities
Research image courtesy of Gartner, Inc.

Source: Adapted from "The OSI Model: An Overview," SANS Institute Reading Room. 2001