Cal eConnect IZ Demonstration

From Direct Project
Jump to: navigation, search

Redwood MedNet Immunization Messaging Service

Pilot Project Brief - Redwood MedNet : : RWMN Direct Pilot Shared Documents : : Cal eConnect ToC Demonstration
Updated October 1, 2011


Immunization (IZ) reporting in California is coordinated by the California Immunization Registry (CAIR), which operates nine regional registries in the state. Electronic IZ reporting currently enters eight of the CAIR regional registries one of two ways: either via a legacy batch file load process or via manual entry by keyboard at the practice using the CAIR web portal*. Most EHRs are able to generate immunization reports in the national standard (HL7 v.2.5.1). Only one of the nine CAIR regions is able to accept the HL7 standard, and most EHRs do not generate batch files in the unique format required by the eight CAIR registries. Therefore a healthcare site with a certified EHR in our Northern California region is likely to record the IZ event twice, once as a patient visit in the EHR, and a second time by keyboard into the CAIR web portal. In the future CAIR will create a service that can consume the standard HL7 v.2.5.1 immunization messages; however, that service is not likely to arrive this year and it may not arrive next year. In 2011 Redwood MedNet developed a file service that consumes the standard HL7 v.2.5.1 VXU immunization message produced by certified EHRs, and then creates the legacy CAIR batch file. This IZ batch load solution is useful for several reasons.
  • It supports the stage one meaningful use measure for IZ reporting by eligible providers who are early adopters of EHR
  • It offers an immediate workflow efficiency gain for practices that currently double enter the IZ events into their EHR and into the CAIR web portal
  • Redwood MedNet also has a standard secure health data delivery route into Microsoft HealthVault, so the IZ message to CAIR can also populate the patient's PHR (if appropriate)

* Exception -- the San Diego regional registry accepts HL7 messages; but the Northern California and Bay Area regional registries, where Redwood MedNet is active, cannot accept HL7 messages at this time.

Project Tasks

  1. Identify an Eligible Provider with a Certified EHR capable of originating Direct Message payloads
  2. Investigate the use of Direct Messaging as a transport option for reporting immunizations to the state registry
  3. Establish a pilot test of Direct Messaging (if appropriate)
  4. Include IZ record validation service to inform sender of mitigation steps for resubmission of the corrected IZ record
  5. Develop user-facing instructions for IZ reporting


The outpatient site for this pilot project is School Health Clinics of Santa Clara County (SHCSCC). This year the clinics installed the NextGen certified EHR. The Project Manager for the IZ service installation is Infinite Consulting Service.


June 2011 - grant funds arrive
July 2011 - workflow evaluation and requirements gathering
August 2011 - draft IZ reporting solution
September 2011 - get quotes, open contracts, purchase services
October 2011 - initiate development
November 2011 - test IZ reporting solution
December 2011 - publish report on project

Findings To Date

Field Deployment of Direct Messaging Not Available from EHR Vendor: The EHR vendor was unable to provide the clinic with a quote for a HISP enabled version of the EHR. However it was possible to purchase a standard VXU interface from the vendor, thereby enabling a routine outbound HL7 push message stream with complete immunization reporting data. While theoretically possible for Redwood MedNet to extend HISP capabilities to the practice in order to insert SMTP into the IZ reporting process, it was a suboptimal workflow solution, and therefore not selected for production deployment.

Activity diagram showing the potential to use Direct Messaging for error reporting. Further investigation during implementation of the immunization reporting service will determine user appetite for an SMTP error notification process.

Reporting Immunizations to State Registry: In this use case Direct Messaging is inappropriate for transport of IZ messages to the registry for two reasons. First, it is simply inconvenient to build a novel, one-off subsystem to transform the VXU messages from the EHR into a Direct Message payload. To do so would originate a sequence of unique steps, introducing unnecessary complexity into the work flow. Instead, it was simpler to build a VPN from the practice data center to Redwood Mednet, and to allow the EHR to do what it already does well -- push an HL7 v.2.5.1 message over LLP to an IP address. And second, within the context of this investigation, it was not practical to create a gateway for CAIR to receive Direct Messages.

Reporting Errors to the Sending Provider: In this use case, the intermittent batch process at CAIR is a deal breaker that interferes with the standard HL7 ACK response files expected by the EHR. This in turn requires that errors in the submission of an IZ report (e.g., invalid lot vaccine number, invalid vaccine manufacturer, etc.) must be communicated back to the sending provider out of band from the automated HL7 reporting process. In this situation Direct Messaging is plausible, but not necessarily optimal, for delivery of the error messages. Continued discussions will allow the clinicians to determine if Direct Messaging is acceptabe for error reporting, or if another notification strategy better matches user work flow.

Next Steps

  1. Milestone planning with ICS
    • Solve ACK workflow
    • Final task list
    • Sign BAA + Participation Agreement with SHCSCC
    • Sign Equipment Placement Agreement with Council
    • Support ICS field deployment tasks
  2. Contract with Mirth Corp
    • Service specification
    • Ship HIE appliance to Council data center
    • Engineer develop data channels
    • Open VPN circuit
    • Test & stablize NextGen VXU feed
    • Unit test NextGen SFTP to CAIR
    • Release CAIR reporting to production
    • User training
    • Implement ACK workflow
  3. Write report