A.5 Audit Trail Message Format Profile

To help assure healthcare privacy and security in automated systems, usage data need to be collected. These data will be reviewed by administrative staff to verify that healthcare data is being used in accordance with the healthcare provider's data security requirements and to establish accountability for data use. This data collection and review process is called security auditing and the data itself comprises the audit trail. Audit trails can be used for surveillance purposes to detect when interesting events might be happening that warrant further investigation.

This profile defines the format of the data to be collected and the minimum set of attributes to be captured by healthcare application systems for subsequent use by a review application. The data includes records of who accessed healthcare data, when, for what action, from where, and which patients' records were involved. No behavioral requirements are specified for when audit messages are generated, or for what action should be taken on their receipt. These are subject to local policy decisions and legal requirements.

Any implementation that claims conformance to this Security Profile shall:

  1. format audit trail messages in accordance with the XML schema specified in A.5.1 in a fashion that allows those messages to be validated against that XML schema, following the general conventions specified in Section A.5.2.

  2. for the events described in this Profile comply with the restrictions specified by this Profile in Section A.5.3, and describe in its conformance statement any extensions.

Note: An implementation may include implementation-specific extensions as long as the above conditions are met.

  1. describe in its conformance statement the events that it can detect and report,

  2. describe in its conformance statement the processing it can perform upon receipt of a message

  3. describe in its conformance statement how event reporting and processing can be configured

Note: Other profiles specify the transmission of audit messages.

A.5.1 DICOM Audit Message Schema

Implementations claiming conformance to this profile shall use the following XML schema to format audit trail messages. This schema is derived from the schema specified in RFC 3881 IETF draft internet standard “Security Audit and Access Accountability XML Message Data Definitions for Healthcare Applications”, according to W3C Recommendation "XML Schema Part 1: Structures," version 1.0, May 2001, and incorporates the DICOM extensions and restrictions outlined in section A.5.2.

This schema is provided in Relax NG Compact format.

Note: This schema can be converted into an equivalent XML schema or other electronic format. It includes some modifications to the RFC 3881 schema that reflect field experience with audit message requirements. It extends the RFC 3881 schema.

datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes";

# This defines the coded value type. The comment shows a pattern that can be used to further

# constrain the token to limit it to the format of an OID. Not all schema software

# implementations support the pattern option for tokens.

other-csd-attributes =

(attribute codeSystemName {token} | # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"

attribute codeSystemName {token}), # This makes clear that codeSystemName is either an OID or String

attribute displayName {token}?,

attribute originalText {token} #Note: this also corresponds to DICOM " Code Meaning"

CodedValueType =

attribute csd-code {token},

other-csd-attributes

# Define the event identification, used later

EventIdentificationContents =

element EventID {CodedValueType },

element EventTypeCode {CodedValueType}*, # Note: DICOM/IHE defines and uses this differently than RFC-3881

attribute EventActionCode { # Optional action code

"C" | ## Create

"R" | ## Read

"U" | ## Update

"D" | ## Delete

"E" }?, ## Execute

attribute EventDateTime {xsd:dateTime},

attribute EventOutcomeIndicator {

"0" | ## Nominal Success (use if status otherwise unknown or ambiguous)

"4" | ## Minor failure (per reporting application definition)

"8" | ## Serious failure (per reporting application definition)

"12"}, ## Major failure, (reporting application now unavailable)

element EventOutcomeDescription {text}?

# Define AuditSourceIdentification, used later

# Note: This includes one constraint that cannot be represented yet in RNC. The use of a token other

# than the specified codes is permitted only if the codeSystemName is present.

# Note: This has no elements, only attributes.

AuditSourceIdentificationContents =

attribute code {

"1" | ## End-user display device, diagnostic device

"2" | ## Data acquisition device or instrument

"3" | ## Web Server process or thread

"4" | ## Application Server process or thread

"5" | ## Database Server process or thread

"6" | ## Security server, e.g., a domain controller

"7" | ## ISO level 1-3 network component

"8" | ## ISO level 4-6 operating software

"9" | ## other

token }, ## other values are allowed if a codeSystemName is present

other-csd-attributes?, ## If these are present, they define the meaning of code

attribute AuditEnterpriseSiteID {token}?,

attribute AuditSourceID {token},

element AuditSourceTypeCode {token}*

# Define ActiveParticipantType, used later

ActiveParticipantContents =

element RoleIDCode {CodedValueType}*,

element MediaIdentifier {

element MediaType {CodedValueType}}?,

attribute UserID {text},

attribute AlternativeUserID {text}?,

attribute UserName {text}?,

attribute UserIsRequestor {xsd:boolean},

attribute NetworkAccessPointID {token}?,

attribute NetworkAccessPointTypeCode {

"1" | ## Machine Name, including DNS name

"2" | ## IP Address

"3" | ## Telephone Number

"4" | ## Email address

"5"}? ## URI (user directory, HTTP-PUT, ftp, etc.)

# The BinaryValuePair is used in ParticipantObject descriptions to capture parameters.

# All values (even those that are normally plain text) are encoded as xsd:base64Binary. This

# is to preserve details of encoding (e.g., nulls) and to protect against text contents that contain

# XML fragments. These are known attack points against applications, so security logs

# can be expected to need to capture them without modification by the audit encoding process.

ValuePair = # clarify the name

attribute type {token},

attribute value {xsd:base64Binary} # used to encode potentially binary, mal-formed XML text, etc.

# Define ParticipantObjectIdentification, used later

# Participant Object Description, used later

DICOMObjectDescriptionContents =

element MPPS {

attribute UID {token}}*, # # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"

element Accession {

attribute Number {token}}*,

element SOPClass { # SOP class for one study

element Instance {

attribute UID {token}}*, # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"

attribute UID {token}?, # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"

attribute NumberOfInstances {xsd:integer}

},

element ParticipantObjectContainsStudy {

element StudyIDs {

attribute UID {token}}*

},

element Encrypted {xsd:boolean}?,

element Anonymized {xsd:boolean}?

ParticipantObjectIdentificationContents =

element ParticipantObjectIDTypeCode {CodedValueType},

(element ParticipantObjectName {token} | # either a name or

element ParticipantObjectQuery {xsd:base64Binary}), # a query ID field,

element ParticipantObjectDetail {ValuePair}*, # optional details, these can be extensive and large

element ParticipantObjectDescription {token}*, # optional descriptive text

DICOMObjectDescriptionContents, # These are extensions made by DICOM to RFC-3881 schema for use describing DICOM objects

attribute ParticipantObjectID {token}, #mandatory ID

attribute ParticipantObjectTypeCode {( # optional type

"1" | #3 Person

"2" | #3 System object

"3" | #3 Organization

"4")}?, ## Other

attribute ParticipantObjectTypeCodeRole {( ## optional role

"1" | ## Patient

"2" | ## Location

"3" | ## Report

"4" | ## Resource

"5" | ## Master File

"6" | ## User

"7" | ## List

"8" | ## Doctor

"9" | ## Subscriber

"10" | ## guarantor

"11" | ## Security User Entity

"12" | ## Security User Group

"13" | ## Security Resource

"14" | ## Security Granulatiry Definition

"15" | ## Provider

"16" | ## Report Destination

"17" | ## Report Library

"18" | ## Schedule

"19" | ## Customer

"20" | ## Job

"21" | ## Job Stream

"22" | ## Table

"23" | ## Routing Criteria

"24")}?, ## Query?,

attribute ParticipantObjectDataLifeCycle {( # optional life cyucle stage

"1" | ## Origination, Creation

"2" | ## Import/ Copy

"3" | ## Amendment

"4" | ## Verification

"5" | ## Translation

"6" | ## Access/Use

"7" | ## De-identification

"8" | ## Aggregation, summarization, derivation

"9" | ## Report

"10" | ## Export

"11" | ## Disclosure

"12" | ## Receipt of Disclosure

"13" | ## Archiving

"14" | ## Logical deletion

"15")}?, ## Permanent erasure, physical destruction

attribute ParticipantObjectSensistity {token}?

# The basic message

message = element AuditMessage {

element EventIdentification {EventIdentificationContents}, # The event must be identified

element ActiveParticipant {ActiveParticipantContents}+, # It has one or more active participants

element AuditSourceIdentification {AuditSourceIdentificationContents}, # It is reported by one source

element ParticipantObjectIdentification {ParticipantObjectIdentificationContents}* # It may have other objects involved

}

# And finally the magic statement that message is the root of everything.

start=message

Figure A.5.1-1 Audit Message Schema

A.5.2 General Message Format Conventions

The following table lists the primary fields from the message schema specified in A.5.1, with additional instructions, conventions, and restrictions on how DICOM applications shall fill in the field values. Please refer to RFC 3881 for the complete definition and specification of fields taken from the schema specified therein. In addition, the following table lists the additional fields that are part of DICOM-specific extensions in the DICOM Audit Message Schema (see A.5.1). The fields names are only those leaf elements and attributes that are specialized or extended for this profile. Note that these fields may be enclosed in other XML elements, as specified by the schema.

Table A.5.2-1 General Message Format

Field Name Opt. Description from RFC 3881 Additional Conditions on Field Format/Value
Event EventID M “Identifier for a specific audited event …” The identifier for the family of event. E.g., “User Authentication”. Extended by DICOM using DCID (400)
EventActionCode U “Indicator for type of action performed during the event that generated the audit.” See Schema
EventDateTime M “Universal coordinated time (UTC), i.e. a date/time specification that is unambiguous as to local time zones.” The time at which the audited event occurred. See section A.5.2.5
EventOutcomeIndicator M “Indicates whether the event succeeded or failed.” When a particular event has some aspects that succeeded and some that failed, then one message shall be generated for successful actions and one message for the failed actions (i.e., not a single message with mixed results).
EventTypeCode U “Identifier for the category of event.” The specific type(s) within the family applicable to the event, e.g., “User Login”. Extended by DICOM using DCID (401)
Active Participant (multi-valued) UserID M “Unique identifier for the user actively participating in the event.” See section A.5.2.1
AlternativeUserID U “Alternative unique identifier for the user.” See section A.5.2.2
UserName U “The human-meaningful name for the user.” See section A.5.2.3
UserIsRequestor M “Indicator that the user is or is not the requestor, or initiator, for the event being audited.” Used to identify which of the participants initiated the transaction being audited. If the audit source cannot determine which of the participants is the requestor, then the field shall be present with the value FALSE in all participants. The system shall not identify multiple participants as UserIsRequestor. If there are several known requestors, the reporting system shall pick only one as UserIsRequestor.
RoleIDCode U “Specification of the role(s) the user plays when performing the event, as assigned in role-based access control security.” Extended by DICOM using DCID (402) Usage of this field is refined in the individual message descriptions below. Other additional roles may also be present, since this is a multi-valued field.
NetworkAccessPointTypeCode U “An identifier for the type of network access point …” See Section A.5.2.4
NetworkAccessPointID U “An identifier for the network access point of the user device This could be a device id, IP address, or some other identifier associated with a device.”
Audit Source AuditEnterpriseSiteID U “Logical source location within the healthcare enterprise network, e.g., a hospital or other provider location within a multi-entity provider group.” Serves to further qualify the Audit Source ID, since Audit Source ID is not required to be globally unique.
AuditSourceID M “Identifier of the source …” The identification of the system that detected the auditable event and created this audit message. Although often the audit source is one of the participants, it could also be an external system that is monitoring the activities of the participants (e.g., an add-on audit-generating device).
AuditSourceTypeCode U “Code specifying the type of source …” Used as defined in RFC 3881. E.g., an acquisition device might use “2” (data acquisition device), a PACS/RIS system might use “4 “(application server process).
Participant Object (multi-valued) ParticipantObjectTypeCode U “Code for the participant object type being audited. This value is distinct from the user's role or any user relationship to the participant object.” Used as defined in RFC 3881
ParticipantObjectTypeCodeRole U “Code representing the functional application role of Participant Object being audited.” Used as defined in RFC 3881
ParticipantObjectDataLifeCycle U “Identifier for the data life-cycle stage for the participant object. This can be used to provide an audit trail for data, over time, as it passes through the system.” Used as defined in RFC 3881.
ParticipantObjectIDTypeCode M “Describes the identifier that is contained in Participant Object ID.” Values may be drawn from those listed in RFC 3881 and DCID (404), as specified in the individual message descriptions.
ParticipantObjectSensitivity U “Denotes policy-defined sensitivity for the Participant Object ID such as VIP, HIV status, mental health status, or similar topics.” Used as defined in RFC 3881.
ParticipantObjectID M “Identifies a specific instance of the participant object.” Usage refined by individual message descriptions
ParticipantObjectName U “An instance-specific descriptor of the Participant Object ID audited, such as a person's name.” Usage refined by individual message descriptions
ParticipantObjectQuery U “The actual query for a query-type participant object.” Usage refined by individual message descriptions
ParticipantObjectDetail U “Implementation-defined data about specific details of the object accessed or used.” Used as defined in RFC 3881. Note: The value field is xs:base64Binary encoded, making this attribute suitable for conveying binary data.
SOPClass MC (DICOM extension) The UIDs of SOP classes referred to in this participant object. Required if ParticipantObjectIDTypeCode is (110180, DCM, “Study Instance UID”) and any of the optional fields (AccessionNumber, ContainsMPPS, NumberOfInstances, ContainsSOPInstances,Encrypted,Anonymized) are present in this Participant Object. May be present if ParticipantObjectIDTypeCode is (110180, DCM, “Study Instance UID”) even though none of the optional fields are present.
Accession U (DICOM extension) An Accession Number(s) associated with this participant object.
MPPS U (DICOM extension) An MPPS Instance UID(s) associated with this participant object.
NumberOfInstances U (DICOM extension) The number of SOP Instances referred to by this participant object.
Instance U (DICOM extension) SOP Instance UID value(s) Note: Including the list of SOP Instances can create a fairly large audit message. Under most circumstances, the list of SOP Instance UIDs is not needed for audit purposes.
Encrypted U (DICOM extension) a single value of True or False indicating whether or not the data was encrypted. Note: If there was a mix of encrypted and non-encrypted data, then create two event reports.
Anonymized U (DICOM extension) A single value of True or False indicating whether or not all patient identifying information was removed from the data
ParticipantObjectContainsStudy U (DICOM extension) A Study Instance UID, which may be used when the ParticipantObjectIDTypeCode is not (110180, DCM, “Study Instance UID”).

A.5.2.1 UserID

If the participant is a person, then the User ID shall be the identifier used for that person on this particular system, in the form of loginName@domain-name.

If the participant is an identifiable process, the UserID selected shall be one of the identifiers used in the internal system logs. For example, the User ID may be the process ID as used within the local operating system in the local system logs. If the participant is a node, then User ID may be the node name assigned by the system administrator. Other participants such as threads, relocatable processes, web service end-points, web server dispatchable threads, etc. will have an appropriate identifier. The implementation shall document in the conformance statement the identifiers used, see A.6. The purpose of this requirement is to allow matching of the audit log identifiers with internal system logs on the reporting systems. .

When importing or exporting data, e.g. by means of media, the UserID field is used both to identify people and to identify the media itself. When the Role ID Code is EV(110154, DCM, “Destination Media”) or EV(110155, DCM, “Source Media”), the UserID may be:

  1. a URI (the preferred form) identifying the source or destination,

  2. an email address of the form “mailto:user@address”

  3. a description of the media type (e.g. DVD) together with a description of its identifying label, as a free text field,

  4. a description of the media type (e.g. paper, film) together with a description of the location of the media creator (i.e., the printer).

The UserID field for Media needs to be highly flexible given the large variety of media and transports that might be used.

A.5.2.2 AlternativeUserID

If the participant is a person, then Alternative User ID shall be the identifier used for that person within an enterprise for authentication purposes, for example, a Kerberos Username (user@realm). If the participant is a DICOM application, then Alternative User ID shall be one or more of the AE Titles that participated in the event. Multiple AE titles shall be encoded as:

AETITLES= aetitle1;aetitle2;…

When importing or exporting data, e.g. by means of media, the Alternative UserID field is used either to identify people or to identify the media itself. When the Role ID Code is (110154, DCM, “Destination Media”) or (110155, DCM, “Source Media”), the Alternative UserID may be any machine readable identifications on the media, such as media serial number, volume label, or DICOMDIR SOP Instance UID.

A.5.2.3 UserName

A human readable identification of the participant. If the participant is a person, the person’s name shall be used. If the participant is a process, then the process name shall be used.

A.5.2.4 Multi-homed nodes

The NetworkAccessPointTypeCode and NetworkAccessPointID can be ambiguous for systems that have multiple physical network connections. For these multi-homed nodes a single DNS name or IP address shall be selected and used when reporting audit events. DICOM does not require the use of a specific method for selecting the network connection to be used for identification, but it must be the same for all of the audit messages generated for events on that node.

A.5.2.5 EventDateTime

The EventDateTime is the date and time that the event being reported took place. Some events have a significant duration. In these cases, a date and time shall be chosen by a method that is consistent and appropriate for the event being reported.

The EventDateTime shall include the time zone information.

Creators of audit messages may support leap-seconds, but are not required to. Recipients of audit messages shall be able to process messages with leap-second information.

A.5.3 DICOM specific audit messages

The following subsections define message specializations for use by implementations that claim conformance to the DICOM Audit Trail Profile. Any field (i.e., XML element and associated attributes) not specifically mentioned in the following tables shall follow the conventions specified in A.5.1 and A.5.2.

An implementation claiming conformance to this Profile that reports an activity covered by one of the audit messages defined by this Profile shall use the message format defined in this Profile. However, a system claiming conformance to this Profile is not required to send a message each time the activity reported by that audit message occurs. It is expected that the triggering of audit messages would be configurable on an individual basis, to be able to balance network load versus the severity of threats, in accordance with local security policies.

Notes: 1. It is a system design issue outside the scope of DICOM as to what entity actually sends an audit event and when. For example, a Query message could be generated by the entity where the query originated, by the entity that eventually would respond to the query, or by a monitoring entity not directly involved with the query, but that generates audit messages based on monitored network traffic.

2. To report events that are similar to the events described here, these definitions can be used as the basis for extending the schema.

In the subsequent tables, the information entity column indicates the relationship between real world entities and the information elements encoded into the message.

A.5.3.1 Application Activity

This audit message describes the event of an Application Entity starting or stopping. This is closely related to the more general case of any kind of application startup or shutdown, and may be suitable for those purposes also.

Table A.5.3.1 – 1 Application Activity Message

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110100, DCM,”Application Activity”)
EventActionCode M Enumerated Value E = Execute
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M DT (110120, DCM, “Application Start”) DT (110121, DCM, “Application Stop”)

Active Participant: Application started (1) UserID M The identity of the process started or stopped formatted as specified in A.5.2.1.
AlternativeUserID MC If the process supports DICOM, then the AE Titles as specified in A.5.2.2.
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110150, DCM, “Application”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Active Participant: Persons and or processes that started the Application (0..N) UserID M The person or process starting or stopping the Application
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110151, DCM, “Application Launcher”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

No Participant Objects are needed for this message.

A.5.3.2 Audit Log Used

This message describes the event of a person or process reading a log of audit trail information.

Note: For example, an implementation that maintains a local cache of audit information that has not been transferred to a central collection point might generate this message if its local cache were accessed by a user.

Table A.5.3.2-1 Audit Log Used Message

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110101, DCM, “Audit Log Used”)
EventActionCode M Shall be enumerated value: R = read
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized
Active Participant: Persons and or processes that started the Application (1..2) UserID M The person or process accessing the audit trail. If both are known, then two active participants shall be included (both the person and the process).
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Participating Object: Identity of the audit log (1) ` ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 13 = security resource
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 12 = URI
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The URI of the audit log
ParticipantObjectName U Shall be: “Security Audit Log”
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized
SOPClass U See A.5.2
Accession U See A.5.2
NumberOfInstances U See A.5.2
Instances U See A.5.2
Encrypted U See A.5.2
Anonymized U See A.5.2
ParticipantObjectContainsStudy U See A.5.2

A.5.3.3 Begin Transferring DICOM Instances

This message describes the event of a system beginning to transfer a set of DICOM instances from one node to another node within control of the system’s security domain. This message may only include information about a single patient.

Note: A separate Instances Transferred message is defined for transfer completion, allowing comparison of what was intended to be sent and what was actually sent.

Table A.5.3.3 – 1 Audit Message for Begin Transferring DICOM Instances

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110102, DCM, “Begin Transferring DICOM Instances”)
EventActionCode M Shall be: E = Execute
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized

Active Participant: Process Sending the Data (1) UserID M The identity of the process sending the data.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110153, DCM, “Source Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Active Participant: Process receiving the data (1) UserID M The identity of the process receiving the data.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110152, DCM, “Destination Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Active Participant: Other Participants (0..N) UserID M The identity of any other participants that might be involved and known, especially third parties that are the requestor
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Participating Object: Studies being transferred (1..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV (110180, DCM, “Study Instance UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The Study Instance UID
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U Element "ContainsSOPClass" with one or more SOP Class UID values
ParticipantObjectDescription U not specialized
SOPClass MC not specialized
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized
Participating Object: Patient (1) ParticipantObjectTypeCode M Shall be: 1 = person
ParticipantObjectTypeCodeRole M Shall be: 1 = patient
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 2 = patient ID
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID
ParticipantObjectName U The patient name
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized

A.5.3.4 Data Export

This message describes the event of exporting data from a system, meaning that the data is leaving control of the system’s security domain. Examples of exporting include printing to paper, recording on film, conversion to another format for storage in an EHR, writing to removable media, or sending via e-mail. Multiple patients may be described in one event message.

A single user (either local or remote) shall be identified as the requestor, i.e., UserIsRequestor with a value of TRUE. This accommodates both push and pull transfer models for media.

Table A.5.3.4-1 Audit Message for Data Export

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110106, DCM, “Export”)
EventActionCode M Shall be: R = Read
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized
Participating Object: Remote Users and Processes (0..n) UserID M The identity of the remote user or process receiving the data
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M See Section A.5.3.4.1
RoleIDCode M EV (110152, DCM, “Destination Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Participating Object: User or Process Exporting the data(1..2) UserID M The identity of the local user or process exporting the data. If both are known, then two active participants shall be included (both the person and the process).
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M See Section A.5.3.4.1
RoleIDCode M EV (110153, DCM, “Source Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Active Participant: Media (1) UserID M See Section A.5.2.3
AlternativeUserID U See Section A.5.2.4
UserName U not specialized
UserIsRequestor M Shall be FALSE
RoleIDCode M EV (110154, DCM, “Destination Media”)
NetworkAccessPointTypeCode MC Required if being exported to other than physical media, e.g. to a network destination rather than to film, paper or CD. May be present otherwise.
NetworkAccessPointID MC Required if Net Access Point Type Code is present. May be present otherwise.
MediaIdentifier MC Volume ID, URI, or other identifier for media. Required if digital media. May be present otherwise.
MediaType M Values selected from DCID (405)
Participating Object: Studies (0..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV (110180, DCM, “Study Instance UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The Study Instance UID
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized
SOPClass MC See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized
Participating Object: Patients (1..N) ParticipantObjectTypeCode M Shall be: 1 = person
ParticipantObjectTypeCodeRole M Shall be: 1 = patient
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 2 = patient ID
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID
ParticipantObjectName U The patient name
ParticipantObjectQuery U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized

A.5.3.5 Data Import

This message describes the event of importing data into an organization, implying that the data now entering the system was not under the control of the security domain of this organization. Transfer by media within an organization is often considered a data transfer rather than a data import event. An example of importing is creating new local instances from data on removable media. Multiple patients may be described in one event message.

A single user (either local or remote) shall be identified as the requestor, i.e., UserIsRequestor with a value of TRUE. This accommodates both push and pull transfer models for media.

Table A.5.3.5-1 Audit Message for Data Import

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110107, DCM, “Import”)
EventActionCode M Shall be: C = Create
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized

Participating Object: User or Process Importing the data (1..n) UserID M The identity of the local user or process importing the data.
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M See Section A.5.3.5
RoleIDCode M EV (110152, DCM, “Destination Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Active Participant: Source Media (1) UserID M See Section A.5.2.3
AlternativeUserID U See Section A.5.2.4
UserName U not specialized
UserIsRequestor M Shall be FALSE
RoleIDCode M EV (110155, DCM, “Source Media”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID MC Shall be present if Net Access Point Type Code is present. Shall use fields as specified in RFC 3881.
MediaIdentifier M Volume ID, URI, or other identifier for media
MediaType M Values selected from DCID (405)

Active Participant: Source (0..n) UserID M See Section A.5.2.3
AlternativeUserID U See Section A.5.2.4
UserName U not specialized
UserIsRequestor M See Section A.5.3.5
RoleIDCode M EV (110153, DCM, “Source Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID MC Shall be present if Net Access Point Type Code is present.

Participating Object: Studies (0..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV (110180, DCM, “Study Instance UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The Study Instance UID
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U Not specialized
ParticipantObjectDescription U not specialized
SOPClass MC See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized
Participating Object: Patients (1..N) ParticipantObjectTypeCode M Shall be: 1 = person
ParticipantObjectTypeCodeRole M Shall be: 1 = patient
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 2 = patient ID
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID
ParticipantObjectName U The patient name
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized

A.5.3.6 DICOM Instances Accessed

This message describes the event of DICOM SOP Instances being viewed, utilized, updated, or deleted. This message shall only include information about a single patient and can be used to summarize all activity for several studies for that patient. This message records the studies to which the instances belong, not the individual instances.

If all instances within a study are deleted, then the EV(110105, DCM, “DICOM Study Deleted”) event shall be used, see A.5.3.8.

Table A.5.3.6-1 Audit Message for DICOM Instances Accessed

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110103, DCM, “DICOM Instances Accessed”)
EventActionCode M Enumerated value: C = create R = read U = update D = delete
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized

Active Participant: Person and or Process manipulating the data (1..2) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Participating Object: Studies (1..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV (110180, DCM, “Study Instance UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The Study Instance UID
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U Not specialized
ParticipantObjectDescription U Not specialized
SOPClass MC See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized
Participating Object: Patient (1) ParticipantObjectTypeCode M Shall be: 1 = person
ParticipantObjectTypeCodeRole M Shall be: 1 = patient
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 2 = patient ID
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID
ParticipantObjectName U The patient name
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized

A.5.3.7 DICOM Instances Transferred

This message describes the event of the completion of transferring DICOM SOP Instances between two Application Entities. This message may only include information about a single patient.

Note: This message may have been preceded by a Begin Transferring Instances message. The Begin Transferring Instances message conveys the intent to store SOP Instances, while the Instances Transferred message records the completion of the transfer. Any disagreement between the two messages might indicate a potential security breach.

Table A.5.3.7-1 Audit Message for DICOM Instances Transferred

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110104, DCM, “DICOM Instances Transferred”)
EventActionCode M Enumerated Value: C = (create) if the receiver did not hold copies of the instances transferred R = (read) if the receiver already holds copies of the SOP Instances transferred, and has determined that no changes are needed to the copies held. U = (update) if the receiver is altering its held copies to reconcile differences between the held copies and the received copies. If the Audit Source is either not the receiver, or otherwise does not know whether or not the instances previously were held by the receiving node, then use “R” = (Read).
EventDateTime M Shall be the time when the transfer has completed
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized

Active Participant: Process that sent the data (1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110153, DCM, “Source Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Active Participant: The process that received the data. (1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110152, DCM, “Destination Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Active Participant: Other participants that are known, especially third parties that are the requestor (0..N) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Participating Object: Studies being transferred (1..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV (110180, DCM, “Study Instance UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The Study Instance UID
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U Not specialized
ParticipantObjectDescription U Not specialized
SOPClass MC See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized
Participating Object: Patient (1) ParticipantObjectTypeCode M Shall be: 1 = person
ParticipantObjectTypeCodeRole M Shall be: 1 = patient
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 2 = patient ID
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID
ParticipantObjectName U The patient name
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized

A.5.3.8 DICOM Study Deleted

This message describes the event of deletion of one or more studies and all associated SOP Instances in a single action. This message shall only include information about a single patient.

Table A.5.3.8-1 Audit Message for DICOM Study Deleted

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110105, DCM, “DICOM Study Deleted”)
EventActionCode M Shall be: D = delete
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized

Active Participant: the person or process deleting the study (1..2) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Participating Object: Studies being transferred (1..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M EV (110180, DCM, “Study Instance UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The Study Instance UID
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U Not specialized
ParticipantObjectDescription U Not specialized
SOPClass MC See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized
Participating Object: Patient (1) ParticipantObjectTypeCode M Shall be: 1 = person
ParticipantObjectTypeCodeRole M Shall be: 1 = patient
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Shall be: 2 = patient ID
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M The patient ID
ParticipantObjectName U The patient name
ParticipantObjectQuery U not specialized
ParticipantObjectDetail U not specialized
ParticipantObjectDescription U not specialized

A.5.3.9 Network Entry

This message describes the event of a system, such as a mobile device, intentionally entering or leaving the network.

Note: The machine should attempt to send this message prior to detaching. If this is not possible, it should retain the message in a local buffer so that it can be sent later. The mobile machine can then capture audit messages in a local buffer while it is outside the secure domain. When it is reconnected to the secure domain, it can send the detach message (if buffered), followed by the buffered messages, followed by a mobile machine message for rejoining the secure domain. The timestamps on these messages is the time that the event was noticed to have occurred, not the time that the message is sent.

Table A.5.3.9-1 Audit Message for Network Entry

Real World Entities Field Name Opt. Value
Event EventID M EV (110108, DCM, ”Network Entry”)
EventActionCode M Shall be: E = Execute
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M EV (110124, DCM, “Attach”) EV (110125, DCM, “Detach”)

Active Participant: Node or System entering or leaving the network (1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M Shall be FALSE
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

No Participant Objects are needed for this message.

A.5.3.10 Query

This message describes the event of a Query being issued or received. The message does not record the response to the query, but merely records the fact that a query was issued. For example, this would report queries using the DICOM SOP Classes:

  1. Modality Worklist

  2. General Purpose Worklist

  3. Composite Instance Query

Notes: 1. The response to a query may result in one or more Instances Transferred or Instances Accessed messages, depending on what events transpire after the query. If there were security-related failures, such as access violations, when processing a query, those failures should show up in other audit messages, such as a Security Alert message.2. Non-DICOM queries may also be captured by this message. The Participant Object ID Type Code, the Participant Object ID, and the Query fields may have values related to such non-DICOM queries.

Table A.5.3.10-1 Audit Message for Query

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110112, DCM, “Query”)
EventActionCode M Shall be: E = Execute
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode U not specialized

Active Participant: Process Issuing the Query (1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110153, DCM, “Source Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Active Participant: The process that will respond to the query (1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode M EV (110152, DCM, “Destination Role ID”)
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Active Participant: Other Participants that are known, especially third parties that requested the query (0..N) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Participating Object: SOP Queried and the Query (1) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole M Shall be: 3 = report
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M DT (110181, DCM, “SOP Class UID”)
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M If the ParticipantObjectIDTypeCode is (110181, DCM, “SOP Class UID”), then this field shall hold the UID of the SOP Class being queried
ParticipantObjectName U not specialized
ParticipantObjectQuery M If the ParticipantObjectIDTypeCode is (110181, DCM, “SOP Class UID”), then this field shall hold the Dataset of the DICOM query, xs:base64Binary encoded. Otherwise, it shall be the query in the format of the protocol used.
ParticipantObjectDetail MC Required if the ParticipantObjectIDTypeCode is (110181, DCM, “SOP Class UID”) A ParticipantObjectDetail element with the XML attribute ”TransferSyntax” shall be present. The value of the Transfer Syntax attribute shall be the UID of the transfer syntax of the query. The element contents shall be xs:base64Binary encoding. The Transfer Syntax shall be a DICOM Transfer Syntax.
ParticipantObjectDescription U not specialized
SOPClass U See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized

A.5.3.11 Security Alert

This message describes any event for which a node needs to report a security alert, e.g., a node authentication failure when establishing a secure communications channel.

Note: The Node Authentication event can be used to report both successes and failures. If reporting of success is done, this could generate a very large number of audit messages, since every authenticated DICOM association, HL7 transaction, and HTML connection should result in a successful node authentication. It is expected that in most situations only the failures will be reported.

Table A.5.3.11-1 Audit Message for Security Alert

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110113, DCM, ”Security Alert”)
EventActionCode M Shall be: E = Execute
EventDateTime M not specialized
EventOutcomeIndicator M Success implies an informative alert. The other failure values imply warning codes that indicate the severity of the alert. A Minor or Serious failure indicates that mitigation efforts were effective in maintaining system security. A Major failure indicates that mitigation efforts may not have been effective, and that the security system may have been compromised.
EventTypeCode M Values selected from DCID( 403)

Active Participant: Reporting Person and/or Process (1..2) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized
Active Participant: Performing Persons or Processes (0..N) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M Shall be FALSE
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized

Participating Object: Alert Subject (0..N) ParticipantObjectTypeCode M Shall be: 2 = system
ParticipantObjectTypeCodeRole U Defined Terms: 5 = master file 13 = security resource
ParticipantObjectDataLifeCycle U not specialized
ParticipantObjectIDTypeCode M Defined Terms: 12 = URI (110182, DCM, “Node ID”) = Node Identifier
ParticipantObjectSensitivity U not specialized
ParticipantObjectID M For a ParticipantObjectIDTypeCode of 12 (URI), then this value shall be the URI of the file or other resource that is the subject of the alert. For a ParticipantObjectIDTypeCode of (110182, DCM, “Node ID”) then the value shall include the identity of the node that is the subject of the alert either in the form of node_name@domain_name or as an IP address. Otherwise, the value shall be an identifier of the type specified by ParticipantObjectIDTypeCode of the subject of the alert.
ParticipantObjectName U not specialized
ParticipantObjectQuery U not specialized
ParticipantObjectDetail M An element with the Attribute “type” equal to "Alert Description” shall be present with a free text description of the nature of the alert as the value
ParticipantObjectDescription U not specialized
SOPClass U See Table A.5.2-1
Accession U not specialized
NumberOfInstances U not specialized
Instances U not specialized
Encrypted U not specialized
Anonymized U not specialized

A.5.3.12 User Authentication

This message describes the event that a user has attempted to log on or log off. This report can be made regardless of whether the attempt was successful or not. No Participant Objects are needed for this message.

Note: The user usually has UserIsRequestor TRUE, but in the case of a logout timer, the Node might be the UserIsRequestor.

Table A.5.3.12-1 Audit Message for User Authentication

Real World Entities Field Name Opt. Value Constraints
Event EventID M EV (110114, DCM, ”User Authentication”)
EventActionCode M Shall be: E = Execute
EventDateTime M not specialized
EventOutcomeIndicator M not specialized
EventTypeCode M Defined Terms: EV (110122, DCM, “Login”) EV (110123, DCM, “Logout”)

Active Participant: Person Authenticated or claimed (1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode M not specialized
NetworkAccessPointID M not specialized
Active Participant: Node or System performing authentication (0..1) UserID M not specialized
AlternativeUserID U not specialized
UserName U not specialized
UserIsRequestor M not specialized
RoleIDCode U not specialized
NetworkAccessPointTypeCode U not specialized
NetworkAccessPointID U not specialized