AIRA Interoperability Project IntroPresentation for Conformance & Guidance for Implementation/Testing

Agenda

Project Introduction Background on IIS Guides

American Immunization Registry Association Promoting the development, implementation and interoperability of

Immunization Information Systems Members include IIS staff working in health departments, partner

organizations such as software vendors and other with an interest in IIS 65 Organization Members 250 Individual Members

Immunization Information Systems Confidential, population-based, computerized databases that record all

immunization doses administered by participating providers to persons residing within a given geopolitical area

Introduction to AIRA Project Team

Mary Beth Kurilo, Policy and Planning Director Nichole Lambrecht, Sr. Project Manager Nathan Bunker, Sr. Technical Project Manager Eric Larson, Sr. Technical Project Manager

Standards Development

• Convene SMEs or Stakeholders to assess current practice or challenge, ID gaps, develop, refine standards

Evaluations • Measure adoption of standards

Joint Development

• Coordinate and facilitate collaborative development of specific tools/technologies/enhancements

Repository• Establish and maintain a repository for

apps, source code, etc. that can be accessed and used by IIS Community

Training/TA • Provide communications, training, collaborative services as needed

AIRA Standards Cooperative Agreement, 2014-2018

Clear standards Tool(s) to

measure alignment with

standards

Measuring Adoption of Standards:We Need…

Interoperability Discovery/Testing: What Are We Testing? HL7 v2: Vaccination Update Message (VXU)

EHR systems are required to support to be certified Supports reporting vaccinations to an IIS

Transport: CDC SOAP WSDL CDC and AIRA members created a simple SOAP web service standard IIS could use

to accept VXU and QBP messages CDC recommends that IIS adopt this standard

HL7 v2: Query by Parameter (QBP) EHR systems will be required to support in the future Allows for querying a specific patient’s vaccination history from IIS Will be looking more at this later this year

Working with NIST

AIRA staff is working closely with NIST staff Rob Snelick Michael Indovina

NIST asks AIRA for feedback on the immunization tools it creates EHR Certification Tool

NIST is creating tools that AIRA will be using in the future: Immunization Guide Authoring Management Tool (IGAMT) Test Case Authoring Management Tool (TCAMT) Software for testing transport (CDC WSDL)

Interoperability Discovery/Testing: What Are We Testing?

Phase I Evaluating 2015 Acceptance of 7

NIST Test Cases

Phase II NIST Transport Compatibility EHR Example Acceptance Recognize Valid Codes Quality Issues Local IIS Requirements Support Clinical Decisions Tolerance Tests Performance ACK Conformance Coming Soon - QBP

Interoperability Discovery/Testing: Where Are We?

Participation 46 IIS Programs 2 Vendors Of these

21 Connected 10 Waiting on Credentials 1 Connection Problem 4 In Queue for Connection

~12 Need to Participate

Last Updated: August 27, 2015

Interoperability Discovery/Testing: What Are We Learning? Of 21 Connected Sites

~6 Support the CDC WSDL 3 Support the Standard ACK

Most IIS have their own local implementation guide which has proven to be very time consuming to review and analyze. This translates to time spent for each EHR to interoperate with each IIS.

IIS Guides Background

CDC and AIRA jointly maintain the CDC Implementation Guide HL7 v2.5.1 Implementation Guide for Immunization Messaging

Release 1.5 – November 5, 2014 Release 1.5 addendum – Just released, clarifications needed for Meaningful Use regs

Modifications and new releases to the guide Managed and approved by the AIRA Standards and Interoperability Steering

Committee (SISC) CDC has requested that IIS create local guides

IIS have been asked to remain conformant to the CDC guide

Constraining Rules IIS have been following: Required in (R) CDC Guide

Must be required (R) in the local guide Required, but may be empty (RE) in CDC Guide

May be constrained to R, or left a RE Optional (O) in the CDC guide

May be constrained to R, RE, or X, or left as O Not Supported (X) in the CDC guide

Must be (X) in the local guide

Consequence of this guidance

IIS often indicate a field is required (R) but still not read it PID-1 Set-ID - ID: Essentially useful field, many IIS essentially ignore this field MSH-15 Accept Acknowledgement Type: IIS may read it but many do not require

it and/or will not change behavior based on what is states Some IIS indicate a field is RE but are not processing the data

To claim conformance to that national standard, or The IIS plans to implement in the near future

Some IIS indicate a filed is O but are processing the data Many IIS indicate X but do not raise an error when it is populated

XTN-1: Use has been deprecated but many IIS will ignore it and some will even still process the data in this field

Missing Concepts - Implementation Status Indifferent (I): system does not read or respond to this field in any way Supported (S): system uses this field as defined in the implementation

guide Deprecated (D): Supported, but only for backwards compatibility (such

as phone number in XTN-1) Future (F): Will be supported (IIS intends to support field in the future,

trading partners should send data now in anticipation that IIS will be able to accept it later.

Missing Concepts –Enforcement Status Error (E): Empty R’s and valued X’s will result in serious error, full or

partial rejection of message, important data was lost, sending system will be notified, sending system should notify users of the problem, corrections will need to be made and messages resent to resolve problem

Warning (W): Error generated but data was still processed, some data may have been lost, sending system should be notified with warnings, sending system should provide mechanism for users to review these warnings, problem did not prevent important data from being received and processed

Not Enforced (NE): Empty R’s and valued X’s will generate no error, problem is ignored

Comments from CGIT

Implementable/implemented profiles do not contain options. Everything is specified. This does not mean that it cannot be constrained further. This is possible. It should not be mixed up with what the interface is doing. We need to keep

that separated. it is important that a profile for implemented interfaces reflect what was

implemented, even if what was implemented in not compliant with HL7 rules.

Comments from CGIT about Usage X

We should correct the expectations. The current statement "may raise an error/warning" is indeed misleading. If an interface ignores an element, than it does not take care of it. This

normally includes even the existence of data in the received message. Proposal: eliminate the option to raise an error/warning

About NULL in HL7: The immunization space does not use NULL, so we only have questions about when a field is R and it is empty.

In favor of non-conformant interfaces with a good documentation instead of all those conformant ones without any specification.