IHE ITI Technical Framework
  • IHE IT Infrastructure (ITI) Technical Framework, Volume
    Revision 20.0, August 4, 2023 – Final Text
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.45 PIXV3 Query [ITI-45]

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

3.45.1 Scope

The scope is identical to ITI TF-2: 3.9.1 , PIX Query Scope.

3.45.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

Corresponding HL7 v3 Application Roles :

Patient Registry Query Placer (PRPA_AR201303UV02)

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.

Corresponding HL7 v3 Application Roles:

Patient Registry Query Fulfiller (PRPA_AR201304UV02)

3.45.3 Referenced Standards

HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186 )

Implementers of this transaction shall comply with all requirements described in ITI TF-2: Appendix V Web Services for IHE Transactions.

3.45.4 Messages

Figure 3.45.4-1: Get Corresponding Identifiers Sequence

3.45.4.1 Get Corresponding Identifiers

3.45.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:

Patient Registry Get Identifiers Query (PRPA_TE201309UV02)

This query requests all other identifiers associated with a particular person identifier.

3.45.4.1.2 Message Semantics

The Get Corresponding Identifiers transaction is initiated by the HL7 Patient Registry Query by Identifier (PRPA_MT201307UV02) message. The Patient Identifier Cross-reference Consumer shall generate the query message whenever it needs to obtain corresponding patient identifier(s) from other Patient Identification Domain(s). The components of the message listed below are required, and their detailed descriptions are provided in the following subsections.

The receiver shall respond to the query by sending the Patient Identifiers message (PRPA_MT201304UV02), which uses the Application Level Acknowledgement transmission wrapper. This satisfies the requirements of original mode acknowledgment; no intermediate Accept Acknowledgement message is to be sent. All appropriate identifiers shall be returned in a single response; therefore no continuation queries are allowed in this transaction.

3.45.4.1.2.1 Major Components of the Patient Registry Query by Identifier

PatientIdentifier Parameter

This required parameter specifies the identifier associated with the person whose information is being queried. For this parameter item, a single patient identifier is specified in the PatientIdentifier.value attribute. Please see ITI TF-2: Appendix E for the use of the II data type for patient identifiers.

DataSource Parameter

This optional parameter specifies the assigning authority/authorities of the Patient Identity Domain(s) whose identifiers need to be returned. If no such parameter is supplied, the PIX Manager is required to return the identifiers from all known Patient Identity Domains.

3.45.4.1.2.2 Message Information Model of the Patient Registry Query by Identifier Message

Below is the Message Information Model for the Query by Identifier message, as restricted for this transaction. The purpose of the model is to describe the data elements relevant for this transaction. It is a strict subset of the Patient Registry Query by Identifier (PRPA_RM201307UV02) RMIM.

The base RMIM can be found on the HL7 V3 2008 Edition CD at Edition2008/domains/uvpa/editable/PRPA_RM201307UV.htm. The following restrictions were made on the original RMIMs to arrive at the restricted model:

  • Exactly one PatientIdentifier parameter SHALL be present
  • Exactly one PatientIdentifier.value attribute SHALL be present
  • If one or more DataSource parameters are present, each SHALL contain exactly one DataSource.value parameter
  • The optional attributes ParameterList.id, QueryByParameter responseElementGroupId, QueryByParameter.modifyCode, and QueryByParameter.executionAndDeliveryTime were removed from the model
  • QueryByParameter.responsePriorityCode is required and is fixed to I (Immediate)
  • QueryByParameter.statusCode is defaulted to "new"
PRPA_RM201307IHE

Figure 3.45.4.1.2.2-1: Message Information Model for the Query by Identifier message

The attributes of this model are described in the following table.

Table 3.45.4.1.2.2-1 Model Attributes

PRPA_HD201307IHE
Patient Registry Query by Identifier

This HMD extract defines the message used to query a patient registry for a list of identifiers.

Derived from Figure 3.45.4.1.2.2-1 (PRPA_RM201307IHE)
QueryByParameter The entry point for the domain content in this query

queryId [1..1]
QueryByParameter  ( II )

Unique identifier for the query

statusCode [1..1] (M)
QueryByParameter  ( CS ) {CNE: QueryStatusCode , fixed value="new"}

There are no continuations necessary for this type of query, so the status is always "new"

responsePriorityCode [1..1]
QueryByParameter  ( CS ) {CNE: QueryPriority , fixed value="I"}

The PIX manager is required to send an immediate response.

DataSource

Optional parameter specifying the assigning authority of a Patient Identity Domain

value [1..1]
ParameterItem  ( II )

The identifier for the Patient Identity Domain's assigning authority. IHE restriction:
The value.root attribute SHALL be a valid ISO OID
The value.extension attribute SHALL NOT be present

semanticsText [1..1]
ParameterItem  ( ST ){default= "DataSource.id"}

PatientIdentifier

value [1..1] (M)
ParameterItem  ( II )

The patient identifier known to the PIX Consumer

semanticsText [1..1]
ParameterItem  ( ST ){default= "Patient.id"}

The Patient Identifier Cross-reference Consumer shall provide the patient identifier in the PatientIdentifier.value attribute according to the rules specified in ITI TF-2: Appendix E .

If the requesting system wishes to select the Patient Identity Domains from which patient identifiers are returned, it does so by sending as many DataSource parameters as domains for which it wants to receive patient identifiers. Each instance of the DataSource parameter shall provide the Assigning Authority identifier for a specific domain using the DataSource.value attribute. Note that the DataSource.value.extension attribute shall not be provided, and the DataSource.value.root attribute shall contain a valid ISO OID. The responding system shall return the Patient.id value for each requested domain, if a value is known. Note that the value of Patient.id.root attribute shall match the DataSource.value.root attribute representing the corresponding Assigning Authority.

If no DataSource parameter is specified the Patient Identifier Cross-reference Manager shall return patient identifiers for all domains for which it possesses a corresponding identifier (subject to local publication restrictions).

3.45.4.1.2.3 Control Act and Transmission Wrappers

Please see ITI TF-2: Appendix O for details on the IHE guidelines for implementing the wrappers. Table 3.4 5 .4.1.2 .3 - 1 contains the Transmission and Control Act wrappers used for this interaction, and the associated constraints.

Table 3.45.4.1.2.3-1: Wrappers and Constraints

Transmission Wrapper Trigger Event Control Act Wrapper
MCCI_MT000100UV01 – Send Message Payload QUQI_MT021001UV01 – Query Control Act Request: Query By Parameter

The value of interactionId SHALL be set to PRPA_IN201309UV02

The value of processingModeCode SHALL be set to T

The acceptAckCode SHALL be set to AL

There SHALL be only one receiver Device

The value of ControlActProcess.moodCode SHALL be set to EVN

The trigger event code in ControlActProcess.code SHALL be set to PRPA_TE201309UV02

The value of authorOrPerformer.typeCode SHALL be set to AUT

The composite message schemas which describe the full payload of this interaction, including the wrappers, can be found online: see ITI TF-2: Appendix W . The schemas from the HL7 V3 2008 Normative Edition are at
Edition2008/processable/multicacheschemas/PRPA_IN201309UV02.xsd).

3.45.4.1.2.4 Web Services Types and Messages

The Patient Registry Query by Identifier message and response will be transmitted using Web Services, according to the requirements specified in ITI TF-2: Appendix V .

The following WSDL naming conventions SHALL apply:

  Query by Identifier -> "PRPA_IN201309UV02_Message"

  Query Response      -> "PRPA_IN201310UV02_Message"

The following WSDL snippet describes the types for these messages:

  …

 <types>

  <xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"

xmlns:hl7="urn:hl7-org:v3">

<!-- Include the message schema -->

<xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201309UV02.xsd"/>

<xsd:element name="PRPA_IN201309UV02"/>

</xsd:schema>

<xsd:schema elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3"

xmlns:hl7="urn:hl7-org:v3">

<!-- Include the message schema -->

<xsd:import namespace="urn:hl7-org:v3" schemaLocation="../schema/HL7V3/NE2008/multicacheschemas/PRPA_IN201310UV02.xsd"/>

<xsd:element name="PRPA_IN201310UV02"/>

</xsd:schema>

  </types>

…

The messages are described by the following snippet:

  …

  <message name="PRPA_IN201309UV02_Message">

<part element="hl7:PRPA_IN201309UV02" name="Body"/>

  </message>

  <message name="PRPA_IN201310UV02_Message">

<part element="hl7:PRPA_IN201310UV02" name="Body"/>

  </message>

The port types for the WSDL describing the Resolved Duplicates Service are described together with the expected actions of the actors which receive these messages in Section 3.45.4.1.3.

3.45.4.1.3 Expected Actions

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes as specified in Table 3.45.4.1.2.2-1 above.

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

3.45.4.1.3.1 Web Services Port Type and Binding Definitions

IHE-WSP201) The attribute /wsdl:definitions/@name SHALL be “PIXManager”.

The following WSDL naming conventions SHALL apply:

  wsdl:definitions/@name="PIXManager":

  "get identifiers" query    -> "PRPA_IN201309UV02_Message"

  "get identifiers" response -> "PRPA_IN201310UV02_Message"

  portType                   -> "PIXManager_PortType"

  get identifiers operation  -> "PIXManager_PRPA_IN201309UV02"

  SOAP 1.2 binding           -> "PIXManager_Binding_Soap12"

  SOAP 1.2 port              -> "PIXManager_Port_Soap12"

The following WSDL snippets specify the PIXV3 Query Port Type and Binding definitions, according to the requirements specified in ITI TF-2: Appendix V .

3.45.4.1.3.1.1 Port Type

  <portType name="PIXManager_PortType">

    <operation name="PIXManager_PRPA_IN201309UV02">

<input message="tns:PRPA_IN201309UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201309UV02"/>

<output message="tns:PRPA_IN201310UV02_Message" wsaw:Action="urn:hl7-org:v3:PRPA_IN201310UV02"/>

</operation>

  </portType>

3.45.4.1.3.1.2 Bindings

SOAP 1.2 binding:

…

  <binding name="PIXManager_Binding_Soap12" type="PIXManager_PortType">

    <wsoap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

    <operation name="PIXManager_PRPA_IN201309UV02">

      <wsoap12:operation soapActionRequired="false"/>

      <input>

        <wsoap12:body use="literal"/>

      </input>

      <output>

        <wsoap12:body use="literal"/>

      </output>

    </operation>

  </binding>

…

An informative WSDL for the PIX Manager implementing the PIXV3 Profile is available online: see ITI TF-2: Appendix W .

3.45.4.1.3.2 Message Examples

Message examples can be found online: see ITI TF-2: Appendix W .

3.45.4.2 Return Corresponding Identifiers

3.45.4.2.1 Trigger Events

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

Patient Registry Get Identifiers Query Response (PRPA_TE201310UV02)

This query response returns all other identifiers associated with a particular person identifier.

3.45.4.2.2 Message Semantics

The Return Corresponding Identifiers message is conducted by the HL7 Patient Identifiers message. The Patient Identifier Cross-reference Manager shall generate this message in direct response to the Patient Registry Query by Identifier message previously received. This message satisfies the Application Level, Original Mode Acknowledgement for the query message.

3.45.4.2.2.1 Major Components of the Get Corresponding Identifiers Query Response

Patient

The Patient class is the entry point to the R-MIM for the Patient Identifiers (PRPA_RM201304UV02) . This is where at least one of the requested patient IDs will be listed.

  Person

The Person class contains the name of the patient for additional verification purposes.

Provider Organization

The Patient class is optionally scoped by the provider organization where this person is a patient. The HL7 definition of the CMET requires that the provider organization needs to be identified by an id attribute, and at least one of address, telecommunications address, or contact person to be present. The id attribute SHALL have only a root, expressed as an ISO OID, and at least one of the id attributes of the Patient class SHALL have a matching root component. See ITI TF-2: Appendix E on the use of the II data type for patient identifiers.

Other Identifiers

The OtherIDs class can optionally be used to capture other identifiers associated with the person such as identifiers required to support all of the HL7 v3 messages corresponding to the PIX/PDQ Transactions (e.g., driver’s license number or social security number). It is important to recognize that the HL7 RIM distinguishes between person-level IDs and patient-level IDs. In this transaction, however, the Patient Identity Cross-Reference Manager has the option to send all identifiers in the id attributes of the Patient class. If that is the case, the OtherIDs class shall not be used. For the purposes of interoperability where both HL7 V3 and HL7 v2.x based transactions are used, and the OtherIDs class is present, the following requirement is imposed on the OtherIDs.id attribute and on the scopingOrganization.id attribute:

OtherIDs.id.root SHALL be identical to scopingOrganization.id.root

scopingOrganization.id.extension SHALL NOT have any value

3.45.4.2.2.2 Message Information Model of the Patient Identifiers Message

Below is the Message Information Model for the Patient Identifiers message, as restricted for this transaction. The purpose of the model is to describe the data elements relevant for this transaction. It is a strict subset of the Patient Identifiers (PRPA_RM201304UV02) RMIM.

The base RMIM can be found on the HL7 V3 2008 Edition CD at Edition2008/domains/uvpa/editable/PRPA_RM201304UV.htm. The following restrictions were made on the original RMIMs to arrive at the restricted model:

  • The focal entity choice is restricted to be only a person
  • All optional classes are removed, except for the provider organization, and other identifiers
  • All optional attributes in the Patient and Person class are removed
PRPA_RM201304IHE

Figure 3.45.4.2.2.2-1: Message Information Model for the Patient Identifiers Message

The attributes of this model are described in the following table.

Table 3.45.4.2.2.2-1: Model Attributes

PRPA_HD201304IHE
Patient Identifiers

This HMD extract defines the message used to respond to the Patient Registry Query By Identifier

Derived from Figure 3.45.4.2.2.2-1 (PRPA_RM201304IHE)
Patient The primary record for the focal person in a Patient Identity Cross-Reference Manager

classCode [1..1] (M)

Patient (CS) {CNE:PAT}

 Structural attribute; this is a "patient" role

id [1..*] (M)

Patient ( SET < II >)

Linked patient identifiers from one or more Patient Identity Domains

statusCode [1..1]

Patient (CS) {CNE:active, fixed value= "active"}

 A value specifying the state of this record in a patient registry (based on the RIM role class state-machine). This record is active.
Person

A subtype of LivingSubject representing a human being

Both Person.name and Patient.id must be non-null

classCode [1..1] (M)

Person (CS) {CNE:PSN, fixed value= "PSN"}

 Structural attribute; this is a "person" entity

determinerCode [1..1] (M)

Person (CS) {CNE:INSTANCE, fixed value= "INSTANCE"}

 Structural attribute; this is a specific person

name [1..*]

Person (BAG<PN>)

 Name(s) for this person
OtherIDs Used to capture additional identifiers for the person such as a Drivers’ license or Social Security Number.

classCode [1..1] (M)

Role (CS) {CNE:ROL}

 Structural attribute. This can be any specialization of "role"

id [1..*] (M)

Role (SET<II>)

 One or more identifiers issued to the focal person by the associated scopingOrganization (e.g., a Driver’s License number issued by a DMV)
3.45.4.2.2.3 Control Act and Transmission Wrappers

Please see ITI TF-2: Appendix O for details on the IHE guidelines for implementing the wrappers. Table 3.45.4.4.3-1 contains the Transmission and Control Act wrappers used for this interaction, and the associated constraints.

Table 3.45.4.4.3-1: Wrappers and Constraints

Transmission Wrapper Trigger Event Control Act Wrapper
MCCI_MT000300UV01 – Send Application Acknowledgement MFMI_MT700711UV01 – Master File/Registry Query Response Control Act (Role Subject)

The value of interactionId SHALL be set to PRPA_IN201310UV02

The value of processingModeCode SHALL be set to T

The acceptAckCode SHALL be set to NE

There SHALL be only one receiver Device

The value of ControlActProcess.moodCode SHALL be set to EVN

The trigger event code in ControlActProcess.code SHALL be set to PRPA_TE201310UV02

There SHALL be zero or one RegistrationEvents present in this message.

If a RegistrationEvent is part of the message, there SHALL be exactly one Patient role present in the payload.

There SHALL be no replacementOf act-relationship present in this message

There SHALL be a QueryByParameter copy of the original query.

The composite message schemas which describe the full payload of this interaction, including the wrappers, can be found online: see ITI TF-2: Appendix W . The schema from the HL7 V3 2008 Normative Edition are at
Edition2008/processable/multicacheschemas/PRPA_IN201310UV02.xsd).

3.45.4.2.2.4 Web Services Types and Messages

Since this is a response to a query, please see Section 3.45.4.1.2.4 for the web services components of this message.

3.45.4.2.3 Expected Actions - Patient Identifier Cross-reference Manager

The Patient Identifier Cross-reference Manager shall return the attributes within the message that are required by the HL7 standard, as shown in Figure 3.45.4.2.2.2-1.

A RegistrationEvent, and the associated Patient class are returned only when the Patient Identifier Cross-reference Manager recognizes the specified Patient ID in the query parameter, and an identifier exists for the specified patient in at least one other domain. The Patient Identifier Cross-reference Manager shall use at one or more Patient.id attributes (and, optionally, zero or more OtherIDs.id attributes) to convey the patient IDs which uniquely identify the patient within each Patient Identification Domain. The identifiers are captured using an Instance Identifier (II) data type. See ITI TF-2: Appendix E for a detailed description of the use of the II data type for patient identifiers.

It is wholly the responsibility of the Patient Identifier Cross-reference Manager to perform the matching of patient identifiers based on the patient identifier it receives. The information provided by the Patient Identifier Cross-reference Manager to the Patient Identifier Cross-reference Consumer is a list of cross-referenced identifiers in one or more of the domains managed by the Patient Identifier Cross-reference Manager, in addition to the original identifier used in the query. The identifier used in the query is returned only in the copy of the QueryByParameter parameter list. 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 ID sent by the Patient Identifier Cross-reference Consumer in PatientIdentifier.value, and corresponding identifiers exist for the specified patient in at least one of the domains requested in DataSource.value (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.)

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper).

A single RegistrationEvent class is returned, where at least one of the identifiers, which the Patient Identifier Cross-reference Manager did recognize as belonging to a requested domain, is returned in Patient.id. Subsequent such identifiers, if any, are returned in either Patient.id or OtherIDs.id, not including the queried-for patient identifier that is returned in the QueryByParameter parameter list (control act wrapper).

Case 2 : The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sent by the Patient Identifier Cross-reference Consumer in PatientIdentifier.value, there are no specific domains requested in the query (no DataSource parameters are present), and corresponding identifiers exist for the specified patient in at least one other domain known to the Patient Identifier Cross-reference Manager (one identifier per domain).

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper).

A single RegistrationEvent class is returned, where at least one of the identifiers, which the Patient Identifier Cross-reference Manager did recognize as belonging to a domain different from the domain of the queried-for patient identifier, is returned in Patient.id. Subsequent such identifiers, if any, are returned in either Patient.id or OtherIDs.id, not including the queried-for patient identifier, which is returned in the QueryByParameter parameter list (control act wrapper).

Case 3 : The Patient Identifier Cross-reference Manager recognizes the specified Patient ID sent in PatientIdentifier.value, but no identifier exists for that patient in any of the domains sent in DataSource.value.

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

NF (no data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper).

No RegistrationEvent is returned.

The queried-for patient identifier is returned in the QueryByParameter parameter list (control act wrapper).

Case 4 : The Patient Identifier Cross-reference Manager does not recognize the Patient ID sent in the PatientIdentifier.value.

AE (application error) is returned in Acknowledgement.typeCode (transmission wrapper) and in QueryAck.queryResponseCode (control act wrapper).

No RegistrationEvent is returned.

The queried-for patient identifier is returned in the QueryByParameter parameter list (control act wrapper).

An AcknowledgmentDetail class is returned in which the attributes typeCode, code, and location are valued as follows.

Attribute VALUE
typeCode E
code 204 (Unknown Key Identifier)
location XPath expression for the value element of the PatientIdentifier parameter

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 Acknowledgement.typeCode (transmission wrapper) and in QueryAck.queryResponseCode (control act wrapper).

No RegistrationEvent is returned.

The queried-for patient identification domains are returned in the QueryByParameter parameter list (control act wrapper).

For each domain that was not recognized, an AcknowledgmentDetail class is returned in which the attributes typeCode, code, and location are valued as follows:

Attribute VALUE
typeCode E
Code 204 (Unknown Key Identifier)
Location

XPath expression for the value element of the DataSource parameter
(which includes the repetition number of the parameter)

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

AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).

OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper)

A single RegistrationEvent class is returned, where at least one of the identifiers, which the Patient Identifier Cross-reference Manager did recognize as belonging to a requested domain, is returned in Patient.id. Subsequent such identifiers, if any, are returned in either Patient.id or OtherIDs.id, not including the queried-for patient identifier that is returned in the QueryByParameter parameter list (control act wrapper).

If the Patient Identifier Cross-reference Manager chooses to return multiple identifiers associated with the same domain, it shall return these identifiers either grouped in a single instance of the OtherIDs class, or all represented via repetitions of the Patient.id attribute.

3.45.4.2.3.1 Web Services Port Type and Binding Definitions

The WSDL snippets for this message are shown in Section 3.45.4.1.3.1

3.45.4.2.3.2 Message Examples

Message examples can be found online: see ITI TF-2: Appendix W .

3.45.4.2.4 Expected Actions - Patient Identifier Cross-reference Consumer

The Patient Identifier Cross-reference Consumer will use the list of patient identifier aliases provided by the Patient Identifier Cross-reference Manger to perform the functions, for which it requested the list. The identifiers found in both Patient.id and OtherIDs.id attributes shall be considered together to form a complete list of patient identifiers from the different Patient Identity domains (either requested or available).

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.45.5 Security Requirements

No transaction specific security considerations.

3.45.5.1 Audit Record Considerations

When grouped with ATNA Secure Node or Secure Application Actors, this transaction is to be audited as “Query Information” event, as defined in ITI TF-2: Table 3.20.4.1.1.1-1. The following tables show items that are required to be part of the audit record for this transaction.

3.45.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-45”, “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 U not specialized
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 SOAP endpoint URI
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M “false”
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 (see ITI TF-2: Appendix E ).
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-45”, “IHE Transactions”, “PIX Query”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID U not specialized
ParticipantObjectName U not specialized
ParticipantObjectQuery M the QueryByParameter segment of the query, base64 encoded
ParticipantObjectDetail U not specialized
3.45.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-45”, “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 U not specialized
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 SOAP endpoint URI
AlternativeUserID M the process ID as used within the local operating system in the local system logs.
UserName U not specialized
UserIsRequestor M “false”
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 (see ITI TF-2: Appendix E ).
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-45”, “IHE Transactions”, “PIX Query”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID U not specialized
ParticipantObjectName U not specialized
ParticipantObjectQuery M the QueryByParameter segment of the query, base64 encoded
ParticipantObjectDetail U not specialized