24 Patient Demographics Query HL7 V3 (PDQV3)
The Patient Demographics Query HL7 V3 Integration Profile (PDQV3) provides ways for multiple distributed applications to query a patient information server for a list of patients, based on user-defined search criteria, and retrieve a patient’s demographic information directly into the application. The discussion and use cases in Section 8 fully apply here, with the obvious adjustments to the referenced transactions.
24.1 PDQV3 Actors/Transactions
The actors in this profile are the same as the actors defined in the PDQ Profile (Section 8.1).
Table 24.1-1: Patient Demographics Query HL7 V3 Integration Profile - Actors and Transactions
| Actors | Transactions | Optionality | Section |
| Patient Demographics Consumer | Patient Demographics Query HL7 V3 [ITI-47] | R | ITI TF-2: 3.47 |
| Patient Demographics Supplier | Patient Demographics Query HL7 V3 [ITI-47] | R | ITI TF-2: 3.47 |
The transaction in this profile directly corresponds to one of the transactions used in the PDQ Profile (Section 8) and provides the identical functionality. Table 24.1-2 describes this correspondence. Note that there is no transaction in PDQV3 that corresponds to the Patient Demographics and Visit Query [ITI-22] in the PDQ Profile.
Table 24.1-2: Transactions Correspondence between the PDQ and PDQV3 Profiles
| Transactions in PDQ | Section in Volume | Transactions in PDQV3 | Section in Volume |
| Patient Demographics Query [ITI-21] | ITI TF-2: 3.21 | Patient Demographics Query HL7 V3 [ITI-47] | ITI TF-2: 3.47 |
24.1.1 PDQV3 Required Actor Groupings
An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 2).
Table 24.1.1-1: PDQV3 - Required Actor Groupings
| PDQV3 Actor | Actor(s) to be grouped with | Reference |
| Patient Demographics Consumer | None | -- |
| Patient Demographics Supplier | None | -- |
Section 24.5 describes some optional groupings that may be of interest for security considerations.
24.2 PDQV3 Actor Options
Options that may be selected for this Integration Profile are listed in the Table 24.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes.
Table 24.2-1: Patient Demographics Query HL7 V3 - Actors and Options
| Actor | Options | Vol. & Section |
| Patient Demographics Consumer | Continuation | ITI TF-1: 24.2.1 |
| Pediatric Demographics | ITI TF-1: 24.2.2 | |
| Patient Demographics Supplier | Continuation | ITI TF-1: 24.2.1 |
| Pediatric Demographics | ITI TF-1: 24.2.2 |
Support of continuations is described in transaction [ITI-47]. This option allows the Patient Demographics Consumer to get the full set of responses in several increments, as opposed to in one single response.
24.2.1 Continuation Option
Support of continuations is described in transaction [ITI-47]. This option allows the Patient Demographics Consumer to get the full set of responses in several increments, as opposed to in one single response.
24.2.2 Pediatric Demographics Option
The experience of immunization registries and other public health population databases has shown that matching and linking patient records from different sources for the same individual person in environments with large proportions of pediatric records requires additional demographic data.
In particular, distinguishing records for children who are twins, triplets, etc. – that is, avoiding false positive matches - may be difficult because much of the demographic data for the two individuals matches. For instance, twin children may have identical last names, parents, addresses, and dates of birth; their first names may be very similar, possibly differing by only one letter. It can be very difficult for a computer or even a human being to determine in this situation whether the slight first name difference points to two distinct individuals or just a typographical error in one of the records. Additional information is extremely helpful in making this determination.
Pediatric Demographics makes use of the following six additional demographic fields to aid record matching in databases with many pediatric records.
| Field | Reason for inclusion | Value |
| Mother’s Maiden Name | Any information about the mother is helpful in making a match | Helps create true positive matches |
| Patient Home Telephone | A telecom helps match into the right household | Helps create true positive matches |
| Patient Multiple Birth Indicator | Indicates this person is a multiple – twin, triplet, etc. | Helps avoid false positive matches of multiples |
| Patient Birth Order | Distinguishes among those multiples. | Helps avoid false positive matches of multiples |
| Last Update Date/Time, Last Update Facility | These fields, although not strictly demographic, can effectively substitute when multiple birth indicator and birth order are not collected. They indirectly provide visit information. Provider visits on the same day may likely indicate two children brought to a doctor together. | Helps avoid false positive matches of multiples |
Patient Identity Source Actors which support the Pediatric Demographics Option are required to support the Patient Identity Management [ITI-30] transaction and shall provide values, when available, for the fields identified as Pediatric Demographics fields.
Patient Identifier Cross-reference Manager Actors which support the Pediatric Demographics Option are required to support the Patient Identity Management [ITI-30] transaction, and if values for one or more of the Pediatric Demographics fields are specified in the Patient Identity Management [ITI-30], they shall be considered as part of the matching algorithm of the PIX Manager.
Pediatric Demographics are defined as all of the following:
- Mother’s Maiden Name
- Patient Home Telephone
- Patient Multiple Birth Indicator
- Patient Birth Order
- Last Update Date/Time
- Last Update Facility
24.3 Patient Demographics Query HL7 V3 Process Flow
Section 8.3 describes use cases that this profile addresses. Figure 8.3-1 also applies to this profile with the changes to the corresponding PDQV3 transactions as specified in Table 24.1-2, and omitting transaction [ITI-22], which has no correspondence in this profile.
24.3.1 Combined Use of PDQV3 with other IHE Workflow Profiles
In addition to the discussion in Section 8.3.1, the use of web services as the transport in the transactions in this profile makes it well suited in cases where other web services-based profiles are used, like XDS.b and PIXV3.
24.3.2 Supplier Data Configuration
The Patient Demographics Supplier provides demographics information about possible matches to the parameters of the query. As described in ITI TF-2: Appendix M , while it is possible for the supplier to have demographics information from multiple domains, only a single set of demographics shall be returned by the supplier.
If the supplier holds information for a single Patient ID domain, it shall provide the demographics information from that domain. In the case where the supplier holds demographics information from multiple Patient ID domains, the determination of which set of information to return must be based on the ID values for the Receiver’s Device and Organization classes of the query transmission wrapper (the equivalent of MSH-5 and MSH-6 in the HL7 Version 2.5 corresponding message).
24.4 Intentionally Left Blank
24.5 Security Considerations
The implementer of this profile is advised that many risks cannot be mitigated by the IHE profile and instead the responsibility for mitigation is transferred to the vendor, and occasionally to the operational environment.
In order to address identified security risks:
- All actors in PDQV3 should be grouped with a Consistent Time (CT) Profile - Time Client. This grouping will assure that all systems have a consistent time clock to assure a consistent timestamp for audit logging.
- All actors in PDQV3 should be grouped with an Audit Trail and Node Authentication (ATNA) Profile - Secure Node or ATNA Secure Application Actor. This grouping will assure that only highly trusted systems can communicate and that all changes are recorded in the audit log.
- All actors in PDQV3 should be grouped with a Cross-Enterprise User Assertion (XUA) X-Service User or X-Service Provider as appropriate. This grouping will enable service side access control and more detailed audit logging.
- All actors in PDQV3 should be grouped with the appropriate actor from the Enterprise User Authentication (EUA) Profile to enable single sign-on inside an enterprise by facilitating one name per user for participating devices and software.