HLN supports IIS implementations in New York City (Citywide Immunization Registry, or CIR) and Rhode Island (KIDSNET/RICAIR). To participate in electronic data exchange via the IZ Gateway, HLN determined that a software layer between the IIS’ existing HL7 services and the Gateway could meet IZ Gateway requirements with minimal disruption to the IIS’ existing infrastructure. Through a multi-jurisdictional joint development initiative, CIR and RICAIR implemented a new service as a shared service layer deployed to the IIS in a container-based architecture. In addition to interfacing with the IZ Gateway, this service provides HL7 message transformation, audit logging, and message routing and queuing. This service runs in Docker containers and requires no changes to the IIS itself.
As we began testing connections to other IIS, we wondered whether IIS-IIS HL7 data exchange might yield similar issues as noted with existing EHR to IIS reporting. Testing of IIS-IIS pairings has highlighted several variances in platform configuration, business rules and policies – some that were known to exist and some that were not. However, an added advantage to conducting IIS-IIS testing is that it provides a communal forum for candid discussion of these variances. Testing meetings with jurisdictions, their IIS vendors and technical support partners allow for a better understanding of the rationale for these variances, as well as an opportunity to align more closely with CDC’s national implementation guide standards.
While the progress of inter-jurisdictional electronic messaging is inspiring, it is equally beneficial to identify data issues that can be addressed and resolved to the benefit of the overall IIS community.
These resolutions help ensure high data quality within IIS and promote HL7 message standardization and conformance with the CDC’s National Implementation Guide version 2.5.1 Release 1.5.
I described some of these data issues below.
Confusion over patient address: In our experience, most IIS record a patient address at the time a dose was administered, or in the absence of new information, defer to the last address received from clinical care as the patient’s current address. This became especially significant under COVID as aggregate reporting and visualization on jurisdictional “dashboards” was closely watched by many sectors of society. As data begins to move from IIS to IIS it may become less clear exactly which address for a patient is the current address. It has long been established that just because an IIS receives a new address from a clinical care site it cannot be assumed that the address is the most recent; similarly an IIS should not assume that an address received from another IIS – especially if it is an out-of-state address – is the most recent address which might trigger the association of that patient’s record to another jurisdiction. One way to mitigate this potential confusion is to assume, in the absence of any other information, that the address associated with the most recent dose administered to the patient is the current address. Another option is for the jurisdiction to add the patient’s address as historical without changing their current address on record.
Data “loops”: IIS-to-IIS data exchange via the IZ Gateway is triggered by a new dose administered to a recipient with an out-of-state address on their patient record. Once that occurs, the entire immunization history is typically sent from one IIS to the other. It is very possible to get into a situation where one IIS sends its recorded doses to another, and the other one then determines that it needs to send its doses back to the first (or to a third IIS), which triggers the first to resend all its doses back to the second one. This can cause a perpetual data “loop.” One way to mitigate this is to review the date and time stamp on the message and look for variances between existing patient data and incoming data to determine whether the message is a duplicate and therefore avoid getting stuck in a data loop.
Data quality: IIS typically have sophisticated programs of data quality assurance and, in some cases, data cleanup and “correction” of doses received from outside sources. Though not confined to IIS-to-IIS data transmission, it is likely that messages received from another IIS and “cleaned” by the receiving IIS will be received again in their original form at some point in the future, causing the messages to be cleaned again or, in the worst case, stored in duplicate in the receiving IIS. This was evident in testing IIS-IIS pairings where an IIS would receive dose and unit values for an administered vaccine and convert them to a non-specific unit of measure. For example, doses administered in milliliters are sent to another IIS that converts the vaccine dosage unit to one dose. This can result in incorrect dosage information being received when querying that IIS for the patient’s vaccine history. An IIS’ storage of dosage units is now discussed prior to testing IIS-IIS pairings.
Unintended triggers: Another aspect of IIS data quality assurance is the routine review and update of data stored in the database. This is often done in bulk as a result of some data refinement, policy change, or system update. However, as IIS begin to implement triggers that automatically initiate sending data to another IIS, it is possible that bulk changes to an IIS could trigger large-scale message transmission to other IIS. These transmissions may or may not be intended by the sending IIS nor desired by the receiving IIS. To mitigate this, we conduct routine monitoring of messages exchanged between IIS for our clients. Unusual spikes in message volumes would alert the IIS technical teams for review.
Updates to existing patient records: Most IIS to IIS connectivity is focused on new vaccine doses administered, but there is the capability for a provider or an IIS to modify fields like lot number, vaccine manufacturer, body site (of an injection) and/or route. Some IIS may have restrictions on which HL7 elements can be updated, but do not return any kind of warning or error if a field is not updated. The concern is that an IIS might not be aware that another IIS is not accepting or processing its updated messages. The topic of ACK messages is also now discussed prior to testing IIS-IIS pairings.
As data continues to flow between IIS, data issues surface that require discussion and resolution across the community. IIS-IIS data exchange testing identifies variances in platform configuration, business rules and policies, but also provides a communal forum for candid discussion of these variances, as well as an opportunity to more closely align with national implementation guide standards.
