Patient Demographics Query for mobile (PDQm)
2.4.0 - Trial-Implementation International flag

This page is part of the IHE Patient Demographics Query for Mobile (v2.4.0: Trial Implementation) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

PDQm Open and Closed issues

Significant changes from PDQm, Rev 2.2:

  • FHIR Implementation Guide instead of pdf - Rev. 2.2
  • Patient is now profiled to forbid modifier extensions
  • AuditEvent is fully profiled using structureDefinition with examples

Issues

IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues may be submitted to the Public Comment form.

As issues are submitted they will be managed on the PDQm GitHub Issues, where discussion and workarounds may be found. These issues, when critical, will be processed using the normal IHE Change Proposal management and balloting. It is important to note that as soon as a Change Proposal is approved, it carries the same weight as a published Implementation Guide (i.e., it is testable at an IHE Connectathon from the time it is approved, even if it will not be integrated until several months later).

Open Issues

These issues were known as part of the publication, and IHE invites comments.

  • PDQm_101: Are there some elements we can get global agreement should be marked as R2 (aka, Must-Support - required to be returned if known)?
  • PDQm_102: Normative vs Trial-Implementation - Currently the HL7 FHIR standard components used (e.g., Patient, Bundle, etc) in this profile are at Normative state. Some portions of PDQm are relying on STU content (such as query parameters, mothersMaidenName).
  • PDQm_103: PDQm has a small volume 1 content. Thus breaking each H2 out into independent html files makes it harder to address. We may choose to do similar to PIXm and have just one volume 1 content with deep links.
  • PDQm_issue_66: PDQm has allowed clients to use GET or POST search, and thus mandated that servers must support both GET and POST. The previous versions of PDQm had only mentioned GET search, but we learned that FHIR core mandated POST and does not allow us to not also mandate it. This leaves regions that want to use only one of these verbs for search seemingly forced to support both verbs for search. The current discussion in FHIR core offers that “support” could include implementing a “policy” that forces an http 405 response. This seems to be a workable solution, and the alternative would not be much different than this anyway.

Closed Issues

These issues have been decided and documented in the publication.

  • Upgraded to FHIR R4
  • Case 4, where one or more identifier domains are indicated by the client but are not authoritative by the server, has been extensively discussed. The conclusion is to stay with allowing a server to return 404 or 200, and to require an OperationOutcome to indicate a warning. There is concern that the clients may not notice that they did not get results for a domain they requested, the client must take the initiative to look for the OperationOutcome to determine if they got full authoritative results. This looking for an OperationOutcome should always be inspected to assure results are what was expected. As such we did update client requirements to explicitly look for patient safety reasons.
  • Removed the Pediatric Demographics Option as unnecessary and confusing. Most of the functionality needed for the use-case is natural part of the normal path of PDQm. The additional search parameters and extensions are allowed for those that need them. There has been little to no implementation of this option in the PDQ or PDQv3 environments.