3.20 Record Audit Event [ITI-20]
This section corresponds to the Record Audit Event [ITI-20] transaction of the IHE IT Infrastructure Technical Framework. This transaction is used to report auditable events to an Audit Record Repository.
3.20.1 Scope
This transaction is used to report auditable events to an Audit Record Repository.
3.20.2 Actor Roles
Table 3.20.2-1: Actor Roles
| Actor: | Any actor or any other application that is grouped with the Secure Node or Secure Application. |
| Role: | Create an audit record and transmit this record to the Audit Record Repository. |
| Actor: | Audit Record Repository |
| Role: | Receive an audit record from the Audit Record Creator and store this for audit purposes. |
| Actor: | Audit Record Forwarder |
| Role: | Forward an audit record to Audit Record Repositories. |
3.20.3 Referenced Standards
| RFC5424 | The Syslog Protocol. |
| RFC5425 | Transmission of Syslog Messages over TLS |
| RFC5426 | Transmission of Syslog Messages over UDP |
| RFC7525 | Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| DICOM |
DICOM PS3.15 Annex A.5 http://medical.nema.org/medical/dicom/current/output/chtml/part15/sect_A.5.html |
| ASTM E2147-01 | Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems |
| NIST SP 800-92 | Guide to Computer Security Log Management. |
| W3C XML 1.0 | Extensible Markup Language (XML) 1.0 |
3.20.4 Messages
Figure 3.20.4-1: Interaction Diagram
Note 1: Any actor initiating [ITI-20] may send to more than one Audit Record Repository.
Note 2: The Audit Repository that receives an [ITI-20] transaction may or may not be grouped with an Audit Record Forwarder. This diagram does not show a chain of forwarding between actors.
UML source for Figure 3.20.4-1
3.20.4.1 Send Audit Event – Syslog Interaction
An actor that is grouped with Secure Node or Secure Application detects an event that should be reported and uses the Audit Event message to send a report about the event to an Audit Record Repository.
This Audit Event message uses the Syslog protocol defined by RFC5424. The Syslog protocol is also used for a wide variety of other event reporting purposes.
RFC5424 defines a Syslog message that includes a free-form message. This Audit Event constrains the Syslog message to use a DICOM schema to specify the message content. See Section 3.20.7.
DICOM has defined a basic event report schema, and some basic event descriptions. IHE has extended this to define other specific event reports for security and privacy events. The Audit Event messages defined in this transaction can be mixed together with other Syslog messages. Organizations and systems may also be using these event schema for reporting events not defined by IHE or DICOM.
The Audit Record Repository and Audit Record Forwarder should be prepared to handle Syslog messages in other formats, as well as messages complying with the IHE Audit Trail Format (defined in Section 3.20.7) that are being used for other purposes.
3.20.4.1.1 Trigger Events
There are two trigger events:
- A Secure Node or Secure Application detects an event that should be reported to the Audit Record Repository. This transaction does not specify all of the policies or reasons for reporting events. They may be specified in other IHE profiles, they may be specified by local law or regulation, or they may be specified by local policy.
- An Audit Record Forwarder determines that a received Syslog message should be sent to another Audit Record Repository. This transaction does not specify what rules or policies determine whether a Syslog message should be forwarded.
The Secure Node or Secure Application shall create the Audit Event message and transmit it to the Audit Record Repository as soon as possible.
The Audit Record Forwarder shall forward the Audit Event message to the Audit Record Repository as soon as possible.
If the Secure Application, Secure Node, or Audit Record Forwarder is unable to send the message to the Audit Record Repository (e.g., it has lost network connectivity or has lost the TLS connection to the Audit Record Repository), then the actor shall store the audit record locally and send it when it is able.
The Audit Record Forwarder may delete its local copy of the Audit Record after this record has been transmitted to the target Audit Record Repository.
3.20.4.1.1.1 DICOM and IHE Audit Event messages
An actor in any IHE profile, when grouped with a Secure Node or Secure Application, shall be able to report the events defined in Table 3.20.4.1.1.1-1 (previously Table 3.20.6-1). This table of auditable events is not exhaustive. Additional reportable events are often identified for specific events in other IHE profiles, and are documented in that profile or transaction.
These events in this table shall be formatted in accordance with Section 3.20.7.
Table 3.20.4.1.1.1-1: Audit Event triggers (previously Table 3.20.6-1)
| Audit Event Trigger | Description | Source Vocabulary |
| Actor-start-stop | Startup and shutdown of any actor. Applies to all actors. Is distinct from hardware powerup and shutdown. | DICOM PS3.15 A.5.3 “Application Activity” |
| Audit-Log-Used | The audit trail repository has been accessed or modified by something other than the arrival of audit trail messages. | DICOM PS3.15 A.5.3 “Audit Log Used” |
| Begin-storing-instances | Begin storing SOP Instances for a study. This may be a mix of instances. | DICOM PS3.15 A.5.3 “Begin Transferring DICOM Instances” |
| Instances-deleted | SOP Instances are deleted from a specific study. One event covers all instances deleted for the particular study. | DICOM PS3.15 A.5.3 “DICOM Instances Accessed” or “DICOM Study Deleted” |
| Instances-Stored | Instances for a particular study have been stored on this system. One event covers all instances stored for the particular study. | DICOM PS3.15 A.5.3 “DICOM Instances Transferred” |
| Mobile-machine-event | Mobile machine joins or leaves secure domain. | DICOM PS3.15 A.5.3 “Network Entry” |
| Node-Authentication-failure | A secure node authentication failure has occurred during TLS negotiation, e.g., invalid certificate. | DICOM PS3.15 A.5.3 “Security Alert” |
| Order-record-event | Order record created, accessed, modified or deleted. Involved actors: Order Placer. This includes initial order, updates or amendments, delivery, completion, and cancellation. See note below. | DICOM PS3.16 Annex D “Order Record” |
| Patient-record-event | Patient record created, modified, or accessed. | DICOM PS3.16 Annex D “Patient Record” |
| PHI-export | Any export of PHI on media, either removable physical media such as CD-ROM or electronic transfer of files such as email. Any printing activity, paper or film, local or remote, which prints PHI. | DICOM PS3.15 A.5.3 “Export” |
| PHI-import | Any import of PHI on media, either removable physical media such as CD-ROM or electronic transfers of files such as email. | DICOM PS3.15 A.5.3 “Import” |
| Procedure-record-event | Procedure record created, modified, accessed or deleted. | DICOM PS3.16 Annex D “Procedure Record” |
| Query Information |
A query has been received, either as part of an IHE transaction, or as part other products functions. For example: 1) Modality Worklist Query 2) Instance or Image Availability Query 3) PIX, PDQ, or XDS Query Notes: The general guidance is to log the query event with the query parameters and not the result of the query. The result of a query may be very large and is likely to be of limited value vs. the overhead. The query parameters can be used effectively to detect bad behavior and the expectation is that given the query parameters the result could be regenerated if necessary. |
DICOM PS3.15 A.5.3 “Query” |
| Security Alert |
Security Administrative actions create, modify, delete, query, and display the following: Configuration and other changes, e.g., software updates that affect any software that processes protected information. Hardware changes may also be reported in this event. 1. Security attributes and auditable events for the application functions used for patient management, clinical processes, registry of business objects and methods (e.g., WSDL, UDDI), program creation and maintenance, etc. 2. Security domains according to various organizational categories such as entity-wide, institutional, departmental, etc. 3. Security categories or groupings for functions and data such as patient management, nursing, clinical, etc. 4. The allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods. 5. Security roles according to various task-grouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control. 6. User accounts. This includes assigning or changing password or other authentication data. It also includes the association of roles with users for role-based access control, or permissions with users for user-based access control. 7. Unauthorized user attempt to use security administration functions. 8. Audit enabling and disabling. 9. User authentication revocation. 10. Emergency Mode Access (aka Break-Glass) Security administration events should always be audited. |
DICOM PS3.15 A.5.3 “Security Alert” |
| User Authentication | This message describes the event of a user log on or log off, whether successful or not. No Participant Objects are needed for this message. | DICOM PS3.15 A.5.3 “User Authentication”. For log off based on inactivity, specify UserIsRequestor=false in the User element to indicate that this was not user initiated. |
| Study-Object-Event | Study is created, modified, accessed, or deleted. This reports on addition of new instances to existing studies as well as creation of new studies. | DICOM PS3.15 A.5.3 “DICOM Instances Accessed” |
| Study-used | SOP Instances from a specific study are created, modified or accessed. One event covers all instances used for the particular study. | DICOM PS3.15 A.5.3 “DICOM Instances Accessed” |
3.20.4.1.1.2 Other event reports
A Secure Node or Secure Application may also report audit events that do not correspond to DICOM events or audit events defined in IHE profiles. For example, a Disclosure can be recorded when an application knows that the act meets the measure of a Disclosure in the legal domain. The Disclosure event is further explained in Section 3.20.8.
Other events may be reported using extensions to the format in Section 3.20.7 or may be reported in another format.
3.20.4.1.2 Message Semantics
The Audit Event message describes an event performed by users or systems. Typical events are queries, views, additions, deletions and changes to data.
An Audit Record Forwarder shall filter and forward Syslog messages unchanged, regardless of their internal format.
A Secure Node or Secure Application shall create and transmit an Audit Event message when reporting an event. This message shall be a Syslog message that is transmitted as described in RFC5424 and formatted as described in Section 3.20.7 Audit Message Format.
Secure Node and Secure Application Actors shall construct the Audit Event message according to the following:
- If the message contains Unicode characters, the characters shall be encoded using the UTF-8 encoding rules. UTF-8 avoids utilizing the control characters that are mandated by the Syslog protocol, but it may appear to be gibberish to a system that is not prepared for UTF-8.
- The PRI field shall be set using the facility value of 10 (security/authorization messages). Most Audit Event messages should have the severity value of 5 (normal but significant), although applications may choose values of 4 (Warning condition) if that is appropriate to the more detailed information in the audit message. This means that for most Audit Event messages the PRI field will contain the value “<85>”.
- The MSGID field in the HEADER of the SYSLOG-MSG shall be set to “IHE+RFC-3881” (minus the quotes). (Note that the use of RFC3881 in the value is retained for backward compatibility.)
- The STRUCTURED-DATA is not used. The MSG field holds the structured event data.
- The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure using UTF-8 minimal length encoding following the DICOM PS3.15 A.5 format, as described in Section 3.20.7 Audit Message Format. The BOM as specified in RFC5424 for use when the MSG is UTF-8 encoded is discouraged, but acceptable, as this is not well supported and discouraged by Unicode.
3.20.4.1.2.1 Audit Message Transports
This transaction defines two transport mechanisms for Record Audit Event messages:
- Transmission of Syslog messages over TLS (RFC5425) with The Syslog Protocol (RFC5424) which formalizes sending Syslog messages over a streaming protocol protectable by TLS. See Section 3.20.4.1.2.1.1.
- Transmission of Syslog messages over UDP (RFC5426) with The Syslog Protocol (RFC5424) which formalizes and obsoletes BSD Syslog protocol defined in RFC3164. See Section 3.20.4.1.2.1.2.
The Audit Record Repository shall support both transport mechanisms.
The Secure Node, Secure Application, and Audit Record Forwarder Actors shall support at least one of the transport mechanisms.
3.20.4.1.2.1.1 Transmission of Syslog Messages over TLS
Transmission of Syslog messages over TLS (RFC 5425) with the Syslog Protocol (RFC 5424) formalizes sending Syslog messages over a streaming protocol protectable by TLS.
RFC5424 states that this MUST be TLS version 1.2. For this transaction, that requirement is relaxed to be that it MUST be TLS; version 1.2 is RECOMMENDED.
3.20.4.1.2.1.2 Transmission of Syslog Messages over UDP (formerly:BSD Syslog)
Transmission of Syslog Messages over UDP (RFC5426) with The Syslog Protocol (RFC5424) formalizes and obsoletes the BSD Syslog protocol (RFC3164). This transport mechanism, originally defined in the IHE Radiology Technical Framework, is appropriate in some situations.
The underlying UDP transport may truncate messages longer than 1024 bytes or the MTU size minus the UDP header length. The Audit Record Repository should accept arbitrarily truncated messages and use its best effort to preserve those fragments (e.g., modify truncated messages so that such messages are well-formed XML, e.g., closing open elements), including possibly partial multi-byte encodings of characters. Because of the potential loss of information, the Audit Record Repository may track modified audits by adding informational text.
Because of the potential for truncated messages and other security concerns, the transmission of Syslog messages over TLS is recommended.
3.20.4.1.2.1.3 Reliable Syslog (deprecated)
The Reliable Syslog “cooked” mode is no longer specified by this transaction. Applications using Reliable Syslog should switch to transmission of Syslog Messages over TLS.
3.20.4.1.3 Expected Actions
An Audit Record Repository (ARR) shall accept any Syslog message that complies with RFC5424. For each Syslog message it may:
- Discard the Syslog message as irrelevant.
- Retain the Syslog message in an internal data store.
- Perform other processing on the Syslog message.
Audit Record Repositories shall accept UTF-8 encodings and store them without damage, i.e., preserve all 8 bits.
Audit Record Forwarders shall accept UTF-8 encodings and forward them without damage, i.e., preserve all 8 bits.
This transaction does not constrain the kind of Syslog messages that can be conveyed, nor does it specify the capacity or capabilities of the data store in the Audit Record Repository. The expectation is that the internal data store on the Audit Record Repository will be used for subsequent analysis and reporting purposes. This transaction does not specify what such activities will be.
The Audit Record Repository may apply a variety of data retention rules to the data store. This transaction does not specify data retention rules. These are usually dependent upon the purposes assigned to a specific Audit Record Repository.
When the Audit Record Repository is grouped with an Audit Record Forwarder, the Audit Record Forwarder shall:
- Apply filtering rules to all Syslog messages received by the Audit Record Repository.
- Forward all Syslog messages that match filters to their configured destinations.
3.20.5 Security Considerations
The use of the TLS transport mechanism is recommended because the audit event messages often contain PHI or other sensitive information. See Section 3.20.4.1.2.1.
The use of the TLS transport mechanism is not always required because there are other means of protection that may be more appropriate in some situations. The decision to use the UDP transport mechanism should be based upon a security and privacy risk analysis.
The data store within the Audit Record Repository may contain sensitive information, and the Audit Record Repository analysis facilities may allow sensitive queries. It will be a high value target for malicious actors, and should be protected accordingly.
The Audit Record Repository is required to generate audit event messages for various kinds of use of the data store and configuration changes. This is specified in Section 3.20.4.1.1.
3.20.6 Retired
This section has been retired. Most of the previous content has been moved to Section 3.20.4. Table 3.20.6-1 "Audit Record trigger events" is now Table 3.20.4.1.1.1-1.
3.20.7 Audit Message Format
All IHE actors shall utilize the IHE Audit Trail Message Format in Section 3.20.7.1. This is a schema based on the standards developed and issued by the IETF, HL7, and DICOM organizations to meet the medical auditing needs as specified by ASTM E2147-01.
Note: The IHE Provisional Audit Message Format has been retired.
3.20.7.1 IHE Audit Trail Message Format
The DICOM Standard, Part 15, Annex A.5 Audit Trail Message Format Profile (see http://medical.nema.org/medical/dicom/current/output/chtml/part15/sect_A.5.html ) provides vocabulary and specification of a schema for events that may occur in the context of DICOM equipment. This XML schema was defined based upon joint work by IHE, HL7, DICOM, ASTM E31, and the Joint NEMA/COCIR/JIRA Security and Privacy Committee.
The DICOM Standard provides a schema for the basic messages and states that extensions are valid. This profile does not restrict private extensions that comply with the W3C XML encoding rules for the use of schemas, namespaces, etc.
IHE has extended the DICOM audit schema for more general healthcare use. Some IHE profiles have defined additional events and appropriate audit event messages for those events. Those audit event messages are often directly associated with IHE transactions. The events are documented in the context of those transactions, and are not documented as part of this transaction.
These audit requirements may be found in the Technical Frameworks from any IHE domain, not just the ITI domain. The notation used in this documentation, which often is in the form of an audit message table, is that used in the DICOM standard. The messages shall be encoded as instances based on the DICOM schema.
The following notation is used for optionality:
| M | This field is mandatory. |
| U | The optionality of this field is unspecialized. The optionality of the underlying standard applies. |
| C | This field is mandatory if a specified condition is true. |
The IHE Audit Trail Message Format describes events with respect to a single patient. In situations where there is an event that applies to more than one identifiable patient, there shall be a separate audit event message for each patient.
3.20.7.1.1 RoleIDCode with access control roles
When describing a human user’s participation in an event, the RoleIDCode value should represent the access control roles/permissions that authorized the event. RoleIDCode is a CodedValueType. Use of standards-based roles/permissions is recommended, rather than use of site or application specific codes. Many older security systems are unable to produce this data, hence it is optional, but should be provided when known.
For example: at a site "St Fraser" they have defined a functional role code "NURSEA" for attending nurse. This can be represented as
EV("NURSEA", "St Fraser", "Attending Nurse")
Candidate standards based structural/functional role codes can be found at ISO, HL7, ASTM, and various other sources.
3.20.7.1.2 Audit Encoding of the Purpose of Use value
The Purpose of Use value in the schema indicates the expected ultimate use of the data, rather than a likely near-term use such as “send to X”. As explained in the IHE Access Control White Paper, there are Access Control decisions that are based on the ultimate use of the data. For example, a Patient may have provided a BPPC Consent/Authorization for treatment purposes, but explicitly disallowed any use for research regardless of de-identification methods used.
The Purpose Of Use is also included in the Audit Event message to enable some forms of reporting of Accounting of Disclosures and Breach Notification. To enable this type of Audit Logging and Access Control decision, the assertion in the Provide User Assertion [ITI-40] transaction in the Cross-Enterprise User Assertion (XUA) Profile includes the intended purpose for which the data will be used. One specific PurposeOfUse would be a “Break-Glass”/Emergency-Mode-Access.
The PurposeOfUse value will come from a Value Set. This Value Set should be derived from the codes found in ISO 14265, or XSPA (Cross-Enterprise Security and Privacy Authorization). Implementations should expect that the Value Set used may be using locally defined values. The use of the IHE Sharing Value Sets (SVS) Profile may assist with this.
When a PurposeOfUse value is available it shall be encoded in the EventIdentification section as “PurposeOfUse” element encoded as a CodedValueType.
For example, the following is how an explicit Disclosure can be recorded when an application knows that the act meets the measure of a Disclosure in the legal domain.
| Field Name | Opt | Value Constraints | |
|
Event
AuditMessage/
|
EventID | M | EV(110106, DCM, “Export”) |
| EventActionCode | M | “R” (Read) | |
| EventDateTime | M | not specialized | |
| EventOutcomeIndicator | M | not specialized | |
| PurposeOfUse | O | EV(12, 1.0.14265.1, “Law Enforcement”) | |
| EventTypeCode | M | EV(“IHE0006”, “IHE”, “Disclosure”) | |
| Source (Document Repository) (1) | |||
| Destination (Document Consumer) (1) | |||
| Audit Source (Document Repository) (1) | |||
| Document (1..n) | |||
3.20.7.1.3 ParticipantObjectIDTypeCode
The DICOM schema mandates codeSystemName and originalText for all coded types. When standard codes are not available and the Audit Event Report is still using the integer values that were specified in RFC3881, IHE actors shall use the integer from RFC3881 as the codeValue, the description from RFC3881 in the originalText attribute and "RFC-3881" in the codeSystemName attribute. Where codes from other coding systems are available, those codes should be used because RFC3881 has been deprecated.
3.20.7.2 RFC3881 format (Deprecated)
The use of RFC3881 has been deprecated by IHE and IETF.
3.20.8 Disclosures audit message
In some countries a Patient has the right to get an accounting of disclosures. This report includes disclosures of their data that meet regulatory criteria. Most audit events, including export events, must be post-analyzed to determine whether they describe an event that needs to be included in the accounting of disclosures. For example, in the USA these rules are defined in HIPAA, and only a few kinds of export events meet the criteria to be included in an accounting of disclosures report. When it is known, at the time the event is recorded, that the event is indeed a disclosure, the disclosure audit message can be used to document the event.
The requirements of an accounting of disclosures are defined in ASTM-2147. A disclosure shall include the following, when the value is known:
- Who did the disclosure (the releasing agent),
- When did the disclosure happen,
- Who was the data disclosed to (receiving agent machine and other parties, if known),
- What patient was involved (multiple patients would be done as multiple audit entries),
- What data was involved, and
- Why the disclosure was done
There is some other information that may be available:
- Who is the custodian of the data (the official organization responsible), and
- Who authorized the release such as a guardian or relative (authorizing agent)?
The following is the layout of the Disclosure audit event. This pattern will be extended and modified by applications when appropriate.
| Field Name | Opt | Value Constraints | |
|
Event
AuditMessage/
|
EventID | M | EV(110106, DCM, “Export”) |
| EventActionCode | M | “R” (Read) for Export | |
| EventDateTime | M | not specialized | |
| EventOutcomeIndicator | M | not specialized | |
| PurposeOfUse | M | why was the data disclosed | |
| EventTypeCode | M | EV(IHE0006, “IHE”, “Disclosure”) - indicates type | |
| ActiveParticipant - Releasing Agents (0..*) | |||
| ActiveParticipant - Custodian (0..1) | |||
| ActiveParticipant - Authorizing Agent (0..n) | |||
| ActiveParticipant - Receiving Agent (1..n) | |||
| Audit Source (1) | |||
| ParticipantObject – Patient (1) | |||
| ParticipantObject – Data (Document) released (1..n) | |||
|
Releasing Agent
AuditMessage/
|
UserID | M | Identity of the human that initiated the Disclosure. |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “true” | |
| RoleIDCode | M | EV(110153, DCM, "Source Role ID") | |
| NetworkAccessPointTypeCode | U | not specialized | |
| NetworkAccessPointID | U | not specialized |
|
Custodian
AuditMessage/
|
UserID | U | not specialized |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “false” | |
| RoleIDCode | M | EV(159541003, SNOMED CT, “Record keeping/library clerk") | |
| NetworkAccessPointTypeCode | U | not specialized | |
| NetworkAccessPointID | U | not specialized |
|
Authorizing Agent (if known)
AuditMessage/
|
UserID | U | not specialized |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “false” | |
| RoleIDCode | M | EV(429577009, SNOMED CT, "Patient Advocate") | |
| NetworkAccessPointTypeCode | U | not specialized | |
| NetworkAccessPointID | U | not specialized |
|
Receiving Agent
AuditMessage/
|
UserID | U | not specialized |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “false” | |
| RoleIDCode | M | EV(110152, DCM, "Destination Role ID") | |
| NetworkAccessPointTypeCode | U | not specialized | |
| NetworkAccessPointID | U | not specialized |
|
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 |
Shall be: 2 = patient |
|
| ParticipantObjectSensitivity | U | not specialized | |
| ParticipantObjectID | M | The patient ID in HL7 CX format. | |
| ParticipantObjectName | U | not specialized | |
| ParticipantObjectQuery | U | not specialized | |
| ParticipantObjectDetail | U | not specialized |
|
Data (Document) Released
(AuditMessage/
|
ParticipantObjectTypeCode | M | “2” (System) |
| ParticipantObjectTypeCodeRole | M | “3” (report) | |
| ParticipantObjectDataLifeCycle | M |
Shall be: 11 = disclosure |
|
| ParticipantObjectIDTypeCode | M |
Shall be: 9 = Report Number |
|
| ParticipantObjectSensitivity | U | not specialized | |
| ParticipantObjectID | M | The value of <ihe:DocumentUniqueId/> | |
| ParticipantObjectName | U | not specialized | |
| ParticipantObjectQuery | U | not specialized | |
| ParticipantObjectDetail | U | not specialized |
|
Releasing Agent
AuditMessage/
|
UserID | M | Identity of the human that initiated the Disclosure. |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “true” | |
| 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, as available |
|
Custodian
AuditMessage/
|
UserID | U | not specialized |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “false” | |
| RoleIDCode | M | EV(159541003, SNOMED CT, “Record keeping/library clerk") | |
| NetworkAccessPointTypeCode | NA | not specialized | |
| NetworkAccessPointID | NA | not specialized |
|
Authorizing Agent (if known)
AuditMessage/
|
UserID | U | not specialized |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “false” | |
| RoleIDCode | M | EV(429577009, SNOMED CT, "Patient Advocate") | |
| NetworkAccessPointTypeCode | NA | not specialized | |
| NetworkAccessPointID | NA | not specialized |
|
Receiving Agent
AuditMessage/
|
UserID | U | not specialized |
| AlternativeUserID | U | not specialized | |
| UserName | U | not specialized | |
| UserIsRequestor | M | “false” | |
| RoleIDCode | M | EV(110152, DCM, "Destination Role ID") | |
| NetworkAccessPointTypeCode | U | not specialized | |
| NetworkAccessPointID | U | not specialized |
|
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 |
Shall be: 2 = patient |
|
| ParticipantObjectSensitivity | U | not specialized | |
| ParticipantObjectID | M | The patient ID in HL7 CX format. | |
| ParticipantObjectName | U | not specialized | |
| ParticipantObjectQuery | U | not specialized | |
| ParticipantObjectDetail | U | not specialized |
|
Data (Document) Released
(AuditMessage/
|
ParticipantObjectTypeCode | M | “2” (System) |
| ParticipantObjectTypeCodeRole | M | “3” (report) | |
| ParticipantObjectDataLifeCycle | M |
Shall be: 11 = disclosure |
|
| ParticipantObjectIDTypeCode | M |
Shall be: 9 = Report Number |
|
| ParticipantObjectSensitivity | U | not specialized | |
| ParticipantObjectID | M | The value of <ihe:DocumentUniqueId/> | |
| ParticipantObjectName | U | not specialized | |
| ParticipantObjectQuery | U | not specialized | |
| ParticipantObjectDetail | U | not specialized |