The Story of State Immunization Registries

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). In 1998, he envisioned a State Immunization registry that would be accessible from the World Wide Web (then only seven years old) for all immunizations administered to children K-12. 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. By the time I was hired in December 2000, he had a State Immunization Registry up and running using ORACLE for the data store and PL/SQL packages with some early HTML web pages for end-user browser access to the State Registry. I, Lisa Erickson, was hired (EDS vendor for WIR) to create the first HL7 2.3.1 Immunization Messaging engine (parsers/writers) for processing 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. I printed out the HL7 2.3.1 Specification which ended up being 7 inches thick as a hard-copy (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, (to obtain their HITECH ACT Meaningful Use checks) and comply with the HITECH ACT. The HL7 engines would parse/validate the incoming messages (generating transaction objects containing the data) and generate the HL7 2.3.1 Response Messages. There were two passes:  

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

      2) Validate the semantics/terminologies for the individual message segments, (e.g., CPT
          Codes, CVX Codes, LOINC for Observations, CVX code matches Trade Name, etc.).

If the message sent by the provider failed either of the two validation passes, we rejected the message, providing 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”, which took an average of three months. Once moved to Production, the same HL7 data validation engine would continuously run against every single message sent in to WIR. We would catch and reject the messages of a provider who had made it to Production if the quality of their messages had degraded. For example, a provider upgraded their version of EPIC, resulting in their messages being rejected because they eliminated a required field in their message, or coded it incorrectly. They had to fix their issue before their data made it through to the WIR Production door again.

Thirty-six of the sixty-four State Immunization Registries (some states have multiple IIS’) have WIR as their base code set. When I am participating in the VA/Cerner State Immunization Registry Work Group meetings with a State IIS, I can almost see the shocked faces of the VA participants upon learning that State IIS onboard testing takes an average of three months, and every State IIS produces its own Implementation Guide based upon the AIRA (CDC) Implementation Guide –  sixty-four unique, Implementation Guides. 

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 [email protected].  We currently support large scale Federal efforts for reporting vaccines to the CDC.