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.

3.9 PIX Query [ITI-9]

This section corresponds to transaction [ITI-9] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-9] is used by the Patient Identifier Cross-reference Consumer and Patient Identifier Cross-reference Manager Actors.

3.9.1 Scope

This transaction involves a request by the Patient Identifier Cross-reference Consumer for a list of patient identifiers that correspond to a patient identifier known by the consumer. The request is received by the Patient Identifier Cross-reference Manager. The Patient Identifier Cross-reference Manager immediately processes the request and returns a response in the form of a list of corresponding patient identifiers, if any.

3.9.2 Use Case Roles

Actor: Patient Identifier Cross-reference Consumer

Role: Queries the Patient Identifier Cross-reference Manager for a list of corresponding patient identifiers, if any

Actor: Patient Identifier Cross-reference Manager

Role: Manages the cross-referencing of patient identifiers across Patient Identification Domains. Upon request it returns a list of corresponding patient identifiers, if any.

3.9.3 Referenced Standard

HL7 2.5, Chapter 2 – Control, Chapter 3 – Patient Administration, Chapter 5 – Query

Note: HL7 version 2.5 was selected for this transaction because it was considered the most stable version that contained the functionality required by transactions [ITI-9] and [ITI-10].

3.9.4 Messages

Figure 3.9-1: Get Corresponding Identifiers Sequence

3.9.4.1 Get Corresponding Identifiers

3.9.4.1.1 Trigger Events

A Patient Identifier Cross-reference Consumer’s need to get the patient identifier associated with a domain for which it needs patient related information will trigger the request for corresponding patient identifiers message based on the following HL7 trigger event:

  • Q23 – Get Corresponding Identifiers
3.9.4.1.2 Message Semantics

The Request for Corresponding Patient Identifiers transaction is conducted by the HL7 QBP^Q23 message. The Patient Identifier Cross-reference Consumer shall generate the query message whenever it needs to obtain a corresponding patient identifier(s) from other Patient Identification Domain(s). The segments of the message listed below are required, and their detailed descriptions are provided in the following subsections.

Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7 profiling are stated in ITI TF-2: Appendix C and C.1.

Table 3.9-1: QBP Query By Parameter

QBP Query By Parameter Chapter in HL7 2.5
MSH Message Header 2
QPD Query Parameter Definition 5
RCP Response Control Parameter 5

The receiver shall respond to the query by sending the RSP^K23 response message. This satisfies the requirements of original mode acknowledgment; no intermediate ACK message is to be sent.

3.9.4.1.2.1 MSH Segment

The MSH segment shall be constructed as defined in ITI TF-2: C.2.2 “Message Control”.

Field MSH-9 Message Type shall have all three components populated with a value. The first component shall have a value of QBP; the second component shall have the value of Q23. The third component shall have a value of QBP_Q21.

3.9.4.1.2.2 QPD Segment

The Patient Identifier Cross-reference Consumer is required to send attributes within the QPD segment as described in Table 3.9-2.

Table 3.9-2: IHE Profile - QPD segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 250 CE R 0471 01375 Message Query Name
2 32 ST R+ 00696 Query Tag
3 250 (Note 1) CX R Person Identifier
4 250 CX O What Domains Returned

Adapted from the HL7 Standard, version 2.5

Note 1: This value assumes completion of an HL7 erratum to correct an error identified in the standard.

This message shall use the field QPD-3 Person Identifier to convey a single Patient ID uniquely identifying the patient within a given Patient Identification Domain.

The Patient Identifier Cross-reference Consumer shall provide the patient identifier in the ID component (first component) of the QPD-3 field (QPD-3.1).

The Patient Identifier Cross-reference Consumer shall provide component QPD-3.4, Assigning Authority, by including either the first subcomponent (namespace ID) or the second and third subcomponents (universal ID and universal ID type) If all three subcomponents are populated, the first subcomponent shall reference the same entity as is referenced by the second and third components.

If the requesting system wishes to select the domains from which they wish to receive Patient IDs, it does so by populating QPD-4-What Domains Returned with as many repetitions as domains for which it wants to receive Patient IDs. Each repetition of QPD-4 shall contain an instance of data type CX in which only the fourth component (Assigning Authority) is populated; the remaining components shall be empty. The responding system shall return the Patient ID value for each requested domain if a value is known.

If QPD-4 is empty, the Patient Identifier Cross-reference Manager shall return Patient IDs for all domains for which it possesses a corresponding Patient ID (subject to local publication restrictions).

The Consumer shall specify “IHE PIX Query” for QPD-1 Message Query Name.

3.9.4.1.2.3 RCP Segment

Although HL7 requires that the RCP Segment be sent in all QBP messages, IHE does not require that the Patient Identifier Cross-reference Consumer send any attributes within the RCP segment, as is specified in the HL7 standard.

3.9.4.1.2.3.1     Populating RCP-1-Query Priority

Field RCP-1-Query Priority shall always contain I , signifying that the response to the query is to be returned in Immediate mode.

3.9.4.1.3 Expected Actions

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the QPD segment as specified in Table 3.9-2.

The Patient Identifier Cross-reference Manager must be capable of receiving all valid combinations of subcomponents that make up the Assigning Authority component (i.e., all valid combinations of QPD-3.4).

The Patient Identifier Cross-reference Manager shall be capable of accepting multiple concurrent PIX Query requests (Get Corresponding Identifiers messages) and responding correctly using the Return Corresponding Identifiers message.

3.9.4.2 Return Corresponding Identifiers

3.9.4.2.1 Trigger Events

The Patient Identifier Cross-reference Manager’s response to the Get Patient Identifiers message will trigger the following message:

  • K23 – Corresponding patient identifiers
3.9.4.2.2 Message Semantics

The Return Corresponding Identifiers transaction is conducted by the HL7 RSP^K23 message. The Patient Identifier Cross-reference Manager shall generate this message in direct response to the QBP^Q23 query message previously received. This message satisfies the Application Level, Original Mode Acknowledgement for the HL7 QBP^Q23 message. The segments of the message listed without enclosing square brackets in the table below are required. Detailed descriptions of all segments listed in the table below are provided in the following subsections. Other segments of the message are optional.

Note: Conventions used in this section as well as additional qualifications to the level of specification and HL7 profiling are stated in ITI TF-2: Appendix C and C.1.

Table 3.9-3: RSP Segment Pattern Response

RSP Segment Pattern Response Chapter in HL7 2.5
MSH Message Header 2
MSA Message Acknowledgement 2
[ERR] Error segment 2
QAK Query Acknowledgement 5
QPD Query Parameter Definition 5
[PID] Patient Identification 3

 

3.9.4.2.2.1 MSH Segment

The MSH segment shall be constructed as defined in ITI TF-2: C.2.2, “Message Control”.

Field MSH-9-Message Type shall have all three components populated with a value. The first component shall have a value of RSP; the second component shall have the value of K23. The third component shall have a value of RSP_K23.

3.9.4.2.2.2 MSA Segment

The Patient Identifier Cross-reference Manager is not required to send any attributes within the MSA segment beyond what is specified in the HL7 standard. See ITI TF-2: C.2.3 for the list of all required and optional fields within the MSA segment.

3.9.4.2.2.3 QAK Segment

The Patient Identifier Cross-reference Manager shall send attributes within the QAK segment as defined in Table 3.9-4. For the details on filling in QAK-2 (Query Response Status) refer to Section 3.9.4.2.2.6.

Table 3.9-4: IHE Profile - QAK segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 32 ST R 00696 Query Tag
2 2 ID R+ 0208 00708 Query Response Status

Adapted from the HL7 standard, version 2.5

3.9.4.2.2.4 QPD Segment

The Patient Identifier Cross-reference Manager shall echo the QPD Segment value that was sent in the QBP^Q23 message.

3.9.4.2.2.5 PID Segment

The Patient Identifier Cross-reference Manager shall return only those attributes within the PID segment that are required by the HL7 standard: PID-3-Patient IdentifierList and PID-5-Patient Name .

The PID segment is returned only when the Patient Identifier Cross-reference Manager recognizes the specified Patient Identification Domain and Patient ID and an identifier exists for the specified patient in at least one other domain. See Section 3.9.4.2.2.6, “Patient Identifier Cross-reference Manager Query Response Behavior,” for a detailed description of how the Patient Identifier Cross-reference Manager responds to the query request under various circumstances.

The Patient Identifier Cross-reference Manager shall use the field PID-3 Patient Identifier List to convey the Patient ID uniquely identifying the patient within each Patient Identification Domain for which a Patient ID exists for the specified patient. Each resulting ID returned in PID-3 shall include a fully qualified Assigning Authority component. In other words, the Assigning Authority component returned shall include ALL subcomponents (namespace ID, Universal ID, and Universal ID type).

To eliminate the issue of conflicting name values between Patient Identifier Domains, the Patient Identifier Cross-reference Manager shall return in an empty (not present) value in the first repetition of field PID-5-Patient Name, and shall return a second repetition of field PID-5-Patient Name in which the only populated component is Component 7 (Name Type Code). Component 7 of repetition 2 shall contain a value of S (Coded Pseudo-name to assure anonymity). All other components of repetition 2 shall be empty (not present).

3.9.4.2.2.6 Patient Identifier Cross-reference Manager Actor Query Response Behavior

It is wholly the responsibility of the Patient Identifier Cross-reference Manager to perform the matching of patient identifiers based on the patient traits it receives. The information provided by the Patient Identifier Cross-reference Manager to Patient Identifier Cross-reference Consumer Actors is a list of cross-referenced identifiers in two or more of the domains managed by the cross-referencing Actor. The list of cross-references is not made available until the set of policies and processes for managing the cross-reference function have been completed. The policies of administering identities adopted by the cooperating domains are completely internal to the Patient Identifier Cross-reference Manager and are outside of the scope of this framework. Possible matches should not be communicated until the healthcare institution policies and processes embodied in the Patient Identifier Cross-reference Manager reach a positive matching decision.

The Patient Identifier Cross-reference Manager shall respond to the query request as described by the following 6 cases:

Case 1 : The Patient Identifier Cross-reference Manager recognizes the specified Patient Identification Domain and Patient ID sent by the Patient Identifier Cross-reference Consumer in QPD-3, and corresponding identifiers exist for the specified patient in at least one of the domains requested in QPD-4 (one identifier per domain). (See Case 6 below for the required behavior if there are multiple identifiers recognized within a given Identifier Domain by the Patient Identifier Cross-reference Manager Actor.)

AA (application accept) is returned in MSA-1.

OK (data found, no errors) is returned in QAK-2.

A single PID segment is returned in which one repetition of PID-3 Patient Identifier List is populated for each of the domains, if any, that the Patient Identifier Cross-reference Manager did recognize in which a single identifier exists for the requested patient, not including the queried-for patient identifier that is returned in QPD-3.

Case 2 : The Patient Identifier Cross-reference Manager recognizes the Patient Identification Domain and Patient ID sent in QPD-3, but no identifier exists for that patient in any of the domains sent in QPD-4.

AA (application accept) is returned in MSA-1.

NF (no data found, no errors) is returned in QAK-2.

No PID segment is returned.

Case 3 : The Patient Identifier Cross-reference Manager recognizes the specified Patient Identification Domain sent in the fourth component of QPD-3, but does not recognize the Patient ID sent in the first component of QPD-3.

AE (application error) is returned in MSA-1 and in QAK-2.

An ERR segment is returned in which the components of ERR-2-Error Location are valued as follows.

COMP # COMPONENT NAME VALUE
1 Segment ID QPD
2 Sequence 1
3 Field Position 3
4 Field Repetition 1
5 Component Number 1
6 Sub-Component Number (empty)

As specified by HL7, ERR-2.6-Sub-Component Number is not valued because we are referring to the entire fourth component of field QPD-3.

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier). Together with the values in ERR-2, this signifies that the Patient Identifier Cross-reference Manager did not recognize the value in the first component of QPD-3.

Case 4 : The Patient Identifier Cross-reference Manager does not recognize the Patient Identification Domain of the identifier sent in QPD-3.

AE (application error) is returned in MSA-1 and in QAK-2.

An ERR segment is returned in which the components of ERR-2-Error Location are valued as follows.

COMP # COMPONENT NAME VALUE
1 Segment ID QPD
2 Sequence 1
3 Field Position 3
4 Field Repetition 1
5 Component Number 4
6 Sub-Component Number (empty)

As specified by HL7, ERR-2.6-Sub-Component Number is not valued because we are referring to the entire fourth component of field QPD-3.

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier). Together with the values in ERR-2, this signifies that the Patient Identifier Cross-reference Manager did not recognize the value in the fourth component of QPD-3.

Case 5 : The Patient Identifier Cross-reference Manager does not recognize one or more of the Patient Identification Domains for which an identifier has been requested.

AE (application error) is returned in MSA-1 and in QAK-2.

For one domain that was not recognized, an ERR segment is returned in which the components of ERR-2-Error Location are valued as indicated below.

COMP # COMPONENT NAME VALUE
1 Segment ID QPD
2 Sequence 1
3 Field Position 4
4 Field Repetition (see below)
5 Component Number (empty)
6 Sub-Component Number (empty)

As specified by HL7, ERR-2.5-Component Number and ERR-2.6-Sub-Component Number are not valued because we are referring to the entire field QPD-4.

ERR-3-HL7 Error Code is populated with the error condition code 204 (unknown key identifier). Together with the values in ERR-2, this signifies that the Patient Identifier Cross-reference Manager did not recognize the domain for the occurrence of QPD-4-What Domains Returned whose ordinal number is returned as an integer in ERR-2.4.

Case 6 : The Patient Identifier Cross-reference Manager recognizes the specified Patient Identification Domain and Patient ID sent by the Patient Identifier Cross-reference Consumer in QPD-3, and corresponding identifiers exist for the specified patient in at least one of the domains requested in QPD-4, and there are multiple identifiers within at least one of the requested domains.

AA (application accept) is returned in MSA-1.

OK (data found, no errors) is returned in QAK-2.

A single PID segment is returned in which one repetition of PID-3-Patient Identifier List is populated for each of the identifiers, not including the queried-for patient identifier that is returned in QPD-3. If the Patient Identifier Cross-reference Manager chooses to return multiple identifiers associated with the same domain, it shall return these identifiers grouped in successive repetitions within the PID-3-Patient Identifier List .

3.9.4.2.3 Expected Actions

The Patient Identifier Cross-reference Consumer will use the list of patient identifier aliases provided by the Patient Identifier Cross-reference Manager to perform the functions for which it requested the list.

In the case where the returned list of identifiers contains multiple identifiers for a single domain, the Patient Identifier Cross-reference Consumer shall either use ALL of the multiple identifiers from the given domain or it shall ignore ALL of the multiple identifiers from the given domain.

This allows Patient Identifier Cross-reference Consumers capable of handling multiple identities for a single patient within a single domain (i.e., those that can correctly aggregate the information associated with the different identifiers) to do so. For those Patient Identifier Cross-reference Consumers not capable of handling this situation, ignoring the entire list of different identifiers prevents the Consumer from presenting incomplete data.

3.9.5 Security Considerations

3.9.5.1 Audit Record Considerations

The PIX Query Transaction is a Query Information event as defined in Table 3.20.4.1.1.1-1 with the following exceptions:

3.9.5.1.1 Patient Identifier Cross-reference Consumer audit message:
Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110112, DCM, “Query”)
EventActionCode M “E” (Execute)
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-9”, “IHE Transactions”, “PIX Query”)
Source (Patient Identifier Cross-reference Consumer) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager) (1)
Audit Source (Patient Identity Cross-reference Consumer) (1)
Patient (0..n)
Query Parameters (1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identifier Cross-reference Consumer Actor facility and sending application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID M The process ID as used within the local operating system in the local system logs.
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110153, DCM, "Source Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

Human Requestor (if known)

AuditMessage/
ActiveParticipant

UserID M Identity of the human that initiated the transaction.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode U Access Control role(s) the user holds that allows this transaction.
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Destination

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identifier Cross-reference Manager facility and receiving application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110152, DCM, "Destination Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

Audit Source

AuditMessage/
AuditSourceIdentification

AuditSourceID U not specialized
AuditEnterpriseSiteID U not specialized
AuditSourceTypeCode U not specialized

Patient

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “1” (Person)
ParticipantObjectTypeCodeRole M “1” (Patient)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M not specialized
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID in HL7 CX format.
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized

Query Parameters

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “2” (system object)
ParticipantObjectTypeCodeRole M “24” (query)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV(“ITI-9”, “IHE Transactions”, “PIX Query”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID U not specialized
ParticipantObjectName U not specialized
ParticipantObjectQuery M The complete query message (including MSH and QPD segments), base64 encoded.
ParticipantObjectDetail M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)
3.9.5.1.2 Patient Identifier Cross-reference Manager audit message:

 

Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110112, DCM, “Query”)
EventActionCode M “E” (Execute)
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-9”, “IHE Transactions”, “PIX Query”)
Source (Patient Identifier Cross-reference Manager) (1)
Destination (Patient Identifier Cross-reference Consumer) (1)
Audit Source (Patient Identifier Cross-reference Manager) (1)
Patient (0..n)
Query Parameters (1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identifier Cross-reference Consumer Actor facility and sending application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110153, DCM, "Source Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

 

Destination

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identifier Cross-reference Manager facility and receiving application from the HL7 message; concatenated together, separated by the | character.
AlternativeUserID M The process ID as used within the local operating system in the local system logs.
UserName U not specialized
UserIsRequestor U not specialized
RoleIDCode M EV(110152, DCM, "Destination Role ID")
NetworkAccessPointTypeCode M “1” for machine (DNS) name, “2” for IP address
NetworkAccessPointID M The machine name or IP address.

 

Audit Source

AuditMessage/
AuditSourceIdentification

AuditSourceID U not specialized
AuditEnterpriseSiteID U not specialized
AuditSourceTypeCode U not specialized

 

Patient

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “1” (Person)
ParticipantObjectTypeCodeRole M “1” (Patient)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M not specialized
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID in HL7 CX format.
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized

 

Query Parameters

(AuditMessage/
ParticipantObjectIdentification)

ParticipantObjectTypeCode M “2” (system object)
ParticipantObjectTypeCodeRole M “24” (query)
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV(“ITI-9”, “IHE Transactions”, “PIX Query”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID U not specialized
ParticipantObjectName U not specialized
ParticipantObjectQuery M The complete query message (including MSH and QPD segments), base64 encoded.
ParticipantObjectDetail M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)