The Immunization Destination
The 1990s immunization registry architecture that was in place when COVID-19 hit attempts to use a single system to perform a myriad of functions: data entry, electronic interfaces, decision support, and in some cases, even reporting. When COVID-19 hit, some immunization registries had difficulty keeping up with the suddenly increasingly load. The Immunization Destination, or IZD, was initially designed as an “edge server” to respond to provider queries for patient immunization records without impacting the data entry system. It evolved into something more: an extraction of the three core functions of immunization registry architecture into an entirely separate system:
- Data exchange
- Record matching
- Decision support
The IZD inherits the technical advantages of Matchmerge Immunization Registry (MIR) and of Matchmerge Decision Support v11 (MDS v11). It therefore is able to provide much higher data quality and better decision support than traditional immunization registries provide. The IZD was designed to be retrofitted onto existing immunization registry infrastructure to provide one central place for provider vaccine record reporting and querying. An interface between the IZD and Wisconsin Immunization Registry (WIR) software has been built. Thus, the IZD can be retrofitted to existing nationwide immunization registry infrastructure to unify the various regional systems while still providing a unified, national or even worldwide central system.
| Standalone Immunization Registries | The Immunization Destination |
|---|---|
| When an Electronic Health Record (EHR) submits an update to an existing records, WIR uses a demographic match in selecting the record to update. | Implements the industry convention of using a unique patient identifier in applying updates. |
| No automated "delete" operation | Implements "deletes". |
| Implements limited Health Level Seven (HL7) Admit, Discharge and Transfer (ADT) messages. | Implements a full complement of ADT operations including add, update, delete, link, unlink and merge. |
| Does not include a Master Person Index (MPI) | Includes and MPI. |
| Does not implement MPI transactions supported by Integrating the Healthcare Enterprise (IHE) MPI profiles. | Implements the full complement of IHE profiles including Patient Identifier Cross-Referencing for MPI (PIX). |
| Does not support document-based technologies commonly used by Health Information Exchanges (HIEs) | Implements Cross-Enterprise Document Sharing (XDS) as supported by IHE. |
| System design inherited from the 1990s implements data entry and electronic interfaces in the same system, causing contention for compute resources. | Lean, mean data model focussing on core functions of data exchange, record matching and decision support. Anything not necessary to support these is excluded from the system architecture. |
| No mechanism to implement individual opt in or opt out. There is no way to exclude records when providers use the system to provide patient care. | Clean, MPI design and separation of concerns supports multiple patient privacy options. Enables records to be loaded for emergencies, then deleted when no longer necessary, or to be loaded but not linked, preventing sharing. |
