1. Cross-Jurisdictional Immunization Data Exchange Project Updated 4/29/14

2. INTRODUCTION AND OVERVIEW

3. Background & Context Advantage of ONC solution: Promotes use of adapted CDC WSDL and HL7 IZ IG V1.5 which will drive interoperability Will improve use of bidirectional querying by IIS Scalable solution More IIS can easily be added to the hub IIS will be able to theoretically communicate with any other IIS on the hub Current IIS Data Exchange Only two pairs of jurisdictions currently exchange data: Washington and Oregon; and, NYC and NY state This exchange is currently done point-to-point using batch files and is therefore not real time ONC Initiative Pilot states will transfer data via a data hub with partner jurisdictions Pilot states will use an adapted version of the CDC Web Services Definition Language (WSDL) Pilot states will use the HL7 Immunization Implementation Guide V1.5 (HL7 2.5.1 IZ IG V1.5) Future? All IIS will interface with the hub and exchange data will all other IIS All IIS will use the adapted CDC WSDL and HL7 IZ IG V1.5 Initiative Goal: To enhance cross-jurisdictional immunization data exchange by: Providing participating pilot sites with a data hub via which they can exchange immunization data Committing pilot sites to implement the HL7 Immunization Implementation Guide V1.5 and use the adapted CDC WSDL

4. Project Scope Out of Scope Dealing with policy issues around data exchange Editing/updating information in registries by Consumers No transformation, translation, or reading of message content as it passes thru the hub (hub does not store any patient information or data) The hub will not ensure that all requesters of information, other than consumers (patients) are licensed to query and receive immunization data In Scope Using current bi-directional messages to enable the exchange Establishing a Data Hub that will be utilized by the pilots Allowing for the initiation of data exchange thru the following three methods: Physician directly to Immunization Registry; Physician via EHR to Immunization Registry; Consumer via Patient Portal Development of the WSDL and HL7 Implementation Guides -WSDL authenticates end users

5. Pilot Criteria All pilot sites must… Upgrade to the new CDC WSDL adapted for the Data Hub Solution The WSDL is backwards compatible Adopt the HL7 Version 2.5.1 IG Immunization Messaging Release 1.5 Implement any changes required to setup the Data Hub as an integration partner Configuring firewalls, ports, etc. Maintain a test and production instance of the IIS and utilize the test version of the Data Hub for Testing and the Production version of the Data Hub for Pilot (production) Have the capacity to issue queries via a QBP Have the capacity to accept and process RSPs Have the capacity to consume a VXU (assumed) Have the ability to create or handle any additional errors from the WSDL or HL7 ACK Adapt the IIS to process business rules that: Recognize when a new patient’s current address (jurisdiction) is in a partner IIS’ jurisdiction Recognize when a patient’s address (jurisdiction) in the IIS has changed form a partner IIS’ jurisdiction to this IIS’ jurisdiction All pilot sites should… Provide capacity to generate an explicit request (i.e. via a “button” or process that requested the data from a partner jurisdiction)

6. USER SCENARIOS

7. HL7 Supported Use Cases 7 Use Case 1: Send Immunization History (VXU) Use Case 2: Request Immunization History (Includes both QBP and processing of RSP) Note that for the purposes of the pilot “valid” and “invalid” doses must be returned This is to reflect jurisdiction differences in what is considered a valid dose allowing the requesting state to make the determination Use Case 5: Acknowledge Receipt Use Case 6: Report Errors

8. Comparison Matrix 8 Use Cases Provider Uses IIS Provider uses an EHR that that supports VXU/ACK only. Provider uses EHR that supports VXU, QBP, and RSP. Patient’s current address is in a partner jurisdiction and there is no record in the IIS. Scenario 1 Automated trigger 1 Scenario 4Scenario 7 Patient current address is in the IIS jurisdiction and the IIS has a record with a partner jurisdiction. Scenario 2 Automated trigger 2 Scenario 5Scenario 8 Patient current address is in the IIS jurisdiction, there is no data in the IIS for patient and patient informs provider of prior residence in a partner jurisdiction Scenario 3 Manual Trigger Scenario 6Scenario 9

9. Patient Portal Jurisdiction 1 IIS Entry Points Consumer Provider Actors IIS Jurisdiction 2 IIS Central Data Hub Hub (Additional IIS…) Use Case Objective: For an Immunization Information System (IIS) to respond to a transaction that contains current or historical addresses that are outside its jurisdiction by triggering a QBP or VXU to the other jurisdiction’s IIS. Use Cases: 1. New record directly entered by provider into current IIS; update sent to partner jurisdiction’s IIS 2. Current IIS queries partner jurisdiction’s IIS triggered by the patient’s address 3. Provider queries patient’s former IIS (partner jurisdiction) and then enters a new patient record directly into the IIS IIS Data Exchange Use Case Diagram

10. DC IIS Scenario 1 Workflow: 1.MD resident goes to a DC provider 2.Provider enters a query directly into the current IIS (DC) with the intention of getting a complete valid record; no match is returned 3.Provider adds patient information into the IIS directly to reflect patient’s current DC address and saves the record 4.DC IIS queries MD IIS for current IZ information a.DC IIS recognizes that patient has an address from a partner jurisdiction (MD) and generates a QBP sent over the hub b.MD IIS receives the QBP from the data hub and returns an RSP across the data hub to the DC IIS(ensures an accurate IZ record) 5.Provider enters new immunization information into the current jurisdiction's IIS (DC) and sends an unsolicited VXU across the hub to the partner (MD) IIS 6.VXU is routed across the data hub to the MD IIS 7.The patient’s primary IIS (MD) processes this VXU and stores the information MD IIS Central Data Hub 1.) MD resident goes to a DC provider 2.) Provider queries DC IIS with no match returned 3.) Provider adds patient info directly into DC IIS with current MD address 4.) DC IIS queries MD IIS for current IZ information (See step 4 Sub-Process steps) 5.) Provider enters new IZ information into DC IIS which triggers an unsolicited VXU update to the MD IIS 7.) MD IIS processes the VXU and stores the updated information End Start 6.) VXU is routed across the data hub to the MD IIS Scenario 1: A MD resident goes to a DC provider; provider enters new information directly into DC IIS where no current record exists Scenario Trigger: Primary Address (automated) Message Type: VXU

11. Scenario 2 Workflow: 1.New DC resident (previously MD) continues care with their former DC provider 2.Provider queries the DC IIS and updates the patient’s current address 3.DC IIS recognizes that patient has an address from a partner jurisdiction (MD) and generates a QBP sent over the hub 4.MD IIS receives the QBP from the data hub and returns an RSP across the data hub to the DC IIS (ensures an accurate IZ record) 1.Partner IIS (MD) will want to update current patient address 5.DC IIS receives the RSP from the data hub 6.Provider enters new immunization information into the current jurisdiction’s IIS (DC) which is now the resident’s primary IIS 2.) DC provider enters new address information into the DC IIS MD IIS DC IIS Central Data Hub 1.) New DC resident continues care with former DC provider Start End Scenario 2: New DC resident, previous MD resident, continues care with former DC provider, who enters new information directly into the DC IIS Scenario Trigger: Patient Address (automated) Message Type: QBP 3.) DC IIS recognizes that patient’s previous address is from a partner jurisdiction (MD) and generates a QBP routed across the data hub 6.) Provider enters new IZ information into the DC IIS 4.) MD IIS receives QBP and sends an RSP across the data hub 5.) DC IIS receives the RSP from the data hub

12. Scenario 3 Workflow: 1.DC resident (former MD resident) goes to a new DC provider 2.Provider queries DC IIS to find no record of patient 3.Provider enters patient demographic information (address) directly into the IIS and invokes a manual trigger to generate a QBP query of the partner jurisdiction (MD) 4.MD IIS receives the QBP from the data hub and returns an RSP message across the hub to the DC IIS 5.DC IIS receives the RSP from the data hub and incorporates the patient’s IZ record 6.The patient receives an immunization and the provider enters the new immunization information directly into the current jurisdiction’s IIS (DC) 12 MD IIS DC IIS Central Data Hub End Start Scenario 3: New DC resident, previous MD resident, provider enters new information directly into DC IIS where no current record exists Scenario Trigger: New Primary Address (manual) Message Type: QBP 1.) New DC resident visits new DC provider for an IZ 2.) DC provider queries DC IIS and finds no record of patient 3.) Provider enters patient address directly into IIS and invokes a manual QBP query routed across the data hub 4.) MD IIS receives a QBP and sends an RSP across the data hub 5.) DC IIS receives the RSP from the data hub 6.) Provider enters new IZ information into the DC IIS

13. APPENDIX

14. HL7 Message Types DefinitionUses ACK- Acknowledgement message Acknowledge receipt of a message (e.g. immunization history, request for immunization history, demographic update, observation report or request for personal ID). This message may indicate success or failure. Send error messages. Could result in rejection of message or parts of message. ADT- Admit, discharge & transfer Send updated or new demographic data about a person. Accept updated or new demographic data about a person. QBP- Query by parameter Request an immunization history from another system. Find one or more candidate clients from another system and select one to be used when requesting an immunization history. PDQ- Type of QBP that facilitates identity resolution based on demographic information PIX- Type of QBP that accomplishes ID cross reference RSP- Response to QBP Return an immunization history. Accept an immunization history in response to query from another system. Acknowledge receipt of a message. One example occurs when query is well-formed, but finds no candidates. In this case the acknowledgement reports this. Send error messages related to messages. VXU- Unsolicited vaccine history Send an immunization history for an individual client from one system to another. In addition to EHR-S and IIS, other systems such as vital records systems or billing systems could use this message to send immunization histories. Receive an unsolicited updated or new immunization history. To send updated or new demographic data about a person. It may be an update or a new record.

15. Project Metrics for Success Functional metrics: Data hub development time Registry interface development time Number of participating pilot sites and sub sites Percent of messages sent thru the hub correctly Data hub technical metrics: Traffic Volume Average response times Production volumes Error rates Total errors Total queries Query processing time Availability/uptime Peak message volume throughput State metrics: Errors Queries Sent Queries Received Message response times Percentage of messages rejected due to multiple match Number of end users Number of unique users providing queries