Cross-Jurisdictional
Immunization Data Exchange
Project
Updated 4/29/14
INTRODUCTION AND OVERVIEW
Background & Context
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
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)
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
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
Project Scope
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
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
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
• Provide capacity to generate an explicit request (i.e. via a “button” or process
that requested the data from a partner jurisdiction)
All pilot sites
should…
USER SCENARIOS
HL7 Supported Use Cases
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
7
Comparison Matrix
Use Cases
Provider Uses IIS
Patient’s current address is in a partner
jurisdiction and there is no record in
the IIS.
Scenario 1
Patient current address is in the IIS
jurisdiction and the IIS has a record
with a partner jurisdiction.
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
Provider uses an EHR that that
supports VXU/ACK only.
Provider uses EHR that supports
VXU, QBP, and RSP.
Scenario 4
Scenario 7
Scenario 5
Scenario 8
Scenario 6
Scenario 9
Automated trigger 1
Scenario 2
Automated trigger 2
Scenario 3
Manual Trigger
8
IIS Data Exchange Use Case Diagram
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
Entry
Points
Actors
Provider
Consumer
Patient Portal
IIS
Jurisdiction 1
IIS
Hub
Central
Data
Hub
(Additional IIS…)
Jurisdiction 2
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 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
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
Scenario Trigger:
Primary Address
(automated)
Message Type:
VXU
6.) VXU is
routed across
the data hub
to the MD IIS
Central
Data
Hub
Start
DC IIS
MD IIS
7.) MD IIS
processes the
VXU and
stores the
updated
information
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 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
1.) New DC
resident
continues care
with former
DC provider
2.) DC
provider
enters new
address
information
into the DC
IIS
3.) DC IIS recognizes that patient’s
previous address is from a
partner jurisdiction (MD) and
generates a QBP routed across
the data hub
Central
Data
Hub
DC IIS
Start
End
Scenario Trigger:
Patient Address
(automated)
Message Type:
QBP
6.) Provider
enters new IZ
information
into the DC IIS
5.) DC IIS
receives the
RSP from the
data hub
MD IIS
4.) MD IIS
receives QBP
and sends an
RSP across the
data hub
Scenario 3: New DC resident, previous MD resident, provider enters
new information directly into DC IIS where no current record exists
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)
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
Central
Data
Hub
DC IIS
Start
End
6.) Provider
enters new IZ
information
into the DC IIS
5.) DC IIS
receives the
RSP from the
data hub
Scenario Trigger:
New Primary
Address (manual)
Message Type:
QBP
4.) MD IIS
receives a
QBP and
sends an RSP
across the
data hub
MD IIS
APPENDIX
HL7 Message Types
Definition
Uses
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.
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