| DICOM PS3.15 2024d - Security and System Management Profiles |
|---|
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:
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.
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.
describe in its conformance statement the events that it can detect and report,
describe in its conformance statement the processing it can perform upon receipt of a message
describe in its conformance statement how event reporting and processing can be configured
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.
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.
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
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.
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.
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.
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.
| DICOM PS3.15 2024d - Security and System Management Profiles |
|---|