AIRA Interoperability Project Intro Presentation 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,

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.