Date: Feb 05 2020
Informal working group (no decisions made)
Attendees: Alean Kirnak, Craig Newman, Danny Wise, Heather Patrick
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.
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.
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.
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
|IZ Activity Model|
|SDIR Identifier Matching specs||SDIR MatchMerge Interface Specifications Ver 4.3 for Sydney.docx|