This document provides an agenda and overview of key topics regarding interoperability between immunization information systems (IIS). It discusses key principles of interoperability including defining interoperability and conformance, and principles such as standards not being locally interpreted and focusing on interoperability over conformance. It also describes an interoperability exercise and provides an update on interoperability testing between IIS systems.

1. AIRA Update on
Interoperability
STC UGM 2016
Scottsdale Arizona
June 15, 2016

2. Agenda
• Key Principles
• Interoperability Exercise
• Local Requirements
• Interoperability Testing Update

3. Key Principles of
Interoperability

4. Key Concepts
• Interoperability
Definition from HIMSS:
Interoperability describes the extent to which systems and devices
can exchange data, and interpret that shared data. For two
systems to be interoperable, they must be able to exchange data
and subsequently present that data such that it can be understood
by a user.
• Conformance
Definition of Conformance Testing from NIST:
Conformance testing is testing to see if an implementation meets
the requirements of a standard or specification.

5. Key Principles
1. Standards should not be locally interpreted

6. Key Principles
• Examples of local interpretations that change the
standard meaning:
– Using Administered-at Location (RXA-11.4) to indicate the facility
where the vaccination was recorded for historical immunizations
– Using Lot Number (RXA-15) to:
• Indicate flag vaccine funding source
• Store additional information, comments or details
– Not allowing Financial Eligibility Code “V01: Not VFC eligible” to
be reported for adults

7. Key Principles
2. Conformance to standards should be testable
IG 2.3.1 HL7 2.5 IG Release 1.5
Does your system meet these standards?

8. Key Principles
• Written standards and conformance testing
processes must be developed in tandem
– No normative standard should be approved without a
corresponding process to determine whether an
interface meets the standard
• AIRA is working with NIST to make this a reality
– Implementation Guide Authoring Management Tool (IGAMT)
– NIST testing framework
– EHR Certification Testing
– IIS Assessment

9. Key Principles
3. Interoperability should be a science not an art
Photo by Cedward Brice, see https://commons.wikimedia.org/wiki/File:Mill_Ave._Bridge,_Tempe.jpg

10. Future
Key Principles
• Interoperability as a science is still maturing
• Various initiatives are decreasing variability:
Present
• HL7 2.3.1
• IG 2.3.1
• HL7 2.9
• IG balloted by HL7
• NIST EHR Certification
• IIS Assessment
• Implementation Guide Authoring
• Functional Standards
• HL7 2.5.1
• IG r1.5
• NIST EHR 2015
Certification
Past

11. Key Principles
4. Focus on interoperability not conformance

12. Key Principles
• These organizations are working to establish standards:
– HL7: Create standards
– CDC: Foster data exchange
– NIST: Verify systems meets the standards
• Only IIS can:
– Collect complete and accurate immunization histories
– Manage inventory and track funded vaccines
– Ensure that data quality problems are prevented or detected
early and fixed

13. Insuring Interoperability
• NIST certifies EHR system conformance:
– Confirms software is able to perform in a standards way
– How EHR and IIS actually operate in production is out-of-scope
• IIS must focus on interoperability
• Conformance is a tool IIS can use to help
• But a conformant interfaces can still fail to work
• And working interfaces can be non-conformant

14. Interoperability
Exercise

15. Usage: R
• Examples
– Patient Name (PID-5)
– Date/Time Start of Administration (RXA-3)

16. Usage: RE
• Examples:
– Patient Address (PID-11)
– Completion Status (RXA-20)

17. Usage: O
• Examples
– Primary Language (PID-15)
– Administered Strength (RXA-12)

18. Usage: X
• Example
– SSN Number Patient (PID-19)

19. Usage: C(a/b)
• Example:
– Birth Order (PID-25) is C(RE/O)
• RE if Multiple Birth Indicator (PID-24) is Yes.

20. Exercise
• Review message on Side A
– Identify as many conformance issues as you can:
• Focus on MSH, PID, and RXA segments
• OBX segments were removed for brevity, ignore this issue
• Review message on Side B
– This message meets current NIST standards for MU 2014
• Do not review it for technical issues
– Examine the message for data quality issues
• Contrast Side A and Side B
– Can conformance checking ensure high quality data?
– Can non-conformant messages transmit high quality data?

21. Find Problems – A
MSH|^~&|Test EHR Application|X68||NIST Test Iz Reg|20141201082201|
|VXU^V04^VXU_V04|NIST-IZ-001.00|P|2.5.1
PID|||D26376273^^^NIST MPI^MR|D26376273|Snow^Madelynn^Ainsley|Lam^Morgan
|20070706|F||2076-8^Native Hawaiian or Other Pacific Islander^CDCREC
|32 Prescott Street Ave^^Warwick^MA^02452^USA^L|
|^PRN^PH^^^657^4058563|||||||||2186-5^non Hispanic or Latino^CDCREC
PD1|||||||||||02^Reminder/Recall - any method^HL70215|||||A|20120701
|20120701
NK1|1|Lam^Morgan^^^^^L|MTH^Mother^HL70063
|32 Prescott Street Ave^^Warwick^MA^02452^USA^L|^PRN^PH^^^657^4058563
ORC|RE||IZ-783274^NDA|||||||I-23432^Burden^Donna^A^^^^^NIST-AA-1|
|57422^RADON^NICHOLAS^^^^^^NIST-AA-1^L
RXA|1|0|20120814|
|140^Influenza, seasonal, injectable, preservative free|0.5
|ML^MilliLiter [SI Volume Units]^UCUM|
|00^New immunization record^NIP001|7832-1^Lemon^Mike^A^^^^^NIST-AA-1
|^^^X68||||Z0860BB|20121104|CSL^CSL Behring^MVX|||CP|A

22. Find Problems – B
MSH|^~&|Test EHR Application|X68||NIST Test Iz Reg|20141201082201|
|VXU^V04^VXU_V04|NIST-IZ-001.00|P|2.5.1|||AL|ER
PID|1||D26376273^^^NIST MPI^MR||Snow^Horatio^Middle^^^^L|Snow^Horatio
|20031107|M||2076-8^Native Hawaiian or Other Pacific Islander^CDCREC
|455 N Galvin Pkwy^^Phoenix^AZ^85008^USA^L|
|^PRN^PH^^^657^5558563|||||||||2186-5^non Hispanic or Latino^CDCREC
PD1|||||||||||02^Reminder/Recall - any method^HL70215|||||A|20120701
|20120701
NK1|1|Snow^Horatio^Middle^^^^L|MTH^Mother^HL70063
|500 E Veterans Way^^Tempe^AZ^85287^USA^L|^PRN^PH^^^657^5558563
ORC|RE||IZ-783274^NDA|||||||I-23432^Burden^Donna^A^^^^^NIST-AA-1|
|57422^RADON^NICHOLAS^^^^^^NIST-AA-1^L
RXA|0|1|20120814|
|01^DTP^CVX|5.0
|mL^MilliLiter [SI Volume Units]^UCUM|
|00^New immunization record^NIP001|7832-1^Lemon^Mike^A^^^^^NIST-AA-1
|^^^X68||||LOTNUMUNKNOWN|20121104
|BAY^Emergent BioDefense Operations Lansing^MVX|||CP|A

23. Pop Quiz
1. Can the IIS accept into production a message that does
not conform to CDC or HL7 standards?
2. If a required (R) field is empty, may an IIS still process
and store the data in the rest of the message?
3. If a not supported (X) field is valued,
must the IIS reject the message
entirely?
4. Can an IIS pick and choose
what data gets accepted
and what does not?

24. Adapting to Local
Requirements
Guidance and Practical Advice on Aligning to the CDC
Immunization Guide

25. Constraint Model
• A profile constrains a standard for a particular use
HL7 2.5 IG r1.5 STC Guide IIS Guide
Pine View
Pediatrics
to State IIS

26. Constraining Usage
National Profile IIS Profile
R : Required R : Required
RE : Required but may be empty R : Required
RE : Required but may be empty
O : Optional R : Required
RE : Required but may be empty
O : Optional
X : Not supported
X : Not supported X : Not supported

27. Proper Use of Required
• Use required to ensure proper structure
• Do not move fields to required to improve data quality
• Changing an RE to R can have un-intended
consequences
• Examples of un-intended consequences when health
industry marked certain fields as required:
– Patient Name (PID-5): Not all patients have names
– Administered Amount (RXA-6): May not be known
• It is better to improve data quality by creating auxiliary
processes for assessing data quality

28. Local Guides
• Keep local implementation guide short
– Less than 25 pages is ideal
– Consider making a 1-2 page “delta guide” to show difference
between CDC IG and Local IIS IG
• Document how errors and warnings are messaged and
handled by the IIS
• Follow HL7 constraining rules
– R and X usage can not be changed
– RE can go to R
– O can be changed to R, RE or X
• Prepare for transition to the new NIST Immunization
Authoring Guide Management Tool

29. Interoperability
Testing Project
Update of Progress Made

30. Big Picture
• Discovery Phase
– IIS Interoperability Status Check Project
• Connect to IIS test systems
• Submit a thousand VXU and QBP messages every month
– Aggregate Analysis Reporting Tool (AART)
• Collects information from all tests performed
• Create AART Report for IIS to see the results of testing
• Assessment Phase
– Measurement for Assessment and Certification Advisory Work
Group (MACAW) was convened this spring
– MACAW will lead community to set assessment measures
– Certification will build on assessment work, but certification is still
on the far horizon and details are yet to be determined

31. Participation
• 52 IIS Programs and 2
Vendors
• Of these
– 43 Connected
– 11 Manual Reporters
• 6 are submitting
manual tests
• 4 IIS Have Yet To
Participate
– Some of these are
migrating to new
systems
Last Updated: May 31, 2016
What Are We Today?

32. NIST
• AIRA Discovery testing depends on NIST resources
• Conformance of Message Format testing
– ACK format: According to
IG r1.5 and AIRA 2015
ACK Guidance
– RSP format: According to
IG r1.5
• CDC WSDL Transport
Testing
http://hl7v2-iz-testing.nist.gov/mu-immunization/

33. What Are We Testing?
Update (VXU/ACK)
• Accept r1.4 and r1.5
VXU updates
• ACK Conformance
• Coded Values
• Tolerance
• EHR Examples
• Performance
Query (QBP/RSP)
• Accept r1.5 QBP (Z34 &
Z44) queries
• RSP Conformance
• Forecasting Support
• Deduplication Support
• CDC WSDL Support

34. What do IIS Need to Do?
• Review your AART Report
– Register for access here: http://ois-pt.org/dqacm/home
– Provide feedback on improvements needed
• Join HL7 Immunization User Group
– Meetings are every 2nd Thursday at 2pm Eastern Time
– Testing updates and guidance are discussed on this monthly call

35. Questions?