A Three-Step Approach for Creating Successful Electronic Immunization Record Exchanges between Clinical Practice and Public Health

Abstract

Population health and individual health are strengthened through proactive immunization programs. Clinicians refer to immunization records at the point of care about to decide which vaccinations their patients and families need to reduce the risk of contracting (and spreading) vaccine preventable disease (VPD). Understanding the earliest possible age intervals that are safe to administer vaccinations provides the youngest children with as much immunity as possible as early as possible. This is especially useful for children at highest risk as their visits to a medical provider may be sporadic. This, coupled with the continuous development of new and combined vaccines and complex vaccination schedules, challenges the provider to understand the appropriate vaccinations to order for their patients. Under-vaccinating increases patients’ VPD risk; over-vaccinating increases provider and consumer health care costs. Clinicians want to make the best clinical and economically responsible decisions — this is the challenge.

The solution lies in providing clinicians timely and accurate vaccination data with decision support tools at the point of care. The use of Electronic Health Records (EHRs) alone cannot achieve this goal. It will take an accountable team made up of the clinician organization, their EHR vendor, and a public health agency to effectively manage immunization coverage for a patient population.

This paper provides a three-step approach to establish and maintain EHR data exchanges, demonstrates the value of both clinical and technical testing prior to data exchange implementation, and discusses lessons learned. It illustrates the value of federal Meaningful Use criteria and considers how its objective to advance data exchange with public health systems increases providers’ access to timely, accurate immunization histories and achieves desired mutual health outcomes for providers and public health programs.

Background

In the early 1990’s the Centers for Disease Control and Prevention (CDC) established an objective for public health agencies to implement population-based data systems to capture immunization events. The goal of the data systems was to increase the vaccine coverage levels of school-aged children. The vision was straightforward: an immunization record should be available to a provider during a patient visit regardless of where that patient had received prior immunizations.

In 1998, the results of a nationwide survey which assessed the development of state immunization information systems (IIS) were published. The findings indicated that fifteen (15) state IISs were considered advanced for the time while the remainder of the states had little to no formal IIS development efforts underway.¹ By 2009, the CDC’s Immunization Information System Annual Report (IISAR) showed that nearly 85% of the sixty-four (64) state, city, and territorial IISs were receiving birth data from vital record systems.² In some cases these data also include the date the infant received a birth dose of Hepatitis B vaccine.

IIS messaging, transport and security standards were established to enable data exchange between clinical systems and the IIS. Private providers’ early data exchanges were implemented through their Practice Management Systems, their electronic medical record system or through 3^rd party billing applications. Presently, IISs serve as a model for other electronic health record systems, given their ability to maintain secure systems and utilize practices that ensure exceedingly high data quality. Because they receive data from many different sources, IISs must be able to resolve duplicate patients and vaccinations, and they do so exceedingly well. The public health expertise supporting IISs ensures their clinical credibility and their use as a clinical decision support tool.

A Perfect Storm for Immunization Data Exchange

As of 2009, incremental steps over the previous fifteen years had slowly advanced IIS development without the full commitment of the provider community. On December 30, 2009, incentives and direction for health information exchange was established through the Health Information Technology for Economic and Clinical Health (HITECH) Act. This act authorized the Department of Health and Human Services to establish programs to improve health care quality, safety, and efficiency through the promotion of health information technology (HIT). Funding from the American Recovery and Reinvestment Act covered payments, commonly known as Meaningful Use incentives, for providers to purchase EHRs and utilize them to improve patient care outcomes. The HITECH Act included a provision for how providers and EHRs would engage public health agencies and systems.³ One of the identified Public Health objectives involved working with the IIS community. Among the Meaningful Use Stage 1 standards is a requirement to demonstrate that the provider or hospital EHR can send immunization data to an IIS. The recently released Meaningful Use Stage 2 standards include the requirement to send clinically correct and complete immunization records from the provider’s EHR to an IIS.⁴ Future stages will expand these requirements to include bi-directional data exchange (sending data to the IIS and receiving data from the IIS).

The CDC Healthy People 2020 Objectives,⁵ which have been called “the nation’s roadmap for a 21^st century vaccine and immunization enterprise,” directs IISs to provide informed decision-making support to both consumers and health care providers.⁶ National health policies that motivate communities of care and supporting technology vendors to rapidly adhere to these policies create the perfect storm for the immunization provider and public health community. After decades of collecting immunization records and supporting immunization programs, state IISs are repositories of high quality health data which can be used to significantly reduce the incidence of vaccine-preventable diseases. The challenge (for whom?) is to harness these initiatives so that data exchange between provider EHRs and IISs removes barriers to participation in the state IIS, ensures that high quality immunization data is collected and exchanged between the systems, and that the data is actively used to ensure that the population is fully and appropriately immunized against VPD.

The purpose of this paper is to identify steps that programs can take that will lead them toward a successful electronic immunization record exchanges between the state’s IIS and the HER vendor. We identify leading vendors that have a record of successful implementations and describe specific actions within a three-step implementation plan based on over 10- years of observing and participating in these exchange initiatives. Finally, we provide a discussion on additional considerations for state IIS programs when beginning an electronic exchange initiative with a vendor or vendors.

Methods and Approach

Efficient electronic data exchanges in day-to-day clinical practice are presently implemented by thousands of healthcare providers and will be common in the next few years. The accelerated pace by which states implement exchanges and support the incentive programs is illustrated by a recent unpublished survey⁷ conducted by Scientific Technologies Corporation (STC). Ninety percent (90%) of states currently are currently or will soon be capable of receiving electronic immunization records through standard Health Level 7 (HL7) data exchanges.

STC facilitated electronic record exchange projects with ten state IISs between 2002 and 2012. We gathered information during each of these projects on various technical, programmatic, clinical and business processes and workflow issues that can predict the likelihood of a successful data exchange implementation. We identified EHR product functionalities such as data validation processes impacting the ability to collect data meeting state IIS requirements. State IIS field-level requirements do vary, but a new focus on dose-level dose accountability for vaccines provided through the federal Vaccine for Children (VFC) program are moving them towards standardization.

The steps and tasks recommended in this document involve successfully implementing data exchange between EHR vendors and an IIS. We identified the steps and tasks necessary to ensure information shared between the EHR and the IIS is clinically correct and complete. We also describe the steps to overcome potential barriers to a successful data exchange, Lastly, we identify ways to identify EHR functional deficiencies and ways to assist the provider staff to identify changes in their business practices and workflow to compensate for those deficiencies.

Findings and Recommendations

We identified three steps to implement and operate a successful electronic information exchange system. The process begins with investigation and discovery, continues with test and evaluation, and finally concludes with the implementation itself. Within each of these general steps are specific activities that must be and should be accomplished prior to moving to the next step. We describe each step and describe specific activities below.

Step 1: Investigation and Discovery

The purpose of this phase is to learn as much as possible about the provider, their EHR, their EHR vendor, and their business processes before testing patient data with the IIS. It is also crucial to identify primary contacts for each project stakeholder at this time. Table 1 below lists EHR vendors that are market leaders and have history of successful data exchange implementations. Table 1 also lists each vendor’s supported type of HL7 data exchange that meets or exceeds current requirements.

Table 1:

Electronic Record Exchange between State Immunization Registries and EHR Vendors

	Type of HL7 Data Exchange Supported
EHR VENDOR	Real Time Export	Batch Export	Supports IIS Queries
Connexin, Office Practicum	X		X
NextGen EHR	X
MIE WebChart (Medical Informatics Engineering)	X		X
RPMS (Indian Health Service)		X	X (testing)
NetSmart Technologies (Insight)	X		X
Greenway Medical / Prime Suite	X
Allscripts Professional	X
Cerner Power Chart	X
Cerner Millenium	X
Sage Software (Intergy)		X
eMDs	X
Epicare (hospital and provider practices)	X
McCormick and Mitchell	X
eClinical Works	X
EHS (now Success EHS)		X
Practice Partner (McKesson)		X
CompuGroup Medical		X
GE Centricity (Logician)		X
CPSI	X
Meditech (hospital solution)		X

Provider Activities

• Hold an official kick-off meeting with the provider and IIS team to outline the process.

• Describe the data quality testing processes.

• Estimate the anticipated length of time until the data exchange will go live.

• Have the provider commit to a minimal turnaround time when responses or investigations need to be completed by the provider staff.

  • ▪ Clarify how patient confidentiality will be maintained throughout the testing process.

• Ensure that the provider’s practice will commit leadership staff to the project through to completion.

• Identify the technical and clinical staff accountable for testing and implementation.

• Identify the provider’s current, past, or anticipated future participation in the VFC program.

• Establish if there are multiple provider locations in the provider organization.

• Identify if the practice is independent or owned by or affiliated with another entity.

• Identify where the computer server resides from which the data will be uploaded to the IIS.

• Validate the current quantity of the immunization data in the EHR:

  • ▪ Identify the length of time the practice has used the EHR.
  • ▪ Identify where the immunization legacy data resides and how or if it will be migrated to the EHR.
  • ▪ Identify where immunization data has been recorded since the EHR was launched. (EHR versus continued entry in the IIS).

• Identify provider staff who will be accountable for completing manual file uploads and how often these will be completed.

• Identify if the provider staff is capable of generating test data from their EHR and if not who will be completing that task.

• Explain how the data they enter into their EHR impacts their ability to track vaccine usage in the IIS and their ability to order and get approval for vaccines from the state VFC program.

EHR Vendor Activities

• Provide the IIS data specifications to the EHR vendor:

  • ▪ Identify the fields that are mandatory and recommended for the specific state IIS to accept the data.
  • ▪ Establish how or if the EHR validates these data fields.
  • ▪ Identify which data fields are included in the interface.

• Meet with the EHR vendor’s technical team to respond to their questions about the IIS application, the specifications, and the data exchange testing and implementation processes.

• Identify an EHR vendor project leader and lead technical staff assigned to the project.

• Review the current and planned export data exchange formats, e.g., HL7 v2.3.1, HL7 v2.5.1, CSV.

• Establish the data exchange capabilities to securely send and receive data:

  • ▪ If the EHR can receive data from the IIS, determine where the data will be stored, how it will be displayed in the patient record, and the processes the EHR will use to de-duplicate both patient and vaccine records.

• Establish what triggers data to be exported from the EHR to the IIS. Examples include: any change in patient data; updated demographic data only; new vaccination entry, administered or historical or the patient record has been “closed” in the EHR. Understand if these triggers happen automatically or if a manual process must also occur.

• Identify how the EHR manages IIS Opt Out and Opt In indicators in their EHR. States that require consent to allow data to be sent to the IIS are Opt In states. In these states, the EHR will need to indicate that consent has been signed and parse the patients included in the export by those who have consented.

• Identify how and if the EHR supports VFC status information at the patient level (how the patient qualifies for the VFC program) and the vaccination level (the vaccine funding source).

• Determine if the EHR documentation is fully integrated with the provider’s billing (i.e., what is documented in the EHR that determines what is generated on the patient bill).

• Review the CVX/ CPT and MVX codes that are available in the EHR to ensure they are complete, accurate and active:

  • ▪ Inactive codes may be used to document vaccinations that were given in the past (historical).

• Ensure that the IIS and the vendor have a common definition for historical and administered vaccinations.

Demonstration

• Have the provider staff demonstrate how they use their EHR to input the following:

  • ▪ Patient demographic information including Next of Kin or legal guardian and race information. NOTE: Patient demographics may be collected in a separate module that then populates the EHR with limited demographics.
  • ▪ Historical and administered vaccinations. Be sure to have the provider define what historical vaccinations mean to them.
  • ▪ Note what fields are entered as free text.
  • ▪ Review the choices available in all drop down lists and if the provider can change those values.

• Determine if the EHR has a vaccine inventory function and if they use it.

• Note if a vaccine funding source can be identified for administered vaccines, e.g., VFC versus private.

• Determine if there is a vaccine forecast in the EHR. If it exists, ask how or if history of disease or contraindications impact the vaccine forecast. Review what the forecast displays.

• Identify the mandatory fields and review the data integrity checks. Warning: users may be able to “trick” the EHR to bypass mandatory fields using generic placeholder information.

• Identify where the provider documents history of disease and other contraindications to vaccination.

• Ask if the EHR has a way to document vaccination refusals, and if so, where and how.

• Ask if the provider knows how to generate a sample of data from their live production system. If not, who would do it for them and how.

Step 2: Test and Evaluate

There are two important testing steps. The first validates the technical capability to send appropriately formatted and fully populated HL7 messages to the IIS. The second ensures that patient and immunization event data is clinically accurate, correct and complete. The state IIS will not implement a data exchange until both criteria have been met.

Technical Testing

This process requires an HL7 test data set to be exported from the EHR to the IIS. The test file should contain at least 250 patient records to identify possible random technical transfer issues. This is usually done with mock patient records first and then live patient data. Live patient data must ultimately be tested to know what the IIS will ultimately get from the provider’s system.

• Messages are reviewed to ensure the expected data set is received in the IIS test environment without error. They are also reviewed for compliance with HL7 message standards and the frequency the data is populated. Adherence to the HL7 message version used is also reviewed, e.g., v2.3.1 or v2.5.1. Meaningful Use Stage 2 requires that EHRs send data in v2.5.1 by 2014.⁸

• When progressing to testing live patient data, at least 1,000 patients with immunization messages should be reviewed. Fewer messages are insufficient to identify random data quality issues that may occur. Multiple iterations of test messages are usually needed to ensure that clean, accurate, and complete data will be sent to the IIS when the exchange is operational. An average of three to six test exchanges is generally required. When an EHR application does not support entering valid and complete immunization and demographic data, changing the provider’s workflow and business processes may compensate for the EHR deficiencies (e.g., making a field mandatory). Frequently, it is the IIS rather than the EHR vendor who discovers the issues and makes recommendations to the providers for these changes. The testing process is more than a validation; it is also provider and EHR education which is ideally provided by a public health specialist as opposed to a technology expert. The public health specialist has the depth of understanding across all systems and clinical programs to make these recommendations.

Data Quality Testing

Some data quality testing is accomplished in the connectivity testing process described above. However, it is recommended that a more detailed process be conducted to validate the quality and quantity of immunization data captured in the provider’s EHR. The tasks include:

• Review the accuracy of current CPT/CVX (vaccine) and MVX (manufacturer) codes in their EHR:

  • ▪ Ensure combination vaccines can be documented as some EHRs support only the entry of single vaccine antigens. Combination vaccines impact vaccine forecasting so vaccines should be able to be documented in the formulation they are given.
  • ▪ Review how and where contraindications to vaccines and history of disease are documented. If they are captured, determine what codes will be sent for each value and where will they be sent in the HL7 message. Ensure that discontinued codes are not being used for administered vaccines.
  • ▪ Ensure that the EHR vaccination list with the corresponding codes which will be sent in the import file is complete and correct. Providers should have vaccine descriptors in their system that reflect vaccines they have available and administer as well as those that they need to document as historical vaccinations.
  • ▪ Ensure the EHR has vaccine descriptors that correspond to the correct CPT or CVX code. It is not unusual to find that the EHR upgrade has been distributed with these errors versus the provider entering them incorrectly.

• Review the vaccination related fields to ensure that they are being consistently populated. The fields include vaccinator name, vaccine manufacturer, vaccine lot number, and vaccine expiration date.

• For an Opt-In IIS, a field to indicate that consent has been obtained must be available and populated and only consented records should import into the IIS.

• For those providers who participate in the VFC program, an indicator must be available in the EHR to mark how the patient qualifies for VFC. This must be updated with each vaccination visit. Many states are now requiring this information in the HL7 message. NOTE: VFC information is only expected in records for patients who are under age 19 years. If the VFC indicator is sent for all patients, then patients at 19 years or older should default to “ineligible.”

• Prior to implementation, compare the HL7 messages from the provider’s EHR against what the clinician sees in their EHR:

  • ▪ Randomly select 50 or more live patient immunization messages from the group that has passed testing.
  • ▪ Have the provider pull those patient records up in their EHR and compare them; they should match exactly.
  • ▪ Have the provider identify discrepancies and review them with the vendor. One or both of the following could occur:
  • • The EHR vendor needs to correct technical errors or change the application to support staff workflow/needs.
    • The EHR vendor needs to retrain clinical staff in the appropriate use of the EHR application so that documentation practices support the interface design.

• After the corrective actions have taken place, a clean test file is imported to the IIS test system to demonstrate that all issues have been addressed.

• After the IIS team accepts the test file, the provider’s EHR is ready for LIVE data exchange.

Step 3: Implementation Phase

After Steps 1 and 2 are complete the provider is ready to implement data exchange between their EHR and the state IIS. After the initial implementation, the data exchange processes require on-going monitoring and evaluation. Many things may change causing the import process that was originally established to fail or be interrupted. For example, with Meaningful Use incentive payments available, many providers are switching from one EHR to another. Provider staff members change. EHR upgrades may interrupt the connection to the IIS. Finally, the provider’s failure to upgrade the EHR in a timely manner may cause incorrect data to be sent to the IIS.

The following items should be reviewed with the provider and the EHR vendor at the IIS data exchange implementation:

• Ensure the provider understands their ongoing responsibilities for the data exchange:

  • ▪ Ensure data files are sent to the IIS on a regular basis:
  • • If data files are manually uploaded, determine the frequency of the data uploads as daily (preferred) or weekly (acceptable). Best practice calls for two individuals within the provider’s office to understand the upload task.
    • If data files are automatically uploaded, assign staff who will confirm that successful data file transmission occurs on a regular basis. Replace assigned staff as needed when turnover occurs.

• Establish how the CPT/CVX codes in an EHR application will be kept current. This includes adding codes as new codes are established and inactivating those that are discontinued. Persons assigned this responsibility should link to the CDC listserve that automatically sends notices about changes to codes (additions, inactivation, changes).⁹ Vaccine codes should be reviewed when system upgrades occur to ensure accuracy. Some providers are responsible to update their own applications and may or may not be alerted to do so by their EHR vendor. Identify who will be responsible to keep EHR upgrades current. Some providers will choose to lag behind when new major releases occur because they feel those releases will have more system bugs.

• Intermittent data quality checks should be a formal process for both the IIS and the provider. Discuss an established schedule for these reviews and how issues will be communicated between the parties. Some IISs can give the provider permissions to check the HL7 message error log themselves with appropriate IIS system permission.

• If the EHR receiving data from the IIS supports IIS queries, ensure that the EHR has a process to manage duplicate patients and vaccinations. EHRs typically handle patient duplicates well because of their experience with receiving data from other systems such as labs and radiology facilities. EHRs are not usually equipped with the logic to de-duplicate vaccinations like an IIS. While this is the EHR vendor’s responsibility, they will require support from the IIS as they resolve their issues.

Discussion and Recommendations

Meaningful Use has added a level of motivation for clinical providers and hospitals to exchange data with an IIS. Rigorous processes to implement these links will pay dividends to public health programs and clinical providers. The state immunization program must retain the expertise and be the “source of truth” for All Things Immunization. They must support both EHR and provider education. This partnership must recognize that sending data to a state IIS is only the first step. The power in the data will come from the ability to query the IIS for patient vaccination records and accept IIS generated patient age-appropriate forecasts. This will maximize the health data assets of the immunization provider community and empower clinical care physicians, nurses, and pharmacists with the complete and accurate information needed to support their vaccine administration decisions.

We have identified best practices for implementing data exchange between the IIS and EHR and describe these activities in detail within three main steps: identification and discovery, testing and validation, and implementation. Regardless of specific circumstances, there are several important considerations regarding the implementation steps we’ve outlined in this paper. These include assumptions and preconceptions regarding the process itself, aspects of the EHR and coding, expectations on the process time and effort required, need for on-going monitoring, how to handle EHR upgrades, and others we describe in detail below. Future research that would identify under what circumstances these considerations come into play will be extremely useful to reduce potential for a state’s initiative to be unsuccessful, and/or to reduce costs of implementation.

First, each data exchange interface is unique. Each provider or their representative has purchased and/or modified an EHR to suit their needs. Each provider has been trained to use their EHR by different people and what they retain about that training varies. Each provider has developed workflow processes and business practices around their EHR implementation. Many providers choose to implement their EHR in phases. Experience has shown the value of using the following practices and processes:

• Make no assumptions during any phase of the process. Take the time to verify all EHR information with the vendor, the provider, and the provider’s clinical staff. The quality and quantity of data entered into the EHR is impacted by the business practices used, the workflow, staff implementation and ongoing training on the EHR application, and individual staff compliance/errors.

• EHRs are not a turn-key data exchange solution for an IIS. Because clinicians are entering immunization and other data into the EHR, providers and the IIS may assume that the record of the immunization event can and will be accurate and complete. This is not the case unless the EHR has the field level validation and other functionality to require it from the user.

• Expect the testing process to be long and challenging. Less vendor attention has been paid to the EHR’s immunization module compared to other core EHR functionality mandated under Meaningful Use Stage 1. Providers may think this process will be easier than it is. Explaining this fully before the process begins can help mitigate this expectation and help diffuse the perception that the IIS community is the barrier to implementation.

• Ongoing data transmission between the EHR and IIS must be monitored and nurtured. Routine software upgrades and hardware changes may cause an established exchange to fail. This is another common reason that continuous monitoring at the IIS is important in order to spot aberrations in information flow.

• EHR upgrades impact immunization data quality. How and when EHR vaccination codes are updated varies by the vendor’s releases and how soon the provider chooses to implement them. After implementing the data exchange, it is important that the provider understand that their vaccine choices need to match what is being administered in their offices. Keeping their systems updated in a timely manner impacts their ability to do this.

• EHR users are creative. They discover ways to record data in their EHR when the application does not offer them the correct vaccine choice. This applies to both doses they administer in their practice and doses that have been given elsewhere (historical doses). Here are some scenarios observed during the testing phase:

  • ▪ If the correct vaccine is not available in the EHR database, users simply select the closest choice, e.g., Td, when they are actually giving Tdap; or PCV7 when they are giving PCV13. This is typically due to the vendor not providing the upgrade in a timely manner or the provider opts to delay system upgrades.
  • ▪ Users documented they administered a Varicella vaccine when they did not because their EHR did not offer a way to document Chicken Pox history in the vaccination record.

• EHR vaccine descriptions are frequently linked to the wrong vaccine code. IISs read the vaccine code in the HL7 message, not the vaccine description. This is discovered when reviewing the EHR vaccine and manufacturer code table review for accuracy and completeness and during the provider’s demonstration of their EHR. Most EHR applications allow providers to change vaccine codes themselves by selecting from a hard-coded list. Some allow an administrative user to originate new vaccine codes and descriptors in their system.

• Data fields required by the state IIS for data exchange may not be mandatory or exist within the EHR. State IISs need their data to support dose level vaccine accountability for VFC vaccinations. The concept of VFC is relatively new to the EHR community. Many EHRs either do not offer the fields in the EHR for the provider to complete or the data validation does not exist to make sure the fields are complete and correct. Fields such as patient VFC status, vaccine funding source, VIS publication date, and the date the VIS was given to the patient or the parent may not exist.

• EHR data field validation and functionality to support complete and correct documentation of the vaccination event are sporadic. Many EHRs allow free text in data fields that are required in the IIS, making it highly susceptible to error. Still others offer drop down lists from which to choose vaccine lot numbers but the user may be able to overwrite the field and enter free text.

• Next of Kin information is frequently not collected in the EHR. EHRs most often have responsible party, emergency contact, or guarantor (person responsible for the bill) fields which may not be the legal guardian. Parent and legal guardian information is important to support de-duplication of patients in the IIS:

  • ▪ The IIS may not accept these alternate fields in lieu on Next of Kin information.
  • ▪ Guarantor information now frequently asks for how the patient is related to the insured (natural child, step child) versus how the insured is related to the child (parent, step-parent). This makes using guarantor information in lieu of Next of Kin impossible.
  • ▪ For children whose insurance is Medicaid, the child’s name must be listed as the guarantor as they are the insurance holder. As such, there will never be parent or legal guardian in this field for children with Medicaid coverage.

• Clinical documentation may drive the provider’s bill. EHRs may be fully integrated with the provider’s billing. If the IIS recommends changes to the EHR vaccine codes, ensure that the charges linked to that code are also reviewed before they are finalized. Disrupted billing or erroneous billing puts the provider at legal and financial risk.

• Vaccination and manufacturer codes of hospital EHR systems are generally set by the pharmacy. Many hospital EHRs require extensive vaccine code mapping or “aliasing” to send data correctly. Requests for additional data fields or changes to the EHR workflow are expensive and usually take many months to be completed. Historical vaccinations are rarely recorded in a hospital EHR because a bona fide record to verify the information is usually not available.

• Hospital EHR systems are not prepared to document patient or vaccination VFC information. This issue is largely unanswered in hospital EHRs. Most hospitals that have worked with an IIS have entered the required data directly into the IIS. Clinicians receive medications from the pharmacy. They are the only ones that would know if the vaccine was supplied by the VFC program. Since hospitals gather the information needed to determine if a patient qualifies for VFC in other areas of the EHR, the patient VFC status could be derived.

• Understand the provider’s organizational structure. The provider may have no direct control over the EHR in use. It is important to understand who supports the EHR in use, who has the ability to make changes in it, and where the data imported to the IIS is stored. Many providers are employees of larger healthcare networks and they contract for IT services controlled by another entity. A single HL7 import may include data that is coming from different EHR products. The data may also go through middleware that could change it before it arrives at the IIS.

• Clinical training issues will be discovered in this process. Clinical vaccination errors will become evident when HL7 messages are reviewed. Most provider offices are now staffed with a number of unlicensed healthcare workers who administer vaccines. These issues should be discussed with the provider’s clinical manager so that appropriate retraining can occur. This highlights the value of a robust EHR immunization module with logic to mark invalid vaccinations and forecast vaccinations based on Advisory Committee on Immunization Practices (ACIP) recommendations. Many clinicians become dependent on this functionality available in the IIS.

Limitations

A limitation of our findings is that our recommendations are not based on a scientific approach, but rather we leveraged observations and experience gained over the course of many different projects. No project was exactly the same and we had no control over programs’ choices in many cases. Another limitation is that some of our recommendations will not apply for all situations. There may be cases when a program’s implementation process may not be successful due to not be able to complete all needed activities when some do not apply. Finally, we acknowledge that even if all recommendations are followed in their entirety, a program’s implementation may still not be successful due to unforeseen factors.

Conclusion

In summary, using proven practices is key to implementing and supporting ongoing Meaningful Use data exchanges. Immunization information system processes must be in place to monitor, alert and support the EHR and clinical care community. Implementation can be achieved through following specific activities within three major steps, while keeping certain considerations regarding the process in mind. Ultimately, public health-supported decisions will mark a milestone in improving healthcare outcomes, increasing individual and population protection against disease, and reducing the significant economic and health impacts — saving both dollars and lives.