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/
|
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/
|
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 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/
|
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/
|
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 Role ID") | |
| NetworkAccessPointTypeCode | M | “1” for machine (DNS) name, “2” for IP address | |
| NetworkAccessPointID | M | The machine name or IP address. |
|
Audit Source
AuditMessage/
|
AuditSourceID | U | not specialized |
| AuditEnterpriseSiteID | U | not specialized | |
| AuditSourceTypeCode | U | not specialized |
|
Patient
(AuditMessage/
|
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/
|
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/
|
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 Role ID") | |
| NetworkAccessPointTypeCode | M | “1” for machine (DNS) name, “2” for IP address | |
| NetworkAccessPointID | M | The machine name or IP address. |
|
Destination
AuditMessage/
|
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 Role ID") | |
| NetworkAccessPointTypeCode | M | “1” for machine (DNS) name, “2” for IP address | |
| NetworkAccessPointID | M | The machine name or IP address. |
|
Audit Source
AuditMessage/
|
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/
|
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/
|
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 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/
|
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/
|
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 Role ID") | |
| NetworkAccessPointTypeCode | M | “1” for machine (DNS) name, “2” for IP address | |
| NetworkAccessPointID | M | The machine name or IP address. |
|
Audit Source
AuditMessage/
|
AuditSourceID | U | not specialized |
| AuditEnterpriseSiteID | U | not specialized | |
| AuditSourceTypeCode | U | not specialized |
|
Patient
(AuditMessage/
|
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/
|
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/
|
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 Role ID") | |
| NetworkAccessPointTypeCode | M | “1” for machine (DNS) name, “2” for IP address | |
| NetworkAccessPointID | M | The machine name or IP address. |
|
Destination
AuditMessage/
|
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 Role ID") | |
| NetworkAccessPointTypeCode | M | “1” for machine (DNS) name, “2” for IP address | |
| NetworkAccessPointID | M | The machine name or IP address. |
|
Audit Source
AuditMessage/
|
AuditSourceID | U | not specialized |
| AuditEnterpriseSiteID | U | not specialized | |
| AuditSourceTypeCode | U | not specialized |
|
Patient
(AuditMessage/
|
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) |