PS3.15

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

DICOM Standards Committee


Table of Contents

Notice and Disclaimer
Foreword
1. Scope and Field of Application
1.1. Security Policies and Mechanisms
1.2. System Management Profiles
2. Normative References
Bibliography
3. Definitions
3.1. Reference Model Definitions
3.2. Reference Model Security Architecture Definitions
3.3. ACSE Service Definitions
3.4. Security Definitions
3.5. DICOM Introduction and Overview Definitions
3.6. DICOM Conformance Definitions
3.7. DICOM Information Object Definitions
3.8. DICOM Service Class Definitions
3.9. DICOM Communication Support Definitions
3.10. DICOM Security Profile Definitions
4. Symbols and Abbreviations
5. Conventions
6. Security and System Management Profile Outlines
6.1. Secure Use Profiles
6.2. Secure Transport Connection Profiles
6.3. Digital Signature Profile
6.4. Media Storage Security Profiles
6.5. Network Address Management Profiles
6.6. Time Synchronization Profiles
6.7. Application Configuration Management Profiles
6.8. Audit Trail Profiles
7. Configuration Profiles
7.1. Actors
7.2. Transactions
A. Secure Use Profiles (Normative)
A.1. Online Electronic Storage Secure Use Profile
A.1.1. SOP Instance Status
A.2. Basic Digital Signatures Secure Use Profile
A.3. Bit-preserving Digital Signatures Secure Use Profile
A.4. Basic SR Digital Signatures Secure Use Profile
A.5. Audit Trail Message Format Profile
A.5.1. DICOM Audit Message Schema
A.5.1.1. Audit Message Schema
A.5.1.2. Codes Used Within The Schema
A.5.1.2.1. Audit Source Type Code
A.5.1.2.2. Participant Object Type Code Role
A.5.1.2.3. Participant Object Data Life Cycle
A.5.1.2.4. Participant Object ID Type Code
A.5.2. General Message Format Conventions
A.5.2.1. UserID
A.5.2.2. AlternativeUserID
A.5.2.3. Username
A.5.2.4. Multi-homed Nodes
A.5.2.5. EventDateTime
A.5.2.6. ParticipantObjectTypeCodeRole
A.5.3. DICOM Specific Audit Messages
A.5.3.1. Application Activity
A.5.3.2. Audit Log Used
A.5.3.3. Begin Transferring DICOM Instances
A.5.3.4. Data Export
A.5.3.4.1. UserIsRequestor
A.5.3.5. Data Import
A.5.3.6. DICOM Instances Accessed
A.5.3.7. DICOM Instances Transferred
A.5.3.8. DICOM Study Deleted
A.5.3.9. Network Entry
A.5.3.10. Query
A.5.3.11. Security Alert
A.5.3.12. User Authentication
A.5.3.13. Order Record
A.5.3.14. Patient Record
A.5.3.15. Procedure Record
A.6. Audit Trail Message Transmission Profile - SYSLOG-TLS
A.7. Audit Trail Message Transmission Profile - SYSLOG-UDP
B. Secure Transport Connection Profiles (Normative)
B.1. The Basic TLS Secure Transport Connection Profile
B.2. ISCL Secure Transport Connection Profile
B.3. The AES TLS Secure Transport Connection Profile
B.4. Basic User Identity Association Profile
B.5. User Identity Plus Passcode Association Profile
B.6. Kerberos Identity Negotiation Association Profile
B.7. Generic SAML Assertion Identity Negotiation Association Profile
B.8. Secure Use of Email Transport
C. Digital Signature Profiles (Normative)
C.1. Base RSA Digital Signature Profile
C.2. Creator RSA Digital Signature Profile
C.3. Authorization RSA Digital Signature Profile
C.4. Structured Report RSA Digital Signature Profile
D. Media Storage Security Profiles (Normative)
D.1. Basic DICOM Media Security Profile
D.1.1. Encapsulation of A DICOM File in a Secure DICOM File
E. Attribute Confidentiality Profiles
E.1. Application Level Confidentiality Profiles
E.1.1. De-identifier
E.1.2. Re-identifier
E.1.3. Conformance Requirements
E.2. Basic Application Level Confidentiality Profile
E.3. Basic Application Level Confidentiality Options
E.3.1. Clean Pixel Data Option
E.3.2. Clean Recognizable Visual Features Option
E.3.3. Clean Graphics Option
E.3.4. Clean Structured Content Option
E.3.5. Clean Descriptors Option
E.3.6. Retain Longitudinal Temporal Information Options
E.3.7. Retain Patient Characteristics Option
E.3.8. Retain Device Identity Option
E.3.9. Retain UIDs Option
E.3.10. Retain Safe Private Option
F. Network Address Management Profiles
F.1. Basic Network Address Management Profile
F.1.1. Resolve Hostname
F.1.1.1. Scope
F.1.1.2. Use Case Roles
F.1.1.3. Referenced Standards
F.1.1.4. DNS Security Considerations (Informative)
F.1.1.5. DNS Implementation Considerations (Informative)
F.1.1.6. Support For Service Discovery
F.1.2. Configure DHCPserver
F.1.2.1. Scope
F.1.2.2. Use Case Roles
F.1.2.3. Referenced Standards
F.1.3. Find and Use DHCP Server
F.1.3.1. Scope
F.1.3.2. Use Case Roles
F.1.3.3. Referenced Standards
F.1.3.4. Interaction Diagram
F.1.4. Maintain Lease
F.1.4.1. Scope
F.1.4.2. Use Case Roles
F.1.4.3. Referenced Standards
F.1.4.4. Normal Interaction
F.1.5. DDNS Coordination
F.1.5.1. Scope
F.1.5.2. Use Case Roles
F.1.5.3. Referenced Standards
F.1.5.4. Basic Course of Events
F.1.6. DHCP Security Considerations (Informative)
F.1.7. DHCP Implementation Considerations (Informative)
F.1.8. Conformance
G. Time Synchronization Profiles
G.1. Basic Time Synchronization Profile
G.1.1. Find NTP Servers
G.1.1.1. Scope
G.1.1.2. Use Case Roles
G.1.1.3. Referenced Standards
G.1.1.4. Basic Course of Events.
G.1.1.5. Alternative Paths
G.1.1.6. Assumptions
G.1.1.7. Postconditions
G.1.2. Maintain Time
G.1.2.1. Scope
G.1.2.2. Use Case Roles
G.1.2.3. Referenced Standards
G.1.2.4. Basic Course of Events.
G.1.3. NTP Security Considerations (Informative)
G.1.4. NTP Implementation Considerations (Informative)
G.1.5. Conformance
H. Application Configuration Management Profiles
H.1. Application Configuration Management Profile
H.1.1. Data Model Component Objects
H.1.1.1. Device
H.1.1.2. Network Application Entity
H.1.1.3. Network Connection
H.1.1.4. Transfer Capabilities
H.1.1.5. DICOM Configuration Root
H.1.1.6. Devices Root
H.1.1.7. Unique AE Titles Registry Root
H.1.1.8. Unique AE Title
H.1.2. Application Configuration Data Model Hierarchy
H.1.3. LDAP Schema For Objects and Attributes
H.1.4. Transactions
H.1.4.1. Find LDAP Server
H.1.4.1.1. Scope
H.1.4.1.2. Use Case Roles
H.1.4.1.3. Referenced Standards
H.1.4.1.4. Interaction Diagram
H.1.4.1.5. Alternative Paths
H.1.4.2. Query LDAP Server
H.1.4.2.1. Scope
H.1.4.2.2. Use Case Roles
H.1.4.2.3. Referenced Standards
H.1.4.2.4. Interaction Description
H.1.4.3. Update LDAP Server
H.1.4.3.1. Scope
H.1.4.3.2. Use Case Roles
H.1.4.3.3. Referenced Standards
H.1.4.3.4. Interaction Description
H.1.4.3.5. Special Update For Network AE Creation
H.1.4.4. Maintain LDAP Server
H.1.5. LDAP Security Considerations (Informative)
H.1.5.1. Threat Assessment
H.1.5.2. Available LDAP Security Mechanisms
H.1.5.3. Recommendations (Informative)
H.1.6. Implementation Considerations (Informative)
H.1.7. Conformance
H.2. DNS Service Discovery
H.2.1. Scope
H.2.2. Use Case Roles
H.2.3. Referenced Standards
H.2.4. Examples

List of Figures

7-1. Transactions and Actors
F.1-1. Resolve Hostname
F.1-2. DNS Referenced Standards
F.1-3. Configure DHCP Server
F.1-4. Find and Use DHCP Server
F.1-5. DHCP Interactions
F.1-6. Maintain Lease
F.1-7. DDNS Coordination
G.1-1. Find NTP Servers
G.2-1. Maintain Time
H.1-1. Application Configuration Data Model
H.1-2. DICOM Configuration Hierarchy
H.1-3. Find LDAP Server
H.1-4. Select LDAP Server
H.1-5. Query LDAP Server
H.1-6. Update LDAP Server
H.2-1. Find DICOM Service

List of Tables

A.5.1.2.1-1. Audit Source Type Code Values
A.5.1.2.2-1. Participant Object Type Code Roles
A.5.1.2.3-1. Participant Object Data Life Cycle Values
A.5.1.2.4-1. Participant Object ID Type Code Values
A.5.2-1. General Message Format
A.5.2.6-1. ParticipantObjectTypeCodeRole
A.5.3.1-1. Application Activity Message
A.5.3.2-1. Audit Log Used Message
A.5.3.3-1. Audit Message for Begin Transferring DICOM Instances
A.5.3.4-1. Audit Message for Data Export
A.5.3.5-1. Audit Message for Data Import
A.5.3.6-1. Audit Message for DICOM Instances Accessed
A.5.3.7-1. Audit Message for DICOM Instances Transferred
A.5.3.8-1. Audit Message for DICOM Study Deleted
A.5.3.9-1. Audit Message for Network Entry
A.5.3.10-1. Audit Message for Query
A.5.3.11-1. Audit Message for Security Alert
A.5.3.12-1. Audit Message for User Authentication
A.5.3.13-1. Audit Message for Order Record
A.5.3.14-1. Audit Message for Patient Record
A.5.3.15-1. Audit Message for Procedure Record
B.1-1. Minimum Mechanisms for TLS Features
B.2-1. Minimum Mechanisms for ISCL Features
B.3-1. Minimum Mechanisms for TLS Features
B.4-1. Minimum Mechanisms for DICOM Association Negotiation Features - Basic User Identity Association Profile
B.5-1. User Identity Plus Passcode Association Profile - Minimum Mechanisms for DICOM Association Negotiation Features
B.6-1. Kerberos Identity Negotiation Association Profile - Minimum Mechanisms for DICOM Association Negotiation Features
B.7-1. Generic SAML Assertion Identity Negotiation Association Profile - Minimum Mechanisms for DICOM Association Negotiation Features
E.1-1. Application Level Confidentiality Profile Attributes
E.3.10-1. Safe Private Attributes
F.1-1. Basic Network Address Management Profile
F.1-2. DHCP Parameters
G.1-1. Basic Time Synchronization Profile
H.1-1. Application Configuration Management Profiles
H.1-2. Attributes of Device Object
H.1-3. Child Objects of Device Object
H.1-4. Attributes of Network AE Object
H.1-5. Child Objects of Network AE Object
H.1-6. Attributes of Network Connection Object
H.1-7. Attributes of Transfer Capability Object
H.1-8. Attributes of the DICOM Configuration Root Object
H.1-9. Child Objects of DICOM Configuration Root Object
H.1-10. Attributes of the Devices Root Object
H.1-11. Child Objects of Devices Root Object
H.1-12. Attributes of the Unique AE Titles Registry Root Object
H.1-13. Child Objects of Unique AE Titles Registry Root Object
H.1-14. Attributes of the Unique AE Title Object
H.1-15. LDAP Security Patterns

Notice and Disclaimer

The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.

NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.

NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.

In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.

NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.

Foreword

This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.

The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].

DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to digital communications of medical information, all rights reserved.

HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.

SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.

LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.

1 Scope and Field of Application

This part of the DICOM Standard specifies Security and System Management Profiles to which implementations may claim conformance. Security and System Management Profiles are defined by referencing externally developed standard protocols, such as TLS, ISCL, DHCP, and LDAP, with attention to their use in a system that uses DICOM Standard protocols for information interchange.

1.1 Security Policies and Mechanisms

The DICOM standard does not address issues of security policies, though clearly adherence to appropriate security policies is necessary for any level of security. The standard only provides mechanisms that could be used to implement security policies with regard to the interchange of DICOM objects between Application Entities. For example, a security policy may dictate some level of access control. This Standard does not consider access control policies, but does provide the technological means for the Application Entities involved to exchange sufficient information to implement access control policies.

This Standard assumes that the Application Entities involved in a DICOM interchange are implementing appropriate security policies, including, but not limited to access control, audit trails, physical protection, maintaining the confidentiality and integrity of data, and mechanisms to identify users and their rights to access data. Essentially, each Application Entity must insure that their own local environment is secure before even attempting secure communications with other Application Entities.

When Application Entities agree to interchange information via DICOM through association negotiation, they are essentially agreeing to some level of trust in the other Application Entities. Primarily Application Entities trust that their communication partners will maintain the confidentiality and integrity of data under their control. Of course that level of trust may be dictated by local security and access control policies.

Application Entities may not trust the communications channel by which they communicate with other Application Entities. Thus, this Standard provides mechanisms for Application Entities to securely authenticate each other, to detect any tampering with or alteration of messages exchanged, and to protect the confidentiality of those messages while traversing the communications channel. Application Entities can optionally utilize any of these mechanisms, depending on the level of trust they place in the communications channel.

This Standard assumes that Application Entities can securely identify local users of the Application Entity, and that user's roles or licenses. Note that users may be persons, or may be abstract entities, such as organizations or pieces of equipment. When Application Entities agree to an exchange of information via DICOM, they may also exchange information about the users of the Application Entity via the Certificates exchanged in setting up the secure channel. The Application Entity may then consider the information contained in the Certificates about the users, whether local or remote, in implementing an access control policy or in generating audit trails.

This Standard also assumes that Application Entities have means to determine whether or not the "owners" (e.g., patient, institution) of information have authorized particular users, or classes of users to access information. This Standard further assumes that such authorization might be considered in the access control provided by the Application Entity. At this time, this Standard does not consider how such authorization might be communicated between Application Entities, though that may be a topic for consideration at some future date.

This Standard also assumes that an Application Entity using TLS has secure access to or can securely obtain X.509 key Certificates for the users of the application entity. In addition, this standard assumes that an Application Entity has the means to validate an X.509 certificate that it receives. The validation mechanism may use locally administered authorities, publicly available authorities, or some trusted third party.

This Standard assumes that an Application Entity using ISCL has access to an appropriate key management and distribution system (e.g., smartcards). The nature and use of such a key management and distribution system is beyond the scope of DICOM, though it may be part of the security policies used at particular sites.

1.2 System Management Profiles

The System Management Profiles specified in this Part are designed to support automation of the configuration management processes necessary to operate a system that uses DICOM Standard protocols for information interchange.

This Part assumes that the Application Entities may operate in a variety of network environments of differing complexity. These environments may range from a few units operating on an isolated network, to a department-level network with some limited centralized network support services, to an enterprise-level network with significant network management services. Note that the System Management Profiles are generally addressed to the implementation, not to Application Entities. The same Profiles need to be supported by the different applications on the network.

2 Normative References

The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.

[ISO/IEC Directives, Part 2] ISO/IEC. 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .

ANSI X9.52 American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.

ECMA 235, The ECMA GSS-API Mechanism

FIPS PUB 46 Data Encryption Standard

FIPS PUB 81 DES Modes of Operation

IETF Internet X.509 Public Key Infrastructure; Time Stamp Protocols; March 2000

ISO/IEC 10118-:1998 Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions (RIPEMD-160 reference)

Note: The draft RIPEMD-160 specification and sample code are also available at ftp://ftp.esat.kuleuven.ac.be/pub/bosselae/ripemd

ISO 7498-1, Information Processing Systems - Open Systems Interconnection - Basic Reference Model

ISO 7498-2, Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture

ISO/TR 8509, Information Processing Systems - Open Systems Interconnection - Service Conventions

ISO 8649:1987, Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element

Integrated Secure Communication Layer V1.00 MEDIS-DC

ITU-T Recommendation X.509 (03/00) "Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks"

Note

ITU-T Recommendation X.509 is similar to ISO/IEC 9594-8 1990. However, the ITU-T recommendation is the more familiar form, and was revised in 1993 and 2000, with two sets of corrections in 2001. ITU-T was formerly known as CCITT.

RFC1035 Domain Name System (DNS)

RFC1305 Network Time Protocol (Version 3) Specification, Implementation

RFC2030 Simple Network Time Protocol (SNTP) Version 4

RFC2131 Dynamic Host Configuration Protocol

RFC2132 Dynamic Host Configuration Protocol Options

RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE)

RFC2181 Clarifications to the DNS Specification

RFC2219 Use of DNS Aliases for Network Services

RFC2246, Transport Layer Security (TLS) 1.0 Internet Engineering Task Force

Note

TLS is derived from SSL 3.0, and is largely compatible with it.

RFC2251 Lightweight Directory Access Protocol (v3)

RFC2313 PKCS #1: RSA Encryption, Version 1.5, March 1998.

RFC2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients

RFC2782 A DNS RR for specifying the location of services (DNS SRV)

RFC2849 The LDAP Data Interchange Format (LDIF)

RFC2898 PKCS #5: Password-Based Cryptography Specification Version 2.0, September 2000

RFC3211 Password-based Encryption for CMS, December 2001

RFC3268 Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS), June 2002.

RFC3447 PKCS #1 RSA Cryptography Specifications Version 2.1, February 2003

Note

The RSA Encryption Standard is also defined in informative annex A of ISO/IEC 9796, and in Normative Annex A of the CEN/TC251 European Prestandard prENV 12388:1996.

RFC3852 Cryptographic Message Syntax,July 2004

RFC3370 Cryptographic Message Syntax (CMS) Algorithms, August 2002

RFC3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), July 2003

SHA-1 National Institute of Standards and Technology, FIPS Pub 180-1: Secure Hash Standard, 17 April 1995

SHA-2 National Institute of Standards and Technology, FIPS Pub 180-2: Secure Hash Standard, 1 August 2002

RFC3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification

RFC3853 S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

RFC5424 The Syslog Protocol

RFC5425 Transport Layer Security (TLS) Transport Mapping for Syslog

RFC5426 Transmission of Syslog Messages over UDP

Note

Normative RFC's are frequently updated by issuance of subsequent RFC's. The original older RFC is not modified to include references to the newer RFC.

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 Reference Model Definitions

This part of the Standard makes use of the following terms defined in ISO 7498-1:

  1. Application Entity

  2. Protocol Data Unit or Layer Protocol Data Unit

  3. Transport Connection

3.2 Reference Model Security Architecture Definitions

This Part of the Standard makes use of the following terms defined in ISO 7498-2:

  1. Data Confidentiality

    Note

    The definition is "the property that information is not made available or disclosed to unauthorized individuals, entities or processes."

  2. Data Origin Authentication

    Note

    The definition is "the corroboration that the source of data received is as claimed."

  3. Data Integrity

    Note

    The definition is "the property that data has not been altered or destroyed in an unauthorized manner."

  4. Key Management

    Note

    The definition is "the generation, storage, distribution, deletion, archiving and application of keys in accordance with a security policy."

  5. Digital Signature

    Note

    The definition is "Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of that unit and protect against forgery e.g., by the recipient."

3.3 ACSE Service Definitions

This part of the Standard makes use of the following terms defined in ISO 8649:

  1. Association or Application Association

3.4 Security Definitions

This Part of the Standard makes use of the following terms defined in ECMA 235:

  1. Security Context

    Note

    The definition is "security information that represents, or will represent a Security Association to an initiator or acceptor that has formed, or is attempting to form such an association."

3.5 DICOM Introduction and Overview Definitions

This Part of the Standard makes use of the following terms defined in PS3.1:

  1. Attribute

3.6 DICOM Conformance Definitions

This Part of the Standard makes use of the following terms defined in PS3.2:

  1. Security Profile

3.7 DICOM Information Object Definitions

This Part of the Standard makes use of the following terms defined in PS3.3:

  1. Module

3.8 DICOM Service Class Definitions

This Part of the Standard makes use of the following terms defined in PS3.4:

  1. Service Class

  2. Service-Object Pair (SOP) Instance

3.9 DICOM Communication Support Definitions

This Part of the Standard makes use of the following terms defined in PS3.8:

  1. DICOM Upper Layer

3.10 DICOM Security Profile Definitions

The following definitions are commonly used in this Part of the DICOM Standard:

Secure Transport Connection:

a Transport Connection that provides some level of protection against tampering, eavesdropping, masquerading.

Message Authentication Code:

A digest or hash code derived from a subset of Data Elements.

Certificate:

An electronic document that identifies a party and that party's public encryption algorithm, parameters, and key. The Certificate also includes, among other things, the identity and a digital signature from the entity that created the certificate. The content and format of a Certificate are defined by ITU-T Recommendation X.509.

4 Symbols and Abbreviations

The following symbols and abbreviations are used in this Part of the Standard.

ACR

American College of Radiology

AE

Application Entity

AES

Advanced Encryption Standard

ANSI

American National Standards Institute

CEN TC251

Comite European de Normalisation-Technical Committee 251-Medical Informatics

CBC

Cipher Block Chaining

CCIR

Consultative Committee, International Radio

CN

Common Name

DES

Data Encryption Standard

DHCP

Dynamic Host Configuration Protocol

DICOM

Digital Imaging and Communications in Medicine

DN

Distinguished Name

DNS

Domain Name System

DDNS

Dynamic Domain Name System

ECMA

European Computer Manufacturers Association

EDE

Encrypt-Decrypt-Encrypt

HL7

Health Level 7

IEC

International Electrical Commission

IEEE

Institute of Electrical and Electronics Engineers

IETF

Internet Engineering Task Force

IOD

Information Object Definition

ISCL

Integrated Secure Communication Layer

ISO

International Standards Organization

JIRA

Japan Medical Imaging and Radiological Systems Industries Association

LDAP

Lightweight Directory Access Protocol

LDIF

LDAP Interchange Format

MAC

Message Authentication Code

MD-5

Message Digest - 5

MEDIS-DC

Medical Information System Development Center

MTU

Maximum Transmission Unit

NEMA

National Electrical Manufacturers Association

NTP

Network Time Protocol

OID

Object Identifier (analogous to UID)

PDU

Protocol Data Unit

RDN

Relative Distinguished Name

RFC

Request For Comment (used for standards issued by the IETF)

RR

Resource Record (when used in the context of DNS)

RSA

Rivest-Shamir-Adleman

SCP

Service Class Provider

SCU

Service Class User

SHA

Secure Hash Algorithm

SNTP

Simple Network Time Protocol

SOP

Service-Object Pair

SSH

Secure Shell

SSL

Secure Sockets Layer

TLS

Transport Layer Security

UID

Unique Identifier

UTC

Universal Coordinated Time

5 Conventions

Terms listed in Section 3 Definitions are capitalized throughout the document.

6 Security and System Management Profile Outlines

An implementation may claim conformance to any of the Security and System Management Profiles individually. It may also claim conformance to more than one Security or System Management Profile. It shall indicate in its Conformance Statement how it chooses which profiles to use for any given transaction.

6.1 Secure Use Profiles

An implementation may claim conformance to one or more Secure Use Profiles. Such profiles outline the use of attributes and other Security Profiles in a specific fashion.

Secure Use Profiles are specified in Annex A.

6.2 Secure Transport Connection Profiles

An implementation may claim conformance to one or more Secure Transport Connection Profiles.

A Secure Transport Connection Profile includes the following information:

  1. Description of the protocol framework and negotiation mechanisms

  2. Description of the entity authentication an implementation shall support

    1. The identity of the entities being authenticated

    2. The mechanism by which entities are authenticated

    3. Any special considerations for audit log support

  3. Description of the encryption mechanism an implementation shall support

    1. The method of distributing session keys

    2. The encryption protocol and relevant parameters

  4. Description of the integrity check mechanism an implementation shall support

Secure Transport Connection Profiles are specified in Annex B.

6.3 Digital Signature Profile

An implementation may claim conformance to one or more Digital Signature Profiles.

A Digital Signature profile consists of the following information:

  1. The role that the Digital Signature plays, including:

    1. Who or what entity the Digital Signature represents.

    2. A description of the purpose of the Digital Signature.

    3. The conditions under which the Digital Signature is included in the Data Set.

  2. A list of Attributes that shall be included in the Digital Signature.

  3. The mechanisms that shall be used to generate or verify the Digital Signature, including:

    1. The algorithm and relevant parameters that shall be used to create the MAC or hash code, including the Value to be used for the MAC Algorithm (0400,0015) Attribute.

    2. The encryption algorithm and relevant parameters that shall be used to encrypt the MAC or hash code in forming the Digital Signature.

    3. The certificate type or key distribution mechanism that shall be used, including the Value to be used for the Certificate Type (0400,0110) Attribute.

    4. Any requirements for the Certified Timestamp Type (0400,0305) and Certified Timestamp (0400,0310) Attributes.

  4. Any special requirements for identifying the signatory.

  5. The relationship with other Digital Signatures, if any.

  6. Any other factors needed to create, verify, or interpret the Digital Signature

Digital Signature Profiles are specified in Annex C.

6.4 Media Storage Security Profiles

An implementation may claim conformance to one or more Media Storage Application Profiles, which in turn require conformance to one or more Media Storage Security Profiles.

Note

An implementation may not claim conformance to a Media Storage Security Profile without claiming conformance to a Media Storage Application Profile.

A Media Storage Security Profile includes the following specifications:

  1. What aspects of security are addressed by the profile.

  2. The restrictions on the types of DICOM Files that can be secured, if any.

  3. How the DICOM Files will be encapsulated and secured.

Media Storage Security Profiles are specified in Annex D.

6.5 Network Address Management Profiles

An implementation may claim conformance to one or more Network Address Management Profiles. Such profiles outline the use of non-DICOM network protocols to obtain the network addresses for the implementation.

Network Address Management Profiles are specified in Annex F.

6.6 Time Synchronization Profiles

An implementation may claim conformance to one or more Time Synchronization Profiles. Such profiles outline the use of non-DICOM protocols to set the current time for the implementation.

Time Synchronization Profiles are specified in Annex G.

6.7 Application Configuration Management Profiles

An implementation may claim conformance to one or more Application Configuration Management Profiles. Such profiles outline the use of non-DICOM network protocols to obtain the descriptions, addresses and capabilities of other devices with which the implementation may communicate using the DICOM Protocol. They also specify the use of those non-DICOM protocols for the implementation to publish or announce its description, addresses and capabilities. They also specify how implementation specific configuration information can be obtained by devices.

Application Configuration Management Profiles are specified in Annex H.

6.8 Audit Trail Profiles

An implementation may claim conformance to one or more Audit Trail Profiles. Such profiles outline the generation and transport of audit messages for security and privacy policy enforcement.

Audit Trail Profiles are specified in Annex A.

7 Configuration Profiles

Configuration management support is implemented by means of protocols defined in standards other than the DICOM standard. These protocols are described here in terms of actors, transactions, and profiles.

Actors are analogous to the Application Entities used within the DICOM profile. An actor is a collection of hardware and software processes that perform a particular role. When a device provides or uses a service it will include an actor to handle the relevant network activity. DICOM Configuration actors may co-exist with other Application Entities on a device. Some DICOM Configuration actors exist as parts of general use IT equipment. Like the Application Entity, specification of an Actor does not imply anything about the details of the actual implementation.

The actor interactions are defined in terms of Transactions. Each transaction is given a name. The transaction may in turn comprise a variety of activity. All transactions are defined in terms of actors that are communicating. The relationships between actors in a transaction may be more complex than the simple SCU and SCP roles in DICOM activities. When the transaction includes interactions with a person, the transactions may be implemented by user interfaces, removable media. and other mechanisms. The person is described in terms of being an actor from the perspective of the transaction use case model. More typically the transactions are a series of network activities that perform a specific operation.

A transaction includes both mandatory and optional components. An Actor that is implementing a transaction is required to implement all of the mandatory components.

Some transactions include human actors in the transaction definition. These actors are not defined as actors elsewhere, nor are they included in profile descriptions. They exist to specify that some sort of mechanism must be provided to permit these people to interact with the computer actor. Other details of how that user interface is provided are not specified by this standard. For an example, see the definition of the Configure DHCP transaction.

Conformance is further managed by means of Profiles. A Profile is defined in terms of what transactions are required for an actor and what transactions are optional. An implementation of a specific actor is documented by specifying what optional transactions and transaction components have been implemented. An implementation that omits any required transactions or components cannot claim to be an implementation of that Actor.

For example, in the Network Address Management Profile the DHCP Server is required to perform the three Transactions to configure the DHCP server, find and use DHCP servers, and maintain the DHCP leases. It may also support the transaction to update the DNS server by means of DDNS coordination.

A Profile includes definitions for more than one Actor. It specifies the transactions for all of the actors that cooperate to perform a function. For example, the Network Address Management Profile covers the DHCP Server actor, the DHCP client Actor, and the DNS Server actor. There must be at least one DHCP Server and one DHCP Client for the system to be useful. The DNS Server itself is optional because the DHCP Server need not implement the DDNS Coordination transaction. If the DNS Server is part of the system, the DDNS coordination is required and the DHCP Server will be expected to participate in the DDNS Coordination transaction.

Note

There may be a DNS server present on the same network as a DHCP Server, but if it is not providing the DNS Server actor from this profile it is not part of the DICOM Configuration activities.

The profiles, actors, and transactions are summarized in the following sections. The detailed description of actor and transactions for each specific profile are described in annexes for each profile. The transactions are documented in terms of parameters and terms from their original standards document, e.g., an RFC for Internet protocols. The full details of the transaction are not described in the annex, only particular details that are relevant to the DICOM application of that transaction. The complete details for these external protocols are documented in the relevant standards documents for the external protocols. Compliance with the requirements of a particular profile shall include compliance with these external protocol documents.

7.1 Actors

DHCP Server

The DHCP Server is a computer/software feature that is provided with a network configuration description, and that provides startup configuration services in accordance with the DHCP protocol.

DHCP Client

The DHCP Client is a software feature that is used to obtain TCP/IP parameters during the startup of a computer. It continues operation to maintain validity of these parameters.

DNS Server

The DNS server is a computer/software feature that provides IP related information in response to queries from clients utilizing the DNS protocol. It is a part of a federated database facility that maintains the current database relating machine names to IP address information. The DNS server may also be isolated from the worldwide federated database and provide only local DNS services.

DNS Client

The DNS client as a computer/software feature that utilizes the DNS protocols to obtain IP information when given hostnames. The hostnames may be in configuration files or other files instead of explicit IP addresses. The hostnames are converted into IP addresses dynamically when necessary. The DNS client uses a DNS server to provide the necessary information.

NTP Server

The NTP server is a computer/software feature that provides time services in accordance with the NTP or SNTP protocol.

NTP Client

The NTP client is software that obtains time information from an NTP server and maintains the client time in synchronization with the time signals from the NTP server.

SNTP Client

The SNTP client is software that obtains time information from an NTP server and maintains the client time in approximate synchronization with time signals from the NTP server. The SNTP client synchronization is not maintained with the accuracy or precision that NTP provides.

LDAP Server

The LDAP server is a computer/ software feature that maintains an internal database of various directory information. Some of this directory information corresponds to DICOM Configuration schema. The LDAP server provides network access to read and update the directory information. The LDAP server provides a mechanism for external loading, unloading, and backup of directory information. The LDAP server may be part of a federated network of servers that provides a coordinated view of a federated directory database in accordance with the rules of the LDAP protocols.

LDAP Client

The LDAP client utilizes the LDAP protocol to make queries to an LDAP server. The LDAP server maintains a database and responds to these queries based on the contents of this database.

7.2 Transactions

The following transactions are used to provide communications between actors in accordance with one or more of the DICOM Configuration protocols.

Configure DHCP Server

This transaction changes the configuration on a DHCP server to reflect additions, deletions, and changes to the IP parameters that have been established for this network.

Find and Use DHCP Server

This transaction is a sequence of network messages that comply with the rules of the DHCP protocol. It allows a DHCP client to find available DHCP servers and select the server appropriate for that client. This transaction obtains the mandatory IP parameter information from the DHCP server and obtains additional optional parameters from the DHCP server.

Configure Client

The service staff uses this transaction to set the initial configuration for a client.

Maintain Lease

This transaction deals with how the DHCP client should behave when its IP lease is not renewed.

DDNS Coordination

This transaction documents whether the DHCP server is coordinating with a DNS server so that access to the DHCP client can be maintained using the hostname assigned to the DHCP client.

Resolve Hostname

This transaction obtains the IP address for a computer when given a hostname.

Maintain Time

These transactions are the activities needed for an NTP or SNTP client to maintain time synchronization with a master time service.

Find NTP Server

This transaction is the autodiscovery procedure defined for NTP. This may use either a broadcast method or a DHCP supported method.

Find LDAP Server

In this transaction the DNS server is queried to obtain the IP address, port, and name of the LDAP server.

Query LDAP Server

In this transaction the LDAP server is queried regarding contents of the LDAP database.

Client Update LDAP Server

This transaction updates the configuration database using LDAP update instructions from the client being configured.

Maintain LDAP Server

This transaction updates the configuration database using local services of the LDAP server.

Figure 7-1 shows the actors and their transactions. The usual device will have an NTP Client, DHCP Client, and LDAP client in addition to the other applications actors. The transactions "Configure DHCP Server", "Configure Client", and "Maintain LDAP Server" are not shown because these transactions are between a software actor and a human actor. DICOM does not specify the means or user interface. It only requires that certain capabilities be supported.

Transactions and Actors

Figure 7-1. Transactions and Actors


A Secure Use Profiles (Normative)

A.1 Online Electronic Storage Secure Use Profile

The Online Electronic Storage Secure Use Profile allows Application Entities to track and verify the status of SOP Instances in those cases where local security policies require tracking of the original data set and subsequent copies.

The Conformance Statement shall indicate in what manner the system restricts remote access.

A.1.1 SOP Instance Status

An implementation that conforms to the Online Electronic Storage Secure Use Profile shall conform to the following rules regarding the use of the SOP Instance Status (0100,0410) Attribute with SOP Instances that are transferred using the Storage Service Class:

  1. An Application Entity that supports the Online Electronic Storage Secure Use Profile and that creates a SOP Instance intended for diagnostic use in Online Electronic Storage shall:

    1. Set the SOP Instance Status to Original (OR).

    2. Include the following Attributes:

      1. the SOP Class UID (0008,0016) and SOP Instance UID (0008,0018)

      2. the Instance Creation Date (0008,0012) and Instance Creation Time (0008,0013), if known

      3. the SOP Instance Status

      4. the SOP Authorization Date and Time (0100,0420)

      5. the SOP Authorization Comment, if any (0100,0424)

      6. the SOP Equipment Certification Number (0100,0426)

      7. the Study Instance UID (0020,000D) and Series Instance UID (0020,000E)

      8. any Attributes of the General Equipment Module that are known

      9. any overlay data present

      10. any image data present

  2. The Application Entity that holds a SOP Instance where the SOP Instance Status is Original (OR) may change the SOP Instance Status to Authorized Original(AO) as long as the following rules are followed:

    1. The Application Entity shall determine that an authorized entity has certified the SOP Instance as useable for diagnostic purposes.

    2. The Application Entity shall change the SOP Instance Status to Authorized Original (AO). The SOP Instance UID shall not change.

    3. The Application Entity shall set the SOP Authorization Date and Time (0100,0420) and Authorization Equipment Certification Number (0100,0426) Attributes to appropriate values. It may also add an appropriate SOP Authorization Comment (0100,0424) Attribute.

  3. There shall only be one Application Entity that holds a SOP Instance where the SOP Instance Status is Original (OR) or Authorized Original (AO). The Application Entity that holds such a SOP instance shall not delete it.

  4. When communicating with an Application Entity that supports Online Electronic Storage the Application Entity that holds a SOP Instance where the SOP Instance Status is Original(OR) or Authorized Original(AO) may transfer that SOP Instance to another Application Entity that also conforms to the Online Electronic Storage Secure Use Profile as long as the following rules are followed:

    1. The transfer shall occur on a Secure Transport Connection.

    2. The two Application Entities involved in the transfer shall authenticate each other and shall confirm via the authentication that the other supports the Online Electronic Storage Secure Use Profile.

    3. The receiving Application Entity shall reject the storage request and discard the received SOP Instance if the data integrity checks done after the transfer indicate that the SOP Instance was altered during transmission.

    4. The transfer shall be confirmed using the push model of the Storage Commitment Service Class. Until it has completed this confirmation, the receiving Application Entity shall not forward the SOP Instance or Authorized Copies of the SOP instance to any other Application Entity.

    5. Once confirmed that the receiving Application Entity has successfully committed the SOP Instance to storage, the sending Application Entity shall do one of the following to its local copy of the SOP Instance:

      1. delete the SOP Instance,

      2. change the SOP Instance Status to Not Specified (NS),

      3. if the SOP Instance Status was Authorized Original (AO), change the SOP Instance Status to Authorized Copy (AC).

  5. When communicating with an Application Entity that supports Online Electronic Storage an Application Entity that holds a SOP Instance whose SOP Instance Status is Authorized Original (AO) or Authorized Copy (AC) may send an Authorized Copy of the SOP Instance to another Application Entity as long as the following rules are followed:

    1. The transfer shall occur on a Secure Transport Connection.

    2. The two Application Entities involved in the transfer shall authenticate each other, and shall confirm via the authentication that the other supports the Online Electronic Storage Secure Use Profile.

    3. The sending Application Entity shall set the SOP Instance Status to either Not Specified (NS) or Authorized Copy (AC) in the copy sent. The SOP Instance UID shall not change.

    4. The receiving Application Entity shall reject the storage request and discard the copy if data integrity checks done after the transfer indicate that the SOP Instance was altered during transmission.

  6. If communicating with a system that does not support the Online Electronic Storage Secure Use Profile, or if communication is not done over a Secure Transport Connection, then

    1. A sending Application Entity that conforms to this Security Profile shall either set the SOP Instance Status to Not Specified (NS), or leave out the SOP Instance Status and associated parameters of any SOP Instances that the sending Application Entity sends out over the unsecured Transport Connection or to systems that do not support the Online Electronic Storage Secure Use Profile.

    2. A receiving Application Entity that conforms to this Security Profile shall set the SOP Instance Status to Not Specified (NS) of any SOP Instance received over the unsecured Transport Connection or from systems that do not support the Online Electronic Storage Secure Use Profile.

  7. The receiving Application Entity shall store SOP Instances in accordance with Level 2 as defined in the Storage Service Class (i.e., all Attributes, including Private Attributes), as required by the Storage Commitment Storage Service Class, and shall not coerce any Attribute other than SOP Instance Status, SOP Authorization Date and Time, Authorization Equipment Certification Number, and SOP Authorization Comment.

  8. Other than changes to the SOP Instance Status, SOP Authorization Date and Time, Authorization Equipment Certification Number, and SOP Authorization Comment Attributes, as outlined above, or changes to group length Attributes to accommodate the aforementioned changes, the Application Entity shall not change any Attribute values.

A.2 Basic Digital Signatures Secure Use Profile

An implementation that validates and generates Digital Signatures may claim conformance to the Basic Digital Signatures Secure Use Profile. Any implementation that claims conformance to this Security Profile shall obey the following rules in handling Digital Signatures:

  1. The implementation shall store any SOP Instances that it receives in such a way that it guards against any unauthorized tampering of the SOP Instance.

  2. Wherever possible, the implementation shall validate the Digital Signatures within any SOP Instance that it receives.

  3. If the implementation sends the SOP Instance to another Application Entity, it shall do the following:

    1. remove any Digital Signatures that may have become invalid due to any allowed variations to the format of Attribute Values (e.g., trimming of padding, alternate representations of numbers),

    2. generate one or more new Digital Signatures covering the Data Elements that the implementation was able to verify when the SOP Instance was received.

A.3 Bit-preserving Digital Signatures Secure Use Profile

An implementation that stores and forwards SOP Instances may claim conformance to the Bit-Preserving Digital Signatures Secure Use Profile. Any implementation that claims conformance to this Security Profile shall obey the following rules in handling Digital Signatures:

  1. The implementation shall store any SOP Instances that it receives in such a way that when the SOP instance is forwarded to another Application Entity, the Value fields of all Attributes are bit-for-bit duplicates of the fields originally received.

  2. The implementation shall not change the order of Items in a Sequence.

  3. The implementation shall not remove or change any Data Element of any SOP Instance that it receives when sending that SOP Instance on to another Application Entity via DICOM. This includes any Digital Signatures received.

    Note

    Implementations may add new Data Elements that do not alter any existing Digital Signatures.

  4. The implementation shall utilize an explicit VR Transfer Syntax.

    Note

    Implementations that cannot use an explicit VR Transfer Syntax cannot conform to this Secure Use Profile, since it may not be able to verify Digital Signatures that are received with an implicit VR Transfer Syntax.

  5. The implementation shall not change the VR of any Data Element that it receives when it transmits that object to another Application Entity.

A.4 Basic SR Digital Signatures Secure Use Profile

Any implementation that claims conformance to this Security Profile shall obey the following rules when creating a Structured Report or Key Object Selection Document that includes Digital Signatures:

  1. When the implementation signs a Structured Report or Key Object Selection Document SOP Instance the Digital Signatures shall be created in accordance with the Structured Report RSA Digital Signature Profile.

  2. In every signed Structured Report or Key Object Selection Document SOP Instance created, all referenced SOP Instances listed in the Referenced SOP Sequence Items of the Current Requested Procedure Evidence Sequence (0040,A375) and Pertinent Other Evidence Sequence (0040,A385)shall include either a Referenced Digital Signature Sequence or a Referenced SOP Instance MAC Sequence. The references may include both.

The implementation claiming conformance shall outline in its conformance statement the conditions under which it will either sign or not sign a Structured Report or Key Object Selection Document.

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 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

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


A.5.2 General Message Format Conventions

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.

Note

This schema, codes, and content were originally derived from RFC3881. RFC3881 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 RFC3881 as the underlying standard. RFC3881 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:

M

This element or attribute is mandatory

U

This element or attribute is user optional. The creator may include it or omit it.

MC

This element or attribute is mandatory if a specified condition is true.

UC

This element or attribute may be present only if a specified condition is true, if the user chooses to include it.

Table A.5.2-1. General Message Format

Field Name

Opt.

Description

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".

DCID 400 “Audit Event ID”

EventActionCode

U

Indicator for type of action performed during the event that generated the audit.

C

Create a new database object, such as Placing an Order

R

Read/View/Print/Query Display or print data, such as a Doctor Census

U

Update data, such as Revise Patient Information

D

Delete items, such as a master file record

E

Perform a system or application function such as log-on, program execution, or use of an object's method

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.

0

Success

4

Minor failure; action restarted, e.g., invalid password with first retry

8

Serious failure; action terminated, e.g., invalid password with excess retries

12

Major failure; action made unavailable, e.g., user account disabled due to excessive invalid log-on attempts

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".

DCID 401 “Audit Event Type Code”

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.

DCID 402 “Audit Active Participant Role ID Code”

Note

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.

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).

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.

1

Person

2

System Object

3

Organization

4

Other

ParticipantObjectTypeCodeRole

U

Code representing the functional application role of Participant Object being audited.

See Section A.5.1.2.2.

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.

See Section A.5.1.2.3.

ParticipantObjectIDTypeCode

M

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”

Note

Usage of this field is refined in the individual message descriptions below. Multiple roles may also be present, since this is a multi-valued field.

ParticipantObjectSensitivity

U

Denotes policy-defined sensitivity for the Participant Object ID such as VIP, HIV status, mental health status, or similar topics.

Locally defined terms.

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.

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.

SOPClass

MC

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

An Accession Number(s) associated with this participant object.

MPPS

U

An MPPS Instance UID(s) associated with this participant object.

NumberOfInstances

U

The number of SOP Instances referred to by this participant object.

Instance

U

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

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

A single value of True or False indicating whether or not all patient identifying information was removed from the data

ParticipantObjectContainsStudy

U

A Study Instance UID, which may be used when the ParticipantObjectIDTypeCode is not (110180, DCM, "Study Instance UID").


A.5.2.1 UserID

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:

  1. a URI (the preferred form) identifying the source or destination,

  2. an email address of the form "mailto:user@address"

  3. a description of the media type (e.g., DVD) together with a description of its identifying label, as a free text field,

  4. 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.

A.5.2.2 AlternativeUserID

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:

AETITLES= aetitle1;aetitle2;…

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.5.2.3 Username

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.

A.5.2.4 Multi-homed Nodes

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.

A.5.2.5 EventDateTime

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.

A.5.2.6 ParticipantObjectTypeCodeRole

The ParticipantObjectTypeCodeRole identifies the role that the object played in the event that is being reported. Most events involve multiple participating objects. ParticipantObjectTypeCodeRole identifies which object took which role in the event. It also covers agents, multi-purpose entities, and multi-role entities. For the purpose of the event one primary role is chosen.

Table A.5.2.6-1. ParticipantObjectTypeCodeRole

Code

Short Description

Description

1

Patient

This object is the patient that is the subject of care related to this event. It is identifiable by patient ID or equivalent. The patient may be either human or animal.

2

Location

This is a location identified as related to the event. This is usually the location where the event took place. Note that for shipping, the usual events are arrival at a location or departure from a location.

3

Report

This object is any kind of persistent document created as a result of the event. This could be a paper report, film, electronic report, DICOM Study, etc. Issues related to medical records life cycle management are conveyed elsewhere.

4

Resource

(deprecated)

5

Master File

This is any configurable file used to control creation of documents or behavior. Examples include the objects maintained by the HL7 Master File transactions, Value Sets, etc.

6

User

A human participant not otherwise identified by some other category

7

List

(deprecated)

8

Doctor

A person who is providing or performing care related to the event, generally a physician. The key distinction between doctor and provider is the nature of their participation. The doctor is the human who actually performed the work. The provider is the human or organization that is responsible for the work.

9

Subscriber

A person or system that is being notified as part of the event. This is relevant in situations where automated systems provide notifications to other parties when an event took place.

10

Guarantor

Insurance company, or any other organization who accepts responsibility for paying for the healthcare event.

11

Security User Entity

A person or active system object involved in the event with a security role.

12

Security User Group

(deprecated)

13

Security Resource

A passive object, such as a role table, that is relevant to the event.

14

Security Granularity Definition

(deprecated) Relevant to certain RBAC security methodologies.

15

Provider

A person or organization responsible for providing care. This encompasses all forms of care, licensed or otherwise, and all sorts of teams and care groups. Note, the distinction between providers and the doctor that actually provided the care to the patient.

16

Data Destination

The destination for data transfer, when some other role is not appropriate.

17

Data Archive

A source or destination for data transfer that acts as an archive, database, or similar role.

18

Schedule

An object that holds schedule information. This could be an appointment book, availability information, etc.

19

Customer

An organization or person that is the recipient of services. This could be an organization that is getting services for a patient, or a person that is getting services for an animal.

20

Job

An order, task, work item, procedure step, or other description of work to be performed. E.g., a particular instance of an MPPS.

21

Job Stream

A list of jobs or a system that provides lists of jobs. E.g., an MWL SCP.

22

Table

(Deprecated)

23

Routing Criteria

An object that specifies or controls the routing or delivery of items. For example, a distribution list is the routing criteria for mail. The items delivered may be documents, jobs, or other objects.

24

Query

The contents of a query. This is used to capture the contents of any kind of query. For security surveillance purposes knowing the queries being made is very important.

25

Data Source

The source or origin of data, when there is no other matching role available.

26

Processing Element

A data processing element that creates, analyzes, modifies, or manipulates data as part of this event.


A.5.3 DICOM Specific Audit Messages

The following subsections define message specializations for use by implementations that claim conformance to the DICOM Audit Trail Profile. Any field (i.e., XML element and associated attributes) not specifically mentioned in the following tables shall follow the conventions specified in A.5.1 and A.5.2.

An implementation claiming conformance to this Profile that reports an activity covered by one of the audit messages defined by this Profile shall use the message format defined in this Profile. However, a system claiming conformance to this Profile is not required to send a message each time the activity reported by that audit message occurs. It is expected that the triggering of audit messages would be configurable on an individual basis, to be able to balance network load versus the severity of threats, in accordance with local security policies.

Note

  1. It is a system design issue outside the scope of DICOM as to what entity actually sends an audit event and when. For example, a Query message could be generated by the entity where the query originated, by the entity that eventually would respond to the query, or by a monitoring entity not directly involved with the query, but that generates audit messages based on monitored network traffic.

  2. To report events that are similar to the events described here, these definitions can be used as the basis for extending the schema.

In the subsequent tables, the information entity column indicates the relationship between real world entities and the information elements encoded into the message.

A.5.3.1 Application Activity

This audit message describes the event of an Application Entity starting or stopping. This is closely related to the more general case of any kind of application startup or shutdown, and may be suitable for those purposes also.

Table A.5.3.1-1. Application Activity Message

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110100, DCM, "Application Activity")

EventActionCode

M

Enumerated Value

E = Execute

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

M

DT (110120, DCM, "Application Start")

DT (110121, DCM, "Application Stop")

Active Participant:

Application started (1)

UserID

M

The identity of the process started or stopped formatted as specified in A.5.2.1.

AlternativeUserID

MC

If the process supports DICOM, then the AE Titles as specified in A.5.2.2.

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110150, DCM, "Application")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Persons and or processes that started the Application (0..N)

UserID

M

The person or process starting or stopping the Application

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110151, DCM, "Application Launcher")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized


No Participant Objects are needed for this message.

A.5.3.2 Audit Log Used

This message describes the event of a person or process reading a log of audit trail information.

Note

For example, an implementation that maintains a local cache of audit information that has not been transferred to a central collection point might generate this message if its local cache were accessed by a user.

Table A.5.3.2-1. Audit Log Used Message

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110101, DCM, "Audit Log Used")

EventActionCode

M

Shall be enumerated value:

R = read

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

Persons and or processes that started the Application (1..2)

UserID

M

The person or process accessing the audit trail. If both are known, then two active participants shall be included (both the person and the process).

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

Identity of the audit log (1)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 13 = security resource

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 12 = URI

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The URI of the audit log

ParticipantObjectName

U

Shall be: "Security Audit Log"

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized

SOPClass

U

See Section A.5.2

Accession

U

See Section A.5.2

NumberOfInstances

U

See Section A.5.2

Instances

U

See Section A.5.2

Encrypted

U

See Section A.5.2

Anonymized

U

See Section A.5.2

ParticipantObjectContainsStudy

U

See Section A.5.2


A.5.3.3 Begin Transferring DICOM Instances

This message describes the event of a system beginning to transfer a set of DICOM instances from one node to another node within control of the system's security domain. This message may only include information about a single patient.

Note

A separate Instances Transferred message is defined for transfer completion, allowing comparison of what was intended to be sent and what was actually sent.

Table A.5.3.3-1. Audit Message for Begin Transferring DICOM Instances

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110102, DCM, "Begin Transferring DICOM Instances")

EventActionCode

M

Shall be: E = Execute

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

Process Sending the Data (1)

UserID

M

The identity of the process sending the data.

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110153, DCM, "Source Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Process receiving the data (1)

UserID

M

The identity of the process receiving the data.

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110152, DCM, "Destination Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Other Participants (0..N)

UserID

M

The identity of any other participants that might be involved and known, especially third parties that are the requestor

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

Studies being transferred (1..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

Element "ContainsSOPClass" with one or more SOP Class UID values

ParticipantObjectDescription

U

not specialized

SOPClass

MC

not specialized

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized

Participating Object:

Patient (1)

ParticipantObjectTypeCode

M

Shall be: 1 = person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = patient ID

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized


A.5.3.4 Data Export

This message describes the event of exporting data from a system, meaning that the data is leaving control of the system's security domain. Examples of exporting include printing to paper, recording on film, conversion to another format for storage in an EHR, writing to removable media, or sending via e-mail. Multiple patients may be described in one event message.

Table A.5.3.4-1. Audit Message for Data Export

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110106, DCM, "Export")

EventActionCode

M

Shall be: R = Read

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

Remote Users and Processes (0..n)

UserID

M

The identity of the remote user or process receiving the data

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

See Section A.5.3.4.1

RoleIDCode

M

EV (110152, DCM, "Destination Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

User or Process Exporting the data(1..2)

UserID

M

The identity of the local user or process exporting the data. If both are known, then two active participants shall be included (both the person and the process).

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

See Section A.5.3.4.1

RoleIDCode

M

EV (110153, DCM, "Source Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Media (1)

UserID

M

See Section A.5.2.3

AlternativeUserID

U

See Section A.5.2.4

UserName

U

not specialized

UserIsRequestor

M

Shall be FALSE

RoleIDCode

M

EV (110154, DCM, "Destination Media")

NetworkAccessPointTypeCode

MC

Required if being exported to other than physical media, e.g., to a network destination rather than to film, paper or CD. May be present otherwise.

NetworkAccessPointID

MC

Required if Net Access Point Type Code is present. May be present otherwise.

MediaIdentifier

MC

Volume ID, URI, or other identifier for media.

Required if digital media. May be present otherwise.

MediaType

M

Values selected from DCID 405 “Media Type Code”

Participating Object:

Studies (0..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized

SOPClass

MC

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized

Participating Object:

Patients (1..N)

ParticipantObjectTypeCode

M

Shall be: 1 = person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = patient ID

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized


A.5.3.4.1 UserIsRequestor

A single user (either local or remote) shall be identified as the requestor, i.e., UserIsRequestor with a value of TRUE. This accommodates both push and pull transfer models for media.

A.5.3.5 Data Import

This message describes the event of importing data into an organization, implying that the data now entering the system was not under the control of the security domain of this organization. Transfer by media within an organization is often considered a data transfer rather than a data import event. An example of importing is creating new local instances from data on removable media. Multiple patients may be described in one event message.

A single user (either local or remote) shall be identified as the requestor, i.e., UserIsRequestor with a value of TRUE. This accommodates both push and pull transfer models for media.

Table A.5.3.5-1. Audit Message for Data Import

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110107, DCM, "Import")

EventActionCode

M

Shall be: C = Create

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

User or Process Importing the data (1..n)

UserID

M

The identity of the local user or process importing the data.

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

See Section A.5.3.5

RoleIDCode

M

EV (110152, DCM, "Destination Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Source Media (1)

UserID

M

See Section A.5.2.3

AlternativeUserID

U

See Section A.5.2.4

UserName

U

not specialized

UserIsRequestor

M

Shall be FALSE

RoleIDCode

M

EV (110155, DCM, "Source Media")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

MC

Shall be present if Net Access Point Type Code is present.

MediaIdentifier

M

Volume ID, URI, or other identifier for media

MediaType

M

Values selected from DCID 405 “Media Type Code”

Active Participant:

Source (0..n)

UserID

M

See Section A.5.2.3

AlternativeUserID

U

See Section A.5.2.4

UserName

U

not specialized

UserIsRequestor

M

See Section A.5.3.5

RoleIDCode

M

EV (110153, DCM, "Source Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

MC

Shall be present if Net Access Point Type Code is present.

Participating Object:

Studies (0..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

Not specialized

ParticipantObjectDescription

U

not specialized

SOPClass

MC

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized

Participating Object:

Patients (1..N)

ParticipantObjectTypeCode

M

Shall be: 1 = person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = patient ID

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized


A.5.3.6 DICOM Instances Accessed

This message describes the event of DICOM SOP Instances being viewed, utilized, updated, or deleted. This message shall only include information about a single patient and can be used to summarize all activity for several studies for that patient. This message records the studies to which the instances belong, not the individual instances.

If all instances within a study are deleted, then the EV(110105, DCM, "DICOM Study Deleted") event shall be used, see Section A.5.3.8.

Table A.5.3.6-1. Audit Message for DICOM Instances Accessed

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110103, DCM, "DICOM Instances Accessed")

EventActionCode

M

Enumerated value:

C = create

R = read

U = update

D = delete

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

Person and or Process manipulating the data

(1..2)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

Studies (1..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

Not specialized

ParticipantObjectDescription

U

Not specialized

SOPClass

MC

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized

Participating Object:

Patient (1)

ParticipantObjectTypeCode

M

Shall be: 1 = person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = patient ID

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized


A.5.3.7 DICOM Instances Transferred

This message describes the event of the completion of transferring DICOM SOP Instances between two Application Entities. This message may only include information about a single patient.

Note

This message may have been preceded by a Begin Transferring Instances message. The Begin Transferring Instances message conveys the intent to store SOP Instances, while the Instances Transferred message records the completion of the transfer. Any disagreement between the two messages might indicate a potential security breach.

Table A.5.3.7-1. Audit Message for DICOM Instances Transferred

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110104, DCM, "DICOM Instances Transferred")

EventActionCode

M

Enumerated Value:

C = (create) if the receiver did not hold copies of the instances transferred

R = (read) if the receiver already holds copies of the SOP Instances transferred, and has determined that no changes are needed to the copies held.

U = (update) if the receiver is altering its held copies to reconcile differences between the held copies and the received copies.

If the Audit Source is either not the receiver, or otherwise does not know whether or not the instances previously were held by the receiving node, then use "R" = (Read).

EventDateTime

M

Shall be the time when the transfer has completed

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

Process that sent the data (1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110153, DCM, "Source Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

The process that received the data. (1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110152, DCM, "Destination Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Other participants that are known, especially third parties that are the requestor (0..N)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

Studies being transferred (1..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

Not specialized

ParticipantObjectDescription

U

Not specialized

SOPClass

MC

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized

Participating Object:

Patient (1)

ParticipantObjectTypeCode

M

Shall be: 1 = person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = patient ID

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized


A.5.3.8 DICOM Study Deleted

This message describes the event of deletion of one or more studies and all associated SOP Instances in a single action. This message shall only include information about a single patient.

Table A.5.3.8-1. Audit Message for DICOM Study Deleted

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110105, DCM, "DICOM Study Deleted")

EventActionCode

M

Shall be: D = delete

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

the person or process deleting the study (1..2)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

Studies being transferred (1..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

Not specialized

ParticipantObjectDescription

U

Not specialized

SOPClass

MC

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized

Participating Object:

Patient (1)

ParticipantObjectTypeCode

M

Shall be: 1 = person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = patient ID

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not specialized


A.5.3.9 Network Entry

This message describes the event of a system, such as a mobile device, intentionally entering or leaving the network.

Note

The machine should attempt to send this message prior to detaching. If this is not possible, it should retain the message in a local buffer so that it can be sent later. The mobile machine can then capture audit messages in a local buffer while it is outside the secure domain. When it is reconnected to the secure domain, it can send the detach message (if buffered), followed by the buffered messages, followed by a mobile machine message for rejoining the secure domain. The timestamps on these messages is the time that the event was noticed to have occurred, not the time that the message is sent.

Table A.5.3.9-1. Audit Message for Network Entry

Real World Entities

Field Name

Opt.

Value

Event

EventID

M

EV (110108, DCM, "Network Entry")

EventActionCode

M

Shall be: E = Execute

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

M

EV (110124, DCM, "Attach")EV (110125, DCM, "Detach")

Active Participant:

Node or System entering or leaving the network (1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

Shall be FALSE

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized


No Participant Objects are needed for this message.

A.5.3.10 Query

This message describes the event of a Query being issued or received. The message does not record the response to the query, but merely records the fact that a query was issued. For example, this would report queries using the DICOM SOP Classes:

  1. Modality Worklist

  2. UPS Pull

  3. UPS Watch

  4. Composite Instance Query

Note

  1. The response to a query may result in one or more Instances Transferred or Instances Accessed messages, depending on what events transpire after the query. If there were security-related failures, such as access violations, when processing a query, those failures should show up in other audit messages, such as a Security Alert message.

  2. Non-DICOM queries may also be captured by this message. The Participant Object ID Type Code, the Participant Object ID, and the Query fields may have values related to such non-DICOM queries.

Table A.5.3.10-1. Audit Message for Query

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110112, DCM, "Query")

EventActionCode

M

Shall be: E = Execute

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

Active Participant:

Process Issuing the Query (1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110153, DCM, "Source Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

The process that will respond to the query (1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

M

EV (110152, DCM, "Destination Role ID")

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Other Participants that are known, especially third parties that requested the query (0..N)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

SOP Queried and the Query (1)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

M

Shall be: 3 = report

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

DT (110181, DCM, "SOP Class UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

If the ParticipantObjectIDTypeCode is (110181, DCM, "SOP Class UID"), then this field shall hold the UID of the SOP Class being queried

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

M

If the ParticipantObjectIDTypeCode is (110181, DCM, "SOP Class UID"), then this field shall hold the Dataset of the DICOM query, xs:base64Binary encoded. Otherwise, it shall be the query in the format of the protocol used.

ParticipantObjectDetail

MC

Required if the ParticipantObjectIDTypeCode is (110181, DCM, "SOP Class UID")

A ParticipantObjectDetail element with the XML attribute "TransferSyntax" shall be present. The value of the Transfer Syntax attribute shall be the UID of the transfer syntax of the query. The element contents shall be xs:base64Binary encoding. The Transfer Syntax shall be a DICOM Transfer Syntax.

ParticipantObjectDescription

U

not specialized

SOPClass

U

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized


A.5.3.11 Security Alert

This message describes any event for which a node needs to report a security alert, e.g., a node authentication failure when establishing a secure communications channel.

Note

The Node Authentication event can be used to report both successes and failures. If reporting of success is done, this could generate a very large number of audit messages, since every authenticated DICOM association, HL7 transaction, and HTML connection should result in a successful node authentication. It is expected that in most situations only the failures will be reported.

Table A.5.3.11-1. Audit Message for Security Alert

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110113, DCM, "Security Alert")

EventActionCode

M

Shall be: E = Execute

EventDateTime

M

not specialized

EventOutcomeIndicator

M

Success implies an informative alert. The other failure values imply warning codes that indicate the severity of the alert. A Minor or Serious failure indicates that mitigation efforts were effective in maintaining system security. A Major failure indicates that mitigation efforts may not have been effective, and that the security system may have been compromised.

EventTypeCode

M

Values selected from DCID 403 “Security Alert Type Code”.

Active Participant:

Reporting Person and/or Process (1..2)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Active Participant:

Performing Persons or Processes (0..N)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

Shall be FALSE

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Participating Object:

Alert Subject (0..N)

ParticipantObjectTypeCode

M

Shall be: 2 = system

ParticipantObjectTypeCodeRole

U

Defined Terms:

5 = master file

13 = security resource

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Defined Terms:

12 = URI(110182, DCM, "Node ID") = Node Identifier

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

For a ParticipantObjectIDTypeCode of 12 (URI), then this value shall be the URI of the file or other resource that is the subject of the alert.

For a ParticipantObjectIDTypeCode of (110182, DCM, "Node ID") then the value shall include the identity of the node that is the subject of the alert either in the form ofnode_name@domain_nameor as an IP address.

Otherwise, the value shall be an identifier of the type specified by ParticipantObjectIDTypeCode of the subject of the alert.

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

M

An element with the Attribute "type" equal to "Alert Description" shall be present with a free text description of the nature of the alert as the value

ParticipantObjectDescription

U

not specialized

SOPClass

U

See Table A.5.2-1

Accession

U

not specialized

NumberOfInstances

U

not specialized

Instances

U

not specialized

Encrypted

U

not specialized

Anonymized

U

not specialized


A.5.3.12 User Authentication

This message describes the event that a user has attempted to log on or log off. This report can be made regardless of whether the attempt was successful or not. No Participant Objects are needed for this message.

Note

The user usually has UserIsRequestor TRUE, but in the case of a logout timer, the Node might be the UserIsRequestor.

Table A.5.3.12-1. Audit Message for User Authentication

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110114, DCM, "User Authentication")

EventActionCode

M

Shall be: E = Execute

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

M

Defined Terms:

EV (110122, DCM, "Login")

EV (110123, DCM, "Logout")

Active Participant:

Person Authenticated or claimed

(1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

M

not specialized

NetworkAccessPointID

M

not specialized

Active Participant:

Node or System performing authentication (0..1)

UserID

M

not specialized

AlternativeUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

M

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized


A.5.3.13 Order Record

This message describes the event of an order being created, modified, accessed, or deleted. This message may only include information about a single patient.

Note

An order record typically is managed by a non-DICOM system. However, DICOM applications often manipulate order records, and thus may be obligated by site security policies to record such events in the audit logs.

Table A.5.3.13-1. Audit Message for Order Record

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110109, DCM, "Order Record")

EventActionCode

M

Enumerated value:

C = create

R = read

U = update

D = delete

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

User (1..2)

UserID

M

The identity of the person or process manipulating the data. If both the person and the process are known, both shall be included.

AlternateUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

U

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Patient (1)

ParticipantObjectTypeCode

M

EV 1 (person)

ParticipantObjectTypeCodeRole

M

EV 1 (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV 2 (patient ID)

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not further specialized


A.5.3.14 Patient Record

This message describes the event of a patient record being created, modified, accessed, or deleted.

Note

There are several types of patient records managed by both DICOM and non-DICOM system. DICOM applications often manipulate patient records managed by a variety of systems, and thus may be obligated by site security policies to record such events in the audit logs. This audit event can be used to record the access or manipulation of patient records where specific DICOM SOP Instances are not involved.

Table A.5.3.14-1. Audit Message for Patient Record

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110110, DCM, "Patient Record")

EventActionCode

M

Enumerated value:

C = create

R = read

U = update

D = delete

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

User (1..2)

UserID

M

The identity of the person or process manipulating the data. If both are known, then two active participants shall be included (both the person and the process).

AlternateUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

U

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Patient (1)

ParticipantObjectTypeCode

M

EV 1 (person)

ParticipantObjectTypeCodeRole

M

EV 1 (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV 2 (patient ID)

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not further specialized


A.5.3.15 Procedure Record

This message describes the event of a procedure record being created, accessed, modified, accessed, or deleted. This message may only include information about a single patient.

Note

  1. DICOM applications often manipulate procedure records, e.g. with MPPS update. Modality Worklist query events are described by the Query event message.

  2. The same accession number may appear with several order numbers. The Study participant fields or the entire message may be repeated to capture such many to many relationships.

Table A.5.3.15-1. Audit Message for Procedure Record

Real World Entities

Field Name

Opt.

Value Constraints

Event

EventID

M

EV (110111, DCM, "Procedure Record")

EventActionCode

C

Enumerated value:

C = create

R = read

U = update

D = delete

EventDateTime

M

not specialized

EventOutcomeIndicator

M

not specialized

EventTypeCode

U

not specialized

User (1..2)

UserID

M

The identity of the person or process manipulating the data. If both are known, then two active participants shall be included (both the person and the process).

AlternateUserID

U

not specialized

UserName

U

not specialized

UserIsRequestor

U

not specialized

RoleIDCode

U

not specialized

NetworkAccessPointTypeCode

U

not specialized

NetworkAccessPointID

U

not specialized

Study (0..N)

ParticipantObjectTypeCode

M

EV 2 (system)

ParticipantObjectTypeCodeRole

M

EV 3 (report)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV (110180, DCM, "Study Instance UID")

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The Study Instance UID

ParticipantObjectName

U

not specialized

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

Not further specialized

ParticipantObjectDescription

U

Not further specialized

SOPClass

MC

not further specialized

Accession

U

not further specialized

NumberOfInstances

U

not further specialized

Instances

U

not further specialized

Encrypted

U

not further specialized

Anonymized

U

not further specialized

Patient (1)

ParticipantObjectTypeCode

M

EV 1 (person)

ParticipantObjectTypeCodeRole

M

EV 1 (patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

EV 2 (patient ID)

ParticipantObjectSensitivity

U

not specialized

ParticipantObjectID

M

The patient ID

ParticipantObjectName

U

The patient name

ParticipantObjectQuery

U

not specialized

ParticipantObjectDetail

U

not specialized

ParticipantObjectDescription

U

not further specialized


A.6 Audit Trail Message Transmission Profile - SYSLOG-TLS

This profile defines the transmission of audit trail messages. Transport Layer Security (TLS) Transport Mapping for Syslog (RFC5425) provides the mechanisms for reliable transport, buffering, acknowledgement, authentication, identification, and encryption. The RFC5424 states that the TLS used MUST be TLS version 1.2. For this DICOM profile TLS MUST be used, and version 1.2 or later is RECOMMENDED.

Note

The words MUST and RECOMMENDED are used in accordance with the IETF specification for normative requirements.

Any implementation that claims conformance to this profile shall also conform to the Audit Trail Message Format Profile. XML audit trail messages created using the format defined in Audit Trail Message Format Profile shall be transmitted to a collection point using the syslog over TLS mechanism, defined in RFC5425. Systems that comply with this profile shall support message sizes of at least 32768 octets.

Note

  1. Audit messages for other purposes may also be transferred on the same syslog connection. These messages might not conform to the Audit Trail Message Format.

  2. RFC5425 specifies mandatory support for 2KB messages, strongly recommends support for at least 8KB, and does not restrict the maximum size.

  3. When a received message is longer than the receiving application supports, the message might be discarded or truncated. The sending application will not be notified.

The XML audit trail message shall be inserted into the MSG portion of the SYSLOG-MSG element of the syslog message as defined in RFC5424 "The Syslog Protocol".The XML audit message may contain Unicode characters that are encoded using the UTF-8 encoding rules.

Note

UTF-8 avoids utilizing the control characters that are reserved by the syslog protocol, but a system that is not prepared for UTF-8 may not be able to display these messages correctly.

The PRI field shall be set using the facility value of 10 (security/authorization messages). Most messages should have the severity value of 5 (normal but significant), although applications may choose other values if that is appropriate to the more detailed information in the audit message. This means that for most audit messages the PRI field will contain the value "<85>".

The MSGID field in the HEADER of the SYSLOG-MSG shall be set. The value "DICOM+RFC3881" may be used for messages that comply with this profile.

The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure following the DICOM Audit Message Schema (see Section A.5.1).

The syslog message shall be created and transmitted as described in RFC5424.

Any implementation that claims conformance to this Security Profile shall describe in its conformance statement:

  1. any configuration parameters relevant to RFC5424 and RFC5425.

  2. Any STRUCTURED-DATA that is generated or processed.

  3. Any implementation schema or message element extensions for the audit messages.

  4. The maximum size of messages that can be sent or received.

A.7 Audit Trail Message Transmission Profile - SYSLOG-UDP

This profile defines the transmission of audit trail messages. Transmission of Syslog Messages over UDP (RFC5426) provides the mechanisms for rapid transport of audit messages. It is the standardized successor to the informative standard "The BSD syslog protocol (RFC3164) ", which is widely used in a variety of settings.

The syslog port number shall be configurable, with the port number (514) as the default.

The underlying UDP transport might not accept messages longer than the MTU size minus the UDP header length. This may result in longer syslog messages being truncated. When these messages are truncated the resulting XML may be incorrect. Because of this potential for truncated messages and other security concerns, the transmission of syslog messages over TLS may be preferred (see Section A.6).

The PRI field shall be set using the facility value of 10 (security/authorization messages). Most messages should have the severity value of 5 (normal but significant), although applications may choose values of 4 (warning condition) if that is appropriate to the more detailed information in the audit message. This means that for most audit messages the PRI field will contain the value "<85>". Audit repositories shall be prepared to deal appropriately with any incoming PRI value.

The MSGID field in the HEADER of the SYSLOG-MSG shall be set. The value "DICOM+RFC3881" may be used for messages that comply with this profile.

The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure following the DICOM Audit Message Schema (see Section A.5.1).

The syslog message shall be created and transmitted as described in RFC5424.

Any implementation that claims conformance to this Security Profile shall describe in its conformance statement:

  1. any configuration parameters relevant to RFC5424 and RFC5426.

  2. Any STRUCTURED-DATA that is generated or processed.

  3. Any implementation schema or message element extensions for the audit messages.

  4. The maximum size of messages that can be sent or received.

B Secure Transport Connection Profiles (Normative)

B.1 The Basic TLS Secure Transport Connection Profile

An implementation that supports the Basic TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security Version 1.0 protocol. Table B.1-1 specifies mechanisms that shall be supported if the corresponding features within TLS are supported by the Application Entity. The profile does not require the implementation to support all of the features (entity authentication, encryption, integrity checks) of TLS. Other mechanisms may also be used if agreed to by negotiation during establishment of the TLS channel.

Table B.1-1. Minimum Mechanisms for TLS Features

Supported TLS Feature

Minimum Mechanism

Entity Authentication

RSA based certificates

Exchange of Master Secrets

RSA

Data Integrity

SHA

Privacy

Triple DES EDE, CBC


IP ports on which an implementation accepts TLS connections, or the mechanism by which this port number is selected or configured, shall be specified in the Conformance Statement. This port shall be different from ports used for other types of transport connections (secure or unsecure).

Note

It is strongly recommended that systems supporting the Basic TLS Secure Transport Connection Profile use as their port the registered port number "2762 dicom-tls" for the DICOM Upper Layer Protocol on TLS: (decimal).

The Conformance Statement shall also indicate what mechanisms the implementation supports for Key Management.

The profile does not specify how a TLS Secure Transport Connection is established, or the significance of any certificates exchanged during peer entity authentication. These issues are left up to the Application Entity, which presumably is following some site specified security policy. The identities of the certificate owners can by used by the application entity for audit log support, or to restrict access based on some external access rights control framework. Once the Application Entity has established a Secure Transport Connection, then an Upper Layer Association can use that secure channel.

Note

There may be an interaction between PDU size and TLS Record size that impacts efficiency of transport. The maximum allowed TLS record size is smaller than the maximum allowed PDU size.

When an integrity check fails, the connection shall be dropped per the TLS protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The provider reason used shall be documented in the conformance statement.

Note

An integrity check failure indicates that the security of the channel may have been compromised.

B.2 ISCL Secure Transport Connection Profile

An implementation that supports the ISCL Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Integrated Secure Communication Layer, V1.00. An Application Entity shall use ISCL to select the mechanisms specified in Table B.2-1. An Application Entity shall as a minimum use an Entity Authentication mechanism and Data Integrity checks. An Application Entity may optionally use a privacy mechanism.

Table B.2-1. Minimum Mechanisms for ISCL Features

Supported ISCL Feature

Minimum Mechanism

Entity Authentication

Three pass (four-way) authentication(ISO/IEC 9798-2)

Data Integrity

Either MD-5 encrypted with DES,or DES-MAC (ISO 8730)

Privacy

DES (see Note)


Note

The use of DES for privacy is optional for Online Electronic Storage.

For the Data Integrity check, an implementation may either encrypt the random number before applying MD-5, or encrypt the output of MD-5. The order is specified in the protocol. A receiver shall be able to perform the integrity check on messages regardless of the order.

IP ports on which an implementation accepts ISCL connections, or the mechanism by which this port number is selected or configured, shall be specified in the Conformance Statement. This port shall be different from ports used for other types of transport connections (secure or unsecure).

Note

It is strongly recommended that systems supporting the ISCL Secure Transport Connection Profile use as their port the registered port number "2761 dicom-iscl" for the DICOM Upper Layer Protocol on ISCL.

The Conformance Statement shall also indicate what mechanisms the implementation supports for Key Management.

The profile does not specify how an ISCL Secure Transport Connection is established. This issue is left up to the Application Entity, which presumably is following some site specified security policy. Once the Application Entity has established a Secure Transport Connection, then an Upper Layer Association can use that secure channel.

Note

There may be an interaction between PDU size and ISCL record size that impacts efficiency of transport.

When an integrity check fails, the connection shall be dropped, per the ISCL protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The provider reason used shall be documented in the conformance statement.

Note

An integrity check failure indicates that the security of the channel may have been compromised.

B.3 The AES TLS Secure Transport Connection Profile

An implementation that supports the AES TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security Version 1.0 protocol. Table B.3-1 specifies mechanisms that shall be supported if the corresponding features within TLS are supported by the Application Entity. The profile does not require the implementation to support all of the features (entity authentication, encryption, integrity checks) of TLS. Other mechanisms may also be used if agreed to by negotiation during establishment of the TLS channel.

Table B.3-1. Minimum Mechanisms for TLS Features

Supported TLS Feature

Minimum Mechanism

Entity Authentication

RSA based Certificates


Two cyphersuite options shall be offered during TLS negotiation by applications that comply with this profile:

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

The application shall offer both options. The AES version shall be preferred. The fallback to 3DES is offered so that this profile can interoperate easily with applications that only support the 3DES cyphersuite.

IP ports on which an implementation accepts TLS connections, or the mechanism by which this port number is selected or configured, shall be specified in the Conformance Statement. This port shall be different from ports used for other types of transport connections (secure or unsecure).

Note

It is strongly recommended that systems supporting the AES TLS Secure Transport Connection Profile use as their port the registered port number "2762 dicom-tls" for the DICOM Upper Layer Protocol on TLS: (decimal).

The Conformance Statement shall also indicate what mechanisms the implementation supports for Key Management.

The profile does not specify how a TLS Secure Transport Connection is established, or the significance of any certificates exchanged during peer entity authentication. These issues are left up to the Application Entity, which presumably is following some site specified security policy. The identities of the certificate owners can by used by the application entity for audit log support, or to restrict access based on some external access rights control framework. Once the Application Entity has established a Secure Transport Connection, then an Upper Layer Association can use that secure channel.

Note

There may be an interaction between PDU size and TLS Record size that impacts efficiency of transport. The maximum allowed TLS record size is smaller than the maximum allowed PDU size.

When an integrity check fails, the connection shall be dropped per the TLS protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The provider reason used shall be documented in the conformance statement.

Note

An integrity check failure indicates that the security of the channel may have been compromised.

B.4 Basic User Identity Association Profile

An implementation that supports the Basic User Identity Association profile shall accept the User Identity association negotiation sub-item, for User-Identity-Type of 1 or 2. It need not verify the passcode. If a positive response is requested, the implementation shall respond with the association response sub-item.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

Table B.4-1. Minimum Mechanisms for DICOM Association Negotiation Features - Basic User Identity Association Profile

Supported Association Negotiation Feature

Minimum Mechanism

User Identity

Username


B.5 User Identity Plus Passcode Association Profile

An implementation that supports the User Identity plus Passcode Association Profile shall send/accept the User Identity association negotiation sub-item, for User-Identity-Type of 2. If a positive response is requested, the association acceptor implementation shall respond with the association response sub-item. The passcode information shall be made available to internal or external authentication systems. The user identity shall be authenticated by means of the passcode and the authentication system. If the authentication fails, the association shall be rejected.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

Table B.5-1. User Identity Plus Passcode Association Profile - Minimum Mechanisms for DICOM Association Negotiation Features

Supported Association Negotiation Feature

Minimum Mechanism

User Identity

Username and Passcode


B.6 Kerberos Identity Negotiation Association Profile

An implementation that supports the Kerberos Identity Negotiation Association Profile shall send/accept the User Identity association negotiation sub-item, for User-Identity-Type of 3. If a positive response is requested, the association acceptor implementation shall respond with the association response sub-item containing a Kerberos server ticket. The Kerberos server ticket information shall be made available to internal or external Kerberos authentication systems. The user identity shall be authenticated by means of the Kerberos authentication system. If the authentication fails, the association shall be rejected.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

Table B.6-1. Kerberos Identity Negotiation Association Profile - Minimum Mechanisms for DICOM Association Negotiation Features

Supported Association Negotiation Feature

Minimum Mechanism

User Identity

Kerberos


B.7 Generic SAML Assertion Identity Negotiation Association Profile

An implementation that supports the Generic SAML Assertion Identity Negotiation Association Profile shall send/accept the User Identity association negotiation sub-item, for User-Identity-Type of 4. If a positive response is requested, the association acceptor implementation shall respond with the association response sub-item containing a SAML response. The SAML Assertion information shall be made available to internal or external authentication systems. The user identity shall be authenticated by means of an authentication system that employs SAML Assertions. If the authentication fails, the association shall be rejected.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

Table B.7-1. Generic SAML Assertion Identity Negotiation Association Profile - Minimum Mechanisms for DICOM Association Negotiation Features

Supported Association Negotiation Feature

Minimum Mechanism

User Identity

SAML Assertion


B.8 Secure Use of Email Transport

When a DICOM File Set is sent over Email transport in compliance with this profile the following rules shall be followed:

  1. The File Set shall be an attachment to the email body.

  2. The entire email (body, File Set attachment, and any other attachments) shall be encrypted using AES, in accordance with RFC3851 and RFC3853.

  3. The email body and attachments may be compressed in accordance with RFC3851.

  4. The email shall be digitally signed by the sender. The signing may be applied before or after encryption. This digital signature shall be interpreted to mean that the sender is attesting to his authorization to disclose the information in this email to the recipient.

The email signature is present to provide minimum sender information and to confirm the integrity of the email transmission (body contents, attachment, etc.). The email signature is separate from other signatures that may be present in DICOM reports and objects contained in the File set attached to the email. Those signatures are defined in terms of clinical uses. Any clinical content attestations shall be encoded as digital signatures in the DICOM SOP instances, not as the email signature. The email may be composed by someone who cannot make clinical attestations. Through the use of the email signature, the composer attests that he or she is authorized to transmit the data to the recipient.

Note

  1. This profile is separate from the underlying use of ZIP File or other File Set packaging over email.

  2. Where private information is being conveyed, most country regulations require the use of encryption or equivalent protections. This Profile meets the most common requirements of regulations, but there may be additional local requirements. Additional requirements may include mandatory statements in the email body and prohibitions on contents of the email body to protect patient privacy.

C Digital Signature Profiles (Normative)

C.1 Base RSA Digital Signature Profile

The Base RSA Digital Signature Profile outlines the use of RSA encryption of a MAC to generate a Digital Signature. This Profile does not specify any particular set of Data Elements to sign. Other Digital Signature profiles may refer to this profile, adding specifications of which Data Elements to sign or other customizations.

The creator of a digital signature shall use one of the RIPEMD-160, MD5, SHA-1 or SHA-2 family (SHA256, SHA384, SHA512) of hashing functions to generate a MAC, which is then encrypted using a private RSA key. All validators of digital signatures shall be capable of using a MAC generated by any of the hashing functions specified (RIPEMD-160, MD5, SHA-1 or SHA256, SHA384, SHA512).

Note

The use of MD5 is not recommended by its inventors, RSA. See:ftp://ftp.rsasecurity.com/pub/pdfs/bulletn4.pdf

The MAC to be signed shall be padded to a block size matching the RSA key size, as directed in RFC2437 (PKCS #1). The Value of MAC Algorithm (0400,0015) shall be set to either "RIPEMD160", "MD5", "SHA1", "SHA256", "SHA384" or "SHA512". The public key associated with the private key as well as the identity of the Application Entity or equipment manufacturer that owns the RSA key pair shall be transmitted in an X.509 (1993) signature certificate. The Value of the Certificate Type (0400,0110) Attribute shall be set to "X509_1993_SIG". A site-specific policy determines how the X.509 certificates are generated, authenticated, and distributed. A site may issue and distribute X.509 certificates directly, may utilize the services of a Certificate Authority, or use any reasonable method for certificate generation and verification.

If an implementation utilizes timestamps, it shall use a Certified Timestamp Type (0400,0305) of "CMS_TSP". The Certified Timestamp (0400,0310) shall be generated as described in "Internet X.509 Public Key Infrastructure; Time Stamp Protocols; March 2000".

C.2 Creator RSA Digital Signature Profile

The creator of a DICOM SOP Instance may generate signatures using the Creator RSA Digital Signature Profile. The Digital Signature produced by this Profile serves as a lifetime data integrity check that can be used to verify that the pixel data in the SOP instance has not been altered since its initial creation. An implementation that supports the Creator RSA Digital Signature Profile may include a Creator RSA Digital Signature with every SOP Instance that it creates; however, the implementation is not required to do so.

As a minimum, an implementation shall include the following attributes in generating the Creator RSA Digital Signature:

  1. the SOP Class and Instance UIDs

  2. the SOP Creation Date and Time, if present

  3. the Study and Series Instance UIDs

  4. any attributes of the General Equipment Module that are present

  5. any attributes of the Overlay Plane Module, Curve Module or Graphic Annotation Module that are present

  6. any attributes of the General Image Module and Image Pixel Module that are present

  7. any attributes of the SR Document General Module and SR Document Content Module that are present

  8. any attributes of the Waveform Module and Waveform Annotation Module that are present

  9. any attributes of the Multi-frame Functional Groups Module that are present

  10. any attributes of the Enhanced MR Image Module that are present

  11. any attributes of the MR Spectroscopy Module that are present

  12. any attributes of the Raw Data Module that are present

  13. any attributes of the Enhanced CT Image Module that are present

  14. any attributes of the Enhanced XA/XRF Image Module that are present

  15. any attributes of the Segmentation Image Module that are present

  16. any attributes of the Encapsulated Document Module that are present

  17. any attributes of the X-Ray 3D Image Module that are present

  18. any attributes of the Enhanced PET Image Module that are present

  19. any attributes of the Enhanced US Image Module that are present

  20. any attributes of the Surface Segmentation Module that are present

  21. any attributes of the Surface Mesh Module that are present

  22. any attributes of the Structured Display Module, Structured Display Annotation Module, and Structured Display Image Box Module that are present

  23. any Attributes of the Implant Template Module that are present

  24. any Attributes of the Implant Assembly Template Module that are present

  25. any Attributes of the Implant Template Group Module that are present

  26. any attributes of the Point Cloud Module that are present

  27. any attributes of the Enhanced Mammography Image Module that are present

  28. any attributes of the Tractography Results Module that are present

  29. any attributes of the Volumetric Graphic Annotation Module that are present

The Digital Signature shall be created using the methodology described in the Base RSA Digital Signature Profile. Typically the certificate and associated private key used to produce Creator RSA Digital Signatures are configuration parameters of the Application Entity set by service or installation engineers.

Creator RSA Digital Signatures bear no direct relationship to other Digital Signatures. However, other Digital Signatures, such as the Authorization Digital Signature, may be used to collaborate the timestamp of a Creator RSA Digital Signature.

C.3 Authorization RSA Digital Signature Profile

The technician or physician who approves a DICOM SOP Instance for use may request the Application Entity to generate a signature using the Authorization RSA Digital Signature Profile. The Digital Signature produced serves as a lifetime data integrity check that can be used to verify that the pixel data in the SOP instance is the same that the technician or physician saw when they made the approval.

As a minimum, an implementation shall include the following attributes in generating the Authorization RSA Digital Signature:

  1. the SOP Class and Instance UIDs

  2. the Study and Series Instance UIDs

  3. any attributes whose Values are verifiable by the technician or physician (e.g., their Values are displayed to the technician or physician)

  4. any attributes of the Overlay Plane, Curve or Graphic Annotation modules that are present

  5. any attributes of the General Image and Image Pixel modules that are present

  6. any attributes of the SR Document General and SR Document Content modules that are present

  7. any attributes of the Waveform and Waveform Annotation modules that are present

  8. any attributes of the Multi-frame Functional Groups module that are present

  9. any attributes of the Enhanced MR Image module that are present

  10. any attributes of the MR Spectroscopy modules that are present

  11. any attributes of the Raw Data module that are present

  12. any attributes of the Enhanced CT Image module that are present

  13. any attributes of the Enhanced XA/XRF Image module that are present

  14. any attributes of the Segmentation Image module that are present

  15. any attributes of the Encapsulated Document module that are present

  16. any attributes of the X-Ray 3D Image module that are present

  17. any attributes of the Enhanced PET Image module that are present

  18. any attributes of the Enhanced US Image module that are present

  19. any attributes of the Surface Segmentation module that are present

  20. any attributes of the Surface Mesh Module that are present

  21. any attributes of the Structured Display, Structured Display Annotation, and Structured Display Image Box modules that are present

  22. any Attributes of the Implant Template module that are present

  23. any Attributes of the Implant Assembly Template module that are present

  24. any Attributes of the Implant Template Group module that are present

  25. any attributes of the Point Cloud Module that are present

  26. any attributes of the Enhanced Mammography Image module that are present

  27. any attributes of the Volumetric Graphic Annotation Module that are present

The Digital Signature shall be created using the methodology describe