Testing the way healthcare communicates

Michael Brown, PMP
Senior Consultant
AEGIS.net, Inc.

The evolution of communication has led to widespread sharing of ideas, knowledge, and information through various types of media (spoken language, written alphabet, printing press, telephone, and internet) that facilitate interaction among different people or organizations. Sharing information creates a well-informed community, effectively spreads knowledge and ideas, and propagates understanding of our environment.

The primary element of communication is sharing an idea or fact in a timely fashion to facilitate ‘Meaningful Use’ of the information. For example, sharing information in a timely manner to execute a stock trade, or treating a patient, transferred from one healthcare provider to another, in need of emergency surgery. In the latter example, information will need to be transferred and understood between two healthcare organizations, requiring both to be able to share patient’s medical history or interoperate, in a timely manner over a network. Effectively sharing this information directly impacts the quality of care provided and affects the outcome of the medical episode (i.e. the emergency surgery).

Interoperability between systems is achieved when multiple electronic health record (EHR) systems are linked using application program interfaces (APIs) and web services. Secure exchange of health information requires large amounts of resources for developing, testing and verifying the process.

Testing and implementing interoperability between EHRs provides its own challenges, especially when testing against another system as it entails development hours spent on meetings and executing web service calls between vendors. Testing interoperability in a simulated environment, where vendors can validate their systems’ interoperability with other, is advantageous.

Types of Interoperability
In order to determine how to test a system, a tester must understand how a system is initially implemented within a production environment. Owing to the continued development and innovations within the EHR market, a healthcare organization can implement EHRs from multiple vendors. There are well over 400 ‘Meaningful Use’ certified EHR vendors, several of which are open source, which providers have used to attest to the standards. With EHR vendors using their own proprietary software to record health information over the course of a patient’s life, many EHRs were not designed to share information easily. Subsequently, EHRs needed reconfiguration to share patient data accurately with other systems across a network.

Sharing information across a network means that information is readable by both, sending and receiving nodes. If the information is not converted from a proprietary EHR system message into a standardized format, the receiving node will not be able to understand the sent message. The ability to exchange messages at the network layer is named ‘technical interoperability’, and is a low-level method of establishing connection with another node.1 It is very similar to one person calling another using a telephone and establishing a connection. Technical interoperability forms the basis for other types of interoperability. As illustrated in Figure 1, technical interoperability is established between two Health systems, A and B, when they can connect with one another.

Figure 1: Technical interoperability

While technical interoperability provides a method for two or more systems to establish a connection, ‘semantic interoperability’ enables both the sender and receiver to understand the data sent.1 Semantic interoperability provides the means for two systems to communicate and acknowledge the information shared within the message by using codes, identifiers, and various document standards.

A structured message is utilized within semantic interoperability with an implemented Health Level Seven International (HL7 V3) messaging and modeling standard. Terminology, such as Systematized Nomenclature of Medicine-Clinical Terms (SNOMED-CT), a medical vocabulary defining various medical terms, is also used to improve communication among multiple health systems. 2 As illustrated in Figure 2, in semantic interoperability the information (letter ‘A’) sent from Health System A appears as is on Health System B. In the telephone metaphor, semantic interoperability means that the person on either end of a phone line can communicate and understand each other.

Figure 2: Semantic interoperability

An EHR system will need architectural modifications to communicate with another system over a network. Both technical and semantic interoperability needs to be established in order to exchange information between multiple healthcare systems within a production environment. Medical data is shared between different organizations over a Health Information Exchange (HIE) using a common set of standards and specifications.

High Level Interoperability Architecture
Proprietary messages contained in the EHRs are converted into a standardized format that is readable by any EHR system within APIs and sent outside the network using web service standards. Adapters and gateways are used to accomplish the goal of sending and receiving messages, respectively, into their system.3 In the context of a telephone call, if two users are speaking to one another in different languages, a verbal translator on either side translates the language into an understandable format. In Figure 3, an EHR vendor directly connects to an adapter, and the adapter to the gateway.

Enabling this transfer of messages are various web services, or methods of communication among multiple applications over the internet. The requirements for these web services are provided through technical specifications such as those provided by Integrating the Healthcare Enterprise (IHE) and the Nationwide Health Information Network (NwHIN) 4. These organizations use existing standards to build methods for gateways and subsequently for multiple organizations with different health system implementations to communicate securely and efficiently over a network. Various types of web services, such as Patient Discovery, Query for Documents, and Retrieve Documents, are utilized by a system to exchange information. Patient Discovery refers to one system requesting and receiving patient information from another system. A Query for Documents service allows a system to enquire and procure patient documents from another system. Retrieve Document provides a method for retrieving patient documents, such as summary of care record or radiology report, from another system.

An EHR specific message is transformed into a standard based message using an adapter. Using Extensible Markup Language (XML), a universal text-based format utilized for exchanging information, for structuring the messages, the translated information that is present within the adapter is sent out in a standard format using Simple Object Access Protocol (SOAP), an XML- based protocol meant for exchanging data in a distributed and decentralized environment. The SOAP message invokes a specific web service and is transported from one valid gateway to another, present on a different node. Once received, adapter picks and processes the message. The message can be in either the form of a request or a response. The SOAP message transferred between the endpoints may contain security headers for ensuring that it is understood by only a specific endpoint. Various types of web services can only be exchanged if their endpoints are validated within a Universal Description Discovery and Integration (UDDI) registry.

The gateways contain endpoints which are used to send various types of web service calls. This type of architecture is usually found within a bi-directional health information exchange (BHIE). There are other architectures also. For example, a messaging architecture known as Direct utilizes secure e-mail to transfer healthcare information between providers. However, the relatively simpler architecture of Direct does not have many important capabilities contained in a BHIE.

Figure 3: High level Bi-directional health information exchange

Figure 3 illustrates a technical specification being carried out over a web service endpoint. Health system A can potentially use a web service to query about patient demographics from health system B. Health system B will provide details of patients who match the query parameters. A Patient Discovery web service may utilize multiple components, such as a master patient index (MPI) to query for a specific patient using defined parameters. The use of multiple components further leads to fragility of these systems.

Testing Interoperability
Validation testing of healthcare systems ensures both interoperability and conformance to the technical specifications as conformance does not guarantee interoperability and vice-versa. Hence, both the elements must be tested prior to a product release. Many of these tests are performed manually by facilitating meetings; wherein developers test their systems against each other. Although this type of manual, peer-to-peer testing is effective, it is usually conducted only at the tail end of a development cycle, providing a short time frame for developers and testers to identify and repair bugs within the system prior to production. This also makes two different development teams, most likely from different organizations, to depend on each other, and leaving timelines and access to resources outside of either one’s full control.

Testers and developers have to test against multiple services, such as Patient Discovery, and use synthetic patient data simulating real patient information to test their systems against multiple variances of simulated gateways/nodes which may be a potential health information exchange partner. This equates to a healthcare provider facilitating multiple meetings with different organizations which proves to be very time consuming and costly. Consequently, this type of testing, although effective, cannot effectively be performed repeatedly throughout the development of a product.

In order to effectively decrease development costs and infuse quality throughout the development cycle, testing must occur frequently within a simulated production environment where multiple vendors can validate their systems’ interoperability with other hosted production environments. This holds good even while upgrading a system, as upgrading a component within a healthcare system may directly impact interoperability among multiple healthcare systems. Figure 4 demonstrates how upgrading a patient database may impact various other components and create interoperability challenges. A break in the connection between the patient database and the health system (possibly due to a server upgrade) has severely impacted the usability of the system and it can no longer exchange requested patient information with other vendors.

Figure 4: Broken interoperability

Effective testing of interoperability implies testing exchange of messages against simulated systems. Multiple systems should function on various Reference Implementations and provide methods to view both, the request and response SOAP message structures. Validation of various SOAP elements must also occur, to ensure proper values were sent and received. Currently, there are certain open source products in the market which provide simulated production environment to test interoperability at both the technical and semantic level, and offer methods to validate the SOAP message.

Ensuring quality within a healthcare system and providing a workable system that interoperate throughout the development lifecycle is a goal for many organizations providing care to multitudes of patients. Testing ensures interoperability prior to production and consequently increases the quality of care and supports organizations in meeting ‘Meaningful Use’ standards.

Interoperability and Quality of Care

‘Meaningful Use’ Stage 2 criteria emphasize the importance of interoperability among multiple healthcare organizations. Interoperability within ‘Meaningful Use’ provides a means to prevent fraud, waste, and abuse (FW&A) as health data can be easily linked to an EHR and exchanged between a payer and provider. In addition to preventing FW&A, testing and ensuring interoperability among multiple healthcare organizations directly improves the quality of care and supports a patient-centric model of healthcare. 3

With patients consulting several providers, interoperability can aid in tracking the care provided to patients throughout the course of their life by creating a longitudinal health record. Obtaining this type of record allows a healthcare professional to view a patient’s record, understand the summary of patient’s medical history, and determine the best possible method of treatment for a patient, improving quality of care. However, this type of data gathering and analysis is only possible if healthcare organizations can share and provide the necessary information.

Conclusion
Interoperability is a fragile yet necessary component of the modern healthcare system. Patients rely on interoperable systems to collect and receive benefits and payouts. It also allows payers and providers access to patient records to improve efficiencies and overall quality of healthcare as well as meet ‘Meaningful Use’ criteria and beyond. Thus it is important that interoperability is tested repeatedly throughout the development process in order to find and repair bugs prior to a product release. Frequent use of open source testing tools ensures a high level of interoperability between the systems.

References

01. Benson T. Principles of Health Interoperability HL7 and SNOMED. London, England: Springer-Verlag London Limited; 2010.
02. Ryan A, Eklund P. A Framework for Semantic Interoperability in Healthcare: A Service Oriented Architecture based on Health Informatics Standards. Stud Health Technol Inform. 2008;136:759-64.
03. Brown M. Facilitating the Secure Exchange of Health Information. AEGIS.net, Inc.
http://aegis.net/documents/Facilitating_the_Secure_Exchange_of_Health_Information.pdf. Published August 6, 2010. Accessed December 18, 2012.
04. Shah SN. An overview of NHIN and NHIN Direct for software developers. DeveloperWorks.
http://www.ibm.com/developerworks/web/library/wa-nhindirect/index.html?ca=drs-. Published July 27, 2010. Accessed December 17, 2012.

Comments are closed.

mhealth + Telehealth World 2013

mhealth + Telehealth World 2013

Categories

Archives