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”).|
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:
a URI (the preferred form) identifying the source or destination,
an email address of the form “mailto:user@address”
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.
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:
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 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.
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.
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.