GSI Health - Litmus Paper: Interoperability

Many vendors have rushed health information exchange (HIE) solutions into the market, or have built “interfaces” or “interoperability standards” into their products, seemingly all doing the same essential thing: enabling data to move between enterprises and between systems. The methods these solutions utilize, however, are widely divergent. For example, some HIE architectures require that a single solution be distributed at every location in the network (e.g. edge servers), while others centralize network functionality, and require custom means to connect to the HIE middleware. Choosing a healthcare IT system is, in some ways, buying into the philosophy of the product’s vendor, which may have unexpected policy implications. The market solutions vary in security architecture, data architecture, network topology, and other vital aspects that will work counter to the interoperability needed to enable many desirable point-of-care functions, like clinical decision support, quality reporting, clinical alerting, etc. Given this variety, it is no surprise that many systems that boast “plug-n-play interoperability,” or the ability to “transmit a CCD or CCR,” or other similar claims, can only do so in very specific ways that are likely incompatible with other vendor products. When evaluating a solution to enable interoperability among your healthcare applications, you need to consider several litmus indicators before concluding that you can achieve your interoperability goal with it. The following table lists some of these important considerations.

Litmus Indicator	Description
Custom Integration Support	Like it or not, plug and play interoperability is very rare today, and so any vendor with an interoperability solution should have a support organization ready to assist you in connecting it to other applications or systems in your environment.
Security Model	If two software systems don’t agree on the security model for interoperability, they won’t be able to connect, period. Some solutions rely on virtual private networks (VPN), while others require “message level” data protections such as public-key infrastructure (PKI) encryption, or some credential infrastructure such as Security Assertion Markup Language (SAML), and so forth.
Storage Model	Systems may vend data out of their internal database structure, export data into an external local database structure (e.g. a clinical-data repository or CDR), or push data to a remote repository. Different models have different implications on privacy policy, availability of data, and integration compatibility.
Asynchronous Transactions	Many real-world interactions are asynchronous, or do not have guarantees on when or how one system will respond to another. For example, electronically placing a lab order or sending a referral do not prescribe the exact timing of responses from the other end, and so the system must be able to handle the response whenever or however they come. Further, some interactions are one-way and unprompted, such as alerting, so understanding how a solution handles these cases is important..
Transactional Rules	Systems must agree on the mechanics of a transaction for them to be compatible for interoperability. For example, who initiates the transaction? What are the steps involved? Is there a particular technical pattern being followed, such as the cross-enterprise document sharing (XDS) paradigm? These and other similar details are fundamental to interoperability.
Payload Standardization	The payload is the actual data involved in a transaction, and so to share data, agreement must be made among systems on the content, format, encoding, required elements, and other details.
Workflow Implications	Rising above the technical details, you may have specific expectations about how shared data is handled by the applications, and it is important to confirm these expectations with the solution vendor. What level of human interaction is needed to complete a transaction? Will shared data be incorporated into the local database of a system (e.g. become part of the electronic record), and if so, is it at the document level or at the detailed data element level? These and similar questions affect the impact of interoperability.

GSI Health Can Help You! GSI Health has extensive experience in testing healthcare IT systems, and focuses on data-driven testing for understandable and thorough test batteries. Our consultants can assist you in navigating the issues discussed in this paper, and provide the professional IV&V services you need to properly test your healthcare IT applications and architecture. Our testing methods account for adherence to national standards, and are extensible to accommodate local requirements. To learn more about how GSI Health can help make you successful in deploying a strong quality assurance program as a part of your healthcare IT project, please contact us by phone at 1-888-206-4237 or email HITvision@gsihealth.com.