Robust Testing Is Required for Reliable Healthcare Interoperability

Healthcare delivery organizations are evolving to meet new market demands and require that their IT systems interoperate more effectively than ever before. HDO CIOs must rigorously test against standards as the most effective path to reliable interoperability.

• Integration is about making a single vendor's suite of products work together seamlessly and holistically as a system.
• Interoperability is about achieving similar results among various, often competing, vendor products and IT services – regardless of the product architectures and technologies that they have been built on.
• While interoperability and integration are not the same – the tools, technologies and standards used to achieve both are often similar.
• Most healthcare delivery organizations (HDOs) and vendors do not adequately test for interoperability.

HDO CIOs and IT leaders:

• Assess your vendor's extraenterprise interoperability capabilities to determine if these will satisfy your information- and work-sharing requirements as you evolve to a real-time healthcare system.
• Ensure your enterprise interface engine or integration platform will support your interoperability requirements and strategic vision.
• Build adequate time and budget for robust interoperability testing into your system development and implementation plans.
• Insist that system vendors show proof of independent (third-party) testing and plans for continuous interoperability.
• Use interoperability and conformance testing services if you are developing applications or interfaces in-house.

Healthcare IT systems, whether developed in-house or acquired, must work together as a coherent system of systems to safely deliver on their collective value proposition. It has never been easy to achieve interoperability among healthcare information systems. Most standards have the flexibility to support a wide variety of use cases. For example, almost every U.S. Health Level Seven (HL7) laboratory results interface is different, due to variations in the coding and interpretations of the standard. This problem is not unique to HL7.

These variations arise in part due to ambiguities in the standards, but primarily, because the vendors find it in their economic interests to push for idiosyncratic interpretations, rather than to change their software and the data entry approaches to those their users have become accustomed. The only way to ensure that HDO systems are truly interoperable is through disciplined and rigorous standards-based testing. Testing does not ensure the absence of errors – but rather reveals the presence of errors. This is particularly true for interoperability testing.

Leading healthcare vendors design and engineer their products to work together. They employ application integration techniques and data-sharing standards to create systems that can acquire, display, share and report on the patient information to support critical clinical workflows and business processes within the HDO.

There are a number of ways to create systems whose components work together to share data and work. Some integrate at the database, while others rely on interfaces and message brokering, Web services, APIs, and service-oriented techniques. Some degree of each of these approaches is used by all healthcare information systems.

Systems integrated at the database can be more attractive to some HDOs. It could be argued that systems integrated entirely at the database do not require integration, but rather, due to the nature of their architecture, share information and state data by way of a common database – therefore eliminating much of the need to pass data between system components.

Application integration platforms and tools (such as message brokers, interface engines, enterprise service buses and database connectors) do an adequate job of creating the technological and application-level connections necessary to implement and maintain system interfaces. However, they are less effective in accounting for differences in the semantics, syntax, events and workflows among integrated applications.

Whether a suite of products is developed using a common application framework; is sequestered from individual best-of-breed applications; is integrated using HL7 messaging or service-oriented architecture (SOA) mechanisms; or shares data and context through a common database, they are all integrated. Each has the design, architectural, technical and governance strengths and shortcomings inherent to a particular approach.

Interoperability and integration are not the same thing – although the tools, technologies and standards to achieve both are often the same. Integration is about making a single vendor's suite of products work together holistically as a system. Interoperability is about achieving similar results among various, often competing, vendor products and IT services – regardless of the product architectures, technologies and hardware platforms they depend on.

In the near future, the various forms of integration and interoperability – messaging, SOA, Web services, APIs, cloud computing, composite applications, visual integration, batch processing, file transfer, and common database or schema – each with unique challenges – will become core competencies of all healthcare system vendors.

HDOs have heterogeneous IT environments made up of products from various vendors, implemented on different platforms in different programming languages, using different application frameworks and tools, often by different development teams. This is true even for those HDOs dominated by so-called healthcare "megasuite" vendors.

Gartner defines "interoperability" among healthcare information systems as the ability to exchange data accurately, in a timely manner, effectively and consistently, and to use the information in the data that has been exchanged. Gartner has described three types of interoperability:

1. Semantic interoperability – Information exchanged is completely computer-processable.
2. Document interoperability – Textual information exchanged is suitable for a person to view along with a computer-processable header that enables the receiving system to index, retrieve and appropriately display the text for a person to read.
3. Incremental interoperability – A hybrid approach that enables clinical information systems at differing levels of semantic sophistication to interoperate on a "best possible" basis.

Each of these interoperability types is appropriate for specific interfaces and use cases. It has never been easy to achieve interoperability among healthcare information systems. The challenges in achieving interoperability include getting the right balance between semantic and document interoperability – and to do so in an incremental manner that enables clinical information systems and cooperating healthcare information systems to evolve.

Healthcare IT vendors, regardless of their application integration approach, will be required to support interoperability standards, such as HL7, clinical document architecture (CDA), Fast Healthcare Interoperability Resources (FHIR), Direct, Integrating the Healthcare Enterprise (IHE), and Digital Imaging and Communications in Medicine (DICOM), to name a few.

To support the increasing number of things in the healthcare provider Internet of Things, vendors will have to expose more and more of their data and functionality to the HDO and other vendors.

The real-time healthcare system (RTHS) is a next-generation operational, management and information technology paradigm that represents the transformation of the HDO into an enterprise that is more patient-friendly, accessible, responsive and transparent, and whose reach could ultimately make care more convenient, of higher quality and more affordable for the consumer.

As the financial and performance pressures on HDOs have increased, HDO CIOs are finding that they cannot meet their organizations' objectives without significantly shifting their views of how technology enables the organization. This creates an imperative to move from their traditional, disjointed healthcare operation to a more real-time, digital healthcare operating model – one that demonstrates increased enterprise awareness, operational excellence and de facto interoperability.

To date, the emphasis has been on capturing and reporting on information. In the near future, the emphasis will be on sharing and quickly acting on information to control or cut costs and improve service, care quality and the overall patient experience. This will require that HDO IT systems interoperate more effectively than ever before to share work and information, and will necessitate more-sophisticated integration and interoperability.

For HDOs to survive and thrive in an unfamiliar, rapidly changing marketplace that is moving from volume to value – their transformation to an RTHS is vital.

Interoperability is difficult under the best of circumstances and extremely difficult under normal circumstances. Most healthcare system vendors and HDOs are not prepared to do the disciplined and exhaustive interoperability testing needed for reliable interoperability. Interoperability testing is necessary to mitigate risk, and conformance testing must be built into the software development life cycle, HDO system implementation initiatives and purchasing decisions. HDOs should demand vendors show proof of independent (third-party) testing and continuous interoperability.

Interoperability testing must not be limited to positive or "happy path" testing – that is, testing to ensure merely that a system does what it has been commissioned to do. Without rigorous negative and exception testing, unexpected things occur in production, and unplanned outages result. Negative test cases (for example, malformed messages) and related defects are critical, because these are among the most difficult problems to isolate and resolve in in production.

Testing environments offering highly visible results and drill-down capabilities into message traffic at the source of the defect can dramatically shorten the troubleshooting cycle and speed interface development and delivery. An interoperability testing platform should include a sufficient quantity of standardized test data available to allow for exercising the most common and exceptional transactional use cases.

Many HDO and vendor organizations are developing and acquiring applications and systems that leverage established industry interfacing and interoperability standards (for example, HL7). Most of these organizations also design and build their own unique testing tools and environments, often at the expense of wider interoperability. Robust interoperability testing requires a community of vendors and providers committed to industry standards to develop a robust set of test cases and testing platform recommendations that the entire healthcare community could leverage and benefit from.

Until then, HDOs and independent software vendors that serve will test their interoperability capabilities through:

• Self-testing and self-attestation of interoperability
• Testing required to onboard with established health information exchanges (for example, Healtheway eHealth Exchange)
• Testing required for certification with standards bodies (for example, HL7 conformance testing)
• Peer-to-peer testing events (for example, IHE Connectathon)
• Testing through third-party interoperability and conformance testing service providers (for example, AEGIS.net Developers Integration Lab)

• What proof of interoperability does the vendor have?
• Which IT and industry standards and protocols are being used for interoperability?
• Which industry interoperability and standards organizations does the vendor participate in?
• Where does the vendor stand on national efforts to harden and certify healthcare interoperability standards?
• What provisions does the vendor have for interoperability testing and its ability to test standards conformance?
• What independent evidence can the vendor provide to demonstrate interoperability (for example, certifications from recognized authorities, and "report cards" from trusted testing organizations)?
• Does the vendor have an expressed opinion or view on the findings of the recently released Jason report (see Note 1)?

Interoperability is about making data available and consistent across applications and workflows, and makes it possible for disparate systems to reference and share patient-related information, and to support business and clinical processes across organizational and system boundaries. Interfacing (a loosely coupled, asynchronous form of application integration) is at the heart of interoperability. If interfaces are not properly designed, tested, versioned, deployed and supported, they can create a fragile and unreliable interoperability environment – becoming prey to poor service levels. If they are not based on a common understanding of the data and industry standards, they can result in incomplete or inaccurate information.

The transformation of the HDO will depend heavily on new and existing systems working together more effectively – sharing data and work – to connect, communicate and collaborate better than they ever have in the past. Robust interoperability testing is the most effective way to ensure this.

The Jason report, entitled "A Robust Health Data Infrastructure," was funded by the Agency for Healthcare Research and Quality (AHRQ) and outlines a vision for a "comprehensive, transparent and overarching software architecture" that would create an open, interoperable health data infrastructure. The report suggests taking 12 months to define the architecture, provides a detailed example of what it might look like, and recommends that many elements be incorporated into Stage 3 meaningful-use requirements.

It also calls for an international interoperability effort led by the U.S. Office of the National Coordinator for Health Information Technology (ONC). The full report includes eight specific recommendations directly affecting ONC, Centers for Medicare & Medicaid Services, Department of Veterans Affairs, and Department of Defense, among others.