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.
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.
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.
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.
NCPDP = National Council for Prescription Drug Programs
Source: Gartner (November 2017)
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:
Synchronous vs. asynchronous
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.
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.
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 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.
API Management Platform
Data Interchange Platforms and Networks
Interface and Integration Engines
Source: Gartner (November 2017)
Source: Adapted from "The OSI Model: An Overview," SANS Institute Reading Room. 2001