DICOM PS3.15 2016b - Security and System Management Profiles

A.5 Audit Trail Message Format Profile
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 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 RFC3881 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 RFC3881 schema that reflect field experience with audit message requirements. It extends the RFC3881 schema.

#### A.5.1-1 Audit Message 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, 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 { 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 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

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

DICOM PS3.15 2016b - Security and System Management Profiles