DICOM PS3.15 2020c - Security and System Management Profiles

A.5 Audit Trail Message Format Profile (Current)
Prev | A Secure Use Profiles (Normative) | Next

## 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 Section 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.

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

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

5. 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], 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.

#### A.5.1.1 Audit Message Schema

The following is the content of the audit 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

    AuditSourceIdentificationContents =
      attribute AuditEnterpriseSiteID { token }?,
      attribute AuditSourceID { token },
      element AuditSourceTypeCode { AuditSourceTypeCodeContent }*

    # Define AuditSourceTypeCodeContent so that an isolated single digit
    # value is acceptable, or a token with other csd attributes so that
    # any controlled terminology can also be used.

    AuditSourceTypeCodeContent =
      attribute csd-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

    # 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, malformed 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 { DICOMObjectDescriptionContents }*,
      attribute ParticipantObjectID { token },          # mandatory ID
      attribute ParticipantObjectTypeCode {             # optional type
        "1" | ## Person
        "2" | ## System object
        "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 Granularity Definition
        "15" |        ## Provider
        "16" |        ## Data Destination
        "17" |        ## Data Archive
        "18" |        ## Schedule
        "19" |        ## Customer
        "20" |        ## Job
        "21" |        ## Job Stream
        "22" |        ## Table
        "23" |        ## Routing Criteria
        "24" |        ## Query
        "25" |        ## Data Source
        "26"          ## Processing Element
        }?,

      attribute ParticipantObjectDataLifeCycle {          # optional life cycle 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 ParticipantObjectSensitivity { 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 {                       # It is reported by one source
           AuditSourceIdentificationContents
         },
         element ParticipantObjectIdentification {                 # It may have other objects involved
           ParticipantObjectIdentificationContents
         }*)
      }

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

#### A.5.1.2 Codes Used Within The Schema

The following value sets are defined in the audit schema above. These are not coded terminology. They are values whose meaning depends upon their use at the proper location within the message.

##### A.5.1.2.1 Audit Source Type Code

The Audit Source Type Code values specify the type of source where an event originated. Codes from coded terminologies and implementation defined codes can also be used for the AuditSourceTypeCode.

Table A.5.1.2.1-1. Audit Source Type Code Values

Value | Meaning
--- | ---
1 | End-user interface
2 | Data acquisition device or instrument
3 | Web server process tier in a multi-tier system
4 | Application server process tier in a multi-tier system
5 | Application server process tier in a multi-tier system
6 | Security server, e.g., a domain controller
7 | ISO level 1-3 network component
8 | ISO level 4-6 operating software
9 | External source, other or unknown type

##### A.5.1.2.2 Participant Object Type Code Role

The Participant Object Type Code Role is an attribute of the ParticipantObjectIdentification, and is not extensible. This attribute may be omitted or one of the following values assigned. Coded terminologies are not supported.

Table

Table A.5.1.2.2-1. Participant Object Type Code Roles

Value | Meaning | Likely associated Participant Object Type Code
--- | --- | ---
1 | Patient | 1 - Person
2 | Location | 3 - Organization
3 | Report | 2 - System Object
4 | Resource | 1 - Person, or 3 - Organization
5 | Master File | 2 - System Object
6 | User | 1 - Person, or 2 - System Object
7 | List | 2 - System Object
8 | Doctor | 1 - Person
9 | Subscriber | 3 - Organization
10 | Guarantor | 1 - Person, or 3 - Organization
11 | Security User Entity | 1 - Person, or 2 - System Object
12 | Security User Group | 2 - System Object
13 | Security Resource | 2 - System Object
14 | Security Granularity Definition | 2 - System Object
15 | Provider | 1 - Person, or 3 - Organization
16 | Data Destination | 2 - System Object
17 | Data Repository | 2 - System Object
18 | Schedule | 2 - System Object
19 | Customer | 3 - Organization
20 | Job | 2 - System Object
21 | Job Stream | 2 - System Object
22 | Table | 2 - System Object
23 | Routing Criteria | 2 - System Object
24 | Query | 2 - System Object

##### A.5.1.2.3 Participant Object Data Life Cycle

The Participant Object Data Life Cycle is an attribute of the ParticipantObjectIdentification, and is not extensible. This attribute may be omitted or one of the following values assigned. Coded terminologies are not supported.

Table A.5.1.2.3-1. Participant Object Data Life Cycle Values

Value | Meaning
--- | ---
1 | Origination or Creation
2 | Import or Copy from original
3 | Amendment
4 | Verification
5 | Translation
6 | Access or Use
7 | De-identification
8 | Aggregation, summarization, derivation
9 | Report
10 | Export or Copy to target
11 | Disclosure
12 | Receipt of Disclosure
13 | Archiving
14 | Logical Deletion
15 | Permanent erasure or physical destruction

##### A.5.1.2.4 Participant Object ID Type Code

The Participant Object ID Type Code describes the identifier that is contained in Participant Object ID. Codes from coded terminologies and implementation defined codes can also be used for the ParticipantObjectTypeCodeRole.

Table A.5.1.2.4-1. Participant Object ID Type Code Values

Value | Meaning | Likely associated Participant Object Type Code
--- | --- | ---
1 | Medical Record Number | 1 - Person
2 | Patient Number | 1 - Person
3 | Encounter Number | 1 - Person
4 | Enrollee Number | 1 - Person
5 | Social Security Number | 1 - Person
6 | Account Number | 1 - Person, or 3 - Organization
7 | Guarantor Number | 1 - Person, or 3 - Organization
8 | Report Name | 2 - System Object
9 | Report Number | 2 - System Object
10 | Search Criteria | 2 - System Object
11 | User Identifier | 1 - Person, or 2 - System Object
12 | URI | 2 - System Object

Prev | Up | Next
A.4 Basic SR Digital Signatures Secure Use Profile | Home | A.5.2 General Message Format Conventions

DICOM PS3.15 2020c - Security and System Management Profiles