Difference between revisions of "PDQ Matching"
| Line 3: | Line 3: | ||
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.''" | 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 <code>SELECT ... FROM ... WHERE param1=p1Val AND param2=p2Val AND ... </code>. 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. | + | 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 <code>SELECT ... FROM ... WHERE param1=p1Val AND param2=p2Val AND ... </code> 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. | Below is a non-exhaustive list of implementation considerations to be taken into account when implementing a patient demographics supplier. | ||
===Accommodate Format Differences=== | ===Accommodate Format Differences=== | ||
| − | + | An obvious example | |
==Error Response for Case 3 in the PDQ profile== | ==Error Response for Case 3 in the PDQ profile== | ||
Revision as of 17:31, 10 February 2015
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
An obvious example
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".