The Story of State Immunization Registries

(Standards and Data Registries Done Right)

By Lisa Erickson

Have the sending  or receiving of COVID-19 immunization data at the top of your mind? J P Systems works to connect organizations using standardized HL7 messaging for vaccine reporting purposes. We thought the story of the birth of the first immunization registry would be a timely topic.

This is the story of the birth of the State Immunization Registries.

Tom Maerz was the Manager of the Wisconsin State Immunization Registry (WIR). As early as 1998, he envisioned a web-based State Immunization Registry to track all K–12 childhood immunizations. This concept was two decades ahead of its time. The design/code for the majority of State Immunization Registries today was his brain-child. Twenty-two years is a lifetime in IT.

First let’s think back to 1998:

• The iPhone didn’t exist (first release was 2007)
• We had graduated from 5-1/4” floppy disks to 3.5″ floppy disks (no CDs, let alone writable CDs)
• We were running Windows 98 on our PCs (no laptops existed)
• Apple was on the verge of bankruptcy and Amazon was four years old
• Internet access was dial-up (56K was a fast connection) 

Tom had a passion for data — clean data. Moreover, by the time I was hired in December 2000, he had a State Immunization Registry up and running. He was using ORACLE and PL/SQL packages with some HTML pages for end user browser access to the State Registry. I was hired (EDS vendor for WIR) to create the first HL7 2.3.1 Immunization Messaging engine (parsers/writers). My task was to process batch files of HL7 2.3.1 Immunization Update/Query and Response messages. Tom Maerz is the reason that State Immunization Registries are considered a “Trusted Data Source”.

Tom insisted on standards-based messaging. I joined the HL7 Immunization Messaging work group (CDC’s AIRA) around 2001. Then, I printed out the HL7 2.3.1 Specification which ended up being 7 inches thick as a hardcopy. I still have it somewhere. I designed, and coded in Java (Java 2.0) an HL7 2.3.1 Immunization Message engine. The only commercially available HL7 Message interpreter was Chameleon, and it was subpar.

Working with Rob Savage (an Epidemiologist), we created the first HL7 Immunization Implementation Guide that we gave to AIRA. I’m proud to say that it is still the basis of  AIRA’s  HL7 2.x Immunization Implementation Guides.

The key was the data quality continuous enforcement process.

We provided the WIR Immunization Implementation Guide to providers eager to onboard. This enabled them to obtain their HITECH ACT Meaningful Use checks and comply with the HITECH ACT. The HL7 engines would parse and validate the incoming messages. Then it generated transaction objects containing the data and subsequently generated the HL7 2.3.1 Response Messages.

There were two passes to the parsing process:  

      1) Validate the incoming HL7 2.3.1 Message against the SHALL requirements of the WIR
          Implementation Guide 

      2) Validate the semantics and terminologies for the individual message segments. Some examples include the CPT Codes, CVX Codes, LOINC for Observations, and CVX code matches Trade Name.

If the message sent by the provider failed either of the two validation passes, we rejected the message. Our response provided the HL7 2.5.1 MSA Response Message describing the error. The provider could NOT advance from our Test environment to our Production environment until their messages were “golden.” This data cleanup effort took the providers an average of three months. Once moved to production, the same HL7 data validation engine would continuously run against every message sent in to WIR. We would catch and reject the messages of a provider in Production if the quality of their messages had degraded. For example, it would catch if a provider upgraded their version of EPIC, resulting in their messages being rejected. EHR upgrades are a notorious cause of problems due to missing required fields, misplaced or miscoded data. They had to fix their issue before their data made it through the WIR Production door again.

Thirty-six of the sixty-four State Immunization Registries (some states have multiple IIS’s) have WIR as their base code set. When participating in VA/Cerner State Immunization Registry Work Group meetings with State IIS’s, I sense the shock of VA participants. They are surprised to learn that State IIS onboard testing takes an average of three months. Plus every State IIS produces its own Implementation Guide based upon the AIRA (CDC) Implementation Guide.

Need to send or receive COVID-19 immunization data electronically?  

J P Systems can help.  Contact us at 1 703 815-0900 or email us at Sales@JPSys.com.  We currently support large scale Federal efforts for reporting vaccines to the CDC.