Immunization information systems (IIS), or registries, help providers and families by consolidating immunization information into one reliable source. They also save money by ensuring that children get only the vaccines they need and improve office efficiency by reducing the time needed to gather and review immunization records. Public health agencies use IIS to conduct surveillance, maintain high immunization coverage rates for the population, and for outbreak management and emergency response.

IIS exist in almost every US state and territory. Most IIS are state-wide, but in some states IIS are regional or local. While they began as a repository for childhood immunizations, IIS initial focus on pre-school children has expanded (within the applicable state/local law) to encompass lifelong immunization and/or emergency preparedness and response as IIS have begun to focus more on data integration across programs. In some states, participation by healthcare providers in IIS is mandated by law; in other states participation is purely voluntary. IIS often support bi-directional data exchange which can enable capabilities that local systems may not have.

Why exchange data with an IIS?

There are a number of good reasons why exchanging data electronically between an IIS and other systems (especially an EHR-S) is desirable:

  1. Create a complete immunization record: Probably the most compelling reason to exchange information with an IIS is to establish as complete an immunization record for a patient as possible. This reduces over- and under-immunization in the clinical setting (when data is retrieved from an IIS), and allows for population-based surveillance at the public health agency (when data is sent to an IIS).
  2. Reduce the burden of on-line data entry: As more and more immunization-reporting organizations (practices, hospitals, and clinics) deploy electronic health record systems (EHR-S), more and more immunization data will already exist in electronic form even before it is ready to be sent to an IIS. Yet in many jurisdictions, users are forced to key-enter immunization data twice (or more): once in a local system, and then again in the IIS. This duplicative activity can be eliminated through proper implementation of electronic data exchange. As another strategy, some IIS encourage providers to enter data directly into the IIS web application and then data is sent back to the EHR-S via automated data transfer.
  3. Enable special functions only found in an IIS: Most IIS contain special functions not found in a typical EHR-S. For example, IIS contains sophisticated algorithms for determining when immunizations are due or overdue for a patient. They also support reminder and recall functions that allow outreach to patients to encourage them to receive a needed immunization. Through data exchange these needed functions can be supported when an EHR-S might not normally be capable of performing them appropriately.
  4. Pressure from some users to only use institutional applications: Clinical practice is complicated, and supporting clinical applications within an organization is equally complicated. As the abundance of computer applications can proliferate over time, many organizations (especially larger organizations) attempt to reign in the cost of supporting a multitude of applications by streamlining the number and type of applications that are available to users. Often, external applications – like an IIS – are perceived of as being more difficult to support and as being distracting for users. IIS typically look different, behave differently, and require different usernames and passwords than institutional systems. For this reason, an increasing number of institutions are discouraging their users from logging in to IIS while at the same time looking for alternative ways to provide the data and special features that IIS offers within their local systems. Electronic data exchange represents one key strategy in fulfilling the data needs of this growing set of organizations.
  5. It’s one of the Minimum Functional Standards for IIS: Exchange of immunization records via the HL7 protocol is a Minimum Functional Standard for IIS as defined by the Centers for Disease Control and Prevention (CDC) and approved by the National Vaccine Advisory Committee (NVAC). Though there is no certification process as of yet for IIS, many projects are funded through by the CDC under Section 317 of the Public Health Service Act. Compliance with CDC minimum functional standards is certainly strongly advised, if not required, to receive these public funds.

Meaningful Use

For both the Mod Period and Stage 3 Meaningful Use, there is now one public health reporting objective with multiple measures, including immunization registry reporting. With this in place, participants will no longer be required to submit data to an IIS as they were in Stage 2 (subject to exclusions) since they can select other measures. This may be partially mitigated by the limited other selections available, especially for EPs (many of whom, for instance, do not practice in states where syndromic surveillance is conducted at ambulatory settings).

The Medicare and Medicaid Programs Electronic Health Record Incentive Program Final Rule for Stage 3 (October, 2015), contains the following objective and measure relative to IIS:

EP/EH/CAH Objective: The EP, eligible hospital or CAH is in active engagement with a public health agency to submit electronic public health data from CEHRT except where prohibited and in accordance with applicable law and practice.
EP/EH/CAH Measure: The EP, eligible hospital, or CAH is in active engagement with a public health agency to submit immunization data.

Though the Final Rule recognizes that the infrastructure to support HIEs is still developing, there is an expectation that, as the program proceeds, expectations for submission of immunization information to public health agencies via HIE will increase. This objective is only relevant to EP/hospitals who administer one or more immunization during the reporting period. It is also worth noting that immunization administration and status is a component of the quality measures required for reporting through the program.

Retrieval of immunization from an IIS to an EHR-S via standards-based query/response is not included during the Mod Period but is required during Stage 3 in 2018. While an EHR must be able to display a forecast retrieved from an IIS, it can implement additional work flow or features to “layer” additional functionality or information on that forecast. An IIS will need to support both data submission and query/response in order to declare itself ready to support Meaningful Use in Stage 3. An agency has to declare its readiness to support a public health measure at least 6 months before the start of a reporting period (January 1 of the reporting year) in order to avoid participants being able to claim an exclusion. The agency does not actually need to be ready six months before, just to declare its intention to be ready when the reporting period begins. If an EP/EH/CAH does not administer immunizations but supports IIS query as part of its clinical practice this activity does qualify for MU.

For MACRA participants, under the proposed CY 2018 Updatesif reporting to an IIS is not possible, other public health measures may be used instead (p. 173). In addition, it is proposed that participants can continue to use older, 2014 CEHRT into 2018 which means that some sites may continue to only support data submission and not query response.

Most states support these capacities within their IIS. CMS has stated that, “An immunization registry may have the capacity to accept immunization data from another EP or hospital, but if for any reason (e.g. waiting list, on-boarding process, other requirements, etc) the registry cannot test with a specific EP or hospital, that EP or hospital can exclude the objective. It is the responsibility of the EP or hospital to document the justification for their exclusion (including making clear that the immunization registry in question is the only one it can submit information to). If the immunization registry, due to State law or policy, would not accept immunization data from you (e.g., not a lifespan registry, etc), you can also claim the exclusion for this objective.” [see FAQ]

Technical Standards

The ONC 2014 Edition Health Information Technology (Health IT) Certification Criteria (September, 2014) identified the following standards for immunization data exchange for Stage 2 which continue to apply for the Mod Period (2015-2017):

§ 170.205 Content exchange standards and implementation specifications for exchanging electronic health information
(e)(3):Standard. HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.4, (incorporated by reference in § 170.299).

For terminology, the Final Rules references the July 2012 version of the CVX code listing incorporated into the HL7 v2.5.1 Implementation Guide v1.4.

For Stage 3 (in 2018, and also if begun early in 2017), the ONC 2015 Edition Health Information Technology (Health IT) Certification Criteria (October, 2015) identified the following standards for immunization data exchange

§ 170.205 Content exchange standards and implementation specifications for exchanging electronic health information
(e)(4):Standard. HL7 2.5.1 (incorporated by reference in § 170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 (incorporated by reference in § 170.299), and HL7 Version 2.5.1 Implementation Guide for Immunization Messaging (Release 1.5)—Addendum, July 2015 (incorporated by reference in § 170.299).

For terminology, the Final Rules references the August 17, 2015 version of the CVX code listing for historical doses administered, and introduces National Drug Code Directory (NDC)—Vaccine NDC Linker, updates through August 17, 2015 for new doses administered.

Testing Procedures

The National Institute of Standards and Technology (NIST) has provided a guidance document and testing tools (see right panel) for ensuring that certified EHR systems can properly record, modify, retrieve, and submit immunization data to an IIS. While submission of test data to NIST by an EHR vendor is automated, evaluation of response messages (i.e., ACK or RSP messages) is done manually by the tester. In addition, vendors are being advised that all immunization history and forecast received in response to a query must be displayed within the EHR. While the test patient can have demographic data stored, the test patient should not have any immunizations stored in the EHR before the simulated query. As discussed above, additional functional can be “layered” on this basic work flow.

Some states are deploying test services that are independent of production IIS services. This is being done for several reasons, including a desire to ensure that test data and production data are not mixed, and also because some IIS do not have the capacity to move successful test sites into production due to either technical or staffing limitations. In this case, states are encouraged to “queue” sites that have tested successfully and move them into production as resources permit.

IIS are not obligated to provide any specific type of documentation of successful (or unsuccessful) meaningful use testing, Many IIS are using server logs to document EP/EH testing if requested, and others are providing automated e-mail messages or letters to document testing success (or failure).