IHE ITI TF Vol2

3.46 PIXV3 Update Notification [ITI-46]

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

3.46.1 Scope

The scope is identical to the scope of transaction [ITI-10], described in ITI TF-2: 3.10.1 .

3.46.2 Use Case Roles

Actor: Patient Identifier Cross-reference Manager

Role: It serves a well-defined set of Patient Identification Domains. The Patient Identifier Cross-reference Manager manages the cross-referencing of patient identifiers across Patient Identification Domains by providing a list of patient ID “aliases” via notification to a configured list of interested Patient Identifier Cross-reference Consumers.

Corresponding HL7 v3 Application Roles:

Patient Registry Informer (PRPA_AR201301UV02)

Actor: Patient Identifier Cross-reference Consumer

Role: Receives notifications from the Patient Identifier Cross-reference Manager of changes to patient ID aliases. Typically the Patient Identifier Cross-reference Consumer uses this information to maintain information links about patients in a different patient ID domain.

Corresponding HL7 v3 Application Roles:

Patient Registry Tracker (PRPA_AR201302UV02)

3.46.3 Referenced Standards

HL7 Version 3 Edition 2008 Patient Administration DSTU, Patient Topic (found at http://www.hl7.org/memonly/downloads/v3edition.cfm#V32008 )

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

3.46.4 Messages

Figure 3.46.4-1: Update Patient Information Sequence

3.46.4.1 Update Patient Information

3.46.4.1.1 Trigger Events

The Patient Identifier Cross-reference Manager shall notify a Patient Identifier Cross-reference Consumer when there is a change in a set of cross-referenced patient identifiers for any of the patient identifiers belonging to Patient Identifier Domains of interest to the consumer. The configuration of the domains of interest to a Patient Cross-reference Consumer is maintained by the Patient Cross-reference Manager.

Several notifications may have to be issued to communicate a single update to a set of cross-reference patient identifiers as required to reflect all the changes on the resulting sets of cross-reference patient Identifiers belonging to Patient Identifier Domains of interest to the Patient Identifier Cross-referencing Consumer.

The following HL7 trigger event will be used to update to the list of patient identifiers:

Patient Registry Record Revised (PRPA_TE201302UV02)

This trigger event signals that patient information was revised in a patient registry.

3.46.4.1.2 Message Semantics

The PIX Update Notification transaction is conducted by the Patient Revise (PRPA_MT201302UV02) message. The Patient Identifier Cross-reference Manager initiates this transaction whenever identifier list information is updated for a patient.

Each message shall be acknowledged by the HL7 V3 Accept Acknowledgement (MCCI_MT000200UV01), which is described in ITI TF-2: Appendix O .

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 shall only contain a list of cross-referenced identifiers for the domains of interest as configured with the Patient Identifier Cross-reference Manager in two or more of the domains managed by the Patient Identifier Cross-reference Manager. Multiple notifications may need to be sent. For example:

Consumer CON_A is configured to receive update notifications for domains DOM_A and DOM_AD. Notifications are sent as follows:

A PIXV3 Patient Registry Record Add message is sent for a patient for DOM_A. The update notification shall contain the patient identifier for DOM_A.
A PIXV3 Patient Registry Record Add message is processed for DOM_AD. The Patient Identifier Cross-reference Manager cross references this patient with DOM_A. The update notification shall contain the patient identifiers for both DOM_A and DOM_AD.
A PIXV3 Patient Registry Record Revise message is processed for DOM_AD changing the patient address. The Patient Identifier Cross-reference Manager cross references determines this patient is no longer the same patient as DOM_A. Two update notifications shall be sent. One containing the patient identifier for DOM_A. The other one containing the patient identifier for DOM_AD.

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 transaction. 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 have configuration indicating which Identity Consumers are interested in receiving the PIXV3 Update Notification transactions. This configuration information shall include identification of the identity consumer systems interested in receiving notifications and, for each of those systems, a list of the patient identifier domains of interest. The Patient Identifier Cross-reference Manager should account for consumers interested in all domains.

Each message shall be acknowledged by the Accept Acknowledgment message sent by the receiver of the Patient Registry Record Revise message to its sender.

3.46.4.1.2.1 Major Components of the Patient Registry Record Revised

Patient

The Patient class is the entry point to the R-MIM for the Patient Revise (PRPA_RM201302UV02) . This is where the updated list of patient identifiers will be present.

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 be optionally used to capture other identifiers associated with the person such as 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.46.4.1.2.2 Message Information Model of the Patient Registry Record Revise 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 Revise (PRPA_RM201302UV02) RMIM.

The base RMIM can be found on the HL7 V3 2008 Edition CD at Edition2008/domains/uvpa/editable/PRPA_RM201302UV.htm. The following restrictions were made on the original RMIMs to arrive at the restricted model (note that the resulting model is identical to the one described in Section 3.45.4.2.2.2):

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

Figure 3.46.4.1.2.2-1: Message Information Model for the Patient Revise Message

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

Table 3.46.4.1.2.1-1: Model Attributes

PRPA_HD201302IHE Patient Revise	This HMD extract defines the message used to send a Patient Update Notification Derived from Figure 3.46.4.1.2.2-1 (PRPA_RM201302IHE)
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 identifiers from one or more 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.46.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.46.4.1.2.3-1 contains the Transmission and Control Act wrappers used for the two interactions, and the associated constraints.

Table 3.46.4.1.3-1: Wrappers and Constraints

Transmission Wrapper

Trigger Event Control Act Wrapper

MCCI_MT000100UV01 – Send Message Payload

MFMI_MT700701UV01 – Master File / Registry Notification Control Act, Role Subject

The value of interactionId SHALL be set to PRPA_IN201302UV02

The value of processingModeCode SHALL be set to T

The acceptAckCode SHALL be set to AL

There SHALL be only one receiver Device

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

RegistrationEvent.statusCode SHALL be set to “active”

There SHALL be no InReplacementOf act relationship for these interactions.

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

3.46.4.1.2.4 Web Services Types and Messages

The Patient Registry Record Revised message will be transmitted using Web Services, according to the requirements specified in ITI TF-2: Appendix V .

The following WSDL naming conventions SHALL apply:

“revise” message -> "PRPA_IN201302UV02_Message"

acknowledgement -> "MCCI_IN000002UV01_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">

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

<xsd:element name="PRPA_IN201302UV02"/>

</xsd:schema>

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

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

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

<xsd:element name="MCCI_IN000002UV01"/>

</xsd:schema>

</types>

…

The messages are described by the following snippet:

…

</message>

</message>

…

The port types for the WSDL describing the Patient Identity Feed Service are described together with the expected actions of the actors which receive these messages in Section 3.46.4.1.3.

3.46.4.1.3 Expected Actions - Patient Identifier Cross-reference Consumer

Whenever the Patient Identifier Cross-reference Consumer receives updated identifier information in a Patient Revise message that results in a change to the cross-referencing of a patient, the actor shall update its internal identifier information for the affected patient(s) in all domains in which it is interested. 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 in which this actor is interested.

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.46.4.1.3.1 Web Services Port Type and Binding Definitions

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

The following WSDL naming conventions SHALL apply:

wsdl:definitions/@name="PIXConsumer":

PIX update message -> " PRPA_IN201302UV02_Message"

acknowledgement -> "MCCI_IN000002UV01_Message"

portType -> "PIXConsumer_PortType"

get identifiers operation -> "PIXConsumer_PRPA_IN201302UV02"

SOAP 1.2 binding -> "PIXConsumer_Binding_Soap12"

SOAP 1.2 port -> "PIXConsumer_Port_Soap12"

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

3.46.4.1.3.1.1 Port Type

</operation>

</portType>

3.46.4.1.3.1.2 Bindings

SOAP 1.2 binding:

…

3 <binding name="PIXConsumer_Binding_Soap12" type="PIXConsumer_PortType">

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

<wsoap12:operation soapActionRequired="false"/>

<input>

<wsoap12:body use="literal"/>

</input>

<wsoap12:body use="literal"/>

</output>

</operation>

</binding>

…

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

3.46.4.1.3.2 Message Examples

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

3.46.5 Security Requirements

No transaction specific security considerations.

3.46.5.1 Audit Record Considerations

When grouped with ATNA Secure Node or Secure Application Actors, this transaction is to be audited as “Patient Record” 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.46.5.1.1 Patient Identifier Cross-reference Manager audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110110, DCM, “Patient Record”)
	EventActionCode	M	“R” (Read)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-46”, “IHE Transactions”, “PIX Update Notification”)
Source (Patient Identifier Cross-reference Manager) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Consumer) (1)
Audit Source (Patient Identifier Cross-reference Manager) (1)
Patient IDs (1..n) (represents the components of PID-3)

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

not specialized

AuditEnterpriseSiteID

not specialized

AuditSourceTypeCode

not specialized

Patient IDs (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	M	Type=II (the literal string), Value=the value of message.id

3.46.5.1.2 Patient Identifier Cross-reference Consumer audit message:

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110110, DCM, “Patient Record”)
	EventActionCode	M	“U” (update)
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-46”, “IHE Transactions”, “PIX Update Notification”)
Source (Patient Identifier Cross-reference Manager) (1)
Destination (Patient Identifier Cross-reference Consumer) (1)
Audit Source (Patient Identifier Cross-reference Consumer) (1)
Patient IDs (1..n) (represents the components of PID-3)

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

not specialized

AuditEnterpriseSiteID

not specialized

AuditSourceTypeCode

not specialized

Patient IDs (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	M	Type=II (the literal string), Value=the value of message.id