Patient Demographics Query for mobile (PDQm)
2.4.0 - Trial-Implementation
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
The Patient Demographics Query for Mobile (PDQm) Profile defines a lightweight RESTful interface to a patient demographics supplier leveraging technologies readily available to mobile applications and lightweight browser based applications.
The functionality is similar to the PDQ and PDQv3 Profiles. The differences are driven by the use of HL7 FHIR. The profile leverages HTTP transport, and the JavaScript Object Notation (JSON), Simple-XML, and Representational State Transfer (REST). The payload format is defined by the HL7 FHIR standard.
The following list provides a few examples of how PDQm might be leveraged by implementers:
This implementation guide is intended to be fully compliant with the HL7 FHIR specification, providing only use-case driven constraints to aid with interoperability, deterministic results, and compatibility with existing PDQ and PDQv3 Profiles.
Figure 1:38.1-1 shows the actors directly involved in the Patient Demographics Query for Mobile Profile and the relevant transactions between them. Note that the actors in this profile are the same as the actors defined in the PDQ Profile (ITI TF-1: 8.1).
Figure 1:38.1-1: PQDm Actor Diagram
Table 1:38.1-1: PDQm; Profile - Actors and Transactions
Actors | Transactions | Initiator or Responder | Optionality | Reference |
---|---|---|---|---|
Patient Demographics Consumer | Mobile Patient Demographics Query [ITI-78] | Initiator | R | ITI TF-2: 3.78 |
Patient Demographics Supplier | Mobile Patient Demographics Query [ITI-78] | Responder | R | ITI TF-2: 3.78 |
Note 1: The Mobile Patient Demographics Query [ITI-78] transaction corresponds to the transactions used in the PDQ and PDQv3 Profiles and provides similar functionality. There is no transaction which corresponds to the Patient Demographics and Visit Query [ITI-22]. See ITI TF-2: Appendix M.4 for a mapping of query fields for PDQ, PDQv3, and PDQm transactions.
No additional requirements.
The Patient Demographics Supplier shall publish an instance
CapabilityStatement at the metadata endpoint following ITI Appendix Z.3 using the FHIR capabilities interaction.
All supported search parameters and search methods (GET, POST) shall be specified. The search parameters defined in [ITI-78] shall be supported, other parameters may be supported.
This capabilities response will typically include all of the capabilities inclusive of all grouped actors and additional functionality.
The transactions in this profile are summarized in the sections below.
Mobile Patient Demographics Query is used by the Patient Demographics Consumer to solicit information about patients whose demographics data match data provided in the query parameters on the request message. The request is received by the Patient Demographics Supplier. The Patient Demographics Supplier processes the request and returns a response in the form of demographics information for the matching patients.
For more details see the detailed transaction description.
Options that may be selected for each actor in this profile, if any, are listed in Table 1:38.2-1. Dependencies between options when applicable are specified in notes.
Table 1:38.2-1: Patient Demographics Query for Mobile - Actors and Options
Actor | Option Name | Reference |
---|---|---|
Patient Demographics Consumer | none | - |
Patient Demographics Supplier | none | - |
No required groupings.
The Security Considerations page describes some optional groupings that may be of interest for security considerations.
Cross-Profile Considerations describes some optional groupings in other related profiles.
The PDQm Profile supports all of the use cases of PDQ while keeping the technology as lightweight as possible. Example uses include:
In this use case an admitted patient is assigned a bed and may not be able to provide positive ID information. The nurse uses the PDQm Profile to establish patient context.
An admitted patient is assigned to a bed. The patient may or may not be able to provide positive ID information. The nurse needs to enter patient identity information into some bedside equipment to establish the relationship of the assigned bed to the patient. The equipment issues a query for a patient pick list to a patient demographics supplier that provides data for a patient pick list. Search criteria entered by the nurse might include one or more of the following:
The system returns a list of patients showing Patient ID, full name, age, sex and displays the list to the nurse. The nurse then selects the appropriate record to enter the patient identity information into the bedside equipment application.
In this use case a patient visits a physician for the first time. The physician system will use the PDQm Profile to import demographics information into the local application.
A patient visits a physician office for the first time. The nurse needs to register the patient; in doing so, it is desired to record the patient’s demographic data in the practice management information system (PMIS). The physician office is connected to a hospital enterprise’s central patient registry. The nurse issues a patient query request to the central patient registry acting as a Patient Demographics Supplier, with some basic patient demographics data as search criteria. In the returned patient list, she picks an appropriate record for the patient, including the hospital’s Patient ID, to enter into the PMIS. (Note the PMIS uses a different Patient ID domain than that of the central patient registry.)
In this use case a lab system obtains identities from multiple Patient ID domains for the purpose of reporting results.
A lab technician enters some basic demographics data (e.g., patient name) into a lab application to query a patient demographics supplier to identify a patient for his lab exams. As the application also needs the patient identifier in another Patient ID Domain in the enterprise for results delivery, the application is configured to query for Patient IDs from other domains in the query response.
Figure 1:38.4.3-1: Basic Process Flow in PDQm Profile
Actors are expected to follow the recommendations and requirements found in ITI TF-2: Appendix Z.8 “Mobile Security Considerations”.
Actors have requirements in the [ITI-78] Security Considerations Section including requirements for Audit Logging when grouped with ATNA Secure Node or Secure Application, and Authentication and Authorization when grouped with Internet User Authorization (IUA) Actors.
When the Patient Demographics Supplier is grouped with actors in other IHE profiles that perform patient information reconciliation activities (e.g., the ADT Actor in the IHE Radiology Scheduled Workflow.b Profile), the Patient Demographics Supplier may use the updated information to respond to PDQm Queries. In addition, the Patient Demographics Query for Mobile Profile may play an integral workflow role in conjunction with other IHE profiles.
Those systems that manage patient demographics could implement the Patient Demographics Supplier in all three profiles: PDQ, PDQv3, and PDQm. In this way the Patient Demographics Consumer can choose the technology stack that best fits. ITI TF-2: Appendix M.4 provides additional details about Patient Demographics Query Profiles and their relationship with one another.
The Patient Demographics Supplier may act as a proxy to an existing PDQ or PDQv3 environment as shown in Figure 1:38.6-1.
Figure 1:38.6-1: Implementing PDQm as a Gateway