PDQ Matching

Patient Demographics Matching

Applies to PDQ, PDQv3, PDQm, XCPD

The Patient Demographics Supplier provides a service to the Patient Demographics Consumer in finding a "best fit" list of possible patient identities that match the demographics information contained in the query parameters. The IHE technical framework does not prescribe what the "best fit" means, it states "The Supplier shall return at least all exact matches to the query parameters sent by the Consumer; IHE does not further specify matching requirements."

On the surface, the minimal requirement may seem to indicate that the Patient demographics supplier can be implemented as a simple front end to a SELECT ... FROM ... WHERE param1=p1Val AND param2=p2Val AND ... SQL query. If that were the case, however, there would be no need to create a profile describing such a service. The IHE Technical framework also states: "The mechanics of the matching algorithms used are internal to the Patient Demographics Supplier Actor and are outside of the scope of this framework.". The purpose of the non-prescriptive language is to allow service providers (i.e. implementers of the Patient Demographics Supplier actor or its equivalents in the other related profiles) to compete on their capabilities to present the best possible list of potential matches given the supplied parameters.

Below is a non-exhaustive list of implementation considerations to be taken into account when implementing a Patient Demographics Supplier.

Accommodate format differences

In many cases, the equivalent demographics information may be presented differently in the Patient Demographics Consumer system, and in the Patient Demographics Supplier system. It is hard to argue that the addresses 1278 Main St. and 1278 Main Street do not constitute "exact match" as intended by the profile. The ITI Technical Framework somewhat addresses this as follows: Handling of phonetic issues, alternate spellings, upper and lower case, wildcards, accented characters, etc., if deemed appropriate, is to be supported by the Patient Demographics Supplier rather than by the Patient Demographics Consumer.

Additional information is not the same as mismatch

It is possible that the Patient Demographics Consumer may have more data than the Patient Demographics supplier. In general, the Patient Demographics Consumer will want to include as much detailed data as possible in the query, so that the responses they receive are as accurate as possible. In addition, some Patient Demographics Consumers may be working with multiple Patient Demographics Suppliers, and having these Suppliers handle additional information properly allows the Consumer to use the same query for all of their partners. Not considering the additional information a mismatch follows the Robustness Principle of the Internet (RFC 1122) in ensuring interoperability.

For example, the two addresses

Patient Demographics Consumer:

820 Jorie Boulevard Oak Brook, IL 60523-2251 USA

and

Patient Demographics Supplier: 820 Jorie Boulevard

Oak Brook, IL 60523

are equivalent, and only differ by the presence of the "+4" in the ZIP, and the country part of the address. Considering this a mismatch could be argued to follow the literal meaning of "exact match" but in reality it is contrary to the intent of the profile, as it doesn't promote interoperability.

Another piece of information that can be present as a query parameter and not known to the Demographics supplier is a patient identifier from an unrelated patient identity domain. Again, considering the presence of this information in the query as a mismatch is not improving interoperability. (Note: in XCPD adding the patient identifier known by the Consumer as a query parameter has additional purpose and meaning).

Error Response for Case 3 in the PDQ profile

IHE PDQ Profile requires that the Patient Demographics Supplier returns "AE" in MSA-1 and error code "204" in ERR-3 as an application error, when a patient identification domain in QRD-8 in a PDQ request message is unknown (see Case 3 in both 3.21.4.2.2.7 and 3.22.4.2.2.7).

HL7 Table 0357 (see 2.15.5.3, HL7 Standard 2.5) indicates, however, error 204 (Unknown Key Identifier) as "Rejection" in the Comment column of the table, which may imply "AR" (application rejection) code in MSA-1.

On the other hand, HL7 Standard 2.5 Section 2.9.2.2 describes the conditions of returning "AE":

• fail to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.). For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementers must decide on an application-specific basis whether the message should be automatically sent again. The response message contains a value of AR in MSA-1-acknowledgment code.

This seems aligned with the IHE requirement, to treat "unknown key identifier" as an application error rather than application rejection. To improve interoperability, it is recommended that a Patient Demographics Supplier implementation be prepared to handle both "AE" and "AR" code values in MSA-1 for error "204".