DICOM PS3.15 2024d - Security and System Management Profiles |
---|
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. The field names are leaf elements and attributes that are in the DICOM Audit Message Schema (see Section A.5.1). Note that these fields may be enclosed in other XML elements, as specified by the schema.
This schema, codes, and content were originally derived from [RFC 3881]. [RFC 3881] is not being maintained or updated by the IETF, and has gradually diverged from the DICOM schema and codes. Other documents exist that refer to [RFC 3881] as the underlying standard. [RFC 3881] does not include corrections and additions to the audit schema made in DICOM since 2004.
In subsequent tables the following notation Is used for optionality:
Table A.5.2-1. General Message Format
The identifier for the family of event. E.g., "User Authentication". |
||||
Indicator for type of action performed during the event that generated the audit. |
||||
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 |
|||
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). |
||||
The specific type(s) within the family applicable to the event, e.g., "User Login". |
||||
Unique identifier for the user actively participating in the event. |
See Section A.5.2.1. |
|||
See Section A.5.2.2. |
||||
See Section A.5.2.3. |
||||
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. |
|||
Specification of the role(s) the user plays when performing the event, as assigned in role-based access control security. |
||||
See Section A.5.2.4. |
||||
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. |
||||
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. |
|||
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). |
||||
See Section A.5.1.2.1. E.g., an acquisition device might use "2" (data acquisition device), a PACS/RIS system might use "4 "(application server process). |
||||
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. |
||||
Code representing the functional application role of Participant Object being audited. |
See Section A.5.1.2.2. |
|||
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. |
See Section A.5.1.2.3. |
|||
Describes the identifier that is contained in Participant Object ID. |
See Section A.5.1.2.4 and CID 404 “Audit Participant Object ID Type Code” |
|||
Denotes policy-defined sensitivity for the Participant Object ID such as VIP, HIV status, mental health status, or similar topics. |
||||
An instance-specific descriptor of the Participant Object ID audited, such as a person's name. |
||||
Implementation-defined data about specific details of the object accessed or used. |
This element is a Type-value pair. The "type" attribute is an implementation-defined text string. The "value" attribute is base 64 encoded data. The value is suitable for conveying binary data. |
|||
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. |
||||
An Accession Number(s) associated with this participant object. |
||||
An MPPS Instance UID(s) associated with this participant object. |
||||
The number of SOP Instances referred to by this participant object. |
||||
A single value of True or False indicating whether or not the data was encrypted. |
||||
A single value of True or False indicating whether or not all patient identifying information was removed from the data |
||||
A Study Instance UID, which may be used when the ParticipantObjectIDTypeCode is not (110180, DCM, "Study Instance UID"). |
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 Section 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:
a URI (the preferred form) identifying the source or destination,
a description of the media type (e.g., DVD) together with a description of its identifying label, as a free text field,
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.
DICOM PS3.15 2024d - Security and System Management Profiles |
---|