Approaches for Immunization Information System (IIS) Project Collaboration with HIE Networks

Noam H. Arzt, Ph.D.We have written in a previous policy white paper about collaboration between Immunization Information System (IIS) projects and Health Information Exchange (HIE) networks, and a second more technical white paper about options for interoperability between IIS and electronic health record (EHR) systems. We described a range of interoperability options for EHR users and IIS and the strengths and challenges of each alternative (see figure below).

The most common approach used by IIS is understandably the least sophisticated: EHR systems establish point-to-point interfaces with an IIS for the purpose of sending immunizations to the IIS or querying the IIS for immunization histories and forecasts. These transactions are stipulated in the Meaningful Use regulations.

An HIE plays no part in this type of interoperability, though a vendor “hub” might be used to enable the communications. Because the IIS community has selected SOAP-based Web Services as the standard for communications between EHRs and IIS these point-to-point communications are well supported. IIS retain the most control over this type of interface, though with increased control comes increased responsibility: both the IIS and clinical site need to ensure that the interface is properly configured and operating at all times. When the number of sites increases, the effort to ensure smooth communications also increases at least proportionately.

The next type of approach – a pass-through approach – allows HIEs to facilitate the transport of messages from EHRs to and from IIS but without any examination or modification of the messages themselves. This approach offers an interesting paradox: on the one hand, the IIS experiences a simplified set of interfaces to configure and maintain. Only a single interface needs to be put in place to the HIE to enable messages from all sites connected to that HIE to be supported.

Some states have mandated this type of connectivity to reduce the number of interfaces coming into State government, often creating a single state “hub” for all communications. However, when it comes time to manage a failing or unreliable connection, it can sometimes be more difficult to troubleshoot an interface which has an HIE sitting in its path. The IIS can only trace its communications back to the HIE, not all the way to the source site, and is dependent on the HIE to troubleshoot further. In most states that have implemented this type of communications it seems that the benefits have largely outweighed the challenges.

The intermediated approach has the most HIE involvement. In this approach, the HIE itself is the entity actually interfacing with the IIS, not the source EHR system. The clinical site sends and receives data to/from the HIE, which in turn sends and receives data on behalf of the clinical site. The purpose of this type of intermediation is to add value or services to the transaction. This can take several forms, including (but not limited to):

This type of approach can offer clinical users much-needed assistance in both creating and using standards-compliant data, but it can introduce even more challenges for an IIS as it can become even harder to trace the original of a communications- or data-related problem. If the HIE takes increasing levels of responsibility for services related to data coming to/from an IIS it must also provide increasing levels of support to both its clinical members and its public health partners. It is also important to ensure for the clinical organizations’ sake that services provided by HIEs do not interfere with the requirements of the CMS EHR Incentive Programs; for instance, an HIE that formats and sends immunization messages to an IIS for the purpose of fulfilling Meaningful Use must itself use certified EHR technology or the transactions do not qualify for that provider or organization.

Where do we go from here?

As we observed in the technical white paper, IIS and HIE projects need to work together to determine which option is best. In large part, choices will depend on how stakeholders wish for the HIE to be involved in IIS data exchange – both short‐term and long‐term. Projects should consider HIE intermediation within the context of overall long‐term HIE/public health data exchange strategy. And the core advice we offered both IIS and HIE projects in the earlier policy white paper still stands:

• Communicate whether you collaborate or not. Whether projects decide to collaborate or not, they need to have open, honest, ongoing channels of communication.
• Know when to compromise, and when to stick to your guns. Both IIS and HIE have primary, somewhat overlapping missions, but they do approach healthcare from different perspectives, with different drivers, and different constraints.
• Leverage where it’s sensible. Though IIS and HIEs have evolved quite differently, they share some common objectives and often have differing capabilities, in today’s environment of resource constraint organizations cannot afford needless redundancy.
• Strive for coherence from the customer’s point of view. IIS and HIE projects should craft service portfolios that are complimentary and coherent from the customer’s point of view.
• Be civil and respectful. You never know when today’s competitor will be tomorrow’s collaborator.