Testing NwHIN or IHE Gateways

IHE has published working profiles adopted by the healthcare industry in various stages of implementation and testing. The NwHIN Exchange seeks to leverage those profiles but advance their maturity collectively by building a framework called the NwHIN Specifications around these specifications. These specifications are collectively called service sets.

Service Sets

The NwHIN has published the following list of service sets:

Each of these service sets defines the use case actors for both initiator and responder scenarios. The NwHIN depends on secure communication leveraging an IHE specification called ZUA XUA or OASIS SAML 2.0. An IHE compliant gateway does not conform to all the documented requirements of an NwHIN Gateway as there are document differences between the two implementations.

IHE Specifications

Integrating the Healthcare Enterprise, or IHE, is a not for profit, global organization responsible for advancing for creating health care interoperability specifications for use by the industry to securely and accurately exchange health information. IHE is partnered with the Healthcare Information Management and Systems Society (HIMSS) to enable and mobilize multiple health care professionals to create and enforce standards for interoperability. These various standards are elaborated within the IHE Specification documentation, demonstrating functionality systems can perform with one another in regards to Health IT interoperability. Each year, these IHE Specifications are put to the test in the annual IHE Connectathon in Chicago where multiple participants bring their system gateways and test various user stories, simulating real world events to ensure interoperability.

OASIS (SAML, XAMCL)

Within the scope of Health IT, a multitude of messages will be sent and received among many organizations on a day-to-day basis. Gateway systems utilize web services to send XML based messages amongst various organizations, adhering to strict standards defined within OASIS. To ensure these messages are securely transferred from one organization to another, a Security Assertion Markup Language (SAML) and Extensible Access Consent Markup Language (XACML) inferences are built into the XML based message. Adding a security layer to the message allows the message to be properly shared among approved exchange partners. If a request message is sent out with specific SAML Assertions built into the message, the request will only go to a limited number of approved exchange partners rather than to any healthcare system gateway.

Certificates

The exchange of health information between two organization gateways is secured through the efforts provided by public key certificates. These certificates provide a method to ensure the gateway is exchanging information with a trusted entity. Currently, the NwHIN Exchange uses two-way authenticated, SHA 256 RSA type SSL TLS 3 based certificates. During peer-to-peer interoperability testing, it is beneficial for two systems to simulate the secure exchange of health information using self-signed certificates.

Alternatively, allowing access to a common root certificate authority (CA) to support and issue cross certifications and individualized gateway certifications to all participating entities facilitates early adaption, installation and configuration of a simulated production gateway environment.

This approach allows for advanced gateway to gateway interoperability testing, for instance testing the functionality for certificate revocation. Within the certificate revocation scenario, if a gateway's certificate is randomly revoked, an exchanging gateway should recognize this and immediately cease trust and exchange related interaction.

Request (Initiator) & Response (Responder) Scenarios

A majority of the defined IHE Profiles and NwHIN Specification actors have one of two types of roles, either as an initiator or a responder. Within each of these roles, the gateway performs a specific service, namely Patient Discovery (PD), Query for Documents (QD), and Retrieve Documents (RD).

Within the initiator scenario, the gateway the user is currently using to test initiates interaction with another gateway by first sending a PD request. A responding gateway will respond to the signal and return a list of results for patients.

Within the Responder Scenario, a gateway sends a PD request to the gateway the user is currently using to test for a PD request; the responding gateway is tested to ensure it responds correctly to the PD request.

A gateway must have the capability to act as both an initiator and a responder (bi-directional) to ensure it can interoperate with other gateways.

The Technical Stack

The Technical Stack includes the Operating System, Firewall, network interaction, web service tier, application server, security stack, SSL encryption and decryption algorithms.

Gateway Versions

The Developers Integration Lab supports bi-directional interoperability testing against multiple versions of standards and specifications for exchanging health information. Health care information exchange specifications are constantly evolving, and similarly the gateways which support the implementation of these standards evolve as well. Subsequently, testing must occur as new upgrades and updates to these specifications are standardized, harmonized, and finally implemented within these systems. The DIL provides a method to test these new standards early and often to ensure a gateway remains compliant against various standards in existence and new versions of other gateways as well. Both backwards and forward compatibility with multiple standards and gateways are necessary to ensure interoperability.

Backwards compatibility

Through their development lifecycle, gateways undergo enhancements necessary to support recent published versions of the specification. Backwards compatibility is critical to ensure gateways interoperating with newer specifications remain capable interoperating with gateways using an older specification. As it currently stands, organizations must manually test interoperability with other organizations as new versions, updates, and standards for gateways are implemented. The facilitation of meetings, analyses of gateway message logs, and re-work required by the current process incorporates a considerable amount of administrative overhead to ensure interoperability. The DIL seeks to provide an easy method for developers to test their gateway implementations as these updates come online, without the addition of the administrative overhead.

Gateways

Gateway is a term applied to a technology whose specific role it is to interface between an organizations backend systems (EMR / EHR) and external entities is seeking to exchange health information. The gateway is responsible for security, authentication, routing, service location, access consent, auditing, error and exception handling. For additional information on related technologies, see the adapter section. Several gateway approaches exist or are available, there are open source products such as the open source CONNECT project. Alternatively, organizations that develop EMR or EHR solutions have expanded their services to include the development of IHE and exchange compliant gateway technologies.

An organization wishing to exchange information within a Health Information Exchange or HIE must ensure the correct gateway solution is chosen. Prominent factors determining the implementation of a specific gateway pertains to the type of Healthcare information to be exchanged and the types of standards exchange partners use. The DIL provides an independent environment for potential participants to test vendor and custom gateway implementations and evaluate which gateway(s) best fits the need of the organization.

Adapters

Large numbers of organizations are working to replace manual paper medical files with EMR and EHRs. Included in service offerings are often times a large data repository, master patient indexes (MPI), Access Consent policy engines, web portal technology, patient centric web sites, and various other systems. These systems are internally available to the operations and administration of the medical facility. While the primary purpose of EHRs and EMRs is the collection of health information through a medical event or encounter, there is a growing need in support of the ONC and CMS to share health information under the coordination of care and improved quality of care MU criteria.

According to the rules highlighted within Meaningful Use Stage 2, interoperability is a critical requirement organizations must achieve wishing to submit claims to CMS. The EMR / EHR retain medical information while the gateway serves as a conduit between the organization and the community to exchange health information. The adapter sits conceptually between the EHR / EMR system and the gateway itself, providing a method to transform the outbound information from the EHR / EMR into a readable, standards based message structure which can be then sent out by the organization's gateway and received by another's gateway. Adapters will need to provide capabilities to support patient correlation and look up functions as well as document query, document retrieve, and document submission type services while adhering to applicable standards and specifications. The adapter will need to be developed with performance characteristics in mind.

Elements of a Good Testing Platform

Multiple approaches for testing conformance and interoperability are used within the industry today. Initially, system testing is a method to demonstrate a solution works in accordance to a specification or business rule. This type of testing is coined 'Happy Path' testing, as you test to ensure the system adheres directly to the specifications. Testing ways to generate errors in a system and find multiple ways to produce an error through a negative business event is called negative testing. Negative testing is as critical to testing using the happy path method, as performing types mitigates the risk of errors occurring in a production environment. These results generated from the testing efforts are critical to the efforts for testing software and exposes multiple system exceptions. Informative feedback in testing is necessary, as it provides information as to where the error is located in the code, so a developer may go in, fix the selected issue, and run the test again.

IHE Connectathon

An organization's approach to implementing a system for the exchange of Health Information adhering to an exchange standard and specification often results in completing easier components of a system first, and implementing the more complex components at a later date. Testing against another gateway implementation does not occur until later stages in the program lifecycle. IHE seeks to mitigate the risk of non-interoperable solutions by hosting a Connectathon in both the U.S. and Europe. These conferences provide a way for developers and companies to bring their gateway implementations and test to ensure they can exchange with one another. Demonstrating a gateway an organization brings to the Connectathon can interoperate with other gateways present, grants the organization visibility and permission to participate in the HIMSS Interoperability Showcase which occurs at the annual HIMSS conference. Please visit the IHE website to learn more about Connectathon and how your organization can participate.

The Importance of Partner-to-Partner Testing

Iterative steps are taken to properly test an organization's implementation for an EHR or EMR adapter and gateway technology. Testing to ensure conformance to the specifications and testing to ensure interoperability with other information trading partners occurs throughout the development lifecycle. The DIL provides the opportunity to perform both conformance and interoperability testing in a near isolated environment, allowing an organization to test partner integration testing in all steps of the development lifecycle. While technology can be confirmed working between an organization and the DIL, true interoperability can only be assured by completing or conducting partner-to-partner testing. The development methodology pertaining to the DIL encourages the continued use of partner-to-partner testing to ensure interoperability among multiple trading partners. The DIL team recommends partner-to-partner or peer-to-peer testing to be included in the testing lifecycle.

Standards and Message Structure

Many of the test cases test scenarios or documented test approaches are used to validate and demonstrate health interoperability at a transport layer. Many of the IHE specifications and Standards Development Organizations (SDOs) specifications and standards, such as HITSP and OASIS, support the transfer of health information. Additional testing capabilities relating to many elements of the standards, such as the type of message passed and the internal workings and structure of the message are critical elements to ensure a gateway is able to exchange health information in a standardized manner. The DIL utilizes a conformance lab which allows you to test conformance to the specifications.