Skip to end of metadata
Go to start of metadata

Date: Feb 05 2020

Quarter: Q1

Informal working group (no decisions made)

Attendees: Alean Kirnak, Craig Newman, Danny Wise, Heather Patrick

Discussion items

Immunization messaging

Caution with respect to adding new IIS and EHR requirements

When adding/clarifying ADT workflows and message specifications, we need to be cautious about adding new requirements, and make sure we frame new guidance as clearly optional.  It can happen that anything in an IG is fair game for certification.  Need to include appropriate wording to avoid inadvertently creating new certification requirements unintentionally.

Use Case 2 changes:  By removing the “RXA-less” VXU from the IG, the 2.8.2 Guide forces patient record submissions to be done via ADTs instead

Past IG versions have always included the ability to submit a VXU without immunizations.  This capability is removed in 2.8.2.  There are many use cases for submitting just a patient record to an IIS, and many incoming message streams in live implementations include them.  This adds to the requirement to do a great job defining the use cases and detailed specifications for the future use of ADTs.

In the first draft, the ADT specifications were kept simple by, for example, confining the trigger events allowed to just A31.  It was pointed out, however, that this would place a new requirement on EHRs to map their existing ADTs as A31s before submitting to an IIS.  A better approach would be for IISs to accept a set of trigger events that EHRs and other systems already have in place.  For IIS purposes, ADTs with a number of trigger events provide comparable format and semantics.  Most IISs do not currently use ADTs, and may not even have the ability to accept them; therefore, IIS modification would be required in any event.  Adding a set of trigger events at the time of modification is not significantly more work than accepting just one.  But requiring EHRs to map their current ADTs to something special for IISs would be a significant amount of new work compared to just allowing them to submit what they already have.

EHRs currently send all kinds of ADTs between systems internally, and externally, to Health Information Exchanges (HIEs) and other systems.  To HIEs, the format tends to adhere to the IHE PIX/PDQ format.  HIEs require ADTs because HIEs commonly use the XDS protocol, which requires an identifier to be supplied with a query – XDS has no built-in way to query with just demographics.  Therefore, EHRs commonly send ADTs in the PIX format to HIEs.

EHRs also typically have two different outgoing message streams for IISs and HIEs:  VXU/QBP messages to IIS and ADTs to HIEs.  It would be a significant new requirement for EHRs to have to send ADTs directly to IISs.  A better opportunity may exist where EHRs send the ADTs to HIEs.  In jurisdictions that have both an IIS and an HIE, typically EHRs route IIS messages through the HIE.  IN these cases, EHRs would already be sending ADTs to the same destination as the IIS messages; routing to IISs additionally may not impose any burdensome new requirement.  More data on which HIEs route to IISs is needed; parties on the call will follow up by researching.

Use Case 3 changes:  Separate demographic query from identifier query

As currently written, Use Case 3 includes both a demographic query and an identifier query and does not separate them.  To enable identifier queries and optimal use of ADTs, it is necessary to separate the two use cases.  A demographic query consists in querying by demographics only – name, DOB and the like – upon which the receiving system performs matching activities and returns 0 or more “candidate” matches, each candidate match including an identifier. 

Upon user review, a second query supplies said identifier, which results in a single returned matching record with near-100% confidence.  This second part is the equivalent of the identifier query.  Thus, the two-step query really consists in a demographic query followed by an identifier query. In another instance, where a patient record has already been submitted, the identifier query may be used by itself.

PIX/PDQ Correspondence

The PIX transaction Patient Identity Feed and the PAM transaction Patient Identity Management ITI-30, correspond to the submission of a patient record (Use Case 2 of the present 2.8.2 IG). 

The PDQ transaction Patient Demographic Query ITI-21 corresponds to the demographic query portion of the current 2.8.2 IG Use Case 3.

Will restoring the “two-step query” take care of the identifier query requirement?

Part of the business requirement for identifier queries is that single responses to demographic queries from EHRs return the wrong patient with enough frequency to create doubt in users.   An inadvertent side-effect of Meaningful Use certification was that the “two-step” query workflow was eliminated under IG v1.5 due to the certification requirement to return a vaccine history and recommendation.  This has already been fixed in 2.8.2.  Will the “two-step” query fix this issue by restoring the opportunity for human review of the returned record before proceeding further?

While restoring the “two-step query” will help in verifying query results, there are numerous reasons for submitting ADTs.

  1. Submitted patient records normally contain more demographics than search criteria.  While some EHRs may populate search criteria with all demographics they have for a patient, this is the exception and not the rule.  The rules is that users try to minimize their data entry and enter only necessary search criteria.  This means that the matching performed by the IIS upon receipt of a demographic query is necessarily less accurate than upon receipt of a patient record.
  2. Some jurisdictions are concerned about privacy when returning a “pick list” of candidate matches.  Such pick lists may expose patient data to providers who don’t have those patients.  If the provider sends ADTs, and follows with identifier queries, it is guaranteed that they will only receive data for patients they see.
  3. An identifier query is more efficient than a demographic query in addition to being more accurate.
  4. Most modern standards paradigms separate identity resolution from querying for clinical information in the interest of modularization and separation of concerns.  XDS has already been mentioned; HL7 V3 and FHIR are other examples. 
  5. User workflow is more efficient when the two-step query process is reduced to an identifier query.

Therefore, while restoring the “two step query” may be helpful, it will not cover all the reasons for enhancing the mechanism by which 2.8.2 specifies sending a patient record to an IIS.

Filtering ADTs

While not discussed this morning, the concern about large numbers of ADTs has been addressed in the San Diego field implementation.  San Diego implemented a filter that winnows the incoming ADT stream prior to message processing.  This proved to reduce the volume by 80-95% and greatly improve performance.


The IGAMT tool was used to produce the current 2.8.2 draft.  Rob Snelick introduced PH to the tool Tuesday in Sydney; the plan is to use the tool to create a draft of an updated guide which can be circulated to stakeholders for vetting.

Takeaways and Action Items

  1. A GAP analysis between the current IZ23 and IZ24 profiles (current 2.8.2 ADT constraints) and what is normally included in PIX and PDQ is needed.
  2. High level text discussion and use case specification needs to be enhanced to sketch out possible ADT and identifier query scenarios.
  3. An inventory of HIEs through which IIS data passes is needed.
IZ Activity Model

Sydney 2019.png

CCD example.docx

SDIR Identifier Matching specsSDIR MatchMerge Interface Specifications Ver 4.3 for Sydney.docx

Action items