IHE ITI Technical Framework
The Final Text ITI Technical Framework is published here in HTML format and is no longer published as PDF. Trial Implementation supplements are available from the Volume 1 Table of Contents.

This Appendix has been updated by Trial-Implementation text that is included below in section M.4.

Appendix M: Using Patient Demographics Query in a Multi-Domain Environment

M.1 HL7 QBP^Q22 Conformance Model

The HL7 Find Candidates Query (QBP^Q22) defines a patient demographics query between a client application and an MPI system (HL7 V2.5, Page 3-64). This implies that the server maintains a master record of the patient demographics, but may know a number of patient identifiers from other domains.

In the QBP^Q22 Conformance Statement, QPD-8 (What Domains Returned) is defined as “the set of domains for which identifiers are returned in PID-3” (HL7 V2.5, Page 3-66, second table). Note that this field does not cite “demographics information in some domains”, but about “identifiers issued in some domains”, and explicitly specifies that these identifiers are returned in PID-3 (Patient ID List).

In the example following the Conformance Statement in HL7 2.5, three patient records are included in the query response; each returned patient record includes two identifiers in PID-3 (domains METRO HOSPITAL and SOUTH LAB) as requested in the query. However, one set of demographic information is returned in the remainder of the PID segment. The example does not illustrate or assume a mechanism for returning multiple sets of demographic information.

Thus it appears that QBP^Q22 is not intended to provide a way to issue a single query for patient demographics maintained in multiple different patient registration systems (domains).

M.2 IHE PDQ Architecture

In the PDQ Integration Profile, the supplier is characterized as a Patient Demographics Supplier. The supplier is not assumed nor required to be an MPI system. It may be holding information from only a single patient identification domain, or may instead hold information from multiple identification domains.

The latter case would apply if, for example, the Patient Demographics Supplier is grouped with an actor accepting ADT feeds from multiple patient registration systems in different domains. Equivalently, the Patient Demographics Supplier (or some other actor with which it is grouped) may manage a set of patient demographics sources, but is not expected to cross-reference them (as a PIX Patient Identifier Cross-reference Manager or an MPI system). A conceptual model embracing both multi-domain concepts is shown in the following picture.

Figure M.2-1: Patient Demographics Supplier in a Multi-domain Environment

Because of the definition of QBP^Q22, it must be determined which patient demographics source a QBP^Q22 query is asking for, before any processing of the query request can proceed. The identification of a need for such determination is the key difference between the IHE PDQ transactions and the original HL7 QBP^Q22 definitions.

Three obvious alternatives exist for determining the patient demographics source.

  1. The supplier advertises different application entities for each of the patient demographics sources it manages. By addressing its query to a particular application entity in MSH-5-Receiving Application , the consumer explicitly selects a source it is asking for.
  2. The consumer is required to populate PID-3.4 in QPD-3 (Query Parameter) with the domain name administered by the corresponding source (patient identifier domain) it is asking for.
  3. The consumer includes in QPD-8 (What Domains Returned) the domain name of the corresponding patient information source it is asking for.

In selecting among these alternatives for the PDQ Profile, IHE-ITI took into account the need to constrain the current HL7 QBP^Q22 definition while maintaining the integrity of the HL7 standard query and at the same time to model the PDQ Profile properly to satisfy its real-world purpose. Based on these considerations, alternative 1 is the best selection, although alternative 2 is acceptable. Alternative 3 is not acceptable because it violates the definition of QPD-8 that is stated in the HL7 Standard.

M.3 Implementing PDQ in a multi-domain architecture

There are three possible approaches in using PDQ in a multi-domain environment:

  1. Group the PDQ Patient Demographics Supplier with a PIX Patient Identifier Cross-reference Manager. This allows the use of QPD-8 to request patient identifiers from other domains to be returned in the demographics query response to the PDQ Patient Demographics Consumer.
  2. Group the PDQ Patient Demographics Supplier with a PIX Patient Identifier Cross-reference Consumer. This allows the use of QPD-8 to request patient identifiers from other domains to be returned in the demographics query response to the PDQ Patient Demographics Consumer.
  3. Group the PDQ Patient Demographics Consumer with a PIX Patient Identifier Cross-reference Consumer. This obliges the Patient Demographics Consumer to use separate query requests to obtain patient demographics information (PDQ Query) and patient identifiers from the domains in which it is interested (PIX Query).

Approach 3 is not recommended if Approach 1 or 2 is feasible. To require the Patient Demographics Consumer to issue a separate PIX query increases complexity and might not be permissible in the actual implementation architecture.

When Approach 1 or 2 is implemented, QPD-8 may be used by the Patient Demographics Consumer to ask for patient identifiers from the single domain used to identify patients in the Affinity Domain. The patient demographics information returned comes from the patient demographics source that is associated with MSH-5-Receiving Application ; the patient demographics source may or may not be associated with the patient identifier domain.

In Approach 2, note that the PDQ Patient Demographics Supplier is grouped with the PIX Patient Identifier Cross-reference Consumer. This combined actor will use a PIX query to satisfy the request of the client from additional patient identifiers and return them in PID-3.

M.4 Patient Demographics Query Implementation Guidance

This section describes the data elements that are used in IHE profiles designed for the querying of patient demographics (Patient Demographics Query Profiles) including PDQ, PDQv3, and PDQm.

While the semantic representation of the data elements differs across the transaction in the PDQ Profiles, the common set of elements and query parameters can be described using abstract terminology. This section explains the data elements and query parameters used in PDQ Profiles from an abstract definition standpoint, and then it provides a map between the three profiles’ implementation specific concept.

Note: More data elements may be known by the Patient Demographics Supplier and may be returned. Elements beyond those profiled are encouraged but not required of the profile. Patient Demographics Consumer Actors should be robust to receiving more data than is profiled.

M.4.1 Patient Demographics Query Data Fields

Table M.4.1-1 outlines the abstract demographics fields which are common to all Patient Demographics Query Profiles.

Table M.4.1-1: Patient Demographics Data Elements (abstract)

Field Purpose
Identifier List Provides one or more identifiers that can be used to uniquely identify the patient within a medical system.
Name(s) Identifies the patient’s preferred, legal, or alias names.
Date/Time of Birth Identifies the date on which the patient was born.
Gender Identifies the patient’s gender used for administrative purposes.
Address(es) Identifies the patient’s associated addresses (home, work, etc.)
Telecommunications Address(es) Identifies the patient’s phone number, fax number, email addresses and other means of telecommunicating with the patient.
Language(s) of communication Identifies languages which can be used when communicating with the patient.
Marital Status Identifies the patient’s marital status at time of last update (married, divorced, etc.)
Non-Medical Identifiers Identifies additional identifiers associated with the patient which are not used for medical purposes (ex: driver’s license, social insurance number, etc.)
Death Date/Time Identifies the time at which the patient died.

Table M.4.1-2 provides a mapping between these abstract data elements and their transaction specific fields.

Table M.4.1-2: Patient Demographics Data Elements (concrete)

Abstract Field PDQ PDQ HL7v3 PDQm
Identifier List PID.3 and PID.18 id identifier
Name(s) PID.5 and PID.9 name name
Date / Time of Birth PID.7 birthTime birthdate
Gender PID.8 administrativeGenderCode gender
Address(es) PID.11 addr address
Telecommunications Address(es) PID.13 and PID.14 telecom telecom
Language(s) of communication PID.15 languageCommunication communication.language
Marital Status PID.16 maritalStatusCode maritalStatus
Non-Medical Identifiers PID.19 and PID.20 asOtherIds identifier
Death Date/Time PID.29 deceasedTime deceasedDateTime
Mother’s Maiden Name PID.6 personalRelationship.name mothersMaidenName
Patient Birth Order PID.25 multipleBirthOrderNumber multipleBirthInteger

M.4.2 Patient Demographics Query Parameters

Table M.4.2-1 outlines the demographics query parameters which are common to all Patient Demographics Query Profiles.

Table M.4.2-1: Patient Demographics Query Parameters (abstract)

Field Purpose
Identifier List Filters the result set to a list of patients whose identifiers match the provided identifiers.
Name Filters the result set to a list of patients whose name (legal, maiden, alias, etc.) matches the provided value. The mechanisms for match are not specified but can include exact match, pattern match, phonetic match, variant match, etc.
Date / Time of Birth Filters the result set to patients whose date/time of birth match the provided value.
Note: Birth time is not applicable in PDQm
Gender Filters the result set to patients whose administrative gender matches the provided value.
Address Filters the result set to patients whose address (home, business, etc.) matches the provided value.
Domains to be Returned Filters the result set to include only identifiers which have been assigned by the specified domains.
Mother’s Maiden Name Filters the result set to include only those patients which whose mother’s maiden name matches the specified name.
Patient Telecommunications Addresses Filters the result set to include only those which have the specified telecommunications addresses.

Table M.4.2-2 provides a mapping between these abstract query parameters and their transaction specific implementation.

Table M.4.2-2: Patient Demographics Query Parameters (concrete)

Abstract Parameter PDQ PDQ HL7v3 PDQm
Identifier List @PID.3 and @PID.18 livingSubjectId identifier
Name @PID.5 livingSubjectName given and family
Date / Time of Birth @PID.7 livingSubjectBirthTime birthdate
Note: Birth time is not applicable in PDQm
Gender @PID.8 livingSubjectAdministrativeGender gender
Address @PID.11 patientAddress address
Domains to be Returned QPD-8 otherIDsScopingOrganization identifier
Mother’s Maiden Name @PID.6 mothersMaidenName mothersMaidenName
Patient Telecommunications Addresses @PID.13 patientTelecom telecom