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.8 Patient Identity Feed [ITI-8]

This section corresponds to transaction [ITI-8] of the IHE IT Infrastructure Technical Framework. Transaction [ITI-8] is used by the Patient Identity Source, Patient Identifier Cross-reference Manager and Document Registry Actors.

3.8.1 Scope

This transaction communicates patient information, including corroborating demographic data, after a patient’s identity is established, modified or merged or after the key corroborating demographic data has been modified.

3.8.2 Use Case Roles

Actor: Patient Identity Source

Role: Provides notification to the Patient Identifier Cross-reference Manager and Document Registry for any patient identification related events, including creation, updates, merges, etc.

Actor: Patient Identifier Cross-reference Manager

Role: Serves a well-defined set of Patient Identification Domains. Based on information provided in each Patient Identification Domain by a Patient Identification Source Actor, it manages the cross-referencing of patient identifiers across Patient Identification Domains.

Actor: Document Registry

Role: Uses patient identifiers provided by Patient Identity Source to ensure that XDS Documents metadata registered is associated with a known patient and updates patient identity in document metadata by tracking identity change operations (e.g., merge).

3.8.3 Referenced Standards

HL7 Version 2.3.1 Chapter 2 – Control, Chapter 3 – Patient Administration

HL7 Version 2.3.1 was selected for this transaction for the following reasons:

  • It provides a broader potential base of Patient Identity Source Actors capable of participating in the profiles associated with this transaction.
  • It allows existing ADT Actors from within IHE Radiology to participate as Patient Identity Source Actors.

3.8.4 Messages

Figure 3.8-1: Patient Identity Sequence

3.8.4.1 Patient Identity Management – Admit/Register or Update Patient

3.8.4.1.1 Trigger Events

The following events from a Patient Identity Source will trigger one of the Admit/Register or Update messages:

  • A01 – Admission of an in-patient into a facility
  • A04 – Registration of an outpatient for a visit of the facility
  • A05 – Pre-admission of an in-patient (i.e., registration of patient information ahead of actual admission).

Changes to patient demographics (e.g., change in patient name, patient address, etc.) shall trigger the following Admit/Register or Update message:

  • A08 – Update Patient Information

The Patient Identifier Cross-reference Manager shall only perform cross-referencing logic on messages received from Patient Identity Source Actors. For a given Patient Identifier Domain there shall be one and only one Patient Identity Source Actor, but a given Patient Identity Source may serve more than one Patient Identifier Domain.

3.8.4.1.2 Message Semantics

The Patient Identity Feed transaction is conducted by the HL7 ADT message, as defined in the subsequent sections. The Patient Identity Source shall generate the message whenever a patient is admitted, pre-admitted, or registered, or when some piece of patient demographic data changes. Pre-admission of inpatients shall use the A05 trigger event. 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.

Required segments are defined below. Other segments are optional

Table 3.8-1: ADT Patient Administration Messages

ADT Patient Administration Message Chapter in HL7 2.3.1
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
PV1 Patient Visit 3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT message to its sender. See ITI TF-2: C.2.3, “Acknowledgement Modes”, for definition and discussion of the ACK message.

This transaction does not require Patient Identity Source Actors to include any attributes not already required by the corresponding HL7 message (as is described in the following sections). This minimal set of requirements enables inclusion of the largest range of Patient Identity Source Actor systems.

This transaction does place additional requirements on the Patient Identifier Cross-reference Manager and Document Registry Actors, requiring them to accept a set of HL7 attributes beyond what is required by HL7. (See Section 3.8.4.1.3 for a description of these additional requirements.)

3.8.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 at least two components. The first component shall have a value of ADT ; the second component shall have one of the values of A01 , A04 , A05 or A08 as appropriate. The third component is optional; however, if present, it shall have the value of ADT_A01 for all message types, as defined in HL7 v2.3.1 Table 0354.

3.8.4.1.2.2 EVN Segment

The Patient Identity Source is not required to send any attributes within the EVN segment beyond what is specified in the HL7 standard. See Table C.1-4 in ITI TF-2: C.2.4 “Common Segment Definitions” for the specification of this segment.

3.8.4.1.2.3 PID Segment

The Patient Identity Source is not required to send any attributes within the PID segment beyond what is specified in the HL7 standard.

When sending ADT messages A01, A04, and A05, the Patient Identity Source shall populate appropriate values in the fields as listed in Table 3.8-2:

Table 3.8-2: IHE Profile - PID segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 4 SI O 00104 Set ID - Patient ID
2 20 CX O 00105 Patient ID
3 250 CX R 00106 Patient Identifier List
4 20 CX O 00107 Alternate Patient ID
5 250 XPN R 00108 Patient Name
6 250 XPN R2 00109 Mother’s Maiden Name
7 26 TS R2 00110 Date/Time of Birth
8 1 IS R2 0001 00111 Administrative Sex
9 250 XPN O 00112 Patient Alias
10 250 CE O 0005 00113 Race
11 250 XAD R2 00114 Patient Address
12 4 IS O 0289 00115 County Code
13 250 XTN R2 00116 Phone Number - Home
14 250 XTN R2 00117 Phone Number - Business
15 250 CE O 0296 00118 Primary Language
16 250 CE O 0002 00119 Marital Status
17 250 CE O 0006 00120 Religion
18 250 CX O 00121 Patient Account Number
19 16 ST R2 00122 SSN Number – Patient
20 25 DLN R2 00123 Driver's License Number - Patient
21 250 CX O 00124 Mother's Identifier
22 250 CE O 0189 00125 Ethnic Group
23 250 ST O 00126 Birth Place
24 1 ID O 0136 00127 Multiple Birth Indicator
25 2 NM O 00128 Birth Order
26 250 CE O 0171 00129 Citizenship
27 250 CE O 0172 00130 Veterans Military Status
28 250 CE O 0212 00739 Nationality
29 26 TS O 00740 Patient Death Date and Time
30 1 ID O 0136 00741 Patient Death Indicator

Adapted from the HL7 standard, Version 2.3.1

Note 1: It is likely that not all attributes marked as R2 above will be sent in some environments.

Note 2: The field length of many attributes in this table exceeds the requirements stated in HL7 v2.3.1. The Patient Identifier Cross-reference Manager (receiver) is required to support these extended lengths to cope with the information it needs to complete identifier cross-referencing logic. The Patient Identity Source may or may not send values of the full length listed in this table.

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

The Patient Identity Source shall provide the patient identifier in the ID component (first component) of the PID-3 field (PID-3.1). The Patient Identity Source shall use component PID-3.4 to convey the assigning authority (Patient Identification Domain) of the patient identifier. Either the first subcomponent (namespace ID) or the second and third subcomponents (universal ID and universal ID type) shall be populated. If all three subcomponents are populated, the first subcomponent shall reference the same entity as is referenced by the second and third components.

3.8.4.1.2.4 PV1 Segment

The Admit/ Register or Update Patient message is not required to include any attributes within the PV1 segment beyond what is specified in the HL7 standard.

3.8.4.1.3 Expected Actions – Patient Identifier Cross-reference Manager

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the PID segment as specified in HL7 standard as well as their extended field length as defined in Table 3.8-2. This is to ensure that the Patient Identifier Cross-reference Manager can handle a sufficient set of corroborating information in order to perform its cross-referencing function.

If the PID-3.4 (assigning authority) component is not included in the message (as described in Section 3.8.4.1.2.3) the Patient Identifier Cross-reference Manager shall fill PID-3.4 prior to storing the ID information and performing its cross-referencing activities. The information filled by the Patient Identifier Cross-reference Manager is based on the configuration associating each of the Patient Identity Source Actors with the subcomponents of the correct assigning authority (namespace ID, UID and UID type). (See Section 3.8.4.1.3.1 below for a list of required Patient Identifier Cross-reference Manager configuration parameters).

A single Patient Identity Source can serve multiple Patient Identification domains. The Patient Identifier Cross-reference Manager shall only recognize (by configuration) a single Patient Identity Source per domain. (See Section 3.8.4.1.3.1 below for a list of required Patient Identifier Cross-reference Manager configuration parameters).

The cross-referencing process (algorithm, human decisions, etc.) is performed within the Patient Identifier Cross-reference Manager Actor, but its specification is beyond the scope of IHE.

Once the Patient Identifier Cross-reference Manager has completed its cross-referencing function, it shall make the newly cross-referenced identifiers available to PIX queries and send out notification to any Patient Identifier Cross-reference Consumers that have been configured (as being interested in receiving such notifications) using the PIX Update Notification transaction (see Section 3.10 for the details of that transaction).

3.8.4.1.3.1 Required Patient Identifier Cross-reference Manager Configuration

The following items are expected to be parameters that are configurable on the Patient Identifier Cross-reference Manager Actor. For each Patient Identification Domain included in the Identification Cross-reference Domain managed by a Patient Identifier Cross-reference Manager Actor, the following configuration information is needed:

  • Identifier of the Domain. This identifier shall specify all 3 components of the HL7 assigning authority (including the namespace ID and/or both the universal ID and universal ID type subcomponents) of the PID-3 field for the identification of the domain.
  • Patient Identity Source for the domain. This is expected to be the MSH-3 Sending Application and the corresponding MSH-4 Sending Facility fields in the HL7 ADT message. (Alternative identification schemes might include IP address of the Patient Identity Source or Node Authentication if the Audit Trail and Node Authentication Integration Profile is used.)
3.8.4.1.4 Expected Actions – Document Registry

The Document Registry shall be capable of accepting attributes in the PID segment as specified in Table 3.8. The Patient Identity Feed transaction contains more triggers and data than what the XDS Document Registry needs for its operation. In particular, A08 – Update Patient Information, if received shall be ignored.

Table 3.8: IHE Profile - PID segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
3 250 CX R 00106 Patient Identifier List

Adapted from the HL7 standard, Version 2.3.1

Note: This table reflects only the attributes required to be handled by the Document Registry (receiver). Other attributes of the PID Segment may be ignored.

If subcomponents 2 and 3 (the universal ID and the universal ID Type of Assigning Authority) of the Patient Identification Domain of the XDS Affinity Domain in PID-3.4 are not filled in the message (as described in Section 3.8.4.1.2.3) the Document Registry shall fill subcomponents 2 and 3 of the Patient Identification Domain of the XDS Affinity Domain prior to storing the patient identity in the registry. The assigning authority information filled by the Document Registry is based on its configuration of the Patient Identification Domain of the XDS Affinity Domain. (See Section 3.8.4.1.4.1 below for a list of required Document Registry configuration parameters.)

The Document Registry shall store only the patient identifiers of the patient identification domain designated by the XDS Affinity Domain for document sharing in the registry. Patient identifiers of other patient identification domains (assigning authorities), if present in a received message, shall be ignored.

3.8.4.1.4.1 Required Document Registry Configuration

The following items are expected to be parameters that are configurable on the Document Registry:

  • Identifier of the Patient Identification Domain of the XDS Affinity Domain. This identifier shall be specified with 3 components of the HL7 assigning authority (data type HD): namespaceID, universal ID and universal ID type. The universal ID shall be an ISO OID (Object Identifier), and therefore the universal ID Type must be “ISO”.

3.8.4.2 Patient Identity Management –Patient Identity Merge (Merge Patient ID)

3.8.4.2.1 Trigger Events

When two patients’ records are found to identify the same patient by a Patient Identity Source in a Patient Identifier Domain and are merged, the Patient Identity Source shall trigger the following message:

  • A40 – Merge Patient – Internal ID

An A40 message indicates that the Patient Identity Source has done a merge within a specific Patient Identification Domain. That is, MRG-1 (patient ID) has been merged into PID-3 (Patient ID).

3.8.4.2.2 Message Semantics

The Patient Identity Feed transaction is an HL7 ADT message. The message shall be generated by the system (Patient Identity Source Actor) that performs the update whenever two patient records are found to reference the same person.

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.

The segments of the HL7 Merge Patient message listed below are required, and the detailed description of the message is provided in Sections 3.8.4.2.2.1 – 3.8.4.2.2.6. The PV1 segment is optional.

Table 3.8-3: ADT A40 Patient Administration Message

ADT A40 Patient Administration Message Chapter in HL7 v2.3.1
MSH Message Header 2
EVN Event Type 3
PID Patient Identification 3
MRG Merge Information 3
[PV1] Patient Visit 3

Each message shall be acknowledged by the HL7 ACK message sent by the receiver of ADT message to its sender. See ITI TF-2: C.2.3 “Acknowledgement Modes” for definition and discussion of the ACK message.

A separate merge message shall be sent for each pair of patient records to be merged. For example, if Patients A, B, and C are all to be merged into Patient B, two ADT^A40 messages would be sent. In the first ADT^A40 message, patient B would be identified in the PID segment and Patient A would be identified in the MRG segment. In the second ADT^A40 message, patient B would be identified in the PID segment, and Patient C would be identified in the MRG segment.

Modification of any patient demographic information shall be done by sending a separate Update Patient Information (A08) message for the current Patient ID. An A40 message is the only method that may be used to update a Patient ID.

3.8.4.2.2.1 MSH Segment

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

Field MSH-9 Message Type shall have at least two components. The first component shall have a value of ADT ; the second component shall have value of A40 . The third component is optional; however, if present, it shall have a value of ADT_A39 .

3.8.4.2.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.8.4.2.2.3 PID Segment

The PID segment shall be constructed as defined in Section 3.8.4.1.2.3.

3.8.4.2.2.4 MRG Segment

The MRG segment shall be constructed as defined in Table 3.8-4:

Table 3.8-4: IHE Profile - MRG segment

SEQ LEN DT OPT TBL# ITEM# ELEMENT NAME
1 250 CX R 00211 Prior Patient Identifier List
2 250 CX O 00212 Prior Alternate Patient ID
3 250 CX O 00213 Prior Patient Account Number
4 250 CX R2 00214 Prior Patient ID
5 250 CX O 01279 Prior Visit Number
6 250 CX O 01280 Prior Alternate Visit ID
7 250 XPN R2 01281 Prior Patient Name

Adapted from the HL7 Standard, Version 2.3.1

The PID and PV1 segments contain the dominant patient information, including patient identifier and the issuing assigning authority. The MRG segment identifies the “old” or secondary patient records to be de-referenced. HL7 does not require that the “old” record be deleted; it does require that the “old” identifier shall not be referenced in future transactions following the merge.

The Patient Identity Source shall send the “old” patient identifier (to be merged) in MRG-1, with the identifier value in the component MRG-1.1 and the assigning authority in the component MRG-1.4. The Patient Identity Source shall populate the same value of the assigning authority in PID-3.4, in the component MRG-1.4.

3.8.4.2.2.5 PV1 Segment

PV1 segment shall be constructed as defined in Section 3.8.4.1.2.4.

3.8.4.2.3 Expected Actions

The Patient Identifier Cross-reference Manager shall be capable of accepting attributes in the MRG segment as specified in Table 3.8-4.

In addition, the Patient Identifier Cross-reference Manager shall perform the Expected Actions as specified in Section 3.8.4.1.3.

When the Patient Identifier Cross-reference Manager receives the ADT^A40 message type of the Patient Identity Feed transaction, it shall cross-reference the patient identifiers provided in the PID-3 and MRG-1 fields of the message by replacing any references it is maintaining internally to the patient ID provided in the MRG-1 field by the patient ID included in the PID-3 field. After the identifier references are replaced, the Patient Identifier Cross-reference Manager shall reapply its internal cross-referencing logic/ policies before providing the updated information via either the PIX Query or PIX Notification Transactions.

3.8.4.2.4 Expected Actions – Document Registry

The Document Registry shall be capable of accepting attributes in the MRG segment as specified in Table 3.8-4. Other attributes may exist, but the Document Registry shall ignore them.

In addition, the Document Registry shall perform the Expected Actions as specified in Section 3.8.4.1.4.

When the Document Registry receives the ADT^A40 message type of the Patient Identity Feed transaction, it shall merge the patient identity specified in MRG-1 (secondary patient identity) into the patient identity specified in PID-3 (primary patient identity) in its registry. After the merge, all Document Submission Sets (including all Documents and Folders beneath them) under the secondary patient identity before the merge shall point to the primary patient identity. The secondary patient identity shall no longer be referenced in the future services provided by the Document Registry.

Changes resulting from an A40 Merge message are not reversible. No UnMerge message is supported by this transaction.

See Section 3.18.4.1.2.3.9 for details of how this message type affects results of a Registry Stored Query [ITI-18] transaction and the end of ITI TF-2: 3.42.4.1.3.3.2 to see how it affects the Register Document Set-b [ITI-42] transaction.

An A40 merge message contains two fields of interest:

  • MRG-1 – subsumed patient identifier: the patient identifier whose use is being ended
  • PID-3 – surviving patient identifier: the patient identifier whose use continues.

After a merge, the patient identifier PID-3 represents all records formerly represented by either MRG-1 or PID-3. All other fields may be ignored.

The following conditions shall be detected by the Document Registry. Messages containing these conditions shall not update the state of the Document Registry.

  • The subsumed patient identifier is not issued by the correct Assigning Authority according to the Affinity Domain configuration.
  • The surviving patient identifier is not issued by the correct Assigning Authority according to the Affinity Domain configuration.
  • The subsumed and surviving patient identifiers are the same.
  • The subsumed patient identifier has already been subsumed by an earlier message.
  • The surviving patient identifier has already been subsumed by and earlier message.
  • Both the subsumed and surviving patient identifier must convey a currently active patient identifier known to the Registry Actor.

If none of the above conditions occur then the Document Registry shall perform the following duties:

  • Records the merge. Only the subsumed and surviving patient identifiers need be remembered. A patient identifier merge affects the processing of future Register Document Set-b [ITI-42] transactions. See ITI TF-2: 3.42.4.1.3.3 Enforcement of Attributes and ITI TF-2: 3.42.4.1.3.5 Document Relationships for more details.
  • Multiple merge transactions can form a recorded merge chain, where the Subsumed identifier of the current merge is the Surviving identifier of a previous merge.
  • Register Document Set-b transactions referencing a subsumed identifier are rejected with an XDSUnknownPatientId error.
  • Registry Stored Query transactions referencing a subsumed identifier return no content.
  • Registry Stored Query transactions referencing a surviving identifier successfully match the entire recorded merge chain and return appropriate metadata.

Note: This transaction does not specify how the merge is to be implemented. It may or may not change the stored form of the metadata. It only specifies the observable results from the perspective of the Registry Stored Query [ITI-18] transaction and the Register Document Set-b [ITI-42] transaction.

3.8.5 Security Considerations

3.8.5.1 Audit Record Considerations – Admit/Register or Update Patient

The Patient Admit/Register transactions (A01, A04, A05) and Update Patient Information (A08) transaction are to be audited as “Patient Record” events, as defined in Table 3.20.4.1.1.1-1. The following tables show items that are required to be part of the audit record for these specific PIX transactions.

3.8.5.1.1 Patient Identity Source Actor audit message:
Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110110, DCM, “Patient Record”)
EventActionCode M

“C” (create) for A01, A04, A05

“U” (update) for A08

EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)
Source (Patient Identity Source Actor) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)
Audit Source (Patient Identity Source Actor) (1)
Patient (1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identity Source 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”)
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 or 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”)
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 M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)
3.8.5.1.2 Patient Identifier Cross-reference Manager or Document Registry Actor audit message:
Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110110, DCM, “Patient Record”)
EventActionCode M

“C” (create) for A01, A04, A05

“U” (update) for A08

EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)
Source (Patient Identity Source Actor) (1)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)
Audit Source (Patient Identifier Cross-reference Manager or Document Registry) (1)
Patient(1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identity Source 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”)
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 or 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”)
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

3.8.5.2 Audit Record Considerations – Patient Identity Merge (Merge Patient ID)

The Patient Identity Merge transaction (A40) is to be audited as a “Patient Record” event, as defined in Table 3.20.4.1.1.1-1. The following tables show items that are required to be part of the audit record for the Patient Identity Merge transaction. Logically, a merge operation consists of a delete on one patient record, and an update of another patient record. Separate audit records shall be written for the delete operation and the update operation.

3.8.5.2.1 Patient Identity Source Actor audit message:
Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110110, DCM, “Patient Record”)
EventActionCode M

“D” (delete) for the Delete operation

“U” (update) for the Update operation

EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)
Source (Patient Identity Source Actor) (1)
Human Requestor (0..n)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)
Audit Source (Patient Identity Source Actor) (1)
Patient(1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identity Source 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”)
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 or 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”)
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 M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)
3.8.5.2.2 Patient Identifier Cross-reference Manager or Document Registry Actor audit message:

 

Field Name Opt Value Constraints

Event

AuditMessage/
EventIdentification

EventID M EV(110110, DCM, “Patient Record”)
EventActionCode M

“D” (delete) for the Delete audit record

“U” (update) for the Update audit record

EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV(“ITI-8”, “IHE Transactions”, “Patient Identity Feed”)
Source (Patient Identity Source Actor) (1)
Destination (Patient Identifier Cross-reference Manager or Document Registry) (1)
Audit Source (Patient Identifier Cross-reference Manager or Document Registry) (1)
Patient(1)

Where:

Source

AuditMessage/
ActiveParticipant

UserID M The identity of the Patient Identity Source 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”)
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 or 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”)
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 M Type=MSH-10 (the literal string), Value=the value of MSH-10 (from the message content, base64 encoded)