IHE ITI TF Vol2

3.64 Notify XAD-PID Link Change [ITI-64]

This section corresponds to Transaction ITI-64. “ Notify XAD-PID Link Change ” of the IHE Technical Framework. Transaction ITI-64 is used by the Patient Identity Cross-Reference Manager and Document Registry Actors.

The following definitions are key to understanding this transaction:

"XAD Assigning Authority" refers to the patient identifier Assigning Authority that is the authoritative source of patient identifiers for the XDS Affinity Domain.

For a given patient,

" XAD-PID " is a patient identifier created by the XAD Assigning Authority. The patient should only have one XAD-PID assigned.
" local patient ID " is the patient ID used by a particular local domain. This value was placed in the " sourcePatientID " metadata attribute for all documents related to the patient from that local domain that have been submitted to the Document Registry.
" previous XAD-PID " is the XAD-PID to which the “local patient ID” was originally linked. This value was placed in the " patientID " metadata attribute for all documents related to the patient from that local domain that have been submitted to the Document Registry
" new XAD-PID " is the correct XAD-PID to which the “local patient ID” is now linked. It will replace “previous XAD-PID” in all documents submitted to the Document Registry for the given “local patient ID” .
“ subsumed local patient ID ” is the patient ID previously used by a local domain that is being merged as a part of this message. On the original submission this value was placed in the " sourcePatientID " metadata attribute. As part of this transaction the “ sourcePatientID ” value must be updated to the “ local patient ID ”.

3.64.1 Scope

This transaction informs the recipient that there has been a change to the link between a “local patient ID” (i.e., that used by the Document Source) and its corresponding XAD-PID (XDS Affinity Domain Patient Identifier).

It should not to be confused with the similar link/unlink events documented in the Patient Identity Management [ITI-30] transaction which is used by patient demographic suppliers to notify other interested systems about changes to its own local patient identity records.

The transaction can be used in any setting where it is appropriate to have XAD-PID link changes processed as a single event, rather than require individual metadata updates to each object.

3.64.2 Use Case Roles

Actor : Patient Identity Cross-Reference Manager

Role : Notifies of the occurrence of changes to a link between local patient identifiers and their corresponding XAD-PID

Actor: Document Registry

Role : Receives notification and performs automatic changes to the metadata of affected objects.

3.64.3 Referenced Standard

HL7 v2.5, chapters 2, 3, 6, 15

3.64.4 Interaction Diagram

Figure 3.64.4-1: Notify XAD-PID Link Messages

3.64.4.1 Notify XAD-PID Link Change

3.64.4.1.1 Trigger Events

The Patient Identity Cross-Reference Manager has made a change in the link between a patient's “local patient ID” and its corresponding XAD-PID or a “ local patient ID ” has been merged.

3.64.4.1.2 Message Semantics

The Patient Identifier Cross-Reference Manager shall encode the Notify XAD-PID Link Change message using the ADT^A43 message. The segments of the message listed in Table 3.64-1 shall be present. Other segments are optional.

Table 3.64.4.1.2-1: Notify XAD-PID Link Change

ADT	Notify XAD-PID Link Change	Chapters in HL7 2.5
MSH	Message Header	2
EVN	Event Type	3
PID	Patient Identification	3
MRG	Merge Patient Information	3

This transaction shall use the HL7 v2 original acknowledgement mode. The Document Registry shall acknowledge each ADT^A43 message with the HL7 v2 Accept ACK message. See ITI TF-2: C.2.3, “Acknowledgement Modes” for the definition and discussion of the ACK message.

3.64.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-3 Sending Application shall contain the OID for the Patient Identity Cross-Reference Manager system. This OID will be different than the OID for the assigning authority.
Field MSH-9 Message Type shall have a value of ADT^A43.

3.64.4.1.2.2 EVN Segment

See ITI TF-2: C.2.4 for the list of all required and optional fields within the EVN segment.

3.64.4.1.2.3 PID Segment

A single PID segment shall include a list with two identifiers in PID-3 as follows:

The first repetition contains the " new XAD-PID ", as the one the Patient Identity Cross-Reference Manager has linked to the " local patient ID "
The second repetition contains the " local patient ID "

Both patient IDs included in PID-3 shall include an Assigning Authority component. The Assigning Authority component returned shall include the subcomponents Universal ID, and Universal ID type. It may include the namespace ID, in which case it shall reference the same entity as is referenced by the other two subcomponents.

To eliminate the issue of multiple name values between Patient Identifier Domains, field PID-5-Patient Name shall have a value of " ", i.e., a single space character (ASCII 0x20).

3.64.4.1.2.4 MRG Segment

A single MRG segment shall include one or two identifiers in MRG-1 as follows:

The first repetition shall contain the “ previous XAD-PID ”. If only a local patient identifier merge is being reflected, the “ previous XAD-PID ” shall be the same as the “ new XAD-PID ”.
The second repetition, if present, shall contain the “ subsumed local patient ID ”. This identifier shall have the same Assigning Authority as the “ local patient ID ” in the PID Segment. The presence of the “ subsumed local patient ID ” indicates that it is being merged into the “ local patient ID ” specified in the PID segment.

Any patient ID included in MRG-1 shall include an Assigning Authority component. The Assigning Authority component shall include the subcomponents Universal ID, and Universal ID type. It may include the namespace ID, in which case it shall reference the same entity as is referenced by the other two subcomponents.

3.64.4.1.3 Expected Actions

This section documents the expected outcome of the Notify XAD-PID Link Change transaction when received by the Document Registry. It is only applicable when the Document Registry is also supporting the XDS Profile (i.e., the Registry Stored Query [ITI-18] transaction).

Upon receipt of this message, the Document Registry shall perform all necessary actions to ensure that it has applied the XAD-PID link change notification to all applicable objects within its database.

After processing the XAD-PID link change, the Document Registry shall ensure that:

Responses to any subsequent Registry Stored Query [ITI-18] transaction for documents related to the " new XAD-PID " (i.e., patientId in the Document) shall include matching documents for that patientID including all those containing a sourcePatientId value of " local Patient ID ".

Responses to any subsequent Registry Stored Query [ITI-18] for documents related to the " previous XAD-PID " shall not include any document with sourcePatientId value of " local Patient ID ".
If “ subsumed local patient ID ” is present, responses to any subsequent Registry Stored Query [ITI-18] shall show the " local Patient ID " in the sourcePatientId attribute for any document that previously contained the " subsumed local patient ID " as the sourcePatientId.

The first two rules essentially reflect the XPID Profile requirement that all DocumentEntry objects assigned to the “local patient ID” must now have a patientID value of “new XAD-PID” not “previous XAD-PID” . The last rule reflects the XPID Profile requirement that all DocumentEntry objects previously assigned to the “ subsumed local patient ID ” shall now have sourcePatientId equal to “ local Patient ID ” and patientID equal to “ new XAD-PID ”.

3.64.4.1.3.1 Document Registry Object Updates

This section describes the requirements for Document Registry object updates that result from processing the Notify XAD-PID Link Change transaction. The resulting metadata shall be generated by the Document Registry so that the changes, as viewed through the Registry Stored Query [ITI-18] transaction, appear to have been created through the mechanism described in ITI TF-3: 4.1.15 “Metadata Versioning Semantics” (currently in the Trial Implementation Supplement - XDS Metadata Update). This section describes this mechanism as applied to this transaction.

After the Notify XAD-PID Link Change transaction is processed, the contents of the Document Registry shall remain in a consistent state with regard to associations linking objects that carry a Patient ID attribute, specifically, that two objects linked by such an Association shall have the same Patient ID. See Section 3.64.4.1.3.2 for discussion of constraint conflict resolution. The exception is a SubmissionSet to DocumentEntry HasMember association that is labeled ‘Reference’. This situation is described in Section 3.64.4.1.3.1.4, item #5.

The following sections detail the required changes for each of the conditions listed. These changes shall be applied to each object to be updated in the Document Registry as described.

3.64.4.1.3.1.1 Creation of a New SubmissionSet

Each Notify XAD-PID Link Change transaction, which updates the XAD-PID associated with a single sourcePatientId, shall result in the creation of a new SubmissionSet object in the Document Registry. Changes to Document Registry objects shall be linked to this new SubmissionSet. These changes include:

Creating a new version of a DocumentEntry and deprecating the previous version
Creating a new version of a Folder and deprecating the previous version
Deprecating an Association
Creating a new Association

The following table shall be used to code the attributes of the new SubmissionSet. Attributes missing from the table are unchanged from normal SubmissionSet object coding.

Table 3.64.4.1.3.1.1-1: New SubmissionSet Attributes

Attribute	Description
author	Not included
contentTypeCode	XDS Affinity Domain defined code indicating the SubmissionSet was created as a result of a Notify XAD-PID Link Change transaction
homeCommunityId	Not included
intendedRecipient	Not included
patientId	Value of “ new XAD-PID ”
sourceId	OID for the sending application as provided in the MSH-3 field of the transaction (see Section 3.64.4.1.2.1)
submissionTime	The time the Document Registry processed the transaction

3.64.4.1.3.1.2 Overlapping Updates

When interpreting the rules described in the sections that follow, the results of a single Notify XAD-PID Link Change transaction shall not create two new versions of any logical object. The rules are written from the point of view of non-overlapping updates. The implementer shall manage overlaps.

3.64.4.1.3.1.3 Deprecated Objects

The Document Registry shall not make changes to any DocumentEntry or Folder objects with availabilityStatus of “Deprecated”.

3.64.4.1.3.1.4 DocumentEntry, not part of a Folder, not linked to other DocumentEntries

The Document Registry shall:

Extract the version and logicalId attributes from the most current version of the DocumentEntry object.
Create a new copy of the DocumentEntry adding the following changes:

Version attribute has value of one more than the version attribute of the existing DocumentEntry
logicalId is kept the same
id attribute is a new UUID (this has a cascading effect to some attributes within; Classifications and ExternalIdentifiers within will also need new id attribute values (UUIDs))
The PatientID attribute is set to the “ new XAD-PID ”
If “subsumed local patient ID” is present, the sourcePatientId attribute is set to the new “local Patient Id”

Assign existing DocumentEntry an availabilityStatus of “Deprecated”.
Create a HasMember Association in the new SubmissionSet linked to the new DocumentEntry. Its PreviousVersion slot shall contain the value of the version attribute of the existing DocumentEntry.
If the existing version is linked to an existing SubmissionSet via a HasMember Association with SubmissionSetStatus set to ‘Reference’, then deprecate that Association and create a new Association between that existing SubmissionSet and the new DocumentEntry. (Note: this is the only case where associated objects do not have the same PatientID attribute value.)

3.64.4.1.3.1.5 DocumentEntry, not part of a Folder but linked to other DocumentEntries

The Document Registry shall:

Perform the actions described in Section 3.64.4.1.3.1.4.
For each DocumentEntry to DocumentEntry Association linked to the existing DocumentEntry:

If, after this update, both DocumentEntries will have the “ new XAD-PID ” then create a new copy of the DocumentEntry to DocumentEntry Association linking the associated DocumentEntry to the new version of the changed DocumentEntry. Note that the associated DocumentEntry may or may not have been updated by this transaction. It is the net effect that is important: Patient IDs in these DocumentEntry objects either match or don’t match. If both DocumentEntries are updated by this transaction then only a single new Association is created.
If, after this XAD-PID update, the two DocumentEntries have different XAD-PIDs then a Document Registry constraint conflict can occur. Refer to Section 3.64.4.1.3.2 for various options on how to proceed.
A side effect of this step is that all RPLC and XFRM_RPLC Associations are lost. The targetObject attribute of these Associations always references a deprecated DocumentEntry that cannot have its XAD-PID updated, as described in Section 3.64.4.1.3.1.3. To trace RPLC and XFRM_RPLC Associations each of the previous versions of the new DocumentEntry must be examined.

3.64.4.1.3.1.6 DocumentEntry, part of a Folder, not linked to other DocumentEntries

If all DocumentEntries that are members of the Folder carry the same sourcePatientId then the Document Registry shall:

Perform the actions described in Section 3.64.4.1.3.1.4 on each DocumentEntry.
Extract the version and logicalId attributes from the existing version of the Folder
Create a copy of the Folder adding the following changes:

Version attribute has value of one more than the existing version
logicalId is kept the same
id attribute is a new UUID (this has a cascading effect to some attributes within; Classifications and ExternalIdentifiers within will also need new id attribute values (UUIDs))
The Patient ID attribute is set to the new XAD-PID.

Assign existing version of the Folder status of “Deprecated”.
Create a HasMember Association in the new SubmissionSet linked to the new Folder. It will contain a Slot with name PreviousVersion. This Slot shall contain the value of the version attribute of the existing Folder.
Create a HasMember Association connecting the new Folder to each of the new DocumentEntries according to the usual rules for inclusion in a Folder.
Create a HasMember Association in the new SubmissionSet for each of the Associations created in the previous step according to the usual rules for adding DocumentEntries to Folders.

If all DocumentEntries that are members of the Folder do not carry the same sourcePatientId then a Document Registry constraint conflict can occur. Refer to Section 3.64.4.1.3.2 for various options on how to proceed.

3.64.4.1.3.1.7 DocumentEntry, part of a Folder and linked to other DocumentEntries via Associations

For a single Notify XAD-PID Link Change transaction, the Document Registry shall perform the instructions in Sections 3.64.4.1.3.1.5 and 3.64.4.1.3.1.6, not repeating any operation:

A single new version of a particular logical DocumentEntry is created, never more
A single new version of a particular logical Folder is created, never more
A single new version of a particular logical Association is created, never more

An example of the interpretation of these rules is for a DocumentEntry that is both a member of a Folder and part of a DocumentEntry to DocumentEntry Association; only a single new version of the DocumentEntry is created that becomes part of the new version of the Folder and is also included in the new DocumentEntry to DocumentEntry association.

3.64.4.1.3.2 Constraint Conflict Resolution

Implementers of Document Registries must also consider that in addition to Document Entry updates, this transaction will also affect existing associations (XFRM, APND, RPLC and XFRM_RPLC) and folders that involve any of these updated Document Entries. The Document Registry shall maintain all the appropriate validation rules and constraints defined in the XDS metadata model. This includes the requirement that all members of folders and associations must have the same patientId . As the Document Registry processes this transaction, this condition may no longer apply, requiring that the Document Registry take corrective action. For example, if a folder contains Document Entries with different values for sourcePatientId . Since the other documents will preserve their current value for patientId , it becomes clear that they cannot all remain together in the same folder. Similar situations can occur with the other association types.

The manner by which the Document Registry will handle these situations is not mandated by IHE. However, the approach the Document Registry uses shall preserve the consistency of its database and be properly documented so that users and administrators can have a clear expectation on the system behavior under these conditions and know how to proceed with manual interventions required to correct the Document Registry state.

Strategies on how to deal with this problem can vary considerably. Here are two possible approaches that may be used by the implementers:

The requirements for this transaction preserve relationships when all participants have the same sourcePatientId. In this first approach, the presence of a single Document Entry with a different value for sourcePatientId would prevent such action and result in all changed Document Entries being dropped from the relationship. This action is only applied to the relationship in question. Since it may not be possible to correctly restore folders for all cases, the update would have to be followed by a report or alert mechanism by which users or (more likely) system administrators could investigate if any of these dropped relationships need to be re-established.
In another approach, in the presence of a single patientID conflict, the update is aborted and no changes are made to the Document Registry. Rather, it puts a “hold” on the Notify XAD-PID Link Changes transaction. In this approach the entire transaction is passed to a system administrator to manually resolve the discrepancies and complete the transaction.

These are just two possible strategies, and one is not necessarily more “ correct” than the other. Implementers will have to evaluate the pros-cons of each alternative in respect to their product architecture and the needs of the client environments and decide which one is more appropriate for them. The important point here is that in regards to which strategy is chosen, implementers must provide clear documentation on the matter describing the behavior of their system.

3.64.5 Security Considerations

No transaction-specific security considerations.

3.64.5.1 Security Audit Considerations

The Notify XAD-PID Link Change transaction (A43) is to be audited as “Patient Record” events, as defined in ITI TF-2: Table 3.20.4.1.1.1-1. The actors involved in the transaction shall create audit data in conformance with DICOM “Patient Record”. Logically, a link change operation consists of updates to possibly many patient records.

The following tables show items that are required to be part of the audit record for this transaction.

3.64.5.1.1 Patient Identity Cross Reference Manager audit message

The Patient Identity Cross Reference Manager shall record one audit event as a result of this transaction.

	Field Name	Opt	Value Constraints
Event AuditMessage/EventIdentification	EventID	M	EV(110110, DCM, “Patient Record”)
	EventActionCode	M	“U” (update) for A43
	EventDateTime	M	not specialized
	EventOutcomeIndicator	M	not specialized
	EventTypeCode	M	EV(“ITI-64”, “IHE Transactions”, “Notify XAD-PID Link Change”)
Source (Patient Identifier Cross-Reference Manager) (1)
Human Requestor (0..n)
Destination (Document Registry) (1)
Audit Source (Patient Identifier Cross-Reference Manager) (1)
localPatientId (1)
subsumedLocalPatientId (0..1)
newPatientId(1)
previousPatientId(1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	M	The identity of the Patient Identity Cross-Reference Manager 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	not specialized
	NetworkAccessPointTypeCode	U	not specialized
	NetworkAccessPointID	U	not specialized

Destination AuditMessage/ ActiveParticipant	UserID	M	The identity of the Document Registry 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

not specialized

AuditEnterpriseSiteID

not specialized

AuditSourceTypeCode

not specialized

localPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	C	If subsumedLocalPatientId is present, then this value shall equal "1" (Origination / Creation). Otherwise, this value is not specialized.
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	the patient ID in HL7 CX format
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="localPatientId" (the literal string, base64 encoded)

subsumedLocalPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	M	"14" (Logical deletion)
	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	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="subsumedPatientId" (the literal string, base64 encoded)

newPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	C	If newPatientId and previousPatientId are not equal, then this value shall equal "1" (Origination / Creation). Otherwise, this value is not specialized.
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	the patient ID in HL7 CX format
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="newPatientId" (the literal string, base64 encoded)

previousPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	C	If newPatientId and previousPatientId are not equal, then this value shall equal "14" (Logical deletion). Otherwise, this value is not specialized.
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	the patient ID in HL7 CX format
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="previousPatientId" (the literal string, base64 encoded)

3.64.5.1.2 Document Registry audit message

The Document Registry shall record one audit event as a result of this transaction.

	Field Name	Opt	Value Constraints
Event AuditMessage/ EventIdentification	EventID	M	EV(110110, DCM, “Patient Record”)
	EventActionCode	M	“U” (update) for A43
	EventDateTime	U	not specialized
	EventOutcomeIndicator	U	not specialized
	EventTypeCode	M	EV(“ITI-64”, “IHE Transactions”, “Notify XAD-PID Link Change”)
Source (Patient Identifier Cross-Reference Manager) (1)
Destination (Document Registry) (1)
Audit Source (Document Registry) (1)
localPatientId (1)
subsumedLocalPatientId (0..1)
newPatientId(1)
previousPatientId(1)
SubmissionSet (1)

Where:

Source AuditMessage/ ActiveParticipant	UserID	M	The identity of the Patient Identity Cross-Reference Manager 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 Document Registry 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

not specialized

AuditEnterpriseSiteID

not specialized

AuditSourceTypeCode

not specialized

localPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	C	If subsumedLocalPatientId is present, then this value shall equal "1" (Origination / Creation). Otherwise, this value is not specialized.
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="localPatientId" (the literal string, base64 encoded)

subsumedLocalPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	M	"14" (Logical deletion)
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="subsumedPatientId" (the literal string, base64 encoded)

newPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	C	If newPatientId and previousPatientId are not equal, then this value shall equal "1" (Origination / Creation). Otherwise, this value is not specialized.
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element will occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="newPatientId" (the literal string, base64 encoded)

previousPatientId (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“1” (person)
	ParticipantObjectTypeCodeRole	M	“1” (patient)
	ParticipantObjectDataLifeCycle	C	If newPatientId and previousPatientId are not equal, then this value shall equal "14" (Logical deletion). Otherwise, this value is not specialized.
	ParticipantObjectIDTypeCode	U	not specialized
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The patient ID in HL7 CX format.
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	M	The ParticipantObjectDetail element shall occur twice. In the first element: Type=MSH-10 (the literal string) Value=the value of MSH-10 (from the message content, base64 encoded) In the second element: Type="urn:ihe:iti:xpid:2017:patientIdentifierType" (the literal string) Value="previousPatientId" (the literal string, base64 encoded)

SubmissionSet (AuditMessage/ ParticipantObjectIdentification)	ParticipantObjectTypeCode	M	“2” (System)
	ParticipantObjectTypeCodeRole	M	“20” (job)
	ParticipantObjectDataLifeCycle	U	not specialized
	ParticipantObjectIDTypeCode	M	EV(“urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd”, “IHE XDS Metadata”, “submission set classificationNode”)
	ParticipantObjectSensitivity	U	not specialized
	ParticipantObjectID	M	The value of the XDSSubmissionSet.entryUUID
	ParticipantObjectName	U	not specialized
	ParticipantObjectQuery	U	not specialized
	ParticipantObjectDetail	U	not specialized