Feature Overlaps Between Immunization Information Systems and EHRs

Immunization Information Systems (IIS) have been around for nearly twenty years. Their functionality, completeness, and usefulness have all increased over this time. IIS and electronic health record (EHR) systems have always had unique features, as well as some overlapping features, and the deployment of EHRs has enhanced the local immunization capabilities of clinician practices. Several critical clinical features that are considered to be core functions of IIS are beginning to be supported by EHRs. This article will review and discuss five such critical features: online data entry, clinical decision support for immunization, reminder-recall, practice-level assessment of up-to-date status, and patient access to their immunization data. The article offers insight into the likelihood and implications of their migration from IIS to EHRs, and offers recommendations to both the IIS and EHR communities for how to thoughtfully guide this migration.

Introduction

Noam H. Arzt, Ph.D. All states and US territories have an Immunization Information System (IIS), defined by the Centers for Disease Control and Prevention (CDC) as, “…confidential, population-based, computerized databases that record all immunization doses administered by participating providers to persons residing within a given geopolitical area.” IIS have been around for nearly twenty years. For providers, access to IIS has always been a key objective to support clinical care, develop quality measures, and provide coverage information required by public health agencies to perform their population-level monitoring and assurance functions. Providers traditionally accessed IIS directly through web-based clients, but increasingly providers access IIS data more indirectly through their local electronic health record (EHR) systems as the EHR Incentive Programs of the Centers for Medicare & Medicaid Services (CMS) have accelerated the deployment of EHR systems and promoted the development of a wide variety of features within EHRs.

Functionality, completeness, and usefulness of IIS have all increased over the years (See here). IIS have worked steadily to meet the requirements of CDC Functional Standards which were revised in 2013. The American Immunization Registry Association (AIRA), in conjunction with CDC, continues to provide needed support and a strong environment for collaboration among IIS projects. The commercial market for IIS products has consolidated over the years with three products dominating (two commercial off-the-shelf, one public health developed) and a smattering of other solutions (some commercial, some custom developed) rounding out the field. IIS projects have increasingly been willing to work together to achieve common goals, and a new “joint development” initiative was launched by AIRA in the Fall of 2013.

State and local governments continue to go through changes as well. Many jurisdictions have tried to reduce overall spending on information technology support by consolidating and centralizing IIS technical staff and operations either at the agency or even the State level. While this type of organizational change tends to go in cycles, the current swing pulls technical staff away from IIS program staff and often limits the technical resources available to support IIS projects. In the worst-case scenario, IIS projects can be marginalized within agencies as overall priorities shift the focus to other efforts and activities.

With shrinking resource bases, IIS continue to look for ways to sustain their projects. Many states do not support IIS with state funds but instead rely on Federal funding from the CDC either through the Immunization Grant Program (Section 317), Center for Medicare and Medicaid Services (CMS) 90/10 matching funds for Medicaid Health Information Technology (HIT) activities, and other grant programs with various Federal agencies. As state (and Federal) budgets continue to be uncertain due to the larger political situation, some IIS projects (like KIDSNET in Rhode Island) look to other related public health projects to enhance the usefulness of the IIS, including integration with childhood lead poisoning prevention programs, obesity management programs, various newborn screening programs, and others. In addition, states have taken on additional program management burdens such as the need to manage vaccine orders by participating in the Vaccine Management Business Improvement Project (VMBIP) and the deployment of the Vaccine Tracking System (VTrckS).

IIS and EHR Functionality

The features of the IIS have continued to change and develop. IIS developed originally as healthcare providers had limited access to clinical systems locally, and even more limited access to decision support applications. IIS and EHRs have always had unique features, as well as some overlapping features, and over time, the deployment of EHRs has enhanced the local immunization capabilities of clinician practices. As the penetration of EHRs continues, spurred by the CMS EHR Incentive Programs and other initiatives, and the capabilities of EHRs continue to develop, users at provider sites will increasingly be directed to use their local applications for most, if not all, clinical functions and activities, including immunization. IIS will continue, however, to play a critical role in consolidating immunization data and making that data available to providers – increasingly through EHR interfaces as opposed to native IIS applications.

Several critical clinical features that are considered to be core functions of IIS are beginning to migrate into EHR software, though they are not supported consistently by EHRs yet. Immunization functional requirements have been well documented (see here and here), and the Health Information and Management Systems Society (HIMSS) now has a voluntary Immunization Integration Program that allows EHRs to test their immunization functionality. This paper will review and discuss five such critical features and offer insight into the likelihood and implications of their migration from IIS to EHRs.

Online Data Entry

From their earliest days, IIS have support online data entry as a core feature. Over the years, products have migrated from terminal-based interfaces, to client/server interfaces, to the web-based interfaces that all IIS provide today. In earlier times data was collected by IIS through these interfaces, often supplemented by low-tech paper or barcode-enabled paper form submission (eventually eliminated by nearly all projects) and custom-developed text file submission (before standards-based HL7 message definitions were in wide use). More recently, the emphasis has shifted to data entry into local EHRs and data submission via HL7 messages to IIS directly from the EHR.

The CMS EHR Incentive Programs have provided a strong incentive for providers to submit data through their EHRs as each successive “stage” has increased the requirements for immunization data submission to IIS. While IIS user interfaces are usually optimized for immunization data entry, EHR user interfaces can sometimes fail to appreciate some of the nuances that support good data entry practices for immunization, including:

Yet despite these limitations, pressure (if not prohibition) will build to decrease the use of outside applications (like IIS) as organizations attempt to not only bring more coherence to their users’ computing environments but to minimize user support costs caused by confusion over internal and external application functionality. This may happen whether local EHRs are ready to provide needed immunization features or not. The CMS EHR Incentive Programs will also continue to be a strong motivator of the movement to data entry to an EHR user interface.

Clinical Decision Support (CDS) for Immunization

One of those important areas of functionality is clinical decision support (CDS). CDS has traditionally been used to support clinicians at the point of care. Extensive background material can be found in the CDC/ASTHO Public Health Community Platform Use Case for Clinical Decision Support for Immunization (CDSi), Version 2 (May 2014) and Clinical Decision Support for Immunizations (CDSi): A Comprehensive, Collaborative Strategy, Biomedical Informatics Insights, Suppl. 2, (October 2016).

Through a number of techniques, CDS systems bring medical knowledge to bear in the context of a specific patient’s medical history to assist in diagnosing or treating a patient’s condition. The CMS EHR Incentive Programs are focusing more attention on CDS. One of the core set of measures in both Stage 1 and Stage 2 Meaningful Use involve the implementation of CDS to support clinical quality. Stage 3 raised the bar even further and expects even more use of CDS. This added focus will potentially provide opportunities for IIS to become more involved in CDS as EHRs often do not reproduce or maintain immunization decision rules comprehensively.

CDS for Immunization involves the evaluation of a patient’s immunization history and the forecast of immunizations that may be due now or in the future. Most common CDS software in IIS today generate clinically accurate CDS for groups of vaccines that are routinely administered to children, adolescents, and adults in accordance with the Advisory Committee on Immunization Practices (ACIP) guidelines. CDS software includes evaluation of the validity of each immunization in a patient's history as well as a recommendation for each vaccine group (e.g., the date on which the next dose is due, series completed, etc.).

Although CDS capabilities are functionally adequate in most cases, they have some limitations. As rules, logic, and terminology change due to changes in the underlying schedule, testing procedures require an iterative series of manual steps that are performed by up to three different sets of individuals: the software developers who verify their modifications or additions, the business analysts working with the developers who verify the changes against the agency's specifications, and immunization program personnel who have deep experience with the immunization schedule and do the final acceptance testing to ensure that the changes have been made to their satisfaction. In addition, because of the inherent complexity of the subject matter as well as the complexity of the software implementation, regression testing must also be undertaken to ensure that a change to one rule does not "break" another. A second limitation of common CDS capabilities is that they often only support a single immunization schedule. This means that many IIS do not have the option of evaluating a record against a second immunization schedule, for example, to determine if students are up-to-date with just the specific immunizations that are required for admission to school.

In an effort to harmonize the outcomes of existing CDS tools used by IIS and other systems, CDC funded the Clinical Decision Support for Immunization (CDSi) project to develop new clinical decision aids for each vaccine on the children's immunization schedule to:

An expert panel was convened in 2011 to develop recommendations in three areas, including unambiguous logic specifications for the ACIP rules themselves, strategies and examples for testing algorithm behavior, and sustainability, communication, and training around the material developed by the panel. The panel initially produced consensus-driven descriptions of the rules for childhood vaccines and completed initial adult vaccine definitions in 2014.

While an EHR system is potentially able to generate its own CDS evaluation and forecast as well as receive evaluation and forecast information from one or more IIS, each evaluation and forecast is only as good as the immunization (and patient) history upon which it is based, and the rules/algorithms that are contained within it. The CDC CDSi Project has helped develop some consensus around immunization evaluation and forecast logic and rules, and its artifacts are mandated fairly regularly, though there continue to be many algorithm variations in use today.

EHRs could access CDS capabilities in a number of ways:

Natively within the EHR

Vendors [Note that throughout this paper “vendor” could also refer to a healthcare organization that develops its own EHR in-house.] could certainly provide CDS capabilities completely within the EHR product as “black box” functionality. This would require the EHR vendor to maintain the logic/rules and software for this functionality within their products. Users would seamlessly have access to the CDS features through the natural course of using the EHR product. The vendor could develop this functionality in-house or acquire it from another vendor or source. While this option leaves the vendor fully in control of the CDS functionality, it also leaves the vendor (at least partially) responsible for maintaining the logic and ensuring the features work effectively with the rest of the product. The vendor also needs to decide strategically if only one set of logic will be maintained for users in all jurisdictions (certainly a simpler choice), or if different logic will be developed and maintained for users in different jurisdictions (more difficult, but perhaps functionally more desirable by users). Given the many requirements on EHR vendors to develop and maintain ONC 2014/15 Certified Software (CEHRT) functionality, this may be a huge investment relative to competing priorities.

Natively within the EHR via a web service accessed by each EHR installation

Rather than embed CDS within the EHR product, the vendor could access the CDS rules as a web service on the Internet. This would allow the development and maintenance of the CDS logic to be done independent of the installation of the EHR itself but still fully controlled by the EHR vendor [Of course, for EHRs delivered as cloud-based or ASP services the vendors already enjoy control of their product installations without ever touching a client site.]. This modularization would also allow a vendor to more easily “swap” CDS modules should a better one come along, so long as the interface specifications from the core EHR product to the CDS service remain the same [As an example, eClinicalWorks provides HLN’s open source ICE CDS to its distributed ambulatory EHR users via a central service maintained by eClinicalWorks.]. It also may provide the EHR vendor with an independent source of expertise for maintaining and supporting the CDS logic itself if acquired from an external source. In addition, this inclusion of the CDS functionality in the base product may allow the EHR to support certain contraindications to immunization (such as an allergy or vaccine-to-drug interaction) without necessarily including them in the CDS algorithm itself. This more loosely-coupled approach allows more flexibility for the EHR vendor and potentially provides an opportunity for IIS to support this option (see below).

Via HL7 query/response with an IIS

Standards-based query/response via HL7 v2 messaging is a common feature supported by IIS and an increasingly common feature supported by EHRs. According to AIRA nearly 40 IIS have been able to participate in their Query and Response Assessment in Q1 2018. Many IIS return an evaluation and forecast as part of the response to a query. Assuming the immunization history in the EHR matched the immunization history in the IIS the evaluation and forecast from the IIS would be quite usable by the EHR which would need to format and present the information within the user interface of the product. [While it is possible for the EHR to display the evaluation and forecast by linking to the web-based client of the IIS we do not consider this true CDS functionality within the EHR. There are several advantages to this approach, including:

But there are also some distinct limitations, including:

The multiplicity of potentially conflicting information received from different IIS may only serve to confuse the clinician and may result in multiple, duplicative investments across the healthcare ecosystem. This challenge is both a technical and policy one which needs to be addressed as this solution develops.

As a web service provided by the IIS

An alternative to accessing the CDS features through HL7 query/response with an IIS is access to the IIS’ CDS logic through a web service maintained by the IIS itself. This is different than access via HL7 because in this case, the EHR is not relying on the immunization history from the IIS, but it is sending its own locally-stored immunization history to the IIS’ CDS service for evaluation. The EHR gains an evaluation and forecast consistent with the IIS without being dependent on IIS data. The EHR vendor does not have to reproduce the logic nor retain the expertise to manage it. While not all IIS will likely host such a service, potentially requiring the EHR vendor to develop multiple CDS strategies, it is likely that one or more IIS services will be “good enough” for use even nationally. But the EHR vendor also gives up a certain amount of control, not only over the logic but over the production web service as well. You get what you pay for: Assuming no payment to the IIS is required for this service, the service level provided by the IIS likely also comes with “no strings attached.”

As a web service provided by an independent organization, public or private

Another variation of the external web service is one provided not by the IIS but by an independent organization. This could range from a no-fee public service to a for-fee service provided by a vendor, organization, or association. By being independent from the IIS this service can grow or change in response to market demands. By charging a fee it has the potential to support itself financially and ensure a level of service that may be more appealing to EHR vendors. With that independence, however, comes a need to prove that its CDS logic is solid, tested, and appropriate. Such a service may or may not offer logic specifications customized to specific jurisdictions. Like some other options above, it does relieve the EHR vendor of the burden of developing and maintaining complex logic while allowing organizations or companies that specialize in this capability to continue to develop, refine, and improve their offerings.

One of the key considerations for an EHR vendor is the degree to which the selected strategy provides a solution for all their users regardless of location/jurisdiction, or whether multiple strategies might be necessary which adds cost and complexity to their solution. Note also that to be effective the EHR would have to have a complete immunization history to send to the independent CDS service. This might require a query to the IIS first before invoking the CDS service itself.

Reminder and Recall to ensure a patient returns when an immunization is due

There is a surge in the desire for consumer access to data. IIS could serve these new consumer markets with reliable and responsive data and advice. IIS today provide features to assist practices in generating contact lists and correspondence to help ensure that patients come back when immunizations are coming due in the near future (reminder) or are due or overdue now (recall). EHRs do not usually support these special reports and features, in part because their accuracy is dependent on CDS (see above). While IIS need to be sure that clinicians do not lose access to these services, they also need to be aware of patient expectations for access to and control of these services directly. According to AIRA,

The primary benefit of Reminder/Recall (RR) is to improve the timeliness and completion of recommended immunizations to prevent disease…. Secondary benefits of Reminder/Recall include improved IIS data quality, achieved by using responses to the Reminder/Recall notices to add or update information in the IIS, and strengthening relationships between IISs and Providers.

There are differences across the country in the perception of which organization – a public health agency or a provider – should even conduct these activities. In many jurisdictions, the public health and provider communities decide together where this outreach should originate, at least for patients for whom a medical home can be established. Many IIS consider themselves the outreach organization of last resort where a medical home cannot be confidently determined. On the other hand, in other jurisdictions, reminder/recall activities are carried out solely by public health agencies as a service to the provider (and patient) community and to meet the public health goal of high coverage population coverage levels and knowing where pockets of under-immunization exist.

Capabilities for reminder/recall vary not only across EHR products but also across IIS. Some IIS allow provider sites to conduct outreach activities using IIS tools just for their own patients. Some IIS conduct these activities for all providers in their jurisdiction with varying capabilities to make the communications to patients appear to be coming from the provider (as opposed to the public health agency). Stage 2 Meaningful Use does address patient reminders specifically, and the requirements for patient to be able to View/Download/Transmit (VDT) their own data may also drive EHR developments in this area. Increasing support for using Direct messaging between providers and patients may also increase the ability of providers to send alerts to patients electronically. IIS could also play a role in providing extracts for reminder/recall notifications that providers could import into their EHR to drive reminder/ notification systems they have acquired.

One of the cardinal rules regarding patient alerts is that if at all possible alerts for a patient for the same conditions should all come from the same source, in this case the EHR or the IIS. There are several reasons why this is important, including:

It is certainly possible for reminder/recall features to exist in both IIS and EHRs, so long as both have sufficient CDS capabilities to accurate produce alerts and providers and public health agencies do not send notices to the same patients without careful coordination. Just like CDS above, it is certainly possible for EHRs to receive reminder/recall “services” from external systems or organizations – even the IIS – assuming the necessary data could be provided or the external system had the ability to query the patient data as required to determine to whom to send the notice.

It is important to reiterate this point: reminder/recall accuracy is dependent upon CDS accuracy in whichever system generates the notice. To the degree that EHRs do not have robust CDS services available they should rely on IIS to perform reminder/recall activities if they are supported. Use of external CDS services can improve the speed with which EHRs can offer reminder/recall services that may be more central to the provider-patient relationship that most clinicians want to develop.

Practice-level assessment of up-to-date status

IIS provides summary statistics and assessments of up-to-date status primarily for pediatric and adolescent patient populations, though some focused adult surveillance is also conducted (e.g., seasonal flu). These measures are used by public health agencies as part of its Assessment, Feedback, Incentives eXchange (AFIX) quality improvement program and by insurance companies as part of their Healthcare Effectiveness Data and Information Set (HEDIS) quality metrics. The EHR Incentive Programs have now added requirements to report clinical quality measures (CQMs) to CMS, including childhood immunization status.

Calculation of practice-level up-to-date status also drives local, regional, and national policy including awareness of the state of health of the population. Healthy People 2020 includes an objective for immunization: “IID-17: Increase the percentage of providers who have had vaccination coverage levels among children in their practice population measured within the past year.” The CDC calculates national and state-level immunization coverage rates routinely from a number of sources. This includes a national direct-dial random survey (National Immunization Survey, or NIS) which CDC hopes to replace with IIS-based data over time; CDC is piloting this potential by funding a small set of sentinel sites to provide data from their IIS., Coverage levels are also reported by CDC IIS project grantees as part of their Immunization Information Systems Annual Report (IISAR).

According to CDC, “AFIX is a quality improvement program used by awardees to raise immunization coverage levels, reduce missed opportunities to vaccinate, and improve standards of practices at the provider level.” At its core, AFIX is a continuous quality improvement program whose effectiveness is largely measured by the immunization rates of a practice’s relevant patient population. The assessment is performed by trained public health immunization program staff (i.e., this is not a self-assessment by providers). The AFIX policies and procedures guide (see CDC’s Assessment, Feedback, Incentives eXchange (AFIX) Program Policies and Procedures Guide, First Edition, 2013, pp. 8-9) identifies two methods for selecting data for coverage level assessment: a chart-based method (sampling), and a method using IIS data (complete data set for a practice). According to a recent AIRA survey (Clark, Sarah et al., Awardee Experiences Using Immunization Information Systems (IIS) for Immunization Coverage Assessments, Child Health Evaluation and Research (CHEAR) Unit, University of Michigan, on behalf of AIRA, May, 2014, p. 3.), 89% of respondents used IIS data at least partially for their AFIX data needs, citing incomplete data as the biggest barrier to completely relying on IIS for this activity. Reliance on IIS data only may initially under-represent vaccine coverage levels but in the long term improve quality in the IIS as providers seek to correct missing and inaccurate data.

Historically, AFIX has been supported by a desktop software product developed and provided by CDC called the Comprehensive Clinic Assessment Software Application (CoCASA). CoCASA allows for anonymized data to be entered into it (manually or via data import) and is then used to perform a variety of data analysis activities through standard queries and reports. Though used by the majority of immunization programs to run AFIX reports (64% of respondents in a recent AIRA survey), CDC will be phasing out support for CoCASA. While there has been a trend towards AFIX programs using IIS data, far fewer projects are using IIS reports instead of CoCASA reports (in a recent survey, only 17% of IIS respondents used IIS reports exclusively for AFIX). CoCASA current support two modes of operation for its reports: when the “Apply ACIP Recommendations” box is not checked, all doses count as valid. When it is checked, a rudimentary algorithm is applied to the doses based on the ACIP schedule. This algorithm does not contain the many nuances that are usually present in a more complete CDS rule set.

Regardless of their requirements for supporting CQMs in ONC certified EHR technology, EHR vendors have been slow to include these sophisticated reports in their standard product offerings. Not only are the queries and report definitions complicated, but many EHR databases are designed best for support of clinical and administrative operations and not sophisticated data query and reporting. Providers and hospitals have begun to look elsewhere for others to provide these services. Accountable Care Organizations (ACOs) which are developing around the country have placed a higher priority on data warehousing and data analysis and becoming a more popular choice for helping providers to generate CQM reports.

Coverage assessments have a strong dependence on CDS services to be done accurately. As IIS CDS services improve, their ability to support coverage assessment improves. But it takes more than just a good CDS to do coverage assessments well – specialized skills are needed to ensure that data is extracted properly, processed properly, and presented properly. AFIX is more than a “data” activity: it is the AFIX visit by public health to a provider site that has the most impact. IIS will likely continue to invest in and improve their CDS and coverage assessment capabilities beyond those of typical EHRs given other priorities of EHR vendors. CDC has invested in at least one solution for IIS to use, and major IIS vendors have developed their own solutions for AFIX support.

Patient Access to Immunization Data

Individual/consumer access to immunization registry data has recently been identified as a priority initiative of the Office of the National Coordinator for Health Information Technology (ONC), the CDC, and the state immunization programs. However, there are a number of challenges to overcome to allow individual access to IIS data. These include policy, technology, identity proofing, communication, and outreach. The response by some states has been to grant access by creating a duplicate database for access. Some others states are investigating portals or PHR/EHR solutions. Still, others enable/require the patient’s healthcare provider to generate a unique personal identification number that is then used by the patient to access the IIS, thus keeping responsibility for patient identification and authorization with the medical home. While it is clear that there are as many options as there are challenges to consumer access, the goal of providing access to consumers to enhance their healthcare engagement is a priority. The ONC strongly encourages the development of tools and applications to make this actionable.

The CMS EHR Incentive Programs provide another backdrop for consumer access to immunization data. The Stage 2 Eligible Professional (EP) MU Core Measure 7 outlines the Patient Electronic Access. The objective states that the provider must “Provide patients the ability to view online, download and transmit their health information within four business days of the information being available to the EP.” “View/Download/Transmit” represents a new, more formal requirement for patients to access their own health data ostensibly through the provider’s EHR system.

In a recent ONC-funded study, two strategies were endorsed for providing patient access to IIS data:

These competing strategies each have their strengths and weaknesses, and likely both strategies will be deployed by IIS projects over the next several years. Limited funding for IIS will likely limit the development and deployment of the first option, while increasing requirements for patient access to medical records, in general, will likely spur the second strategy along. Access to children’s immunization records have some additional complexities that may be easier to manage by a provider who knows the family better, including preventing access where legal custody of a child may be unknown or providing access to a child in foster care. Both IIS and EHR enabled strategies can accommodate these situations, some better than others.

Conclusion

It is not yet clear how quickly EHRs will evolve to provide these five features, if they do at all. The issues described above provide a strong imperative for IIS to plan strategically for the role of both their data as well as their features.

Figure 2 provides an assessment of the current IIS and EHR support for the features described in this paper, as well as an indication of their likely support trajectory. IIS are expected to remain strong in CDS and Reminder/ Recall services, though these capabilities will increasingly migrate into the EHRs as well. Online data entry in the IIS will continue to be displaced by the EHR user interface. Patient access will develop rapidly within the EHR and PHR world, as well as gain some additional traction in the IIS community as well. Finally, though EHRs will continue to avoid including practice-level assessments in their products, IIS will improve their support for assessments as CDS improves and the support cutoff date for CoCASA gets closer.

Service-oriented architecture (SOA), including web services and other techniques, will likely play an increasing role in the deployment of these features in both IIS and EHRs. SOA may allow more of these features to be offered by IIS and EHRs to each other, or by independent third-party service providers to IIS, EHRs, or both. In this context, Figure 2 can also be seen as displaying whether the control over access to these services lies with the IIS or EHR even if these systems are not providing the feature themselves but relying on external service providers.

We offer the following advice, purposely aimed at both IIS and EHRs: