Auth+XDS-PID+Research

=Difficulties Surrounding the Implementation of $XDSUnknownPatientID= As a general rule, the OASIS specifications which underlie the NHIN prescribe that unsuccessful queries or requests return a blank list, as opposed to an error message which describes the reason for the failure. This is primarily a mitigation against the risk of fishing attacks. The trade off is that an end user is unable to determine if a blank list means their request was bad or rejected or if the query was good, but there are in fact no documents available.
 * Background:**

In the case of Query for Documents (QfD), the specification defines an error code, XDSUnknownPatientID. The purpose of this error code is to inform initiating nodes that the PID used in their query is invalid. The reason this error code was included was to accommodate the chance that a PID may become 'stale' in the time which elapses between a PD request and a Query for Documents request. The VA in particular plans to pre-retrieve PIDs from other NHIOs and use those PIDs in subsequent QfD requests which may occur months later. They requested this error code, which they could use as a trigger to re-discover and obtain a 'fresh' PID.

Definitions: Invalid PID - One which is completely unknown Stale PID - One which one applied to a specific patient, but has since been retired

Implementers (CONNECT and Kaiser) have raised two issues: > > Broadly speaking, CONNECT presents the PID included in a QfD request to the Policy Decision Point (PDP), seeking an Approve or Deny to use that PID to obtain any and all information associated with the patient (including PID validity history). If the PID is invalid for whatever reason, it will not be recognized by the PDP, a Deny will be returned to the Gateway, which will return an empty list. In order to accommodate this (or any similar) error code, Implementers would be required to maintain a list of PIDs which are not currently valid, but that were previously valid and make that list accessible to the PDP. The PDP would have to be configured to return an Approve to the Gateway for whatever further processing would be required to return the error code. > > Kaiser dealt with the possibility of 'stale' PIDs by configuring their Gateway to re-discover when a blank list is returned. They only make a single attempt to rediscover so as not to get caught in a loop.
 * Issue/Question:**
 * 1) The language used in the spec to explain the condition for which this error code should be returned is unclear.
 * 2) The requirements introduced by the specification of this error code extend well beyond the gateway and may even be incompatible with current NHIN Gateway design.

Current NHIN Gateway implementers (CONNECT and Kaiser, we are still checking on MedPlus and Medicity) have not been able to meet the requirement to return this error code for stale PIDs, as they cannot distinguish between stale and invalid in thier interactions with the PDP. Options and alternatives for discussion include:
 * Current Discussion:**


 * 1) Advise implementers of the risk of stale PIDs and guide them to Patient Discover in associuation with or in (antiicaption of) a patient encounter or other reason to QfD.
 * 2) Deal with the stale PID risk on the Initiating side. Follow Kaiser's example and configure to re-discover once if a blank list is returned. In thier opinion, this is a far simpler mitigation from an implementation approach.
 * 3) Blank lists vs error codes in general - Should end users have an expectation to be able to distinguish between aquery which could not be honored and one that is processed and actualy indicates that no docs are avaialbel? Specific error codes (incorrent role or purpose of use) are probably not a good idea. How about 'Query Not Allowed' or similar?