Requirements for Interoperability in Healthcare Information Systems

Abstract

Interoperability is a requirement for the successful deployment of Electronic Health Records (EHR). EHR improves the quality of healthcare by enabling access to all relevant information at the diagnostic decision moment, regardless of location. It is a system that results from the cooperation of several heterogeneous distributed subsystems that need to successfully exchange information relative to a specific healthcare process. This paper analyzes interoperability impediments in healthcare by first defining them and providing concrete healthcare examples, followed by discussion of how specifications can be defined and how verification can be conducted to eliminate those impediments and ensure interoperability in healthcare. This paper also analyzes how Integrating the Healthcare Enterprise (IHE) has been successful in enabling interoperability, and identifies some neglected aspects that need attention. RESULTSIn this section, we analyze the technical, semantic, functional, quality and logistical integration aspects. For each category, interoperability impediments are described and discussed; we give examples derived from the healthcare domain, and provide guidance to mitigate the impediment at the specification and testing levels. Technical Concerns Connection ImpedimentThis impediment occurs when there is a disagreement between components at the communication level, including the lower layer protocols (LLP). An obvious example is when peers are not using the same version of the standard, such as when one is using HL7 version 2.3 and the other is expecting HL7 version 2.5. Although newer versions of HL7 v2 are backward compatible, interfaces between systems may be necessary to remove new fields not supported by older versions. Likewise, using the DICOM standard, peers may not agree on the service-object pair (SOP) Class, i.e., the service (or action) to be executed on the information object. Another example occurs when one peer is using secure socket and the other does not support secure communication.In order to eliminate this impediment, requirements for the communication protocol, its version, and the underlying LLP must be specified. Moreover, when the communication protocol allows for multiple possibilities, one specific possibility must be specified. For example, when security is required, one needs to specify what kind of certificate is to use, whether encryption is required and what type of encryption algorithms is supported. The testing software issues transactions using the specified protocol and the specified LLP to verify whether the connection could be established with the system under test and information could be exchanged.IHE has succeeded in eliminating this impediment by specifying, for each transaction, the communication standard to be used, such as DICOM or HL7. Moreover, it specifies the version of the standard when multiple versions exist. For example, the Modality worklist query is achieved using the DICOM standard (Radiology [19]); the Patient Identification Query is achieved using HL7 v2....

Active Learning of the HL7 Medical Standard

“…Furthermore, the skills students acquired went beyond learning one or multiple standards: they learned how standards can cooperate to achieve an integrated workflow. Integration in medicine is still a big challenge [ 14 , 15 ], at the conceptual level and at the implementation one, as well. Becoming familiar with these challenges and with existing integration solutions is one of the most important skills students must acquire.…”

Testing of Electronic Healthcare Record images and reports viewer

“…Therefore the testing environment is essential not only in the development process of the viewer but also for testing, demonstration and training. Although IHE provides testing for specific integration profiles such as PDQ or XDS, the proposed environment complements IHE testing by allowing quality impediments to be tested [1]. By populating the environment with large image sets, the viewer can be tested for memory consumption, timeliness, reliability and availability.…”

“…By populating the environment with large image sets, the viewer can be tested for memory consumption, timeliness, reliability and availability. Moreover, by simulating faulty situations, such as the nonavailability of specific peers, the quality of service and the security impediments [1] can be assessed and accounted for. Moreover, during the lifecycle of the viewer, regression tests are conducted using all data deployed in the test environment.…”

The impact of net neutrality on digital health

“…More practices, varied care settings, and healthcare systems are utilizing electronic health records (EHRs) and digital health platforms to capture, store, and move data (3,4). In addition, in the United States, the broad dissemination of data to stakeholders is often a requirement of policy (5). Further, innovative and disruptive early stage companies are often leveraging functional aspects of mobile devices to create patient related data or content which must be transported over wireless and wireline networks (6).…”