Unattributed Code Systems

Copyright Fragment

This fragment is available on download.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

Type Reference Content
web profiles.ihe.net Recommend ATNA , encouraged IHE-IUA or SMART-app-launch
web profiles.ihe.net Recommend ATNA , encouraged IHE-IUA or SMART-app-launch
web profiles.ihe.net
web profiles.ihe.net
web github.com Patient Demographics Query for Mobile (PDQm), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 3.1.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.PDQm/ and changes regularly. See the Directory of published versions
web www.ihe.net IG © 2020+ IHE IT Infrastructure Technical Committee . Package ihe.iti.pdqm#3.1.1-current based on FHIR 4.0.1 . Generated 2025-06-10
Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web github.com Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web www.ihe.net Links: Table of Contents | QA Report | New Issue | Issues Version History | CC0 | Propose a changeexternal
web profiles.ihe.net SHOULD use a security framework. Recommend ATNA , encouraged IHE-IUA or SMART-app-launch
web profiles.ihe.net SHOULD use a security framework. Recommend ATNA , encouraged IHE-IUA or SMART-app-launch
web profiles.ihe.net The FHIR standard provides encodings for responses as either XML or JSON. Patient Demographics Suppliers SHALL support both message encodings, whilst Patient Demographics Consumers SHALL support one and MAY support both. See ITI TF-2: Appendix Z.6 for details .
web profiles.ihe.net See ITI TF-2: Appendix Z.6 for more details on response format handling. See ITI TF-2: Appendix Z.7 for guidance for Access Denied.
web profiles.ihe.net See ITI TF-2: Appendix Z.6 for more details on response format handling. See ITI TF-2: Appendix Z.7 for guidance for Access Denied.
web profiles.ihe.net Please see ITI TF-2: Appendix Z.1 for details on the IHE guidelines for implementing FHIR bundles.
web profiles.ihe.net The Patient Demographics Match Transaction is a Query Information event as defined in Table 3.20.4.1.1.1-1 . The actors involved SHALL record audit events according to the following:
web profiles.ihe.net The Patient Demographics Consumer when grouped with ATNA Secure Node or Secure Application Actor SHALL be able to record an audit event consistent with the Patient Demographics Consumer AuditEvent . Audit Example for a PDQm Match transaction from consumer perspective .
web profiles.ihe.net The Patient Demographics Supplier when grouped with ATNA Secure Node or Secure Application Actor SHALL be able to record an audit consistent with the Patient Demographics Supplier AuditEvent . Audit Example for a PDQm Match transaction from supplier perspective .
web profiles.ihe.net The Internet User Authorization (IUA) Profile provides support for user authentication, app authentication, and authorization decisions. When PDQm actors are grouped with IUA actors there are additional security and privacy functionality enabled by this grouping. There are additional requirements and functionality enabled through scope definitions that are transaction-specific.
web profiles.ihe.net A Patient Demographics Consumer, when grouped with an IUA Authorization Client, SHALL use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Demographics Consumer to get corresponding identifiers with the Patient Demographics Match [ITI-119] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72].
web profiles.ihe.net A Patient Demographics Consumer, when grouped with an IUA Authorization Client, SHALL use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Demographics Consumer to get corresponding identifiers with the Patient Demographics Match [ITI-119] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72].
web profiles.ihe.net The Patient Demographics Supplier, when grouped with an IUA Resource Server, SHALL require Incorporate Access Token [ITI-72] in all Patient Demographics Match [ITI-119] transactions, SHALL enforce the authorization decision in the token, and MAY further enforce policies beyond those made by the Authorization Server such as consent or business rules.
web profiles.ihe.net The Patient Demographics Supplier, when grouped with an IUA Resource Server, SHALL require Incorporate Access Token [ITI-72] in all Patient Demographics Match [ITI-119] transactions, SHALL enforce the authorization decision in the token, and MAY further enforce policies beyond those made by the Authorization Server such as consent or business rules.
web profiles.ihe.net This parameter of type string, when supplied, represents the resource identifier for the Patient Resource being queried. See ITI TF-2: Appendix Z.2.3 for use of the string data type. Note: A search using _id is always an exact match search.
web profiles.ihe.net These parameters of type string , when supplied, specify the name of the person whose information is being queried. For this parameter the Patient Demographics Consumer MAY use either family name, given name or a combination of both names to filter by family, given or family and given names respectively. See ITI TF-2: Appendix Z.2.3 for use of the string data type.
web profiles.ihe.net This repeating parameter of type token , when supplied, specifies an identifier associated with the patient whose information is being queried (e.g., a local identifier, account identifier, etc.). See ITI TF-2: Appendix Z.2.2 for use of the token data type.
web profiles.ihe.net This parameter of type string , when supplied, specifies one or more address parts associated with the person whose information is being queried. For details on matching rules, see ITI TF-2: Appendix Z.2.3 .
web profiles.ihe.net This parameter of type token , when supplied, specifies the administrative gender of the person whose information is being queried. For this parameter item, a single administrative gender code from value set http://hl7.org/fhir/R4/valueset-administrative-gender.html SHALL be specified as the only value of the token. See ITI TF-2: Appendix Z.2.2 for use of the token data type.
web profiles.ihe.net The Patient Demographics Consumer SHALL populate the patient identity domain portion of the token with values described in ITI TF-2: Appendix E .
web profiles.ihe.net The Patient Demographics Supplier SHALL return all exact matches to the search parameters sent by the Patient Demographics Consumer; IHE does not further specify matching requirements. Additional details for handling query parameters are described in ITI TF-2: Appendix Z.2 .
web profiles.ihe.net The Mobile Patient Demographics Query Transaction is a Query Information event as defined in Table 3.20.4.1.1.1-1 . The actors involved SHALL record audit events according to the following:
web profiles.ihe.net The Patient Demographics Consumer when grouped with ATNA Secure Node or Secure Application Actor SHALL be able to record a Patient Demographics Consumer AuditEvent . Audit Example for a PDQm Query transaction from consumer perspective .
web profiles.ihe.net The Patient Demographics Supplier when grouped with ATNA Secure Node or Secure Application Actor SHALL be able to record a Patient Demographics Supplier AuditEvent . Audit Example for a PDQm Query transaction from supplier perspective .
web profiles.ihe.net A Patient Demographics Consumer, when grouped with an IUA Authorization Client, SHALL use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Demographics Consumer to get corresponding identifiers with the Mobile Patient Demographics Query [ITI-78] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72].
web profiles.ihe.net A Patient Demographics Consumer, when grouped with an IUA Authorization Client, SHALL use Get Access Token [ITI-71] to request the following scope from the IUA Authorization Server. This enables the Patient Demographics Consumer to get corresponding identifiers with the Mobile Patient Demographics Query [ITI-78] transaction with the authorizing token in the combined transaction Incorporate Access Token [ITI-72].
web profiles.ihe.net The Patient Demographics Supplier, when grouped with an IUA Resource Server, SHALL require Incorporate Access Token [ITI-72] in all Mobile Patient Demographics Query [ITI-78] transactions, SHALL enforce the authorization decision in the token, and MAY further enforce policies beyond those made by the Authorization Server such as consent or business rules.
web profiles.ihe.net The Patient Demographics Supplier, when grouped with an IUA Resource Server, SHALL require Incorporate Access Token [ITI-72] in all Mobile Patient Demographics Query [ITI-78] transactions, SHALL enforce the authorization decision in the token, and MAY further enforce policies beyond those made by the Authorization Server such as consent or business rules.
web en.wikipedia.org Both Bundle.link and Bundle.entry.link are defined to support providing additional context when Bundles are used (e.g. HATEOAS ).
web en.wikipedia.org Option 2 : Populate Patient.identifier.value with a Universally Unique Identifier , including the urn:uuid: prefix. In this case, the corresponding value for Patient.identifier.system SHALL be urn:ietf:rfc:3986 . The UUID SHOULD be persisted within the FHIR resource so that subsequent accesses return the same identifier, but it is not REQUIRED in environments where doing so is not possible.
web github.com The source code for this Implementation Guide can be found on IHE GitHub
web www.google.com Search this IG
web profiles.ihe.net IHE uses the normative words: “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” according to standards conventions .
web profiles.ihe.net PDQm uses Must Support in StructureDefinition profiles. This is equivalent to the IHE use of R2 as defined in Appendix Z .
web github.com Resolves PDQm_issue_90 .
web github.com Resolves PDQm_issue_86 .
web www.ihe.net FHIR Implementation Guide instead of PDF - Rev. 2.2
web github.com IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues can be submitted to the Public Comment Form .
web www.ihe.net IHE welcomes New Issues from the GitHub community. For those without GitHub access, issues can be submitted to the Public Comment Form .
web github.com As issues are submitted they will be managed on the PDQm GitHub Issues , where discussion and workarounds might 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).
web wiki.ihe.net As issues are submitted they will be managed on the PDQm GitHub Issues , where discussion and workarounds might 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).
web www.ihe.net As issues are submitted they will be managed on the PDQm GitHub Issues , where discussion and workarounds might 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).
web github.com 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.
web github.com PDQm_issue_92 : Currently we are mandating that Patient Demographics Suppliers support both ITI-78, with ITI-119 being OPTIONAL, while Patient Demographics Consumers have the option to choose to support either one or both transactions. Is requiring support for ITI-78 a problem for any Patient Demographics Suppliers?
web github.com PDQm_issue_101 : Currently the expected actions for ITI-78 and ITI-119 require that all Patient Resources returned by the Patient Demographics Supplier conform to the PDQm Patient Profile . Are these requirements reasonable? While Patient Demographics Consumers SHOULD be robust in handling non-conformant Resources in the response, the intent of this requirement is to require that any Resources produced by the Patient Demographics Supplier are reasonably interoperable. Furthermore, we have decided not to derive from IPA Patient at this time. It is unclear if HL7 intends for IPA to generically cover all use cases for Patient data, or if IPA is limited to use cases of Patients accessing their own data. Discussion on this matter can be reviewed on HL7’s FHIR Zulip Chat .
web github.com PDQm_issue_112 The onlyCertainMatches parameter MAY be optionally set to true to indicate that the Patient Demographics Consumer would only like matches returned when they are certain to be matches for the subject of the request. The Patient Demographics Consumer might want to use onlyCertainMatches to prevent multiple Patient Resources from being returned in the response. This is often necessary in B2B cases where the Patient Demographics Consumer is operating in the background without a user confirming the Patient match. However, onlyCertainMatches does not guarantee that only a single Patient Resource will be returned. There might still be multiple results returned in the response when the same person has multiple records in the Patient Demographics Supplier. FHIR-37361 and FHIR-40880 request an additional parameter for specifying that matches SHOULD only be returned when there is exactly 1 certain match.
web github.com PDQm_issue_94 : In PDQ, PDQv3, and PDQm ITI-78, we have the ability for the client to limit the search results to patients with an identifier issued by a particular patient identification domain. We do not have equivalent functionality in ITI-119. While a client could suggest that it is interested in a particular patient identification domain by including the assigning authority of that domain as an identifier system in the $match input parameters, the semantics of $match would not require the server to honor that request. We do not believe this is likely to be an issue for real world implementations of ITI-119.
web profiles.ihe.net Editor, add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A :
web profiles.ihe.net Editor, add the following new or modified transactions to the IHE Technical Frameworks General Introduction Appendix B :
web profiles.ihe.net There are two additional profiles, PDQv3 (Patient Demographics Query HL7v3) and PDQm (Patient Demographics Query for Mobile), which provide similar functionality to Patient Demographics Query. These profiles adapt the Patient Demographics Query transaction of the Patient Demographics Supplier and Patient Demographics Consumer Actors for HL7v3 and HL7 FHIR. ITI TF-2x: Appendix M.4 provides additional details about these Patient Demographics Query Profiles and their relationship with one another.
web profiles.ihe.net There are two additional profiles, PDQ (Patient Demographics Query) and PDQm (Patient Demographics Query for Mobile), which provide similar functionality to Patient Demographics Query V3. These profiles adapt the Patient Demographics Query transaction of the Patient Demographics Supplier and Patient Demographics Consumer Actors for HL7v2 and HL7 FHIR. ITI TF-2x: Appendix M.4 provides additional details about these Patient Demographics Query Profiles and their relationship with one another.
web www.kereval.com Provider: INRIA (Rennes, France), KEREVAL
web gazelle.ihe.net Gazelle PatientManager online
web gazelle.ihe.net User Manual
web gazelle.ihe.net Tool support
web gazelle.ihe.net Consumer test definition: PM_PDQ_Query-Patient_Demographics_Consumer
web gazelle.ihe.net Supplier test definition: PM_PDQ_Query-Patient_Demographics_Supplier
web www.kereval.com Provider: INRIA (Rennes, France), KEREVAL , and Mallinckrodt Institute of Radiology (Saint Louis, USA)
web gazelle.ihe.net Gazelle EVSClient online
web gazelle.ihe.net User Manual
web gazelle.ihe.net Tool support
web gazelle.ihe.net The tests listed below are defined in Gazelle Master Model and are performed by systems testing PDQm at IHE Connectathons.
web profiles.ihe.net 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.
web profiles.ihe.net 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.
web profiles.ihe.net 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 .
web profiles.ihe.net Note 1: The Mobile Patient Demographics Query [ITI-78] and Patient Demographics Match [ITI-119] transactions correspond to the transactions used in the PDQ and PDQv3 Profiles and provide 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.
web profiles.ihe.net Note 1: The Mobile Patient Demographics Query [ITI-78] and Patient Demographics Match [ITI-119] transactions correspond to the transactions used in the PDQ and PDQv3 Profiles and provide 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.
web profiles.ihe.net Note 1: The Mobile Patient Demographics Query [ITI-78] and Patient Demographics Match [ITI-119] transactions correspond to the transactions used in the PDQ and PDQv3 Profiles and provide 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.
web profiles.ihe.net 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. The PDQm $Match Operation SHALL also be supported if the Match Operation Option is declared.
web en.wikipedia.org A patient visits the office of the general practitioner they see regularly. The general practitioner needs to retrieve the patient’s electronic medical record from the jurisdictional central database. In the local jurisdiction, patients are issued photo ID cards by the local jurisdictional authority that include identifiers unique to the patient. These identifiers end with a check digit using a strong algorithm, such as the modulo-11 algorithm. The practitioner’s office clerk uses the unique identifier on the patient’s photo ID card to locate and retrieve the patient’s record from the jurisdictional database.
web en.wikipedia.org The Patient Demographics Match [ITI-119] transaction, on the other hand, follows the semantics of the FHIR $match operation. This FHIR operation provides Master Patient Index (MPI) style search functionality. This interaction gives the Patient Demographics Supplier full authority to implement the patient matching algorithm of its choice, rather than following the strict rules of the FHIR search interaction. These types of systems will often use a scoring algorithm to match patients to the given demographics, and return results that meet or exceed a threshold. The algorithm might assign partial credit to demographics that match partially, such as names with alternate spellings or identifiers with transposed digits. Thus, this is a more powerful search that puts responsibility on the Patient Demographics Supplier to perform the complex patient matching logic. The Patient Demographics Consumer can even request that only ‘certain’ matches be returned, ensuring that weak matches are not even presented.
web profiles.ihe.net Actors are expected to follow the recommendations and requirements found in ITI TF-2: Appendix Z.8 “Mobile Security Considerations” .
web profiles.ihe.net Actors have requirements in the [ITI-78] Security Considerations Section and the [ITI-119] 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.
web profiles.ihe.net Actors have requirements in the [ITI-78] Security Considerations Section and the [ITI-119] 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.
web profiles.ihe.net When the PDQm 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. A discussion of the various IHE profiles involved in patient identity management and how they relate to one another can be found in the Enabling Document Sharing Health Information Exchange Using IHE Profiles White Paper .
web profiles.ihe.net 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.

Internal Images

tree-filter.png
tree-filter.png