Security and System Management Profiles

Download
ODT PS3 HTML part15 HTML part15 Doc part15 ODT part15 PDF

PS3.15

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

DICOM Standards Committee

Copyright © 2024 NEMA

A DICOM® publication

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
Glossary
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
6.9. Attribute Confidentiality 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. NetworkAccessPointTypeCode, NetworkAccessPointID
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. Basic TLS Secure Transport Connection Profile
B.2. ISCL Secure Transport Connection Profile
B.3. 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
B.9. BCP 195 TLS Secure Transport Connection Profile
B.10. Non-Downgrading BCP 195 TLS Secure Transport Connection Profile
B.11. Extended BCP 195 TLS Profile Secure Transport Connection Profile
B.12. BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile
B.13. Modified BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile
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 (Normative)
E.1. Application Level Confidentiality Profile
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
E.3.11. Retain Institution Identity 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
H.2.5. Conformance

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 Role Values
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.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-1a. De-identification Action Codes
E.1-1. Application Level Confidentiality Profile Attributes
E.3.4-1. Application Level Confidentiality Profile Clean Structured Content Option Content Item Concept Name Codes
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 [ITU-T 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 [ITU-T 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.

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.

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

[ISO 7498-1] ISO. 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.

[ISO 7498-2] ISO. 1989. Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture.

[ISO/TR 8509] ISO. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .

[ISO 8649] ISO. 1988. Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).

[ISO/IEC 10118-3] ISO. 2004. Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions (RIPEMD-160 reference). The draft RIPEMD-160 specification and sample code are also available at http://homes.esat.kuleuven.be/~bosselae/ripemd160.html .

[ECMA 235] ECMA. March 1996. The ECMA GSS-API Mechanism. http://www.ecma-international.org/publications/standards/Ecma-235.htm .

[ANSI X9.52] ANSI. 1998. Triple Data Encryption Algorithm Modes of Operation.

[DNS-SD] Cheshire S.. DNS Self-Discovery. http://www.dns-sd.org/ .

[FIPS 180-1] National Institute of Standards and Technology. 17 April 1995. SHA-1: Secure Hash Standard.

[FIPS 180-2] National Institute of Standards and Technology. 1 August 2002. SHA-2: Secure Hash Standard.

[ITU-T X.509] ITU. Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks. http://www.itu.int/rec/T-REC-X.509 . 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..

[RFC 1035] IETF. Domain Name System (DNS). http://www.rfc-editor.org/info/rfc1035 .

[RFC 2030] IETF. Simple Network Time Protocol (SNTP) Version 4. http://www.rfc-editor.org/info/rfc2030 .

[RFC 2131] IETF. Dynamic Host Configuration Protocol. http://www.rfc-editor.org/info/rfc2131 .

[RFC 2132] IETF. Dynamic Host Configuration Protocol Options. http://www.rfc-editor.org/info/rfc2132 .

[RFC 2136] IETF. Dynamic Updates in the Domain Name System (DNS UPDATE). http://www.rfc-editor.org/info/rfc2136 .

[RFC 2181] IETF. Clarifications to the DNS Specification. http://www.rfc-editor.org/info/rfc2181 .

[RFC 2219] IETF. Use of DNS Aliases for Network Services. http://www.rfc-editor.org/info/rfc2219 .

[RFC 2246] IETF. Transport Layer Security (TLS) 1.0 Internet Engineering Task Force. http://www.rfc-editor.org/info/rfc2246 .

[RFC 2251] IETF. Lightweight Directory Access Protocol (v3). http://www.rfc-editor.org/info/rfc2251 .

[RFC 2313] IETF. March 1998. PKCS #1: RSA Encryption, Version 1.5. http://www.rfc-editor.org/info/rfc2313 .

[RFC 2437] IETF. October 1998. PKCS #1: RSA Cryptography Specifications - Version 2.0. http://www.rfc-editor.org/info/rfc2437 .

[RFC 2563] IETF. DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients. http://www.rfc-editor.org/info/rfc2563 .

[RFC 2782] IETF. A DNS RR for specifying the location of services (DNS SRV). http://www.rfc-editor.org/info/rfc2782 .

[RFC 2827] IETF. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. http://www.rfc-editor.org/info/rfc2827 .

[RFC 2849] IETF. The LDAP Data Interchange Format (LDIF). http://www.rfc-editor.org/info/rfc2849 .

[RFC 2898] IETF. September 2000. PKCS #5: Password-Based Cryptography Specification Version 2.0. http://www.rfc-editor.org/info/rfc2898 .

[RFC 3161] IETF. March 2000. Internet X.509 Public Key Infrastructure - Time-Stamp Protocol (TSP). http://www.rfc-editor.org/info/rfc3161 .

[RFC 3164] IETF. August 2001. The BSD syslog Protocol. http://www.rfc-editor.org/info/rfc3164 .

[RFC 3211] IETF. December 2001. Password-based Encryption for CMS. http://www.rfc-editor.org/info/rfc3211 .

[RFC 3268] IETF. June 2002. Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS). http://www.rfc-editor.org/info/rfc3268 .

[RFC 3447] IETF. February 2003. PKCS #1 RSA Cryptography Specifications Version 2.1. http://www.rfc-editor.org/info/rfc3447 .

[RFC 3370] IETF. August 2002. Cryptographic Message Syntax (CMS) Algorithms. http://www.rfc-editor.org/info/rfc3370 .

[RFC 3565] IETF. July 2003. Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). http://www.rfc-editor.org/info/rfc3565 .

[RFC 3851] IETF. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. http://www.rfc-editor.org/info/rfc3851 .

[RFC 3853] IETF. S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP). http://www.rfc-editor.org/info/rfc3853 .

[RFC 3881] IETF. September 2004. Security Audit and Access Accountability Message - XML Data Definitions for Healthcare Applications. http://www.rfc-editor.org/info/rfc3881 .

[RFC 4033] IETF. March 2005. DNS Security Introduction and Requirements. http://www.rfc-editor.org/info/rfc4033 .

[RFC 4034] IETF. March 2005. Resource Records for the DNS Security Extensions. http://www.rfc-editor.org/info/rfc4034 .

[RFC 4035] IETF. March 2005. Protocol Modifications for the DNS Security Extensions.

[RFC 5246] IETF. August 2008. The Transport Layer Security (TLS) Protocol Version 1.2. http://www.rfc-editor.org/info/rfc5246 .

[RFC 5424] IETF. The Syslog Protocol. http://www.rfc-editor.org/info/rfc5424 .

[RFC 5425] IETF. Transport Layer Security (TLS) Transport Mapping for Syslog. http://www.rfc-editor.org/info/rfc5425 .

[RFC 5426] IETF. Transmission of Syslog Messages over UDP. http://www.rfc-editor.org/info/rfc5426 .

[RFC 5652] IETF. September 2009. Cryptographic Message Syntax. http://www.rfc-editor.org/info/rfc5652 .

[RFC 5905] IETF. Network Time Protocol Version 4: Protocol and Algorithms Specification. http://www.rfc-editor.org/info/rfc5905 .

[RFC 5906] IETF. Network Time Protocol Version 4: Autokey Specification. http://www.rfc-editor.org/info/rfc5906 .

[RFC 6762] IETF. February 2013. Multicast DNS. http://www.rfc-editor.org/info/rfc6762 .

[RFC 6763] IETF. February 2013. DNS-Based Service Discovery. http://www.rfc-editor.org/info/rfc6763 .

[RFC 8446] IETF. August 2018. The Transport Layer Security (TLS) Protocol Version 1.3. http://www.rfc-editor.org/info/rfc8446 .

[RFC 8553] IETF. DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names. http://www.rfc-editor.org/info/rfc8553 .

[RFC 8633] IETF. RFC8633 Network Time Protocol Best Current Practices. http://www.rfc-editor.org/info/rfc8633 .

[RFC 8996] Moriarty K and Farrell S. March 2021. Deprecating TLS 1.0 and TLS 1.1. BCP 195. http://www.rfc-editor.org/info/rfc8996 .

[RFC 9325] Sheffer Y, Saint-Andre P, and Fossati T. Nov 2022. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). BCP 195. RFC 9325. http://www.rfc-editor.org/info/rfc9325 .

[BCP 195] IETF. Information on BCP 195. References RFC 8996 and RFC 9325. http://www.rfc-editor.org/info/bcp195 .

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

Application Entity

See [ISO 7498-1].

Protocol Data Unit

See [ISO 7498-1].

Transport Connection

See [ISO 7498-1].

3.2 Reference Model Security Architecture Definitions

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

Data Confidentiality

See [ISO 7498-2].

Note

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

Data Origin Authentication

See [ISO 7498-2].

Note

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

Data Integrity

See [ISO 7498-2].

Note

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

Key Management

See [ISO 7498-2].

Note

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

Digital Signature

See [ISO 7498-2].

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

Association

See [ISO 8649].

3.4 Security Definitions

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

Security Context

See [ECMA 235].

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:

Attribute

See Attribute in PS3.1 .

Service Object Pair Class (SOP Class)

See Service-Object Pair Class in PS3.1 .

3.6 DICOM Conformance Definitions

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

Security Profile

See Security Profile in PS3.2 .

3.7 DICOM Information Object Definitions

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

Module

See Module in PS3.3 .

3.8 DICOM Service Class Definitions

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

Service Class

See Service Class in PS3.4 .

Service-Object Pair Instance (SOP Instance)

See Service-Object Pair Instance in PS3.4 .

3.9 DICOM Communication Support Definitions

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

DICOM Upper Layer Service

See DICOM Upper Layer Service in PS3.4 .

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.

3.11 DICOM Data Structures and Encoding

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

Data Set

See Data Set in PS3.5 .

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.

6.9 Attribute Confidentiality Profiles

An implementation may claim conformance to the Basic Application Level Confidentiality Profile and to one or more Basic Application Level Confidentiality Options. This profile and options support the de-identification of datasets to prevent leakage of individually identifiable information, for reasons of privacy.

The Basic Application Level Confidentiality Profile and its Options are specified in Annex E.

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 Storage Level 2 (Full) 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 [RFC 3881], according to W3C Recommendation "XML Schema Part 1: Structures," version 1.0, May 2001, and incorporates the DICOM extensions and restrictions outlined in Section A.5.2.

This schema is provided in Relax NG Compact format.

Note

This schema can be converted into an equivalent XML schema or other electronic format. It includes some modifications to the [RFC 3881] schema that reflect field experience with audit message requirements. It extends the [RFC 3881] schema.

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

Database 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 Role Values

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

25

Data Source

2 - System Object

26

Processing Element

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 [RFC 3881]. [RFC 3881] is not being maintained or updated by the IETF, and has gradually diverged from the DICOM schema and codes. Other documents exist that refer to [RFC 3881] as the underlying standard. [RFC 3881] does not include corrections and additions to the audit schema made in DICOM since 2004.

In subsequent tables the following notation Is used for optionality:

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

Execute 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 NetworkAccessPointTypeCode, NetworkAccessPointID

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 Section A.5.1 and Section 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 Object

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 Object

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 Number

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

AlternativeUserID

U

See Section A.5.2.2

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 Object

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 Number

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

AlternativeUserID

U

See Section A.5.2.2

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

AlternativeUserID

U

See Section A.5.2.2

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 Object

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 Number

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 Object

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 Number

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 Object

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 Number

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 Object

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 Number

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 Object

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 Object

ParticipantObjectTypeCodeRole

U

Defined Terms:

5 = Master File

13 = Security Resource

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Defined Terms:

12 = URI

DT (110182, DCM, "Node ID")

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 of node_name@domain_name or 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.

AlternativeUserID

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

Shall be: 1 = Person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = Patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = Patient Number

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

AlternativeUserID

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

Shall be: 1 = Person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = Patient)

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = Patient Number

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

AlternativeUserID

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

Shall be: 2 = System Object

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

Shall be: 1 = Person

ParticipantObjectTypeCodeRole

M

Shall be: 1 = Patient

ParticipantObjectDataLifeCycle

U

not specialized

ParticipantObjectIDTypeCode

M

Shall be: 2 = Patient Number

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. [RFC 5425] provides the mechanisms for reliable transport, buffering, acknowledgement, authentication, identification, and encryption. [RFC 5424] 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 [RFC 5425]. 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. [RFC 5425] 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 [RFC 5424]. 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 [RFC 5424].

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

  1. any configuration parameters relevant to [RFC 5424] and [RFC 5425].

  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. [RFC 5426] provides the mechanisms for rapid transport of audit messages. It is the standardized successor to the informative standard [RFC 3164], 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 [RFC 5424].

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

  1. any configuration parameters relevant to [RFC 5424] and [RFC 5426].

  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 Basic TLS Secure Transport Connection Profile

Retired. See PS3.3-2018a.

B.2 ISCL Secure Transport Connection Profile

Retired. See PS3.3-2018a.

B.3 AES TLS Secure Transport Connection Profile

Retired. See PS3.3-2018a.

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 [RFC 3851] and [RFC 3853].

  3. The email body and attachments may be compressed in accordance with [RFC 3851].

  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.

B.9 BCP 195 TLS Secure Transport Connection Profile

Retired. See PS3.3-2022d.

B.10 Non-Downgrading BCP 195 TLS Secure Transport Connection Profile

Retired. See PS3.3-2022d.

B.11 Extended BCP 195 TLS Profile Secure Transport Connection Profile

Retired. See PS3.3-2022d.

B.12 BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile

An implementation that supports the BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security protocol. It shall comply with [BCP 195] which includes [RFC 8996], and [RFC 9325]. In the context of this profile, “client” refers to the entity initiating the TLS connection and “server” refers to the entity that is responding to that TLS connection initiation request. This may differ from the role that the entity might play in any DICOM transactions over the TLS connection.

Note

  1. A device may support multiple TLS profiles. DICOM does not specify how such devices are configured in the field or how different TLS profile-related rules are specified. The site will determine what configuration is appropriate.

  2. The DICOM profiles for TLS describe the capabilities of a product. Product configuration may permit selection of a particular profile and/or additional negotiation rules. The specific cipher suite used is negotiated by the TLS implementation based on these rules.

Servers and clients shall support TLS 1.2 and may support TLS 1.3. Clients shall attempt to negotiate TLS 1.3 if it is supported. Servers shall prefer TLS 1.3 if offered by the client.

In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers shall prefer strict TLS configuration.

Application protocols typically provide a way for the server to offer TLS during an initial protocol exchange, and sometimes also provide a way for the server to advertise support for TLS (e.g., through a flag indicating that TLS is required). Unfortunately, these indications are sent before the communication channel is encrypted.

A client shall attempt to negotiate TLS even if the above indications are not communicated by the server.

All communications shall be encrypted with integrity checks enabled. Hence, implementations shall not use NULL key exchange, cipher, or signature/hash protocols.

Servers shall support bi-directional mutual authentication. Clients are not required, but are encouraged, to support and use bi-directional mutual authentication. The server may be configured to not use bi-directional mutual authentication.

The TCP ports on which an implementation accepts TLS connections for DICOMweb shall be different from those on which an implementation accepts TLS connections for DIMSE. The HTTP/HTTPS connection for DICOMweb can be shared with other HTTP/HTTPS traffic.

Note

It is recommended that systems supporting this Profile use the registered port number "2762 dicom-tls" for the DICOM Upper Layer Protocol on TLS, which is used by DIMSE.

The Conformance Statement shall indicate:

  • TCP ports on which an implementation accepts TLS connections, or the mechanism by which these port numbers are selected or configured

  • What mechanisms the implementation supports for Key Management.

  • Which key exchange algorithms, cipher suites, and signature algorithms the implementation supports.

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 Conformance Statement shall document the provider reasons issued by the implementation.

B.13 Modified BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile

An implementation that supports the Modified BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security protocol. It shall comply with [BCP 195] which includes [RFC 8996], and [RFC 9325] with the additional restrictions enumerated below. In the context of this profile, “client” refers to the entity initiating the TLS connection and “server” refers to the entity that is responding to that TLS connection initiation request. This may differ from the role that the entity might play in any DICOM transactions over the TLS connection.

Note

  1. A device may support multiple TLS profiles. DICOM does not specify how such devices are configured in the field or how different TLS profile-related rules are specified. The site will determine what configuration is appropriate.

  2. The DICOM profiles for TLS describe the capabilities of a product. Product configuration may permit selection of a particular profile and/or additional negotiation rules. The specific cipher suite used is negotiated by the TLS implementation based on these rules.

A client shall attempt to negotiate TLS even if the above indications are not communicated by the server.

The following cryptographic algorithms, grouped by function, shall not be used:

  • Key Exchange

    • DH

    • ECDH

    • RSAES PKCS#1 v1.5 (RSA)

  • Signature

    • GOST R 34.10-2012

  • Block Cipher

    • RC2

    • EXPORT-RC2

    • IDEA

    • DES

    • EXPORT-DES

    • GOST 28147-89

    • Magma

    • 3-key Triple DES

    • Kuznyechik

    • ARIA

    • SEED

  • Block Cipher Mode of Operation

    • CBC

    • CTR-OMAC

  • Stream Cipher

    • RC4

    • EXPORT-RC4

  • Hash Function

    • MD5

    • SHA-1

    • GOST R 34.11-2012

Only the following cryptographic algorithms, grouped by function, are permitted:

  • Key Exchange

    • ECDHE

    • DHE

  • Signature

    • ECDSA

    • RSASSA PKCS#1 v1.5 (RSA)

    • RSASSA-PSS

  • Block Cipher

    • AES

    • Camellia

  • Block Cipher Mode of Operation

    • GCM

    • CCM

    • CCM_8

  • Stream Cipher

    • ChaCha20-Poly 1305

  • Hash Function

    • SHA-256

    • SHA-384

When DHE is used for Key Exchange, the key length shall be 2048 bits or more. Cipher suites containing DHE shall not be selected when using implementations that do not allow explicit setting of the DHE key length.

When ECDHE is used for Key Exchange, the key length shall be 256 bits or more.

Servers shall support all of the following cipher suites for TLS 1.3. Clients that support TLS 1.3 shall support at least one of the following cipher suites.

  • TLS_AES_256_GCM_SHA384

  • TLS_CHACHA20_POLY1305_SHA256

  • TLS_AES_128_GCM_SHA256

  • TLS_AES_128_CCM_SHA256

  • TLS_AES_128_CCM_8_SHA256

Note

In TLS 1.3 Key Exchange and Signature, algorithms are not specified in the cipher suite negotiation. Implementations may choose from the list above of permitted algorithms.

Servers shall support all of the following cipher suites for TLS 1.2.

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_CCM

  • TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM

  • TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

The above cipher suites are preferred for TLS 1.2. Clients that support TLS 1.2 shall support at least one of the cipher suites listed above or below. Servers may support the following cipher suites as a fallback for TLS 1.2 but are not required to do so.

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_256_CCM

  • TLS_DHE_RSA_WITH_AES_256_GCM_CCM_8

  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_128_CCM

  • TLS_DHE_RSA_WITH_AES_128_CCM_8

When using TLS 1.2, cipher suites other than those listed in either list above are not permitted.

The following requirements apply to Certificates within TLS:

  • If the subject public key algorithm is RSA, the key length shall be 2048 bits or more.

  • If the subject public key algorithm is ECC, the key length shall be 256 bits or more.

  • If the certificate signature algorithm is RSA, the key length shall be 2048 bits or more.

  • If the certificate signature algorithm is ECDSA, the key length shall be 256 bits or more.

  • The hash function shall be SHA-256 or greater.

Servers shall support both TLS 1.2 and TLS 1.3. Clients shall support at least one of TLS 1.2 or TLS 1.3. Clients shall attempt to negotiate TLS 1.3 if it is supported. Servers shall prefer TLS 1.3 if offered by the client. Implementations may fall back to TLS 1.2 if the client does not negotiate TLS 1.3.

In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers shall prefer strict TLS configuration.

Application protocols typically provide a way for the server to offer TLS during an initial protocol exchange, and sometimes also provide a way for the server to advertise support for TLS (e.g., through a flag indicating that TLS is required); unfortunately, these indications are sent before the communication channel is encrypted.

Servers shall support bi-directional mutual authentication. Clients are not required, but are encouraged, to support and use bi-directional mutual authentication. The server may be configured to not use bi-directional mutual authentication.

The TCP ports on which an implementation accepts TLS connections for DICOMweb shall be different from those on which an implementation accepts TLS connections for DIMSE. The HTTP/HTTPS connection for DICOMweb can be shared with other HTTP/HTTPS traffic.

Note

It is recommended that systems supporting this Profile use the registered port number "2762 dicom-tls" for the DICOM Upper Layer Protocol on TLS.

The Conformance Statement shall indicate:

  • TCP ports on which an implementation accepts TLS connections, or the mechanism by which these port numbers are selected or configured

  • What mechanisms the implementation supports for Key Management.

  • Which key exchange algorithms, cipher suites, and signature algorithms the implementation supports.

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 Conformance Statement shall document the provider reasons issued by the implementation.

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 data to be signed shall be padded to a block size matching the RSA key size, as directed in [RFC 2437] (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 [ITU-T 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 [ITU-T X.509] certificates are generated, authenticated, and distributed. A site may issue and distribute [ITU-T 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 [RFC 3161].

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.

The 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

Local rules and regulations may further restrict the hashing functions that are permitted. These regulations usually restrict the hashing functions that may be used by the SCP in creating a new signature on a new SOP Instance. For example, they may prohibit use of RIPEMD-160 and MD5. The regulations usually allow an SCU to verify an old signature that uses an algorithm that is now prohibited for new signatures. Implementations that support this profile will need to accommodate these local regulations.

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 Series 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 Modules that are present

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

  30. any Attributes of the Microscopy Bulk Simple Annotations Module that are present

Note

The requirement is upon Attributes, and the use of Modules in the list above is for documentation brevity. For example, a SOP instance of an Encapsulated STL IOD will have all of the Attributes of the Encapsulated Document Series Module (used to encapsulate the STL file) signed. It will also have the Attributes used in any icon images signed, because the icon images use Attributes that are also Attributes of the General Image Module and Image Pixel Module. The General Image Module and Image Pixel Module are not incorporated the Encapsulated STL IOD and do not appear in the Encapsulated STL IOD Modules table.

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.

The SCP may include other attributes when generating the Creator RSA Digital Signature, and the SCU shall support verification of such signatures.

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.

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

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 described in the Base RSA Digital Signature Profile. The Application Entity shall determine the identity of the technician or physician and obtain their certificate through a site-specific procedure such as a login mechanism or a smart card.

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

C.4 Structured Report RSA Digital Signature Profile

This profile defines a mechanism for adding Digital Signatures to Structured Reports or Key Object Selection Documents where there is no more than one Verifying Observer. Instances that follow this Digital Signature Profile shall include at least one Digital Signature at the top level of the Data Set.

All Digital Signatures that follow this profile shall include a Digital Signature Purpose Code Sequence Attribute (0400,0401).

As a minimum, an implementation shall include the following Attributes in generating the Digital Signature required by this profile:

  1. the SOP Class UID

  2. the Study and Series Instance UIDs

  3. all Attributes of the General Equipment Module that are present

  4. the Current Requested Procedure Evidence Sequence

  5. the Pertinent Other Evidence Sequence

  6. the Predecessor Documents Sequence

  7. the Observation DateTime

  8. all Attributes of the SR Document Content Module that are present

If the Verification Flag is set to "VERIFIED" (and the SOP Instance UID can no longer change) at least one of the Digital Signatures profile shall have the purpose of (5, ASTM-sigpurpose, "Verification Signature") and shall also include the following Attributes in addition to the above Attributes:

  1. the SOP Instance UID

  2. the Verification Flag

  3. the Verifying Observer Sequence

  4. the Verification DateTime

Note

The system may also add a Creator RSA Digital Signature, which could cover other Attributes that the machine can verify.

All occurrences of Referenced SOP Instance MAC Sequence (0400,0403) shall have the Value of MAC Algorithm (0400,0015) set to either "RIPEMD160", "MD5", "SHA1", "SHA256", "SHA384" or "SHA512"..

The Digital Signature shall be created using the methodology described in the Base RSA Digital Signature Profile. The Application Entity shall determine the identity of the signatories and obtain their certificate through an application-specific procedure such as a login mechanism or a smart card. The conformance statement shall specify how the application identifies signatories and obtains certificates.

Note

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

D Media Storage Security Profiles (Normative)

D.1 Basic DICOM Media Security Profile

The Basic DICOM Media Security Profile allows encapsulation of a DICOM File into a Secure DICOM File such that the following aspects of security are addressed:

  • confidentiality,

  • integrity,

  • data origin authentication (optional).

This profile specifies the use of either AES or Triple-DES for content encryption and RSA, or password-based encryption and AES or Triple-DES, for the key transport of the content-encryption keys. The encrypted content is a DICOM File that can either

  • be signed with one or more digital signatures, using SHA-1, SHA256, SHA384, or SHA512 as the digest algorithm and RSA as the signature algorithm, or

  • be digested with SHA-1, SHA256, SHA384, or SHA512 as digest algorithm, without application of digital signatures.

Note

The digest algorithm requirements will evolve as the threats evolve. As the digest requirements have changed, this profile has changed to include additional requirements.

D.1.1 Encapsulation of A DICOM File in a Secure DICOM File

A Secure DICOM File conforming to this security profile shall contain an Enveloped-data content type of the Cryptographic Message Syntax defined in IETF STD 70 [RFC 5652], [RFC 3370] and [RFC 3565]. The enveloped data shall use RSA [RFC 3447], or password-based encryption using PBKDF2 [RFC 2898] for the key derivation algorithm and either AES or Triple-DES [RFC 3211], for the key transport of the content-encryption keys. Creators of a Secure DICOM File conforming to this security profile may use either AES or Triple-DES for content-encryption. Readers claiming conformance to this profile shall be capable of decrypting Secure DICOM Files using either AES or Triple-DES. The AES key length may be any length allowed by the RFCs. The Triple-DES key length is 168 bits as defined by [ANSI X9.52]. Encoding shall be performed according to the specifications for RSA Key Transport and Triple DES Content Encryption in [RFC 3370], and for AES Content Encryption in [RFC 3565].

The encrypted content of the Enveloped-data content type shall be of the following choices:

  • Signed-data content type;

  • Digested-data content type.

In both cases, SHA-1 [FIPS 180-1], SHA256, SHA384, or SHA512 [FIPS 180-2] shall be used as the digest algorithm. In case of the Signed-data content type, RSA [RFC 2313] shall be used as the signature algorithm.

In the case of password-based encryption using PBKDF2, the octet string that contains the password used to generate the key shall be limited to the encoding and the graphic character representation defined by the Default Character Repertoire.

Note

  1. RSA key transport of the content-encryption keys is specified as a requirement in the European Prestandard ENV 13608-2: Health Informatics - Security for healthcare communication - Part 2: Secure data objects.

  2. No requirements on the size of the asymmetric key pairs used for RSA key transport are defined in this profile.

  3. No requirements or restrictions on the use of the SignedAttributes element of the Signed-data content type's SignerInfo structure are defined in this profile. SignedAttributes might for example be used to specify the signing time or SMIME capabilities, as required by ENV 13608-2.

  4. The use of password-based encryption for key transport of content encryption keys is potentially less secure than certificate-based encryption, but may be useful when the list of recipients is not known a priori or when there is no public key infrastructure deployed. The security depends on the entropy of the password, which if user-selected can be quite low. [RFC 3211] strongly recommends the use of a pass "phrase" rather than a single word, and [RFC 2898] does not impose any practical length limit. Also, the method used to exchange the password or pass phrase also could have a significant impact on the level of security.

  5. PBKDF2 as defined in [RFC 2898] specifies the password to be "an octet string of arbitrary length whose interpretation as a text string is unspecified". For interoperability between the sender and recipient, both a character encoding scheme and a graphic character representation needs to be defined. ISO IR6 (US-ASCII), being the Default Character Repertoire for DICOM (see PS3.5), is specified in order to avoid any potential ambiguity caused by the use of other character sets (such as UTF-8) that do not necessarily result in the same binary values for particular graphic character representation.

The graphic character representation of certain symbols in ISO IR6 is explicitly defined, even though the same binary representation may have a different graphic character representation in other 7-bit schemes. For example, in the version of ISO 646 used in Japan (ISO-IR 14 Romaji), 05/12 is represented as "¥" rather than backslash "\". It is the responsibility of the application to assure that the input method and display of such symbols to the user is mapped to the correct encoding, regardless of locale. I.e., if the password is "123\$", then it should be encoded as 03/01 03/02 03/03 05/12 02/04, regardless of whether the user types the backslash "\"(U+005C) on a Japanese or US keyboard; they should not be expected to type the "¥" (U+00A5) key on a Japanese keyboard, nor should 05/12 be displayed as "¥" if the password is displayed as text.

The restriction to the ISO IR 6 encoding and graphic character representation (rather than, for example, the minimal encoding of UTF-8) also eliminates the ambiguity introduced by homographs (characters that look the same but encode differently), and alternative encodings with the same meaning, such as the single German character "ß" (U+00DF) as opposed to the two-character "ss" (U+0073 U+0073), and the use of phonetic as opposed to ideographic representation of the same meaning, such as Japanese hiragana "ぞう" (U+305E U+3046) versus kanji "像" (U+50CF).

It is the responsibility of the application to prevent the user from creating passwords using characters that cannot be represented; e.g., on a Western European keyboard, the user should not be permitted to enter an accented character such as "é" (U+00E9) or "ö" (U+00F6), since there is no defined mapping of such characters to IS IR 6 characters (such as "e" or "o").

E Attribute Confidentiality Profiles (Normative)

This Annex addresses the removal and replacement of Attributes within a DICOM Dataset that may potentially result in leakage of Individually Identifiable Information (III) about the patient or other individuals or organizations associated with the data.

Note

Use of the Attribute Confidentiality Profiles does not guarantee that all individually identifying information will be removed, i.e., de-identification of the Attributes does not imply de-identification of the Information Object. Use of these profiles does not replace a de-identification process, but should be part of it. The description of such a process is beyond the scope of DICOM, but would at least involve determining the context of the de-identification (e.g., for what purpose is the data de-identified, who are the recipients, how is the de-identified data shared), interpreting the applicable regulations, and assessing the risk of detrimental re-identification.

The Profiles are provided to address the balance between the removal of information and the need to retain information so that the Datasets remain useful for their intended purpose.

Options are used in addition to the Profiles to prevent a combinatorial expansion of different Profiles.

E.1 Application Level Confidentiality Profile

The Application Level Confidentiality Profile addresses the following aspects of security:

  • Data Confidentiality at the application layer.

Other aspects of security not addressed by this Profile, that may be addressed elsewhere in the Standard, include:

  • Confidentiality in other layers of the DICOM model;

  • Data Integrity.

This Profile is targeted toward creating a special purpose, de-identified version of an already-existing Data Set. It is not intended to replace the original SOP Instance from which the de-identified SOP Instance is created, nor is it intended to act as the primary representation of clinical Data Sets in image archives. The de-identified SOP Instances are useful, for example, in creating teaching or research files, performing clinical trials, or submission to registries where the identity of the patient and other individuals is required to be protected. In some cases, it is also necessary to provide a means of recovering identity by authorized personnel.

E.1.1 De-identifier

An Application may claim conformance to the Basic Application Level Confidentiality Profile and Options as a de-identifier if it protects and retains all Attributes as specified in the Profile and Options. Protection in this context is defined as the following process:

  1. The application may create one or more instances of the Encrypted Attributes Data Set and copy Attributes to be protected into the (single) item of the Modified Attributes Sequence (0400,0550) of one or more of the Encrypted Attributes Data Set instances.

    Note

    1. A complete reconstruction of the original Data Set may not be possible; however, Attributes (e.g., SOP Instance UID) in the Modified Attributes Sequence of an Encrypted Attributes Data Set may refer back to the original SOP Instance holding the original Data Set.

    2. It is not required that the Encrypted Attributes Data Set be created; indeed, there may be circumstances where the de-identified Dataset is expected to be archived long enough that any contemporary encryption technology may be inadequate to provide long term protection against unauthorized recovery of identification.

    3. Other mechanisms to assist in identity recovery or longitudinal consistency of replaced UIDs or dates and times are deprecated in favor of the Encrypted Attributes Data Set mechanism that is intended for this purpose. For example, if it is desired to include an encrypted hash of the Patient's Name, it should not be encoded in a separate Private Data Element implemented for that purpose, but should be included in the Encrypted Attributes Data Set and encoded using the standard mechanism. This allows for compatibility between different implementations and provides security based on the quality and control of the encryption keys. Note also, that unencrypted hashes are considerably less secure and should be avoided, since they are vulnerable to trivial dictionary based attacks.

  2. Each Attribute to be protected shall then either be removed from the dataset, or have its value replaced by a different "replacement value" that does not allow identification of the patient.

    Note

    1. It is the responsibility of the de-identifier to ensure that this process does not negatively affect the integrity of the Information Object Definition, i.e., Dummy values may be necessary for Type 1 Attributes that are protected but may not be sent with zero length, and are to be stored or exchanged in encrypted form by applications that may not be aware of the security mechanism.

    2. The Standard does not mandate the use of any particular dummy value, and indeed it may have some meaning, for example in data that may be used for teaching purposes, where the real patient identifying information is encrypted for later retrieval, but a meaningful alternative form of identification is provided. For example, a dummy Patient's Name (0010,0010) may convey the type of pathology in a teaching case. It is the responsibility of the de-identifier software or human operator to ensure that the dummy values cannot be used to identify the patient.

    3. It is the responsibility of the de-identifier to ensure the consistency of dummy values for Attributes such as Study Instance UID (0020,000D) or Frame of Reference UID (0020,0052) if multiple related SOP Instances are protected. Indeed, all Attributes of every entity about the Instance level should remain consistent for all Instances protected, e.g., Patient ID for the Patient entity, Study ID for the Study entity, Series Number for the Series entity.

    4. If an Attribute to be protected is contained in a Sequence of Items, the complete Sequence of Items may need to be protected.

    5. The de-identifier should ensure that no identifying information that is burned in to the image pixel data either because the modality does not generate such burned in identification in the first place, or by removing it through the use of the Clean Pixel Data Option; see Section E.3. If non-pixel data graphics or overlays contain identification, the de-identifier is required to remove them, or clean them if the Clean Graphics Option is supported. See Section E.3.3 The means by which burned in or graphic identifying information is located and removed is outside the scope of this Standard.

  3. Each Attribute specified to be retained shall be retained. At the discretion of the de-identifier, Attributes may be added to the dataset to be protected.

    Note

    As an example, the Attribute Patient's Age (0010,1010) might be introduced as a replacement for Patient's Birth Date (0010,0030) if the patient's age is of importance, and the selected Options permit it.

  4. If used, all instances of the Encrypted Attributes Data Set shall be encoded with a DICOM Transfer Syntax, encrypted, and stored in the dataset to be protected as an Item of the Encrypted Attributes Sequence (0400,0500). The encryption shall be done using RSA [RFC 2313] for the key transport of the content-encryption keys. A de-identifier conforming to this security Profile may use either AES or Triple-DES for content-encryption. The AES key length may be any length allowed by the RFCs. The Triple-DES key length is 168 bits as defined by [ANSI X9.52]. Encoding shall be performed according to the specifications for RSA Key Transport and Triple DES Content Encryption in [RFC 3370] and for AES Content Encryption in [RFC 3565].

    Note

    1. Each item of the Encrypted Attributes Sequence (0400,0500) consists of two Attributes, Encrypted Content Transfer Syntax UID (0400,0510) containing the UID of the Transfer Syntax that was used to encode the instance of the Encrypted Attributes Data Set, and Encrypted Content (0400,0520) containing the block of data resulting from the encryption of the Encrypted Attributes Data Set instance.

    2. RSA key transport of the content-encryption keys is specified as a requirement in the European Prestandard ENV 13608-2: Health Informatics - Security for healthcare communication - Part 2: Secure data objects.

  5. No requirements on the size of the asymmetric key pairs used for RSA key transport are defined in this confidentiality scheme. Implementations claiming conformance to the Basic Application Level Confidentiality Profile as a de-identifier shall always protect (e.g., encrypt and replace) the SOP Instance UID (0008,0018) Attribute as well as all references to other SOP Instances, whether contained in the main dataset or embedded in an Item of a Sequence of Items, that could potentially be used by unauthorized entities to identify the patient.

    Note

    In the case of a SOP Instance UID embedded in an Item of a Sequence, this means that the enclosing Attribute in the top-level Data Set must be encrypted in its entirety.

  6. The Attribute Patient Identity Removed (0012,0062) shall be replaced or added to the dataset with a value of YES. Additionally, one or more codes from CID 7050 “De-identification Method” corresponding to the Profile and Options used shall be added to De-identification Method Code Sequence (0012,0064), and/or a text string describing the method used shall be inserted in or added to De-identification Method (0012,0063).

  7. If the Dataset being de-identified is being stored within a DICOM File, then the File Meta Information including the 128 byte preamble, if present, shall be replaced with a description of the de-identifying application. Otherwise, there is a risk that identity information may leak through unmodified File Meta Information or preamble. See PS3.10. This includes information regarding Application Entity Titles, Presentation Addresses, implementation information, and private information.

  8. If the Dataset being de-identified is being communicated by DICOM Real-Time Video, then the File Meta Information including the 128 byte preamble, if present, shall be replaced with a description of the de-identifying application. Otherwise, there is a risk that identity information may leak through unmodified File Meta Information or preamble. See PS3.22. This includes information regarding Application Entity Titles, Presentation Addresses, implementation information, and private information.

The Attributes listed in Table E.1-1 for each Profile or Option are contained in Standard IODs, or may be contained in Standard Extended IODs. An implementation claiming conformance to the Basic Application Level Confidentiality Profile as a de-identifier shall protect or retain all instances of the Attributes listed in Table E.1-1, whether contained in the main dataset or embedded in an Item of a Sequence of Items. The action codes in Table E.1-1a are used in Table E.1-1.

Table E.1-1a. De-identification Action Codes

D

replace with a non-zero length value that may be a dummy value and consistent with the VR

Z

replace with a zero length value, or a non-zero length value that may be a dummy value and consistent with the VR

X

remove

K

keep (unchanged for non-Sequence Attributes, cleaned for Sequences)

C

clean, that is replace with values of similar meaning known not to contain identifying information and consistent with the VR

U

replace with a non-zero length UID that is internally consistent within a set of Instances

Z/D

Z unless D is required to maintain IOD conformance (Type 2 versus Type 1)

X/Z

X unless Z is required to maintain IOD conformance (Type 3 versus Type 2)

X/D

X unless D is required to maintain IOD conformance (Type 3 versus Type 1)

X/Z/D

X unless Z or D is required to maintain IOD conformance (Type 3 versus Type 2 versus Type 1)

X/Z/U*

X unless Z or replacement of contained instance UIDs (U) is required to maintain IOD conformance (Type 3 versus Type 2 versus Type 1 sequences containing UID references)

These action codes are applicable to both Sequence and non-Sequence Attributes; in the case of Sequences, the action is applicable to the Sequence and all of its contents. Cleaning a sequence ("C" action) entails changing values of Attributes within that Sequence when the meaning of the Sequence within the context of its use in the IOD is specified, or recursively applying the Profile rules to each Dataset in each Item of the Sequence otherwise. Keeping a Sequence ("K" action) requires recursively applying the Profile rules to each Dataset in each Item of the Sequence (for example, in order to remap any UIDs contained within that sequence).

A requirement for an Option, when implemented, overrides any requirement for the underlying Profile. This will make de-identification retain or remove more information.

Note

  1. The Attributes listed in Table E.1-1 may not be sufficient to guarantee confidentiality of patient identity. In particular, identifying information may be contained in Private Attributes, new Standard Attributes, Retired Standard Attributes and additional Standard Attributes not present in Standard Composite IODs (as defined in PS3.3) but used in Standard Extended SOP Classes. Table E.1-1 indicates those Attributes that are used in Standard Composite IODs as well as those Attributes that are Retired. Also included in Table E.1-1 are some Elements that are not normally found in a Dataset, but are used in Commands, Directories and Meta Information Headers, but that could be misused within Private Sequences. Textual Content Items of Structured Reports, textual annotations of Presentation States, Curves and Overlays are specifically addressed. It is the responsibility of the de-identifier to ensure that all identifying information is removed.

  2. It should be noted that conformance to the Basic Application Level Confidentiality Profile does not necessarily guarantee confidentiality. For example, if an attacker already has access to the original images, the Pixel Data could be matched, though the probability and impact of such a threat may be deemed to be negligible. If the Encrypted Attributes Sequence is used, it should be understood that any encryption scheme may be vulnerable to attack. Also, an organization's Security Policy and Key Management policy are recognized to have a much greater impact on the effectiveness of protection.

  3. National and local regulations, which may vary, might require that additional Attributes be de-identified, though the Profile and Options have been designed to be sufficient to satisfy known regulations without compromising the usefulness of the de-identified instances for their intended purpose.

  4. Table E.1-1 is normative, but it is subject to extension as the DICOM Standard evolves and other similar Attributes are added to IODs. De-identifiers may take this extensibility into account, for example, by considering handling all dates and times on the basis of their Value Representation of DT, DA or TM, rather than just those date and time Attributes lists.

  5. The Profile and Options do not specify whether the design of a de-identifier should be to remove what is known to be a risk of identity leakage, or to retain only what is known to be safe. The former approach may fail when the Standard is extended, or when a vendor adds unanticipated Standard Attributes or Private Attributes, whilst the latter requires an extensive, if not complete, comparison of each instance with the Information Object Definitions in PS3.3 to avoid discarding required or useful information. Table E.1-1 defines the minimum actions required for conformance.

  6. De-identification of Private SOP Classes is not defined.

  7. The "C" (clean) action is specified not only for string VRs, but also for Code Sequences, since the use of private or local codes and non-standard code meanings may potentially cause identity leakage.

  8. The Digital Signatures Sequence (FFFA,FFFA) needs to be removed because it contains the Certificate of Signer (0400,0115); theoretically the signature could be verified and the object re-signed by the de-identifier itself with its own certificate, but this is not required by the Standard.

  9. In general, there are no CS VR Attributes in this table, since it is usually safe to assume that code strings do not contain identifying information.

  10. In general, there are no Code Sequence Attributes in this table, since it is usually safe to assume that coded sequence entries, including private codes, do not contain identifying information. Exceptions are codes for providers and staff.

  11. The Clean Pixel Data and Clean Recognizable Visual Features Options are not listed in this table, since they are defined by descriptions of operations on the Pixel Data itself. The Clean Pixel Data Option may be applied to the Pixel Data within the Icon Image Sequence, or more likely the Icon Image Sequence may be recreated entirely once the Pixel Data of the main Dataset has been cleaned. The Icon Image Sequence is to be removed when its Pixel Data cannot be cleaned.

  12. The Original Attributes Sequence (0400,0561) (which in turn contains the Modified Attributes Sequence (0400,0550) ) generally needs to be removed, because it may contain unencrypted copies of other Attributes that may have been modified (e.g., coerced to use local identifiers and names during import of foreign images); an alternative approach would be to selectively modify its contents. This is distinct from the use of the Modified Attributes Sequence (0400,0550) within the Encrypted Attributes Sequence (0400,0500).

  13. Table E.1-1 distinguishes Attributes that are in standard Composite IODs defined in PS3.3 from those that are not; some Attributes are defined in PS3.3 for other IODs, or have a specific usage other than in the top level Dataset of a Composite IOD, but are (mis-) used by implementers in instances as a Standard Extended SOP Class at other levels than as defined by the Standard. Any such Attributes encountered may be removed without compromising the conformance of the instance with the standard IOD. For example, Verifying Observer Sequence (0040,A073) is only defined in structured report IODs and hence is described in Table E.1-1 as D since it is Type 1C; if encountered in an image instance, it should simply be removed (treated as X).

  14. Using an Attribute Confidentiality Profile Option that requires the retention of information that normally would be removed, potentially increases the risk of detrimental re-identification. Following de-identification rules as outlined here implies retention or non-retention of information only and does not deal with any related regulatory aspect.

  15. Because of the varied nature of encapsulated documents (CDA, PDF, STL/OBJ, etc.), options for cleaning the content of the Encapsulated Document (0042,0011) Attribute are not specified by the Standard, and it is required to be replaced. If a De-identifier has additional knowledge of the content it may attempt to clean the Attribute, and document in its Conformance Statement how this is performed.

Table E.1-1. Application Level Confidentiality Profile Attributes

Attribute Name

Tag

Retd. (from PS3.6)

In Std. Comp. IOD (from PS3.3)

Basic Prof.

Rtn. Safe Priv. Opt.

Rtn. UIDs Opt.

Rtn. Dev. Id. Opt.

Rtn. Inst. Id. Opt.

Rtn. Pat. Chars. Opt.

Rtn. Long. Full Dates Opt.

Rtn. Long. Modif. Dates Opt.

Clean Desc. Opt.

Clean Struct. Cont. Opt.

Clean Graph. Opt.

Accession Number

(0008,0050)

N

Y

Z

Acquisition Comments

(0018,4000)

Y

N

X

C

Acquisition Context Sequence

(0040,0555)

N

Y

X/Z

C

Acquisition Date

(0008,0022)

N

Y

X/Z

K

C

Acquisition DateTime

(0008,002A)

N

Y

X/Z/D

K

C

Acquisition Device Processing Description

(0018,1400)

N

Y

X/D

C

Acquisition Field Of View Label

(0018,11BB)

N

Y

D

C

Acquisition Protocol Description

(0018,9424)

N

Y

X

C

Acquisition Time

(0008,0032)

N

Y

X/Z

K

C

Acquisition UID

(0008,0017)

N

Y

U

K

Actual Human Performers Sequence

(0040,4035)

N

N

X

Additional Patient History

(0010,21B0)

N

Y

X

C

Address (Trial)

(0040,A353)

Y

N

X

Admission ID

(0038,0010)

N

Y

X

Admitting Date

(0038,0020)

N

N

X

K

C

Admitting Diagnoses Code Sequence

(0008,1084)

N

Y

X

C

Admitting Diagnoses Description

(0008,1080)

N

Y

X

C

Admitting Time

(0038,0021)

N

N

X

K

C

Affected SOP Instance UID

(0000,1000)

N

N

X

K

Allergies

(0010,2110)

N

N

X

C

C

Annotation Group Description

(006A,0006)

N

Y

X

C

Annotation Group Label

(006A,0005)

N

Y

D

C

Annotation Group UID

(006A,0003)

N

Y

D

K

Approval Status DateTime

(0044,0004)

N

N

X

K

C

Arbitrary

(4000,0010)

Y

N

X

Assertion DateTime

(0044,0104)

N

Y

D

K

C

Assertion Expiration DateTime

(0044,0105)

N

Y

X

K

C

Attribute Modification DateTime

(0400,0562)

N

Y

D

K

C

Author Observer Sequence

(0040,A078)

N

Y

X

Barcode Value

(2200,0005)

N

Y

X/Z

Beam Description

(300A,00C3)

N

Y

X

C

Beam Hold Transition DateTime

(300C,0127)

N

Y

D

K

K

C

Bolus Description

(300A,00DD)

N

Y

X

C

Branch of Service

(0010,1081)

N

N

X

Calibration Date

(0014,407E)

N

N

X

K

K

C

Calibration DateTime

(0018,1203)

N

Y

Z

K

K

C

Calibration Time

(0014,407C)

N

N

X

K

K

C

Camera Owner Name

(0016,004D)

N

Y

X

Cassette ID

(0018,1007)

N

Y

X

K

Certificate of Signer

(0400,0115)

N

Y

D

Certified Timestamp

(0400,0310)

N

Y

X

K

C

Clinical Trial Coordinating Center Name

(0012,0060)

N

Y

Z

K

Clinical Trial Protocol Ethics Committee Approval Number

(0012,0082)

N

Y

X

Clinical Trial Protocol Ethics Committee Name

(0012,0081)

N

Y

D

K

Clinical Trial Protocol ID

(0012,0020)

N

Y

D

Clinical Trial Protocol Name

(0012,0021)

N

Y

Z

Clinical Trial Series Description

(0012,0072)

N

Y

X

C

Clinical Trial Series ID

(0012,0071)

N

Y

X

Clinical Trial Site ID

(0012,0030)

N

Y

Z

K

Clinical Trial Site Name

(0012,0031)

N

Y

Z

K

Clinical Trial Sponsor Name

(0012,0010)

N

Y

D

Clinical Trial Subject ID

(0012,0040)

N

Y

D

Clinical Trial Subject Reading ID

(0012,0042)

N

Y

D

Clinical Trial Time Point Description

(0012,0051)

N

Y

X

C

Clinical Trial Time Point ID

(0012,0050)

N

Y

Z

Comments on Radiation Dose

(0040,0310)

N

Y

X

C

Comments on the Performed Procedure Step

(0040,0280)

N

Y

X

C

Compensator Description

(300A,02EB)

N

Y

X

C

Concatenation UID

(0020,9161)

N

Y

U

K

Conceptual Volume Combination Description

(3010,000F)

N

Y

Z

C

Conceptual Volume Description

(3010,0017)

N

Y

Z

C

Conceptual Volume UID

(3010,0006)

N

Y

U

K

Confidentiality Constraint on Patient Data Description

(0040,3001)

N

N

X

Constituent Conceptual Volume UID

(3010,0013)

N

Y

U

K

Consulting Physician's Name

(0008,009C)

N

Y

Z

Consulting Physician Identification Sequence

(0008,009D)

N

Y

X

Container Component ID

(0050,001B)

N

Y

X

Container Description

(0040,051A)

N

Y

X

C

Container Identifier

(0040,0512)

N

Y

D

Content Creator's Identification Code Sequence

(0070,0086)

N

Y

X

Content Creator's Name

(0070,0084)

N

Y

Z/D

Content Date

(0008,0023)

N

Y

Z/D

K

C

Content Sequence

(0040,A730)

N

Y

D

C

Content Time

(0008,0033)

N

Y

Z/D

K

C

Context Group Local Version

(0008,0107)

N

Y

D

K

C

Context Group Version

(0008,0106)

N

Y

D

K

C

Contrast/Bolus Agent

(0018,0010)

N

Y

Z/D

C

Contrast/Bolus Start Time

(0018,1042)

N

Y

X

K

C

Contrast/Bolus Stop Time

(0018,1043)

N

Y

X

K

C

Contribution DateTime

(0018,A002)

N

Y

X

K

C

Contribution Description

(0018,A003)

N

Y

X

C

Country of Residence

(0010,2150)

N

N

X

Creation Date

(2100,0040)

N

N

X

K

C

Creation Time

(2100,0050)

N

N

X

K

C

Current Observer (Trial)

(0040,A307)

Y

N

X

Current Patient Location

(0038,0300)

N

N

X

Curve Data

(50xx,xxxx)

Y

N

X

C

Curve Date

(0008,0025)

Y

Y

X

K

C

Curve Time

(0008,0035)

Y

Y

X

K

C

Custodial Organization Sequence

(0040,A07C)

N

Y

X

Data Set Trailing Padding

(FFFC,FFFC)

N

Y

X

Date

(0040,A121)

N

Y

D

K

C

Date of Document or Verbal Transaction (Trial)

(0040,A110)

Y

N

X

K

C

Date of Installation

(0018,1205)

N

Y

X

K

K

C

Date of Last Calibration

(0018,1200)

N

Y

X

K

K

C

Date of Last Detector Calibration

(0018,700C)

N

Y

X/D

K

K

C

Date of Manufacture

(0018,1204)

N

Y

X

K

K

C

Date of Secondary Capture

(0018,1012)

N

Y

X

K

C

DateTime

(0040,A120)

N

Y

D

K

C

DateTime of Last Calibration

(0018,1202)

N

N

X

K

K

C

Decay Correction DateTime

(0018,9701)

N

Y

D

K

C

Decomposition Description

(0018,937F)

N

Y

X

C

Derivation Description

(0008,2111)

N

Y

X

C

Destination AE

(2100,0140)

N

Y

D

C

Detector ID

(0018,700A)

N

Y

X/D

K

Device Alternate Identifier

(3010,001B)

N

Y

Z

Device Description

(0050,0020)

N

Y

X

K

Device Label

(3010,002D)

N

Y

D

K

Device Serial Number

(0018,1000)

N

Y

X/Z/D

K

Device Setting Description

(0016,004B)

N

Y

X

C

Device UID

(0018,1002)

N

Y

U

K

K

Digital Signature DateTime

(0400,0105)

N

Y

D

K

C

Digital Signatures Sequence

(FFFA,FFFA)

N

Y

X

Digital Signature UID

(0400,0100)

N

Y

U

Dimension Organization UID

(0020,9164)

N

Y

U

K

Discharge Date

(0038,0030)

Y

N

X

K

C

Discharge Diagnosis Description

(0038,0040)

Y

N

X

C

Discharge Time

(0038,0032)

Y

N

X

K

C

Displacement Reference Label

(300A,079A)

N

Y

X

C

Distribution Address

(4008,011A)

Y

N

X

Distribution Name

(4008,0119)

Y

N

X

Dose Reference Description

(300A,0016)

N

Y

X

C

Dose Reference UID

(300A,0013)

N

Y

U

K

Dosimetric Objective UID

(3010,006E)

N

Y

U

K

Effective DateTime

(0068,6226)

N

Y

D

K

C

Encapsulated Document

(0042,0011)

N

Y

D

End Acquisition DateTime

(0018,9517)

N

Y

X/D

K

C

Entity Description

(3010,0037)

N

Y

X

C

Entity Label

(3010,0035)

N

Y

D

C

Entity Long Label

(3010,0038)

N

Y

D

C

Entity Name

(3010,0036)

N

Y

X

C

Equipment Frame of Reference Description

(300A,0676)

N

Y

X

C

Ethics Committee Approval Effectiveness End Date

(0012,0087)

N

Y

X

K

C

Ethics Committee Approval Effectiveness Start Date

(0012,0086)

N

Y

X

K

C

Ethnic Group

(0010,2160)

N

Y

X

K

Exclusion Start DateTime

(0018,9804)

N

Y

D

K

C

Expected Completion DateTime

(0040,4011)

N

N

X

K

C

Failed SOP Instance UID List

(0008,0058)

N

N

U

K

Fiducial UID

(0070,031A)

N

Y

U

K

Filler Order Number / Imaging Service Request

(0040,2017)

N

Y

Z

Filter Lookup Table Description

(003A,032B)

N

Y

X

C

Findings Group Recording Date (Trial)

(0040,A023)

Y

N

X

K

C

Findings Group Recording Time (Trial)

(0040,A024)

Y

N

X

K

C

First Treatment Date

(3008,0054)

N

Y

X/D

K

C

Fixation Device Description

(300A,0196)

N

Y

X

C

Flow Identifier

(0034,0002)

N

Y

D

Flow Identifier Sequence

(0034,0001)

N

Y

D

Fractionation Notes

(3010,007F)

N

Y

Z

C

Fraction Group Description

(300A,0072)

N

Y

X

C

Frame Acquisition DateTime

(0018,9074)

N

Y

D

K

C

Frame Comments

(0020,9158)

N

Y

X

C

Frame of Reference UID

(0020,0052)

N

Y

U

K

Frame Origin Timestamp

(0034,0007)

N

Y

D

K

C

Frame Reference DateTime

(0018,9151)

N

Y

D

K

C

Functional Sync Pulse

(0018,9623)

N

Y

D

K

C

Gantry ID

(0018,1008)

N

Y

X

K

Generator ID

(0018,1005)

N

Y

X

K

GPS Altitude​

(0016,0076)

N

Y

X

GPS Altitude​ Ref

(0016,0075)

N

Y

X

GPS Area ​Information

(0016,008C)

N

Y

X

GPS Date​ Stamp

(0016,008D)

N

Y

X

K

C

GPS Dest ​Bearing

(0016,0088)

N

Y

X

GPS Dest​ Bearing Ref

(0016,0087)

N

Y

X

GPS Dest ​Distance

(0016,008A)

N

Y

X

GPS Dest ​Distance Ref

(0016,0089)

N

Y

X

GPS Dest​ Latitude

(0016,0084)

N

Y

X

GPS Dest​ Latitude Ref

(0016,0083)

N

Y

X

GPS Dest ​Longitude

(0016,0086)

N

Y

X

GPS Dest ​Longitude Ref

(0016,0085)

N

Y

X

GPS Differential

(0016,008E)

N

Y

X

GPS DOP

(0016,007B)

N

Y

X

GPS Img ​Direction

(0016,0081)

N

Y

X

GPS Img​ Direction Ref

(0016,0080)

N

Y

X

GPS Latitude​

(0016,0072)

N

Y

X

GPS Latitude​ Ref

(0016,0071)

N

Y

X

GPS Longitude

(0016,0074)

N

Y

X

GPS Longitude Ref

(0016,0073)

N

Y

X

GPS Map​ Datum

(0016,0082)

N

Y

X

GPS Measure ​Mode

(0016,007A)

N

Y

X

GPS Processing​ Method

(0016,008B)

N

Y

X

GPS Satellites

(0016,0078)

N

Y

X

GPS Speed​

(0016,007D)

N

Y

X

GPS Speed​ Ref

(0016,007C)

N

Y

X

GPS Status

(0016,0079)

N

Y

X

GPS Time​ Stamp

(0016,0077)

N

Y

X

GPS Track

(0016,007F)

N

Y

X

GPS Track ​Ref

(0016,007E)

N

Y

X

GPS Version ID

(0016,0070)

N

Y

X

Graphic Annotation Sequence

(0070,0001)

N

Y

D

C

Hanging Protocol Creation DateTime

(0072,000A)

N

Y

D

K

C

HL7 Document Effective Time

(0040,E004)

N

N

X

K

C

Human Performer's Name

(0040,4037)

N

N

X

Human Performer's Organization

(0040,4036)

N

N

X

Icon Image Sequence

(see Note 11)

(0088,0200)

N

Y

X

Identifying Comments

(0008,4000)

Y

N

X

C

Image Comments

(0020,4000)

N

Y

X

C

Image Presentation Comments

(0028,4000)

Y

N

X

Imaging Service Request Comments

(0040,2400)

N

N

X

C

Impedance Measurement DateTime

(003A,0314)

N

Y

D

K

C

Impressions

(4008,0300)

Y

N

X

C

Information Issue DateTime

(0068,6270)

N

Y

D

K

C

Instance Coercion DateTime

(0008,0015)

N

Y

X

K

C

Instance Creation Date

(0008,0012)

N

Y

X/D

K

C

Instance Creation Time

(0008,0013)

N

Y

X/Z/D

K

C

Instance Creator UID

(0008,0014)

N

Y

U

K

Instance Origin Status

(0400,0600)

N

Y

X

Institution Address

(0008,0081)

N

Y

X

K

Institutional Department Name

(0008,1040)

N

Y

X

K

Institutional Department Type Code Sequence

(0008,1041)

N

Y

X

K

Institution Code Sequence

(0008,0082)

N

Y

X/Z/D

K

Institution Name

(0008,0080)

N

Y

X/Z/D

K

Instruction Performed DateTime

(0018,9919)

N

Y

Z/D

K

C

Insurance Plan Identification

(0010,1050)

Y

N

X

Intended Fraction Start Time

(3010,0085)

N

Y

X

K

C

Intended Phase End Date

(3010,004D)

N

Y

X/D

K

C

Intended Phase Start Date

(3010,004C)

N

Y

X/D

K

C

Intended Recipients of Results Identification Sequence

(0040,1011)

N

N

X

Interlock DateTime

(300A,0741)

N

Y

D

K

C

Interlock Description

(300A,0742)

N

Y

D

C

Interlock Origin Description

(300A,0783)

N

Y

D

C

Interpretation Approval Date

(4008,0112)

Y

N

X

K

C

Interpretation Approval Time

(4008,0113)

Y

N

X

K

C

Interpretation Approver Sequence

(4008,0111)

Y

N

X

Interpretation Author

(4008,010C)

Y

N

X

Interpretation Diagnosis Description

(4008,0115)

Y

N

X

C

Interpretation ID

(4008,0200)

Y

N

X

Interpretation ID Issuer

(4008,0202)

Y

N

X

Interpretation Recorded Date

(4008,0100)

Y

N

X

K

C

Interpretation Recorded Time

(4008,0101)

Y

N

X

K

C

Interpretation Recorder

(4008,0102)

Y

N

X

Interpretation Text

(4008,010B)

Y

N

X

C

Interpretation Transcriber

(4008,010A)

Y

N

X

Interpretation Transcription Date

(4008,0108)

Y

N

X

K

C

Interpretation Transcription Time

(4008,0109)

Y

N

X

K

C

Intervention Drug Start Time

(0018,0035)

N

Y

X

K

C

Intervention Drug Stop Time

(0018,0027)

N

Y

X

K

C

Irradiation Event UID

(0008,3010)

N

Y

U

K

Issue Date of Imaging Service Request

(0040,2004)

N

N

X

K

C

Issuer of Admission ID

(0038,0011)

Y

Y

X

Issuer of Admission ID Sequence

(0038,0014)

N

Y

X

Issuer of Clinical Trial Protocol ID

(0012,0022)

N

Y

X

Issuer of Clinical Trial Series ID

(0012,0073)

N

Y

X

Issuer of Clinical Trial Site ID

(0012,0032)

N

Y

X

Issuer of Clinical Trial Subject ID

(0012,0041)

N

Y

X

Issuer of Clinical Trial Subject Reading ID

(0012,0043)

N

Y

X

Issuer of Clinical Trial Time Point ID

(0012,0055)

N

Y

X

Issuer of Patient ID

(0010,0021)

N

Y

X

Issuer of Service Episode ID

(0038,0061)

Y

Y

X

Issuer of Service Episode ID Sequence

(0038,0064)

N

Y

X

Issuer of the Container Identifier Sequence

(0040,0513)

N

Y

Z

Issuer of the Specimen Identifier Sequence

(0040,0562)

N

Y

Z

Issue Time of Imaging Service Request

(0040,2005)

N

N

X

K

C

Label Text

(2200,0002)

N

Y

X/Z

C

Large Palette Color Lookup Table UID

(0028,1214)

Y

N

U

K

Last Menstrual Date

(0010,21D0)

N

N

X

K

C

Lens Make

(0016,004F)

N

Y

X

K

Lens Model

(0016,0050)

N

Y

X

K

Lens Serial Number

(0016,0051)

N

Y

X

K

Lens Specification

(0016,004E)

N

Y

X

K

Long Device Description

(0050,0021)

N

Y

X

C

MAC

(0400,0404)

N

Y

X

Maker Note

(0016,002B)

N

Y

X

C

Manufacturer's Device Class UID

(0018,100B)

N

Y

U

K

K

Manufacturer's Device Identifier

(3010,0043)

N

Y

Z

K

Media Storage SOP Instance UID

(0002,0003)

N

N

U

K

Medical Alerts

(0010,2000)

N

N

X

C

Medical Record Locator

(0010,1090)

Y

N

X

Military Rank

(0010,1080)

N

N

X

Modified Attributes Sequence

(0400,0550)

N

N

X

Modified Image Date

(0020,3403)

Y

N

X

K

C

Modified Image Description

(0020,3406)

Y

N

X

Modified Image Time

(0020,3405)

Y

N

X

K

C

Modifying Device ID

(0020,3401)

Y

N

X

K

Modifying System

(0400,0563)

N

Y

D

K

Most Recent Treatment Date

(3008,0056)

N

Y

X/D

K

C

Multi-energy Acquisition Description

(0018,937B)

N

Y

X

C

Multiplex Group UID

(003A,0310)

N

Y

U

K

Name of Physician(s) Reading Study

(0008,1060)

N

Y

X

Names of Intended Recipients of Results

(0040,1010)

N

N

X

Network ID

(0008,1000)

Y

N

X

C

Nonconforming Data Element Value

(0400,0552)

N

N

X

Nonconforming Modified Attributes Sequence

(0400,0551)

N

N

X

Observation Date (Trial)

(0040,A192)

Y

N

X

K

C

Observation DateTime

(0040,A032)

N

Y

X/D

K

C

Observation Start DateTime

(0040,A033)

N

Y

X

K

C

Observation Subject UID (Trial)

(0040,A402)

Y

N

U

K

Observation Time (Trial)

(0040,A193)

Y

N

X

K

C

Observation UID

(0040,A171)

N

Y

U

K

Occupation

(0010,2180)

N

Y

X

C

Operator Identification Sequence

(0008,1072)

N

Y

X/D

Operators' Name

(0008,1070)

N

Y

X/Z/D

Order Callback Phone Number

(0040,2010)

N

N

X

Order Callback Telecom Information

(0040,2011)

N

N

X

Order Entered By

(0040,2008)

N

N

X

Order Enterer's Location

(0040,2009)

N

N

X

Original Attributes Sequence

(0400,0561)

N

Y

X

Originator

(2100,0070)

N

N

X

C

Other Clinical Trial Protocol IDs Sequence

(0012,0023)

N

Y

X

Other Patient IDs

(0010,1000)

Y

Y

X

Other Patient IDs Sequence

(0010,1002)

N

Y

X

Other Patient Names

(0010,1001)

N

Y

X

Overlay Comments

(60xx,4000)

Y

N

X

C

Overlay Data

(60xx,3000)

N

Y

X

C

Overlay Date

(0008,0024)

Y

Y

X

K

C

Overlay Time

(0008,0034)

Y

Y

X

K

C

Override DateTime

(300A,0760)

N

Y

D

K

C

Palette Color Lookup Table UID

(0028,1199)

N

Y

U

K

Participant Sequence

(0040,A07A)

N

Y

X

Participation DateTime

(0040,A082)

N

Y

Z

K

C

Patient's Address

(0010,1040)

N

N

X

Patient's Age

(0010,1010)

N

Y

X

K

Patient's Birth Date

(0010,0030)

N

Y

Z

Patient's Birth Name

(0010,1005)

N

N

X

Patient's Birth Time

(0010,0032)

N

Y

X

Patient's Institution Residence

(0038,0400)

N

N

X

Patient's Insurance Plan Code Sequence

(0010,0050)

N

Y

X

Patient's Mother's Birth Name

(0010,1060)

N

N

X

Patient's Name

(0010,0010)

N

Y

Z

Patient's Primary Language Code Sequence

(0010,0101)

N

Y

X

Patient's Primary Language Modifier Code Sequence

(0010,0102)

N

Y

X

Patient's Religious Preference

(0010,21F0)

N

N

X

Patient's Sex

(0010,0040)

N

Y

Z

K

Patient's Sex Neutered

(0010,2203)

N

Y

X/Z

K

Patient's Size

(0010,1020)

N

Y

X

K

Patient's Telecom Information

(0010,2155)

N

N

X

Patient's Telephone Numbers

(0010,2154)

N

N

X

Patient's Weight

(0010,1030)

N

Y

X

K

Patient Comments

(0010,4000)

N

Y

X

C

Patient ID

(0010,0020)

N

Y

Z/D

Patient Setup Photo Description

(300A,0794)

N

Y

X

C

Patient Setup UID

(300A,0650)

Y

N

U

K

Patient State

(0038,0500)

N

N

X

C

C

Patient Transport Arrangements

(0040,1004)

N

N

X

Patient Treatment Preparation Method Description

(300A,0792)

N

Y

X

C

Patient Treatment Preparation Procedure Parameter Description

(300A,078E)

N

Y

X

C

Performed Location

(0040,0243)

N

N

X

Performed Procedure Step Description

(0040,0254)

N

Y

X

C

Performed Procedure Step End Date

(0040,0250)

N

Y

X

K

C

Performed Procedure Step End DateTime

(0040,4051)

N

N

X

K

C

Performed Procedure Step End Time

(0040,0251)

N

Y

X

K

C

Performed Procedure Step ID

(0040,0253)

N

Y

X

Performed Procedure Step Start Date

(0040,0244)

N

Y

X

K

C

Performed Procedure Step Start DateTime

(0040,4050)

N

N

X

K

C

Performed Procedure Step Start Time

(0040,0245)

N

Y

X

K

C

Performed Station AE Title

(0040,0241)

N

N

X

C

Performed Station Geographic Location Code Sequence

(0040,4030)

N

N

X

K

Performed Station Name

(0040,0242)

N

N

X

K

Performed Station Name Code Sequence

(0040,4028)

N

N

X

K

Performing Physician's Name

(0008,1050)

N

Y

X

Performing Physician Identification Sequence

(0008,1052)

N

Y

X

Person's Address

(0040,1102)

N

Y

X

Person's Telecom Information

(0040,1104)

N

Y

X

Person's Telephone Numbers

(0040,1103)

N

Y

X

Person Identification Code Sequence

(0040,1101)

N

Y

D

Person Name

(0040,A123)

N

Y

D

Physician(s) of Record

(0008,1048)

N

Y

X

Physician(s) of Record Identification Sequence

(0008,1049)

N

Y

X

Physician(s) Reading Study Identification Sequence

(0008,1062)

N

Y

X

Physician Approving Interpretation

(4008,0114)

Y

N

X

Placer Order Number / Imaging Service Request

(0040,2016)

N

Y

Z

Plate ID

(0018,1004)

N

Y

X

K

Position Acquisition Template Description

(3002,0123)

N

Y

X

C

Position Acquisition Template Name

(3002,0121)

N

Y

X

C

Pregnancy Status

(0010,21C0)

N

N

X

K

Pre-Medication

(0040,0012)

N

N

X

C

Prescription Description

(300A,000E)

N

Y

X

C

Prescription Notes

(3010,007B)

N

Y

Z

C

Prescription Notes Sequence

(3010,0081)

N

Y

Z

C

Presentation Creation Date

(0070,0082)

N

Y

X

K

C

Presentation Creation Time

(0070,0083)

N

Y

X

K

C

Presentation Display Collection UID

(0070,1101)

N

Y

U

K

Presentation Sequence Collection UID

(0070,1102)

N

Y

U

K

Prior Treatment Dose Description

(3010,0061)

N

Y

X

C

Private Attributes

(gggg,eeee) where gggg is odd

N

N

X

C

Procedure Step Cancellation DateTime

(0040,4052)

N

N

X

K

C

Product Expiration DateTime

(0044,000B)

N

N

X

K

C

Protocol Name

(0018,1030)

N

Y

X/D

C

Pyramid Description

(0008,1088)

N

Y

X

C

Pyramid Label

(0020,0027)

N

Y

X

C

Pyramid UID

(0008,0019)

N

Y

U

K

Radiation Dose Identification Label

(300A,0619)

N

Y

D

C

Radiation Dose In-Vivo Measurement Label

(300A,0623)

N

Y

D

C

Radiation Generation Mode Description

(300A,067D)

N

Y

Z

C

Radiation Generation Mode Label

(300A,067C)

N

Y

D

C

Radiopharmaceutical Start DateTime

(0018,1078)

N

Y

X

K

C

Radiopharmaceutical Start Time

(0018,1072)

N

Y

X

K

C

Radiopharmaceutical Stop DateTime

(0018,1079)

N

Y

X

K

C

Radiopharmaceutical Stop Time

(0018,1073)

N

Y

X

K

C

Reason for Omission Description

(300C,0113)

N

Y

X

C

Reason for Requested Procedure Code Sequence

(0040,100A)

N

Y

X

C

Reason for Study

(0032,1030)

Y

N

X

C

Reason for Superseding

(3010,005C)

N

Y

Z

C

Reason for the Attribute Modification

(0400,0565)

N

Y

D

C

Reason for the Imaging Service Request

(0040,2001)

Y

N

X

C

Reason for the Requested Procedure

(0040,1002)

N

Y

X

C

Reason for Visit

(0032,1066)

N

Y

X

C

Reason for Visit Code Sequence

(0032,1067)

N

Y

X

C

Receiving AE

(0074,1234)

N

N

X

C

Recorded RT Control Point DateTime

(300A,073A)

N

Y

D

K

C

Referenced Conceptual Volume UID

(3010,000B)

N

Y

U

K

Referenced DateTime

(0040,A13A)

N

Y

D

K

C

Referenced Digital Signature Sequence

(0400,0402)

N

Y

X

Referenced Dose Reference UID

(300A,0083)

N

Y

U

K

Referenced Dosimetric Objective UID

(3010,006F)

N

Y

U

K

Referenced Fiducials UID

(3010,0031)

N

Y

U

K

Referenced Frame of Reference UID

(3006,0024)

N

Y

U

K

Referenced General Purpose Scheduled Procedure Step Transaction UID

(0040,4023)

Y

N

U

K

Referenced Image Sequence

(0008,1140)

N

Y

X/Z/U*

K

Referenced Observation UID (Trial)

(0040,A172)

Y

N

U

K

Referenced Patient Alias Sequence

(0038,0004)

Y

N

X

Referenced Patient Photo Sequence

(0010,1100)

N

Y

X

Referenced Patient Sequence

(0008,1120)

N

Y

X

K

Referenced Performed Procedure Step Sequence

(0008,1111)

N

Y

X/Z/D

K

Referenced SOP Instance MAC Sequence

(0400,0403)

N

Y

X

Referenced SOP Instance UID

(0008,1155)

N

Y

U

K

Referenced SOP Instance UID in File

(0004,1511)

N

N

U

K

Referenced Study Sequence

(0008,1110)

N

Y

X/Z

K

Referenced Treatment Position Group UID

(300A,0785)

N

Y

U

K

Referring Physician's Address

(0008,0092)

N

N

X

Referring Physician's Name

(0008,0090)

N

Y

Z

Referring Physician's Telephone Numbers

(0008,0094)

N

N

X

Referring Physician Identification Sequence

(0008,0096)

N

Y

X

Region of Residence

(0010,2152)

N

N

X

Related Frame of Reference UID

(3006,00C2)

Y

N

U

K

Request Attributes Sequence

(0040,0275)

N

Y

X

C

Requested Contrast Agent

(0032,1070)

N

N

X

C

Requested Procedure Comments

(0040,1400)

N

N

X

C

Requested Procedure Description

(0032,1060)

N

Y

X/Z

C

Requested Procedure ID

(0040,1001)

N

N

X

Requested Procedure Location

(0040,1005)

N

N

X

Requested Series Description

(0018,9937)

N

Y

X

C

Requested SOP Instance UID

(0000,1001)

N

N

U

K

Requesting AE

(0074,1236)

N

N

X

C

Requesting Physician

(0032,1032)

N

N

X

Requesting Service

(0032,1033)

N

N

X

Respiratory Motion Compensation Technique Description

(0018,9185)

N

Y

X

C

Responsible Organization

(0010,2299)

N

Y

X

Responsible Person

(0010,2297)

N

Y

X

Results Comments

(4008,4000)

Y

N

X

C

Results Distribution List Sequence

(4008,0118)

Y

N

X

Results ID

(4008,0040)

Y

N

X

Results ID Issuer

(4008,0042)

Y

N

X

Retrieve AE Title

(0008,0054)

N

Y

X

C

Review Date

(300E,0004)

N

Y

Z

K

C

Reviewer Name

(300E,0008)

N

Y

X/Z

Review Time

(300E,0005)

N

Y

Z

K

C

ROI Creator Sequence

(3006,004D)

N

Y

X

ROI DateTime

(3006,002D)

N

Y

X

K

C

ROI Description

(3006,0028)

N

Y

X

C

ROI Generation Description

(3006,0038)

N

Y

X

C

ROI Interpreter

(3006,00A6)

N

Y

Z

ROI Interpreter Sequence

(3006,004E)

N

Y

X

ROI Name

(3006,0026)

N

Y

Z

C

ROI Observation DateTime

(3006,002E)

N

Y

X

K

C

ROI Observation Description

(3006,0088)

Y

Y

X

C

ROI Observation Label

(3006,0085)

Y

Y

X

C

RT Accessory Device Slot ID

(300A,0615)

N

Y

Z

RT Accessory Holder Slot ID

(300A,0611)

N

Y

Z

RT Physician Intent Narrative

(3010,005A)

N

Y

Z

C

RT Plan Date

(300A,0006)

N

Y

X/D

K

C

RT Plan Description

(300A,0004)

N

Y

X

C

RT Plan Label

(300A,0002)

N

Y

D

C

RT Plan Name

(300A,0003)

N

Y

X

C

RT Plan Time

(300A,0007)

N

Y

X/D

K

C

RT Prescription Label

(3010,0054)

N

Y

D

C

RT Tolerance Set Label

(300A,062A)

N

Y

D

C

RT Treatment Approach Label

(3010,0056)

N

Y

X/D

C

RT Treatment Phase UID

(3010,003B)

N

Y

U

K

Safe Position Exit Date

(3008,0162)

N

Y

D

K

C

Safe Position Exit Time

(3008,0164)

N

Y

D

K

C

Safe Position Return Date

(3008,0166)

N

Y

D

K

C

Safe Position Return Time

(3008,0168)

N

Y

D

K

C

Scheduled Admission Date

(0038,001A)

Y

N

X

K

C

Scheduled Admission Time

(0038,001B)

Y

N

X

K

C

Scheduled Discharge Date

(0038,001C)

Y

N

X

K

C

Scheduled Discharge Time

(0038,001D)

Y

N

X

K

C

Scheduled Human Performers Sequence

(0040,4034)

N

N

X

Scheduled Patient Institution Residence

(0038,001E)

Y

N

X

Scheduled Performing Physician's Name

(0040,0006)

N

N

X

Scheduled Performing Physician Identification Sequence

(0040,000B)

N

N

X

Scheduled Procedure Step Description

(0040,0007)

N

Y

X

C

Scheduled Procedure Step End Date

(0040,0004)

N

N

X

K

C

Scheduled Procedure Step End Time

(0040,0005)

N

N

X

K

C

Scheduled Procedure Step Expiration DateTime

(0040,4008)

N

N

X

K

C

Scheduled Procedure Step ID

(0040,0009)

N

Y

X

Scheduled Procedure Step Location

(0040,0011)

N

N

X

K

Scheduled Procedure Step Modification DateTime

(0040,4010)

N

N

X

K

C

Scheduled Procedure Step Start Date

(0040,0002)

N

N

X

K

C

Scheduled Procedure Step Start DateTime

(0040,4005)

N

N

X

K

C

Scheduled Procedure Step Start Time

(0040,0003)

N

N

X

K

C

Scheduled Station AE Title

(0040,0001)

N

N

X

C

Scheduled Station Geographic Location Code Sequence

(0040,4027)

N

N

X

K

Scheduled Station Name

(0040,0010)

N

N

X

K

Scheduled Station Name Code Sequence

(0040,4025)

N

N

X

K

Scheduled Study Location

(0032,1020)

Y

N

X

K

Scheduled Study Location AE Title

(0032,1021)

Y

N

X

C

Scheduled Study Start Date

(0032,1000)

Y

N

X

K

C

Scheduled Study Start Time

(0032,1001)

Y

N

X

K

C

Scheduled Study Stop Date

(0032,1010)

Y

N

X

K

C

Scheduled Study Stop Time

(0032,1011)

Y

N

X

K

C

Selector AE Value

(0072,005E)

N

Y

D

C

Selector AS Value

(0072,005F)

N

Y

D

K

Selector DA Value

(0072,0061)

N

Y

D

K

C

Selector DT Value

(0072,0063)

N

Y

D

K

C

Selector LO Value

(0072,0066)

N

Y

D

C

Selector LT Value

(0072,0068)

N

Y

D

C

Selector OB Value

(0072,0065)

N

Y

D

Selector PN Value

(0072,006A)

N

Y

D

Selector SH Value

(0072,006C)

N

Y

D

C

Selector ST Value

(0072,006E)

N

Y

D

C

Selector TM Value

(0072,006B)

N

Y

D

K

C

Selector UN Value

(0072,006D)

N

Y

D

Selector UR Value

(0072,0071)

N

Y

D

Selector UT Value

(0072,0070)

N

Y

D

C

Series Date

(0008,0021)

N

Y

X/D

K

C

Series Description

(0008,103E)

N

Y

X

C

Series Instance UID

(0020,000E)

N

Y

U

K

Series Time

(0008,0031)

N

Y

X/D

K

C

Service Episode Description

(0038,0062)

N

Y

X

C

Service Episode ID

(0038,0060)

N

Y

X

Setup Technique Description

(300A,01B2)

N

Y

X

C

Shielding Device Description

(300A,01A6)

N

Y

X

C

Slide Identifier

(0040,06FA)

Y

N

X

Smoking Status

(0010,21A0)

N

N

X

K

SOP Authorization DateTime

(0100,0420)

N

Y

X

K

C

SOP Instance UID

(0008,0018)

N

Y

U

K

Source Conceptual Volume UID

(3010,0015)

N

Y

U

K

Source End DateTime

(0018,936A)

N

Y

D

K

C

Source Frame of Reference UID

(0064,0003)

N

Y

U

K

Source Identifier

(0034,0005)

N

Y

D

Source Image Sequence

(0008,2112)

N

Y

X/Z/U*

K

Source Manufacturer

(300A,0216)

N

Y

X

K

Source of Previous Values

(0400,0564)

N

Y

Z

K

Source Serial Number

(3008,0105)

N

Y

X/Z

K

Source Start DateTime

(0018,9369)

N

Y

D

K

C

Source Strength Reference Date

(300A,022C)

N

Y

D

K

C

Source Strength Reference Time

(300A,022E)

N

Y

D

K

C

Special Needs

(0038,0050)

N

N

X

C

Specimen Accession Number

(0040,050A)

Y

N

X

Specimen Detailed Description

(0040,0602)

N

Y

X

C

Specimen Identifier

(0040,0551)

N

Y

D

Specimen Preparation Sequence

(0040,0610)

N

Y

Z

C

Specimen Short Description

(0040,0600)

N

Y

X

C

Specimen UID

(0040,0554)

N

Y

U

K

Start Acquisition DateTime

(0018,9516)

N

Y

X/D

K

C

Station AE Title

(0008,0055)

N

Y

X

C

Station Name

(0008,1010)

N

Y

X/Z/D

K

Storage Media File-set UID

(0088,0140)

N

Y

U

K

Structure Set Date

(3006,0008)

N

Y

Z

K

C

Structure Set Description

(3006,0006)

N

Y

X

C

Structure Set Label

(3006,0002)

N

Y

D

C

Structure Set Name

(3006,0004)

N

Y

X

C

Structure Set Time

(3006,0009)

N

Y

Z

K

C

Study Arrival Date

(0032,1040)

Y

N

X

K

C

Study Arrival Time

(0032,1041)

Y

N

X

K

C

Study Comments

(0032,4000)

Y

N

X

C

Study Completion Date

(0032,1050)

Y

N

X

K

C

Study Completion Time

(0032,1051)

Y

N

X

K

C

Study Date

(0008,0020)

N

Y

Z

K

C

Study Description

(0008,1030)

N

Y

X

C

Study ID

(0020,0010)

N

Y

Z

Study ID Issuer

(0032,0012)

Y

N

X

Study Instance UID

(0020,000D)

N

Y

U

K

Study Read Date

(0032,0034)

Y

N

X

K

C

Study Read Time

(0032,0035)

Y

N

X

K

C

Study Time

(0008,0030)

N

Y

Z

K

C

Study Verified Date

(0032,0032)

Y

N

X

K

C

Study Verified Time

(0032,0033)

Y

N

X

K

C

Substance Administration DateTime

(0044,0010)

N

N

X

K

C

Synchronization Frame of Reference UID

(0020,0200)

N

Y

U

K

Target UID

(0018,2042)

N

Y

U

K

Telephone Number (Trial)

(0040,A354)

Y

N

X

Template Extension Creator UID

(0040,DB0D)

Y

N

U

K

Template Extension Organization UID

(0040,DB0C)

Y

N

U

K

Template Local Version

(0040,DB07)

Y

N

X

K

C

Template Version

(0040,DB06)

Y

N

X

K

C

Text Comments

(4000,4000)

Y

N

X

Text String

(2030,0020)

N

N

X

Time

(0040,A122)

N

Y

D

K

C

Time of Document Creation or Verbal Transaction (Trial)

(0040,A112)

Y

N

X

K

C

Time of Last Calibration

(0018,1201)

N

Y

X

K

K

C

Time of Last Detector Calibration

(0018,700E)

N

Y

X/D

K

K

C

Time of Secondary Capture

(0018,1014)

N

Y

X

K

C

Timezone Offset From UTC

(0008,0201)

N

Y

X

K

C

Topic Author

(0088,0910)

Y

N

X

Topic Keywords

(0088,0912)

Y

N

X

Topic Subject

(0088,0906)

Y

N

X

Topic Title

(0088,0904)

Y

N

X

Tracking UID

(0062,0021)

N

Y

U

K

Transaction UID

(0008,1195)

N

N

U

K

Transducer Identification Sequence

(0018,5011)

N

Y

X

K

Treatment Control Point Date

(3008,0024)

N

Y

D

K

C

Treatment Control Point Time

(3008,0025)

N

Y

D

K

C

Treatment Date

(3008,0250)

N

Y

X/D

K

C

Treatment Machine Name

(300A,00B2)

N

Y

X/Z

K

Treatment Position Group Label

(300A,0608)

N

Y

D

C

Treatment Position Group UID

(300A,0609)

N

Y

U

K

Treatment Session UID

(300A,0700)

N

Y

U

K

Treatment Site

(3010,0077)

N

Y

X/D

C

Treatment Sites

(300A,000B)

Y

N

X

C

Treatment Technique Notes

(3010,007A)

N

Y

Z

C

Treatment Time

(3008,0251)

N

Y

X/D

K

C

Treatment Tolerance Violation DateTime

(300A,0736)

N

Y

D

K

C

Treatment Tolerance Violation Description

(300A,0734)

N

Y

D

C

UDI Sequence

(0018,100A)

N

Y

X

K

UID

(0040,A124)

N

Y

U

Unique Device Identifier

(0018,1009)

N

Y

X

K

User Content Label

(3010,0033)

N

Y

D

C

User Content Long Label

(3010,0034)

N

Y

D

C

Verbal Source (Trial)

(0040,A352)

Y

N

X

Verbal Source Identifier Code Sequence (Trial)

(0040,A358)

Y

N

X

Verification DateTime

(0040,A030)

N

Y

D

K

C

Verifying Observer Identification Code Sequence

(0040,A088)

N

Y

Z

Verifying Observer Name

(0040,A075)

N

Y

D

Verifying Observer Sequence

(0040,A073)

N

Y

D

Verifying Organization

(0040,A027)

N

Y

D

Visit Comments

(0038,4000)

N

N

X

C

​Waveform Filter Description

(003A,0329)

N

Y

X

C

X-Ray Detector ID

(0018,9371)

N

Y

D

K

X-Ray Detector Label

(0018,9373)

N

Y

X

K

X-Ray Source ID

(0018,9367)

N

Y

D

K

E.1.2 Re-identifier

An Application may claim conformance to the Basic Application Level Confidentiality Profile as a re-identifier if it is capable of removing the protection from a protected SOP instance given that the recipient keys required for the decryption of one or more of the Encrypted Content (0400,0520) Attributes within the Encrypted Attributes Sequence (0400,0500) of the SOP instance are available. Removal of protection in this context is defined as the following process:

  1. The application shall decrypt, using its recipient key, one instance of the Encrypted Content (0400,0520) Attribute within the Encrypted Attributes Sequence (0400,0500) and decode the resulting block of bytes into a DICOM dataset using the Transfer Syntax specified in the Encrypted Content Transfer Syntax UID (0400,0510). Re-identifiers claiming conformance to this Profile shall be capable of decrypting the Encrypted Content using either AES or Triple-DES in all possible key lengths specified in this Profile.

    Note

    If the application is able to decode more than one instance of the Encrypted Content (0400,0520) Attribute within the Encrypted Attributes Sequence (0400,0500), it is at the discretion of the application to choose any one of them.

  2. The application shall move all Attributes contained in the single item of the Modified Attributes Sequence (0400,0550) of the decoded dataset into the main dataset, replacing "dummy value" Attributes that may be present in the main dataset.

    Note

    1. Re-identification does not imply a complete reconstruction of the original SOP Instance, since it is not required that all Attributes being protected be part of the Encrypted Attributes Data Set. If the original UIDs are part of the Encrypted Attributes Data Set, they might be usable to gain access to the original, unprotected SOP Instance.

    2. The presence of an encrypted Data Set that cannot be decrypted indicates that some or all of the Attribute Values in the message may not be real (they are dummies). Therefore, the recipient must not assume that any value in the message is diagnostically relevant.

  3. The Attribute Patient Identity Removed (0012,0062) shall be replaced or added to the dataset with a value of NO and De-identification Method (0012,0063) and De-identification Method Code Sequence (0012,0064) shall be removed.

E.1.3 Conformance Requirements

The Conformance Statement of an application that claims conformance to the Basic Application Level Confidentiality Profile shall describe:

  • which Attributes are removed during protection;

  • which Attributes are replaced by dummy values and how the dummy values are generated;

  • which Attributes are included in Encrypted Attributes Data Sets for later re-identification, and any pertinent details about how keys are selected for performing the encryption;

  • the scope across which the application is able to ensure referential integrity of replacement values for references such as SOP Instance UID, Frame of Reference UID, etc. if multiple SOP instances are protected (e.g., across multiple Studies, consistent replacement if the same Study processed more than once, etc.);

  • which Attributes and Attribute Values are inserted during protection of a SOP instance;

  • which Transfer Syntaxes are supported for encoding/decoding of the Encrypted Attributes Data Set;

  • which Options are supported;

  • any additional restrictions (e. g. key sizes for public keys).

E.2 Basic Application Level Confidentiality Profile

This Profile is intended for use in clinical trials, and other scenarios in which de-identification may be required, such as creation of teaching files, other types of publication, as well as submission of images and associated information to registries, such as oncology or radiation dose registries.

This Basic Application Level Confidentiality Profile defines an extremely conservative approach that removes all information related to:

  • the identity and demographic characteristics of the patient

  • the identity of any responsible parties or family members

  • the identity of any personnel involved in the procedure

  • the identity of the organizations involved in ordering or performing the procedure

  • additional information that could be used to match instances if given access to the originals, such as UIDs, dates and times

  • Private Attributes

when that information is present in the non-Pixel Data Attributes, including graphics or overlays, as described in Table E.1-1.

Note

Unless the Clean Pixel Data Option or the Clean Recognizable Visual Features Option is specified, this Profile does not address information in the pixels.

The Attribute Longitudinal Temporal Information Modified (0028,0303) shall be added to the Dataset with a Value of "REMOVED" if none of the Retain Longitudinal Temporal Information Options is applied.

E.3 Basic Application Level Confidentiality Options

Various Options are defined to be applicable to the Basic Application Level Confidentiality Profile. Some of these Options require removal of additional information, and some of these Options require retention of information that would otherwise be removed.

The following Options are defined that require removal of additional information:

  • Clean Pixel Data Option

  • Clean Recognizable Visual Features Option

  • Clean Graphics Option

The following options are defined that require processing of information that would otherwise be removed but that is needed for specific uses:

  • Clean Structured Content Option

  • Clean Descriptors Option

The following Options are defined that require retention of information that would otherwise be removed but that is needed for specific uses:

  • Retain Longitudinal Temporal Information with Full Dates Option

  • Retain Longitudinal Temporal Information with Modified Dates Option

  • Retain Patient Characteristics Option

  • Retain Device Identity Option

  • Retain Institution Identity Option

  • Retain UIDs Option

  • Retain Safe Private Option

E.3.1 Clean Pixel Data Option

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, any information burned in to the Pixel Data (7FE0,0010) corresponding to the Attribute information specified to be removed by the Profile and any other Options specified shall also be removed, as described in Table E.1-1.

This may require intervention of or approval by a human operator.

The Attribute Burned In Annotation (0028,0301) shall be added to the Dataset with a Value of "NO".

Note

  1. This capability is called out as a specific Option, since it may be extremely burdensome in practice to implement and is unnecessary for the vast majority of modalities that do not burn in such annotation in the first place. For example, CT images do not normally contain such burned in annotation, whereas Ultrasound images routinely do.

  2. Though image processing and optical character recognition techniques can be used to detect the presence of and location of burned in text, and matching against known identifying information can be applied, deciding whether or not that text is identifying information or some other type of information may be non-trivial. Compliance with this Option requires that identifying information is removed, regardless of how that is achieved. It is not required that information specified to be retained in the non-pixel data by other Options (e.g., physical characteristics, dates or descriptors) also be retained burned-in to the pixel data. Thus the most conservative approach of removing any and all burned in text would be compliant. This may involve sacrificing additional potentially useful information such as localizer posting and manual graphic annotations.

  3. The Stored Pixel Values are to be changed (blacked out); it is not sufficient to superimpose an overlay or graphic annotation or shutter to obscure the Stored Pixel Data Values, since those may not be ignored by the receiving system.

  4. This Option is intended to apply to the Pixel Data (7FE0,0010) Attribute that occurs in the top level Dataset of an Image Storage SOP Instance. The other standard use of Pixel Data (7FE0,0010) is within Icon Image Sequence (0088,0200), which is already described in Table E.1-1 and the accompanying note as requiring removal. This Option does not require the ability to manually or automatically process the Stoered Pixel Data Values of Pixel Data (7FE0,0010) occurring in any other location than the top level dataset, but it does not prohibit it. Pixel Data (7FE0,0010) occurring within private Attributes will be removed because such Attributes will not be known to be safe.

E.3.2 Clean Recognizable Visual Features Option

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, if there is sufficient visual information within the Pixel Data of a set of instances to allow an individual to be recognized from the instances themselves or a reconstruction of a set of instances, then sufficient removal or distortion of the Pixel Data shall be applied to prevent recognition.

This may require intervention of or approval by a human operator.

The Attribute Recognizable Visual Features (0028,0302) shall be added to the Dataset with a Value of "NO".

Note

  1. This capability is called out as a specific Option, since it may be extremely burdensome in practice to implement and is unnecessary for the vast majority of anatomic sites and modalities.

  2. In the case of full-face photographs, the risk of visual identification is obvious, and numerous techniques are well established for de-identification, such as applying black rectangles over the eyes, etc.

  3. In the case of high-resolution cross-sectional imaging of the entire head and neck, it has been suggested that a 3D volume or surface rendering of the pixel data may be sufficient to allow identification (or matching against a constrained subset of individuals) under some circumstances.

  4. Application of this Option may render the pixel data unusable for the purpose for which it has been collected, and hence its use may require a compromise between de-identification and utility based on obtaining appropriate ethical approval and informed consent. Consider for example, the case of dental images.

  5. Since the Referenced Patient Photo Sequence is removed as part of the Basic Profile, support of the Clean Recognizable Visual Features Option does not add requirements for that Attribute.

E.3.3 Clean Graphics Option

Instances of various Standard and Standard Extended SOP Classes, including Images, Presentation States and other Composite SOP Instances, may contain identification information encoded as graphics, text annotations or overlays. This does not include information contained in Structured Report SOP Classes.

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, any information encoded in graphics, text annotations or overlays corresponding to the Attribute information specified to be removed by the Profile and any other Options specified shall also be removed, as described in Table E.1-1.

This may require intervention of a human operator.

Note

  1. This capability is called out as a specific Option, since it may be more practical to simply remove all such graphics, text annotations or overlays (as required by the Profile without this Option).

  2. As with burned-in pixel data annotation, deciding whether or not text is identifying information or some other type of information may be non-trivial. It is not required that information specified to be retained in the non-pixel data by other Options (e.g., physical characteristics, dates or descriptors) also be retained in graphics, text annotations or overlays.

E.3.4 Clean Structured Content Option

Instances of Structured Report SOP Classes may contain identifiable information in a Content Sequence (0040,A730) encoded in Content Items. Instances of other SOP Classes may contain structured content encoded in a similar manner in the Acquisition Context Sequence (0040,0555) or Specimen Preparation Sequence (0040,0610).

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, any information encoded in SR Content Items or Acquisition Context or Specimen Preparation Sequence Items corresponding to the Attribute information specified to be removed by the Profile and any other Options specified shall also be removed.

Note

  1. For example, the "observer" responsible for a diagnostic imaging report may be explicitly identified in Observation Content related Content Items in an SR.

  2. A de-identifier that does not implement this Option creates significant risk when attempting to de-identity a Structured Report unless it is only used to de-identify instances that are known to have no identifying information in the Content Sequence.

  3. As this Standard and external coding schemes are maintained, the codes specified as Concept Name Codes may change. The previous codes are considered Retired but implementations may continue to send them and de-identifiers will be expected to be able to continue to recognize and de-identify Content Items with the Retired codes, including the Code Value and Coding Scheme Designator, even if the current Standard does not publish them.

    A notable example is the change throughout the Standard from using "SNOMED-RT style" Code Values with a Coding Scheme Designator of "SRT", "SNM3" or "99SDM", to the use of SNOMED CT numeric Code Values with a Coding Scheme Designator of "SCT". A mapping of retired to new SNOMED codes is found in Annex O “SNOMED Concept ID to SNOMED ID Mapping” in PS3.16.

Table E.3.4-1. Application Level Confidentiality Profile Clean Structured Content Option Content Item Concept Name Codes

Code Meaning

Code Value

Coding Scheme Designator

Value Type

Retd. (from PS3.16)

In Std. Tpl. (from PS3.16)

Basic Prof.

Rtn. UIDs Opt.

Rtn. Dev. Id. Opt.

Rtn. Inst. Id. Opt.

Rtn. Pat. Chars. Opt.

Rtn. Long. Full Dates Opt.

Rtn. Long. Modif. Dates Opt.

Clean Desc. Opt.

Accession Number

121022

DCM

TEXT

N

Y

X

Acquired Image

113795

DCM

IMAGE

N

Y

D

K

Acquisition Date

126201

DCM

DATE

N

Y

X

K

C

Acquisition Protocol

125203

DCM

TEXT

N

Y

X

C

Acquisition Time

126202

DCM

TIME

N

Y

X

K

C

Activity Session

C67447

NCIt

TEXT

N

Y

X

C

Administration of radiopharmaceutical

440252007

SCT

TEXT

N

Y

D

C

Admission DateTime

15

NCDR [2.0b]

DATETIME

N

Y

X

K

C

Anatomic Identifier

112050

DCM

TEXT

N

Y

X

C

Anesthesia Finish Time

398164008

SCT

DATETIME

N

Y

X

K

C

Anesthesia Start Time

398325003

SCT

DATETIME

N

Y

X

K

C

Best illustration of finding

121080

DCM

IMAGE

N

Y

X

K

Best illustration of finding

121080

DCM

WAVEFORM

N

Y

X

K

Calibration DateTime

113723

DCM

DATETIME

N

Y

D

K

C

Calibration Protocol

113720

DCM

TEXT

N

Y

X

C

Calibration Responsible Party

113724

DCM

TEXT

N

Y

D

C

Catheterization Operator

76

NCDR [2.0b]

PNAME

N

Y

D

Cath Lab Procedure Log

121120

DCM

COMPOSITE

N

Y

X

K

Clinical Report

371524004

SCT

COMPOSITE

N

Y

X

K

Clinical Report

371524004

SCT

TEXT

N

Y

X

C

Comment

121106

DCM

TEXT

N

Y

X

C

Complication of Procedure

116224001

SCT

TEXT

N

Y

X

C

Component ID

112347

DCM

TEXT

N

Y

D

Conclusion

121077

DCM

TEXT

N

Y

X

C

Content Date

111018

DCM

DATE

N

Y

X/D

K

C

Content Time

111019

DCM

TIME

N

Y

X/D

K

C

Current procedure evidence

122073

DCM

COMPOSITE

N

Y

X

K

Date of last menstrual period

11955-2

LN

DATE

N

Y

X

K

C

DateTime Concern Noted

121431

DCM

DATETIME

N

Y

X

K

C

DateTime Concern Resolved

121432

DCM

DATETIME

N

Y

X

K

C

DateTime Ended

111527

DCM

DATETIME

N

Y

X

K

C

DateTime of Death

122165

DCM

DATETIME

N

Y

X

K

C

DateTime of Intervention

122105

DCM

DATETIME

N

Y

X

K

C

DateTime of last evaluation

111536

DCM

DATETIME

N

Y

X

K

C

DateTime of processing

111702

DCM

DATETIME

N

Y

X

K

C

DateTime of Recording of Log Entry

121125

DCM

DATETIME

N

Y

X

K

C

DateTime problem observed

111535

DCM

DATETIME

N

Y

X

K

C

DateTime Problem Resolved

121433

DCM

DATETIME

N

Y

X

K

C

DateTime Started

111526

DCM

DATETIME

N

Y

X/D

K

C

Degree of Freedom ID

112363

DCM

TEXT

N

Y

D

Derived Fiducial

112357

DCM

UIDREF

N

Y

D

K

Derived Planning Data

112373

DCM

COMPOSITE

N

Y

X

K

Derived Planning Images

112372

DCM

COMPOSITE

N

Y

X

K

Description of Change

111021

DCM

TEXT

N

Y

X

C

Description of Material

121145

DCM

TEXT

N

Y

X

C

Device Description

120999

DCM

TEXT

N

Y

X

K

Device Name

113877

DCM

TEXT

N

Y

X

K

Device Observer Name

121013

DCM

TEXT

N

Y

X

K

Device Observer Physical Location During Observation

121017

DCM

TEXT

N

Y

X

K

Device Observer Serial Number

121016

DCM

TEXT

N

Y

X

K

Device Observer UID

121012

DCM

UIDREF

N

Y

X/D

K

K

Device Serial Number

113880

DCM

TEXT

N

Y

X/D

K

Device Subject Name

121193

DCM

TEXT

N

Y

D

K

Device Subject Physical Location during observation

121197

DCM

TEXT

N

Y

X

K

Device Subject Serial Number

121196

DCM

TEXT

N

Y

X

K

Device Subject UID

121198

DCM

UIDREF

N

Y

X

K

K

Discharge DateTime

122163

DCM

DATETIME

N

Y

X

K

C

Dose Image

121342

DCM

IMAGE

N

Y

X

K

Drug administered

122083

DCM

TEXT

N

Y

X/D

C

Drug end

122082

DCM

DATETIME

N

Y

X

K

C

Drug start

122081

DCM

DATETIME

N

Y

X

K

C

ECG Finding

271921002

SCT

TEXT

N

Y

X/D

C

EDD

11778-8

LN

DATE

N

Y

X

K

C

End of X-Ray Irradiation

113810

DCM

DATETIME

N

Y

D

K

C

Equipment Identification

121122

DCM

TEXT

N

Y

X

K

C

Event UID Used

128429

DCM

UIDREF

N

Y

D

K

Experience

C54627

NCIt

NUM

N

Y

X

Fellow

121088

DCM

PNAME

N

Y

X

Fetus ID

11951-1

LN

TEXT

N

Y

D

Filler Number

121021

DCM

TEXT

N

Y

X

Finding

121071

DCM

TEXT

N

Y

X/D

C

Finding Site

363698007

SCT

TEXT

N

Y

D

C

Frame of Reference UID

112227

DCM

UIDREF

N

Y

X/D

K

Glucose Measurement Date

127857

DCM

DATE

N

Y

D

K

C

Glucose Measurement Time

127858

DCM

TIME

N

Y

D

K

C

History

11329-0

LN

TEXT

N

Y

X

C

Identification of the Attenuator

130527

DCM

TEXT

N

Y

D

K

Identification of the X-Ray Source

113832

DCM

TEXT

N

Y

D

K

Identifier

125010

DCM

TEXT

N

Y

X

Identifier within Person Observer's Role

128775

DCM

TEXT

N

Y

X

Identifying Segment

112229

DCM

IMAGE

N

Y

D

K

Illustration of Finding

125201

DCM

IMAGE

N

Y

X

K

Illustration of ROI

121200

DCM

IMAGE

N

Y

X

K

Image Acquired

121138

DCM

IMAGE

N

Y

D

K

Imaging Start DateTime

122712

DCM

DATETIME

N

Y

D

K

C

Implant Assembly Template

112366

DCM

COMPOSITE

N

Y

X

K

Impression Description

111033

DCM

TEXT

N

Y

D

C

Indications for Procedure

18785-6

LN

TEXT

N

Y

D

C

Intervention attempt identifier

121154

DCM

TEXT

N

Y

D

Irradiation Authorizing

113850

DCM

PNAME

N

Y

D

Irradiation Event Label

113605

DCM

TEXT

N

Y

X

Irradiation Event UID

113769

DCM

UIDREF

N

Y

D

K

Issuer of Identifier

110190

DCM

TEXT

N

Y

X

Issuer of Parent Specimen Identifier

111706

DCM

TEXT

N

Y

X

Issuer of Specimen Identifier

111724

DCM

TEXT

N

Y

X

Key Object Description

113012

DCM

TEXT

N

Y

X

C

LV Wall Motion Segmental Findings

18118-0

LN

TEXT

N

Y

X

C

Manufacturer Implant Template

112371

DCM

COMPOSITE

N

Y

D

K

Mating Feature ID

112352

DCM

TEXT

N

Y

D

Mating Feature Set ID

112351

DCM

TEXT

N

Y

D

Medication Type

111516

DCM

TEXT

N

Y

X

C

Mother of fetus

121036

DCM

PNAME

N

Y

X

Organization Name

113873

DCM

TEXT

N

Y

X

K

Original Source

111040

DCM

COMPOSITE

N

Y

D

K

Parent Specimen Identifier

111705

DCM

TEXT

N

Y

D

Patient Data Used During Planning

112361

DCM

COMPOSITE

N

Y

X

K

Patient Image

112354

DCM

IMAGE

N

Y

X

K

Patient Model

113815

DCM

TEXT

N

Y

D

C

Patient Presentation

121110

DCM

TEXT

N

Y

X

C

Patient Radiation Dose Model Data

128425

DCM

COMPOSITE

N

Y

X

K

Patient Radiation Dose Model Data

128425

DCM

IMAGE

N

Y

X

K

Patient Radiation Dose Model Data

128425

DCM

UIDREF

N

Y

X

K

Patient Radiation Dose Model Reference

128426

DCM

TEXT

N

Y

X

C

Patient State

109054

DCM

TEXT

N

Y

X

C

Patient Transferred From

122128

DCM

TEXT

N

Y

X

K

Performed Procedure Step SOP Instance UID

121126

DCM

UIDREF

N

Y

D

K

Performing Physician

121114

DCM

PNAME

N

Y

D

Person administering drug/contrast

121152

DCM

PNAME

N

Y

X

Person ID

113871

DCM

TEXT

N

Y

X

Person ID Issuer

113872

DCM

TEXT

N

Y

X

Person Name

113870

DCM

PNAME

N

Y

D

Person Observer's Login Name

128774

DCM

TEXT

N

Y

X

Person Observer's Organization Name

121009

DCM

TEXT

N

Y

X

K

Person Observer Name

121008

DCM

PNAME

N

Y

D

Physician Note

121173

DCM

TEXT

N

Y

X

C

Placer Number

121020

DCM

TEXT

N

Y

X

Prescription Identifier

113516

DCM

TEXT

N

Y

X

Prior report for current patient

122075

DCM

COMPOSITE

N

Y

X

K

Procedure Action ID

121124

DCM

TEXT

N

Y

X/D

Procedure DateTime

122146

DCM

DATETIME

N

Y

X/D

K

C

Procedure DateTime

52

NCDR [2.0b]

DATETIME

N

Y

D

K

C

Procedure Description

121065

DCM

TEXT

N

Y

X/D

C

Procedure Number in this admission

53

NCDR [2.0b]

TEXT

N

Y

X

Procedure Result

122177

DCM

TEXT

N

Y

X

C

Procedure Study Component UID

121019

DCM

UIDREF

N

Y

X

K

Procedure Study Instance UID

121018

DCM

UIDREF

N

Y

X

K

Procedure Time Base

122701

DCM

DATETIME

N

Y

X

K

C

Processing step description

111703

DCM

TEXT

N

Y

X

C

Protocol Time Point Identifier

126071

DCM

TEXT

N

Y

X

C

Pulse Sequence Name

128230

DCM

TEXT

N

Y

X

C

Quoted Source

121002

DCM

COMPOSITE

N

Y

D

K

Radiation Dose Composite Parameters

128436

DCM

COMPOSITE

N

Y

D

K

Radiation Dose Estimate Name

128403

DCM

TEXT

N

Y

D

C

Radiation Dose Representation Data

128414

DCM

COMPOSITE

N

Y

D

K

Radiation Dose Representation Data

128414

DCM

IMAGE

N

Y

D

K

Radionuclide Identifier

113514

DCM

TEXT

N

Y

X

Radiopharmaceutical Administration Event UID

113503

DCM

UIDREF

N

Y

D

K

Radiopharmaceutical Dispense Unit Identifier

113511

DCM

TEXT

N

Y

X

Radiopharmaceutical Lot Identifier

113512

DCM

TEXT

N

Y

X

Radiopharmaceutical Start DateTime

123003

DCM

DATETIME

N

Y

X/D

K

C

Radiopharmaceutical Stop DateTime

123004

DCM

DATETIME

N

Y

X

K

C

RDSR Frame of Reference Description

130507

DCM

TEXT

N

Y

X

C

Reagent Vial Identifier

113513

DCM

TEXT

N

Y

X

Real World Value Map used for measurement

126100

DCM

COMPOSITE

N

Y

X

K

Reason for Proceeding

113907

DCM

TEXT

N

Y

X

C

Recent Physical Activity

113552

DCM

TEXT

N

Y

X

C

Recommendation

121075

DCM

TEXT

N

Y

X

C

Recommended Follow-up Date

111054

DCM

DATE

N

Y

X/D

K

C

Referenced Segment

121191

DCM

IMAGE

N

Y

X/D

K

Referenced Segmentation Frame

121214

DCM

IMAGE

N

Y

D

K

Related Patient Data Not Used During Planning

112364

DCM

COMPOSITE

N

Y

X

K

Room Identification

121121

DCM

TEXT

N

Y

X

Sampling DateTime

111469

DCM

DATETIME

N

Y

D

K

C

Selected Region Description

111058

DCM

TEXT

N

Y

D

C

Series Instance UID

112002

DCM

UIDREF

N

Y

D

K

Series or Instance used for Water Equivalent Diameter estimation

113985

DCM

UIDREF

N

Y

D

K

Service Delivery Location

121434

DCM

TEXT

N

Y

X

K

Service Performer

121435

DCM

PNAME

N

Y

X

Service Performer

121435

DCM

TEXT

N

Y

X

Social History

160476009

SCT

TEXT

N

Y

X

C

Source image for segmentation

121233

DCM

IMAGE

N

Y

D

K

Source of Measurement

121112

DCM

IMAGE

N

Y

D

K

Source of Measurement

121112

DCM

WAVEFORM

N

Y

X

K

Source series for segmentation

121232

DCM

UIDREF

N

Y

D

K

Spatial Fiducials

128447

DCM

COMPOSITE

N

Y

X

K

Spatial Registration

112353

DCM

COMPOSITE

N

Y

X

K

Spatial Registration Reference

128444

DCM

COMPOSITE

N

Y

D

K

Specimen Container Identifier

111700

DCM

TEXT

N

Y

X

Specimen Identifier

121041

DCM

TEXT

N

Y

X

Specimen UID

121039

DCM

UIDREF

N

Y

X

K

SR Instance Used

128416

DCM

COMPOSITE

N

Y

D

K

Start DateTime

398201009

SCT

DATETIME

N

Y

D

K

C

Start of X-Ray Irradiation

113809

DCM

DATETIME

N

Y

D

K

C

Station AE Title

110119

DCM

TEXT

N

Y

X

K

ST Elevation Onset DateTime

122173

DCM

DATETIME

N

Y

X

K

C

Stop DateTime

397898000

SCT

DATETIME

N

Y

D

K

C

Stress Protocol

109056

DCM

TEXT

N

Y

X

C

Study Date

111060

DCM

DATE

N

Y

X/D

K

C

Study Instance UID

110180

DCM

UIDREF

N

Y

D

K

Study Time

111061

DCM

TIME

N

Y

X/D

K

C

Subject Age

121033

DCM

NUM

N

Y

X

K

Subject Birth Date

121031

DCM

DATE

N

Y

X

Subject ID

121030

DCM

TEXT

N

Y

X/D

Subject Name

121029

DCM

PNAME

N

Y

D

Subject Sex

121032

DCM

CODE

N

Y

X

K

Subject Time Point Identifier

126070

DCM

TEXT

N

Y

X

C

Subject UID

121028

DCM

UIDREF

N

Y

X

K

Summary

121111

DCM

TEXT

N

Y

X

C

Supporting Information

112359

DCM

COMPOSITE

N

Y

X

K

Time Point

C2348792

UMLS

TEXT

N

Y

X/D

C

Tracking Unique Identifier

112040

DCM

UIDREF

N

Y

D

K

Unique Device Identifier

74711-3

LN

TEXT

N

Y

X

K

Unique Device Identifiers

121000

DCM

CONTAINER

N

Y

X

K

User Selected Fiducial

112356

DCM

UIDREF

N

Y

D

K

Waveform Acquired

121143

DCM

WAVEFORM

N

Y

D

K

X-Ray Attenuator Model Data

128470

DCM

COMPOSITE

N

Y

X

K

X-Ray Attenuator Model Data

128470

DCM

IMAGE

N

Y

X

K

X-Ray Attenuator Model Data

128470

DCM

UIDREF

N

Y

X

K

X-Ray Radiation Dose Report

113701

DCM

COMPOSITE

N

Y

X

K

E.3.5 Clean Descriptors Option

Even though many Attributes are defined in the DICOM Standard for specific purposes, such as to describe a Study or a Series, those that contain plain text over which an operator has control may contain unstructured information that includes identities.

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, any information that is embedded in text or string Attributes corresponding to the Attribute information specified to be removed by the Profile and any other Options specified shall also be removed, as described in Table E.1-1.

Note

  1. For example, an operator may include a person's name or a patient's demographics or physical characteristics in the Study Description (0008,1030), perhaps because their modality user interface does not provide other fields or because other systems do not display them. E.g., the description might contain "CT chest abdomen pelvis - 55F Dr. Smith".

  2. One approach to cleaning such text strings without human intervention is to extract and retain only values known to be useful and safe and discard all others. For example, in the string "CT chest abdomen pelvis - 55F Dr. Smith" are found in Study Description (0008,1030), then it would be feasible to detect and retain "CT chest abdomen pelvis" and discard the remainder. In an international setting, this may require an extensive dictionary of words that are safe to retain, e.g., to detect "Buik" for abdomen in Dutch or "λεκάνη" for pelvis in Greek. Another possibility is to extract such information and attempt to code the information in other Attributes (if otherwise absent or empty) such as Anatomic Region Sequence (0008,2218). However, the possibility of string values being both identifying and descriptive in different uses needs to be considered, e.g., "Dr. Hand" or "M. Genou".

  3. Table E.1-1 calls out specific Attributes known to be at risk, but an implementer may want to consider any Attribute that could potential contain character data, though this Option does not require that this be done. For example, all SH, LO, ST, LT and UT Value Representations could perhaps be misused. Code strings, CS, are not generally at risk, but a check against known Defined Terms and Enumerated Values could be performed. Though extremely unusual, it is conceivable that even a DS or IS string could be misused, and a check could be made that only legal numeric characters were used. Any PN Attribute is obviously at risk. The OB VR is discussed in the Retain Safe Private Option.

  4. This Option specifies what needs to be removed, not what needs to be retained. Depending on the application, it may be desirable to retain some information, such as technique description, but discard other information, such as diagnosis, for example because it may bias the interpretation in a clinical trial. For example, one approach is to remove all description and comment Attributes except Series Description (0008,103E), since this Attribute rarely contains identifying or diagnosis information yet is typically a reliable source of useful information about the acquisition technique populated automatically from modality device protocols, though it still could be cleaned as described in Note 2.

  5. It should be recognized that if any descriptor contains information about a particularly unusual procedure or condition, then in conjunction with other demographic information it might reduce the number of possible individuals that could be the imaging subject. However, this is to some extent true also if the condition or other unusual physical features are obvious from visual examination of the images themselves. E.g., how many conjoined twins born in a particular month in Philadelphia might there be?

The manner of cleaning shall be described in the Conformance Statement.

E.3.6 Retain Longitudinal Temporal Information Options

Dates and times are recognized as having a potential for leakage of identity because they constrain the number of possible individuals that could be the imaging subject, though only if there is access to other information about the individuals concerned to match it against.

However, there are applications that require dates and times to be present to able to fulfill the objective. This is particularly true in therapeutic clinical trials in which the objective is to measure change in an outcome measure over time. Further, it is often necessary to correlate information from images with information from other sources, such as clinical and laboratory data, and dates and times need to be consistent.

Two mutually exclusive Options are specified to address these requirements:

  • Retain Longitudinal Temporal Information With Full Dates Option

  • Retain Longitudinal Temporal Information With Modified Dates Option

When the Retain Longitudinal Temporal Information With Full Dates Option is specified in addition to the Basic Application Level Confidentiality Profile, any dates and times present in the Attributes shall be retained, as described in Table E.1-1. The Attribute Longitudinal Temporal Information Modified (0028,0303) shall be added to the Dataset with a Value of "UNMODIFIED".

When the Retain Longitudinal Temporal Information With Modified Dates Option is specified in addition to the Basic Application Level Confidentiality Profile, any dates and times present in the Attributes listed in Table E.1-1 shall be modified. The modification of the dates and times shall be performed in a manner that:

  • aggregates or transforms dates so as to reduce the possibility of matching for re-identification

  • preserves the gross longitudinal temporal relationships between images obtained on different dates to the extent necessary for the application

  • preserves the fine temporal relationships between images and real-world events to the extent necessary for analysis of the images for the application

The Attribute Longitudinal Temporal Information Modified (0028,0303) shall be added to the Dataset with a Value of "MODIFIED".

Note

  1. Aggregation of dates may be performed by various means such as setting all dates to the first day of the month, all months to the first month of the year, etc., depending on the precision required for the application.

  2. It is possible to modify all dates and times to dummy values by shifting them relative to an arbitrary event, and hence retain the precise longitudinal temporal relationships amongst a set of studies, when either de-identification of the entire set is performed at the same time, or some sort of mapping or database is kept to repeat this process on separate occasions. It may also be desirable to record the type of event and the temporal offset from that event, and Attributes are provided for that purpose; see Longitudinal Temporal Offset from Event (0012,0052) and Longitudinal Temporal Event Type (0012,0053) in the PS3.3 Section C.7.2.3 Clinical Trial Study Module.

  3. Transformation of dates and times should be considered together, in order to address studies that span midnight.

  4. Any transformation of times should be performed in such a manner as to not disrupt computations needed for analysis, such as comparison of start of injection time to the acquisition time for PET SUV, or extraction of time-intensity values from dynamic contrast enhanced studies.

The manner of date modification shall be described in the Conformance Statement.

E.3.7 Retain Patient Characteristics Option

Physical characteristics of the patient documented in the Attributes, which are descriptive rather than identifying information per se, are recognized as having a potential for leakage of identity because they constrain the number of possible individuals that could be the imaging subject, though only if there is access to other information about the individuals concerned to match it against.

Note

This is distinct from physical characteristics that can be derived from the Pixel Data, such as age or sex estimation from the appearance of the bones.

However, there are applications that require such physical characteristics in order to perform the computations necessary to analyze the images to fulfill the objective. One such class of applications is those that are related to metabolic measures, such as computation of PET Standard Uptake Values (SUV) or DEXA or MRI measures of body composition, which are based on body weight, body surface area or lean body mass.

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, information about age, sex, height and weight and other characteristics present in the Attributes shall be retained, as described in Table E.1-1.

The manner of cleaning of retained Attributes shall be described in the Conformance Statement.

E.3.8 Retain Device Identity Option

Information about the identity of the device that was used to perform the acquisition is recognized as having a potential for leakage of identity because it may constrain the number of possible individuals that could be the imaging subject, though only if there is access to other information about the individuals concerned to match it against.

However, there are applications that require such device information to perform the analysis or interpretation. The type of correction for spatial or other inhomogeneity may require knowledge of the specific device serial number. Confirmation that specific devices that have been previously qualified (e.g., with phantoms) may be required. Further, there may be a need to maintain a record of the device used for regulatory or registry purposes, yet the acquisition site may not maintain an adequate electronic audit trail.

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, information about the identity of the device in the Attributes shall be retained, as described in Table E.1-1.

For some retained values, such as Application Entity Titles, if these are to be retained they are specifed to be Cleaned, rather than just Kept, since they may contain embedded institution or person identification information that is not intended to be disclosed.

Note

The Source Application Entity Title (0002,0016), Sending Application Entity Title (0002,0017), and Receiving Application Entity Title (0002,0018) are not included in the list of Attributes to be removed or retained, since they are part of the File Meta Information (see PS3.10), which is entirely replaced whenever a file is stored or modified during de-identification. See Section E.1.1.

E.3.9 Retain UIDs Option

Though individuals do not have unique identifiers themselves, studies, series, instances and other entities in the DICOM model are assigned globally unique UIDs. Whilst these UIDs cannot be mapped directly to an individual out of context, given access to the original images, or to a database of the original images containing the UIDs, it would be possible to recover the individual's identity.

However, there are applications that require the ability to maintain an audit trail back to the original images and though there are other mechanisms they may not scale well or be reliably implemented. This Option is provided for use when it is judged that the risk of gaining access to the original information via the UIDs is small relative to the benefit of retaining them.

When this Option is specified in addition to an Application Level Confidentiality Profile, UIDs shall be retained, as described in Table E.1-1.

Note

  1. A UID of a DICOM entity is not the same as a unique identifier of an individual, such as would be proscribed by some privacy regulations.

  2. UIDs are generated using a hierarchical scheme of "roots", which may be traceable by a knowledgeable person back to the original assignee of the root, typically the device manufacturer, but sometimes the organization using the device.

  3. When evaluating the risk of matching UIDs with the original images or PACS database, one should consider that even if the UIDs are changed, the pixel data itself presents a similar risk. Specifically, the pixel data of the de-identified image can be matched against the pixel data of the original image. Such matching can be greatly accelerated by comparing pre-computed hash values of the pixel data. Removal of burned-in identification may change the pixel data but then matching against a sub-region of the pixel data is almost certainly possible (e.g., the central region of an image). Even addition of noise to an image is not sufficient to prevent re-identification since statistical matching techniques can be used. Ultimately, if any useable pixel data is retained during de-identification, then re-identification is nearly always possible if one has access to the original images. Ergo, replacement of UIDs should not give rise to a false confidence that the images have been more thoroughly de-identified than if the UIDs are retained.

  4. Regardless of this Option, implementers should take care not to remove UIDs that are structural and defined by the Standard as opposed to those that are instance-related. E.g., one would never remove or replace the SOP Class UID for de-identification purposes.

  5. The Implementation Class UID (0002,0012) is not included in the list of UID Attributes to be retained, since it is part of the File Meta Information (see PS3.10), which is entirely replaced whenever a file is stored or modified during de-identification. See Section E.1.1.

  6. UIDs may have been generated using a date/time stamp mechanism to assist in uniqueness generation. Hence if the original UIDs are not replaced, they may assist identity recovery. That said, the presence of an apparent date/time stamp in a UID does not indicate that it is an original UID, since replacement UIDs may contain new date/time stamps related to when the instance was de-identified. Also, UUIDs may be time-based rather than name-based or random-number-based, so use of the PS3.5 Section B.2 UUID Derived UID mechanism does not necessarily avoid this issue.

E.3.10 Retain Safe Private Option

By definition, Private Attributes contain proprietary information, in many cases the nature of which is known only to the vendor and not publicly documented.

However, some Private Attributes may be necessary for the desired application. For example, specific technique information such as CT helical span pitch, or pixel value transformation, such as PET SUV rescale factors, may only be available in Private Attributes since the information is either not defined in Standard Attributes, or was added to the DICOM Standard after the acquisition device was manufactured.

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, Private Attributes that are known by the de-identifier to be safe from identity leakage shall be retained, together with the Private Creator IDs that are required to fully define the retained Private Attributes; all other Private Attributes shall be removed or processed in the element-specific manner recommended by Deidentification Action (0008,0307), if present within Private Data Element Characteristics Sequence (0008,0300) (see PS3.3 Section C.12.1).

Whether or not an Attribute is known to be safe may be determined by:

  • its presence in a block of Private Data Elements with a Value of "SAFE" in Block Identifying Information Status (0008,0303) or individually listed in Nonidentifying Private Elements (gggg,0004) (within Private Data Element Characteristics Sequence (0008,0300); see PS3.3 Section C.12.1)

  • its presence in Table E.3.10-1 Safe Private Attributes

  • documentation in the Conformance Statement

  • some other means.

When this Option is not specified, all Private Attributes shall be removed, as described in Table E.1-1.

Note

  1. A sample list of Private Attributes thought to be safe is provided here. Vendors do not guarantee them to be safe, and do not commit to sending them in any particular software version (including future products).

    Table E.3.10-1. Safe Private Attributes

    Data Element

    Private Creator

    VR

    VM

    Meaning

    (7053,xx00)

    Philips PET Private Group

    DS

    1

    SUV Factor - Multiplying Stored Pixel Values by Rescale Slope then this factor results in SUVbw in g/l

    (7053,xx09)

    Philips PET Private Group

    DS

    1

    Activity Concentration Factor - Multiplying Stored Pixel Values by Rescale Slope then this factor results in MBq/ml.

    (00E1,xx21)

    ELSCINT1

    DS

    1

    DLP

    (00E1,xx50)

    ELSCINT1

    DS

    1

    Acquisition Duration

    (01E1,xx26)

    ELSCINT1

    CS

    1

    Phantom Type

    (01F1,xx01)

    ELSCINT1

    CS

    1

    Acquisition Type

    (01F1,xx07)

    ELSCINT1

    DS

    1

    Table Velocity

    (01F1,xx26)

    ELSCINT1

    DS

    1

    Pitch

    (01F1,xx27)

    ELSCINT1

    DS

    1

    Rotation Time

    (0019,xx23)

    GEMS_ACQU_01

    DS

    1

    Table Speed [mm/rotation]

    (0019,xx24)

    GEMS_ACQU_01

    DS

    1

    Mid Scan Time [sec]

    (0019,xx27)

    GEMS_ACQU_01

    DS

    1

    Rotation Speed (Gantry Period)

    (0019,xx9E)

    GEMS_ACQU_01

    LO

    1

    Internal Pulse Sequence Name

    (0043,xx27)

    GEMS_PARM_01

    SH

    1

    Scan Pitch Ratio in the form "n.nnn:1"

    (0045,xx01)

    GEMS_HELIOS_01

    SS

    1

    Number of Macro Rows in Detector

    (0045,xx02)

    GEMS_HELIOS_01

    FL

    1

    Macro width at ISO Center

    (0903,xx10)

    GEIIS PACS

    US

    1

    Reject Image Flag

    (0903,xx11)

    GEIIS PACS

    US

    1

    Significant Flag

    (0903,xx12)

    GEIIS PACS

    US

    1

    Confidential Flag

    (2001,xx01)

    Philips Imaging DD 001

    FL

    1

    MR Image Chemical Shift

    (2001,xx02)

    Philips Imaging DD 001

    IS

    1

    MR Image Chemical Shift Number

    (2001,xx03)

    Philips Imaging DD 001

    FL

    1

    MR Image Diffusion B-Factor

    (2001,xx04)

    Philips Imaging DD 001

    CS

    1

    MR Image Diffusion Direction

    (2001,xx05)

    Philips Imaging DD 001

    SS

    1

    Graphic Annotation Parent ID

    (2001,xx06)

    Philips Imaging DD 001

    CS

    1

    MR Image Enhanced

    (2001,xx07)

    Philips Imaging DD 001

    CS

    1

    MR Image Type Edes

    (2001,xx08)

    Philips Imaging DD 001

    IS

    1

    MR Image Phase Number

    (2001,xx09)

    Philips Imaging DD 001

    FL

    1

    MR Image Prepulse Delay

    (2001,xx0a)

    Philips Imaging DD 001

    IS

    1

    Image Plane Number

    (2001,xx0b)

    Philips Imaging DD 001

    CS

    1

    Image Plane Orientation

    (2001,xx0c)

    Philips Imaging DD 001

    CS

    1

    MR Series Arrhythmia Rejection

    (2001,xx0e)

    Philips Imaging DD 001

    CS

    1

    MR Series Cardiac Cycled

    (2001,xx0f)

    Philips Imaging DD 001

    SS

    1

    MR Series Cardiac Gate Width

    (2001,xx10)

    Philips Imaging DD 001

    CS

    1

    MR Series Cardiac Sync

    (2001,xx11)

    Philips Imaging DD 001

    FL

    1

    MR Series Diffusion Echo Time

    (2001,xx12)

    Philips Imaging DD 001

    CS

    1

    MR Series Dynamic Series

    (2001,xx13)

    Philips Imaging DD 001

    SL

    1

    MR Series Epi Factor

    (2001,xx14)

    Philips Imaging DD 001

    SL

    1

    MR Series Nr Of Echoes

    (2001,xx15)

    Philips Imaging DD 001

    SS

    1

    MR Series Nr Of Locations

    (2001,xx16)

    Philips Imaging DD 001

    SS

    1

    MR Series Nr Of Phase Contrast Directions

    (2001,xx17)

    Philips Imaging DD 001

    SL

    1

    MR Series Nr Of Phases

    (2001,xx18)

    Philips Imaging DD 001

    SL

    1

    MR Series Nr Of Slices

    (2001,xx19)

    Philips Imaging DD 001

    CS

    1

    MR Series Partial Matrix Scanned

    (2001,xx1a)

    Philips Imaging DD 001

    FL

    3

    MR Series Pc Velocity

    (2001,xx1b)

    Philips Imaging DD 001

    FL

    1

    MR Series Prepulse Delay

    (2001,xx1c)

    Philips Imaging DD 001

    CS

    1

    MR Series Prepulse Type

    (2001,xx1d)

    Philips Imaging DD 001

    IS

    1

    MR Series Reconstruction Number

    (2001,xx1e)

    Philips Imaging DD 001

    CS

    1

    MR Series Reformat Accuracy

    (2001,xx1f)

    Philips Imaging DD 001

    CS

    1

    MR Series Respiration Sync

    (2001,xx21)

    Philips Imaging DD 001

    CS

    1

    MR Series Sel Part Inversion Recovery

    (2001,xx22)

    Philips Imaging DD 001

    FL

    1

    MR Series Water Fat Shift

    (2001,xx23)

    Philips Imaging DD 001

    DS

    1

    MR Series Flip Angle

    (2001,xx24)

    Philips Imaging DD 001

    CS

    1

    MR Series Is Interactive

    (2001,xx25)

    Philips Imaging DD 001

    SH

    1

    MR Series Echo Time Display

    (2001,xx26)

    Philips Imaging DD 001

    CS

    1

    Presentation State Subtraction Active

    (2001,xx27)

    Philips Imaging DD 001

    CS

    1

    Edge Enhancement Kernel Size

    (2001,xx28)

    Philips Imaging DD 001

    FL

    1

    Edge Enhancement Gain Factor Sub

    (2001,xx29)

    Philips Imaging DD 001

    FL

    1

    Edge Enhancement Gain Factor

    (2001,xx2a)

    Philips Imaging DD 001

    CS

    1

    Edge Enhancement Taste Adapt Sub

    (2001,xx2b)

    Philips Imaging DD 001

    CS

    1

    Edge Enhancement Taste Adapt

    (2001,xx2c)

    Philips Imaging DD 001

    FL

    1

    Harmonization Factor

    (2001,xx2d)

    Philips Imaging DD 001

    SS

    1

    Stack Number Of Slices

    (2001,xx2e)

    Philips Imaging DD 001

    CS

    1

    Harmonization Kernel Size

    (2001,xx2f)

    Philips Imaging DD 001

    FL

    1

    Harmonization Gain

    (2001,xx30)

    Philips Imaging DD 001

    UL

    1

    Log Subtraction Gain Step Taste

    (2001,xx31)

    Philips Imaging DD 001

    US

    1

    Mixing Nr Of Mask Image Numbers

    (2001,xx32)

    Philips Imaging DD 001

    FL

    1

    Stack Radial Angle

    (2001,xx33)

    Philips Imaging DD 001

    CS

    1

    Stack Radial Axis

    (2001,xx34)

    Philips Imaging DD 001

    CS

    1

    Mixing Mask Operation Type

    (2001,xx35)

    Philips Imaging DD 001

    SS

    1

    Stack Slice Number

    (2001,xx36)

    Philips Imaging DD 001

    CS

    1

    Stack Type

    (2001,xx37)

    Philips Imaging DD 001

    CS

    1

    Mixing Operation Type

    (2001,xx38)

    Philips Imaging DD 001

    FL

    1

    Overlay Mix Factor

    (2001,xx39)

    Philips Imaging DD 001

    FL

    1

    Overscan Factor

    (2001,xx3a)

    Philips Imaging DD 001

    CS

    1

    Pixel Shift

    (2001,xx3b)

    Philips Imaging DD 001

    FL

    4

    Pixel Shift Split Line Coordinates

    (2001,xx3c)

    Philips Imaging DD 001

    FL

    2

    Pixel Shift Shift Vectora

    (2001,xx3d)

    Philips Imaging DD 001

    UL

    1

    Contour Fill Color

    (2001,xx3e)

    Philips Imaging DD 001

    FL

    2

    Pixel Shift Shift Vectorb

    (2001,xx3f)

    Philips Imaging DD 001

    CS

    1

    Displayed Area Zoom Interpolation Meth

    (2001,xx40)

    Philips Imaging DD 001

    CS

    1

    Pixel Shift Split Screen

    (2001,xx41)

    Philips Imaging DD 001

    FL

    1

    Subtraction Land Marking Factor

    (2001,xx42)

    Philips Imaging DD 001

    CS

    1

    Subtraction Land Marking Active

    (2001,xx43)

    Philips Imaging DD 001

    IS

    2

    Ellips Displ Shut Major Ax Frst End Pnt

    (2001,xx44)

    Philips Imaging DD 001

    IS

    2

    Ellips Displ Shut Major Ax Scnd End Pnt

    (2001,xx45)

    Philips Imaging DD 001

    IS

    2

    Ellips Displ Shut Other Ax Frst End Pnt

    (2001,xx46)

    Philips Imaging DD 001

    CS

    1

    Graphic Line Style

    (2001,xx47)

    Philips Imaging DD 001

    FL

    1

    Graphic Line Width

    (2001,xx48)

    Philips Imaging DD 001

    SS

    1

    Graphic Annotation Id

    (2001,xx49)

    Philips Imaging DD 001

    IS

    1

    Trace First Image

    (2001,xx4a)

    Philips Imaging DD 001

    CS

    1

    Trace Taste

    (2001,xx4b)

    Philips Imaging DD 001

    CS

    1

    Interpolation Method

    (2001,xx4c)

    Philips Imaging DD 001

    CS

    1

    Poly Line Begin Point Style

    (2001,xx4d)

    Philips Imaging DD 001

    CS

    1

    Poly Line End Point Style

    (2001,xx4e)

    Philips Imaging DD 001

    CS

    1

    Window Smoothing Taste

    (2001,xx4f)

    Philips Imaging DD 001

    FD

    1

    Harmonization Offset

    (2001,xx50)

    Philips Imaging DD 001

    LO

    1

    Graphic Marker Type

    (2001,xx51)

    Philips Imaging DD 001

    IS

    1

    Overlay Plane Id

    (2001,xx53)

    Philips Imaging DD 001

    CS

    1

    Presentation Gl Trafo Invert

    (2001,xx54)

    Philips Imaging DD 001

    FL

    1

    Contour Fill Transparency

    (2001,xx55)

    Philips Imaging DD 001

    UL

    1

    Graphic Line Color

    (2001,xx56)

    Philips Imaging DD 001

    CS

    1

    Graphic Type

    (2001,xx57)

    Philips Imaging DD 001

    CS

    1

    Log Subtraction Taste

    (2001,xx58)

    Philips Imaging DD 001

    UL

    1

    Series Xray Contrast Transfer Taste

    (2001,xx59)

    Philips Imaging DD 001

    IS

    1

    Curve Id

    (2001,xx5a)

    Philips Imaging DD 001

    ST

    1

    Graphic Annotation Model

    (2001,xx5d)

    Philips Imaging DD 001

    ST

    1

    Measurement Text Units

    (2001,xx5e)

    Philips Imaging DD 001

    ST

    1

    Measurement Text Type

    (2001,xx5f)

    Philips Imaging DD 001

    SQ

    1-n

    Stack Sequence

    (2001,xx60)

    Philips Imaging DD 001

    SL

    1

    MR Series Nr Of Stacks

    (2001,xx61)

    Philips Imaging DD 001

    CS

    1

    Series Transmitted

    (2001,xx62)

    Philips Imaging DD 001

    CS

    1

    Series Committed

    (2001,xx63)

    Philips Imaging DD 001

    CS

    1

    Examination Source

    (2001,xx64)

    Philips Imaging DD 001

    SH

    1

    Text Type

    (2001,xx65)

    Philips Imaging DD 001

    SQ

    1-n

    Overlay Plane Sequence

    (2001,xx66)

    Philips Imaging DD 001

    SQ

    1-n

    Image Curve

    (2001,xx67)

    Philips Imaging DD 001

    CS

    1

    Linear Presentation Gl Trafo Shape Sub

    (2001,xx68)

    Philips Imaging DD 001

    SQ

    1-n

    Modality Gl Trafo Sequence

    (2001,xx69)

    Philips Imaging DD 001

    SQ

    1-n

    Display Shutter Sequence

    (2001,xx6a)

    Philips Imaging DD 001

    SQ

    1-n

    Spatial Transformation Sequence

    (2001,xx6b)

    Philips Imaging DD 001

    SQ

    1-n

    Edge Enhancement Sequence

    (2001,xx6d)

    Philips Imaging DD 001

    LO

    1

    Text Font

    (2001,xx6e)

    Philips Imaging DD 001

    SH

    1

    Series Type

    (2001,xx6f)

    Philips Imaging DD 001

    SQ

    1-n

    Mixing Sequence

    (2001,xx71)

    Philips Imaging DD 001

    CS

    1

    Graphic Constraint

    (2001,xx72)

    Philips Imaging DD 001

    IS

    2

    Ellips Displ Shut Other Ax Scnd End Pnt

    (2001,xx73)

    Philips Imaging DD 001

    SQ

    1-n

    Referenced Mask Image Sequence

    (2001,xx74)

    Philips Imaging DD 001

    DS

    1-n

    Window Center Sub

    (2001,xx75)

    Philips Imaging DD 001

    DS

    1-n

    Window Width Sub

    (2001,xx76)

    Philips Imaging DD 001

    UL

    1

    Presentation State Xray Contrast Transfer Taste

    (2001,xx77)

    Philips Imaging DD 001

    CS

    1

    Gl Trafo Type

    (2001,xx79)

    Philips Imaging DD 001

    SQ

    1-n

    Harmonisation Sequence

    (2001,xx7a)

    Philips Imaging DD 001

    FL

    1

    Window Rounding Factor

    (2001,xx7b)

    Philips Imaging DD 001

    IS

    1

    MR Series Acquisition Number

    (2001,xx7c)

    Philips Imaging DD 001

    UL

    1

    Frame Number

    (2001,xx7d)

    Philips Imaging DD 001

    OW/OB

    1

    Frame Pixel Data

    (2001,xx7e)

    Philips Imaging DD 001

    US

    1

    Edge Enhancement Gain Taste

    (2001,xx7f)

    Philips Imaging DD 001

    US

    1

    Edge Enhancement Gain Taste Sub

    (2001,xx80)

    Philips Imaging DD 001

    LO

    1

    Text Anchor Point Alignment

    (2001,xx81)

    Philips Imaging DD 001

    IS

    1

    MR Series Nr Of Dynamic Scans

    (2001,xx82)

    Philips Imaging DD 001

    IS

    1

    MR Series Echo Train Length

    (2001,xx83)

    Philips Imaging DD 001

    DS

    1

    MR Series Imaging Frequency

    (2001,xx84)

    Philips Imaging DD 001

    DS

    1

    MR Series Inversion Time

    (2001,xx85)

    Philips Imaging DD 001

    DS

    1

    MR Series Magnetic Field Strength

    (2001,xx86)

    Philips Imaging DD 001

    IS

    1

    MR Series Nr Of Phase Encoding Steps

    (2001,xx87)

    Philips Imaging DD 001

    SH

    1

    MR Series Nucleus

    (2001,xx88)

    Philips Imaging DD 001

    DS

    1

    MR Series Number Of Averages

    (2001,xx89)

    Philips Imaging DD 001

    DS

    1

    MR Series Percent Phase Field Of View

    (2001,xx8a)

    Philips Imaging DD 001

    DS

    1

    MR Series Percent Sampling

    (2001,xx8b)

    Philips Imaging DD 001

    SH

    1

    MR Series Transmitting Coil

    (2001,xx8c)

    Philips Imaging DD 001

    CS

    0-n

    Needs Processing

    (2001,xx90)

    Philips Imaging DD 001

    LO

    1

    Text Foreground Color

    (2001,xx91)

    Philips Imaging DD 001

    LO

    1

    Text Background Color

    (2001,xx92)

    Philips Imaging DD 001

    LO

    1

    Text Shadow Color

    (2001,xx93)

    Philips Imaging DD 001

    LO

    1

    Text Style

    (2001,xx94)

    Philips Imaging DD 001

    LO

    1

    Processing Order Specialization

    (2001,xx9a)

    Philips Imaging DD 001

    SQ

    1-n

    Graphic Number Sequence

    (2001,xx9b)

    Philips Imaging DD 001

    UL

    1

    Graphic Number

    (2001,xx9d)

    Philips Imaging DD 001

    LO

    1

    Subtraction Type

    (2001,xx9f)

    Philips Imaging DD 001

    US

    2

    Pixel Processing Kernel Size

    (2001,xxa1)

    Philips Imaging DD 001

    CS

    1

    Is Raw Image

    (2001,xxa2)

    Philips Imaging DD 001

    US

    1

    Log Subtraction Curve Taste

    (2001,xxa3)

    Philips Imaging DD 001

    UL

    1

    Text Color Foreground

    (2001,xxa4)

    Philips Imaging DD 001

    UL

    1

    Text Color Background

    (2001,xxa5)

    Philips Imaging DD 001

    UL

    1

    Text Color Shadow

    (2001,xxc0)

    Philips Imaging DD 001

    UL

    1

    Content Item Identifier

    (2001,xxc1)

    Philips Imaging DD 001

    LO

    1

    Nested Object Type Name

    (2001,xxc2)

    Philips Imaging DD 001

    FD

    1

    Subtraction Rescale Factor

    (2001,xxc3)

    Philips Imaging DD 001

    UL

    1

    Subtraction Offset

    (2001,xxc5)

    Philips Imaging DD 001

    SQ

    0-1

    Mask Image Lut Sequence

    (2001,xxc6)

    Philips Imaging DD 001

    SQ

    0-1

    Gain Lut Sequence

    (2001,xxc7)

    Philips Imaging DD 001

    SQ

    0-1

    Contrast Image Lut Sequence

    (2001,xxca)

    Philips Imaging DD 001

    SQ

    1

    Reversed Modality Lut

    (2001,xxcb)

    Philips Imaging DD 001

    IS

    1

    Redundant Overlay Plane Id

    (2001,xxd0)

    Philips Imaging DD 001

    AT

    1-n

    Frame Index Pointer

    (2001,xxd1)

    Philips Imaging DD 001

    US

    1-n

    Index Number Vector

    (2001,xxd2)

    Philips Imaging DD 001

    US

    1

    Frame Detector Number

    (2001,xxd3)

    Philips Imaging DD 001

    US

    1

    Frame Phase Number

    (2001,xxd4)

    Philips Imaging DD 001

    US

    1

    Frame Rotation Number

    (2001,xxd5)

    Philips Imaging DD 001

    US

    1

    Frame Rr Interval Number

    (2001,xxd6)

    Philips Imaging DD 001

    US

    1

    Frame Time Slot Number

    (2001,xxd7)

    Philips Imaging DD 001

    US

    1

    Frame Slice Number

    (2001,xxd8)

    Philips Imaging DD 001

    US

    1

    Frame Angular View Number

    (2001,xxd9)

    Philips Imaging DD 001

    US

    1

    Frame Time Slice Number

    (2001,xxda)

    Philips Imaging DD 001

    CS

    1

    Is Arrowhead

    (2001,xxdb)

    Philips Imaging DD 001

    US

    1

    PET Rr Interval Index

    (2001,xxdc)

    Philips Imaging DD 001

    US

    1

    PET Time Slot Index

    (2001,xxdd)

    Philips Imaging DD 001

    US

    1

    PET Time Slice Index

    (2001,xxde)

    Philips Imaging DD 001

    US

    1

    PET Slice Index

    (2001,xxdf)

    Philips Imaging DD 001

    UL

    1

    Voxel Number

    (2001,xxe9)

    Philips Imaging DD 001

    SQ

    0-n

    Per Frame Voxels Functional Group

    (2001,xxf1)

    Philips Imaging DD 001

    FL

    6

    MR Image Prospective Motion Correction

    (2001,xxf2)

    Philips Imaging DD 001

    FL

    1-n

    MR Image Retrospective Motion Correction

    (2001,xxf3)

    Philips Imaging DD 001

    CS

    1

    Dynamic Linear Voigl Trafo

    (2001,xxf4)

    Philips Imaging DD 001

    UL

    1

    Color Key

    (2001,xxf5)

    Philips Imaging DD 001

    CS

    1

    Rotated Text Allowed

    (2001,xxf6)

    Philips Imaging DD 001

    UL

    1

    Number Of Represented Images

    (2001,xxf7)

    Philips Imaging DD 001

    LO

    0-n

    Data Type Icons

    (2001,xxf9)

    Philips Imaging DD 001

    SQ

    0-n

    Flagging Sequence

    (2001,xxfb)

    Philips Imaging DD 001

    SQ

    0-1

    Bookmark Sequence

    (2001,xxfc)

    Philips Imaging DD 001

    SQ

    0-1

    Ris Code Sequence

    (2001,xxfd)

    Philips Imaging DD 001

    SQ

    0-n

    Workflow Step Sequence

    (2001,xxff)

    Philips Imaging DD 001

    OW/OB

    1

    Volume Pixel

    (2001,xx01)

    Philips Imaging DD 002

    US

    1

    Edr Setgp

    (2001,xx02)

    Philips Imaging DD 002

    FD

    1

    Edr Setsk

    (2001,xx03)

    Philips Imaging DD 002

    CS

    1

    Um Rank Type

    (2001,xx04)

    Philips Imaging DD 002

    SS

    1

    Um Rank Number

    (2001,xx05)

    Philips Imaging DD 002

    FD

    1

    Um Rank Enhancement

    (2001,xx06)

    Philips Imaging DD 002

    US

    1

    Um Kernel Size

    (2001,xx07)

    Philips Imaging DD 002

    CS

    1

    Um Gamma Type

    (2001,xx08)

    Philips Imaging DD 002

    FD

    1

    Um Gamma Angle

    (2001,xx09)

    Philips Imaging DD 002

    FD

    1

    Um Gamma Shift

    (2001,xx0a)

    Philips Imaging DD 002

    FD

    1

    Um Gamma Center

    (2001,xx0b)

    Philips Imaging DD 002

    FD

    1

    Drr Contrast Equalization

    (2001,xx0c)

    Philips Imaging DD 002

    US

    1

    Drr Contrast Equalization Kernel Size

    (2001,xx0d)

    Philips Imaging DD 002

    CS

    1

    Drr Sharp Lut Type

    (2001,xx0e)

    Philips Imaging DD 002

    FD

    1

    Drr Sharpening

    (2001,xx0f)

    Philips Imaging DD 002

    US

    1

    Drr Sharp Kernel Size

    (2001,xx10)

    Philips Imaging DD 002

    SS

    1

    Drr Window Width

    (2001,xx11)

    Philips Imaging DD 002

    SS

    1

    Drr Window Level

    (2001,xx12)

    Philips Imaging DD 002

    CS

    1

    Drr Lut Type

    (2001,xx13)

    Philips Imaging DD 002

    SS

    1

    Unique Processing Mode

    (2001,xx14)

    Philips Imaging DD 002

    FD

    1

    Unique Contrast Balance

    (2001,xx15)

    Philips Imaging DD 002

    FD

    1

    Unique Center Density

    (2001,xx16)

    Philips Imaging DD 002

    FD

    1

    Unique Bright Density

    (2001,xx17)

    Philips Imaging DD 002

    FD

    1

    Unique Detail Contrast

    (2001,xx18)

    Philips Imaging DD 002

    CS

    1

    Unique Density Curve

    (2001,xx19)

    Philips Imaging DD 002

    FD

    1

    Unique Density Min

    (2001,xx1a)

    Philips Imaging DD 002

    FD

    1

    Unique Density Max

    (2001,xx1b)

    Philips Imaging DD 002

    FD

    1

    Unique Gamma

    (2001,xx1c)

    Philips Imaging DD 002

    FD

    1

    Unique Gamma Min

    (2001,xx1d)

    Philips Imaging DD 002

    FD

    1

    Unique Gamma Max

    (2001,xx1e)

    Philips Imaging DD 002

    FD

    1

    Unique Structure Preference

    (2001,xx1f)

    Philips Imaging DD 002

    FD

    1

    Unique Noise Limit

    (2001,xx20)

    Philips Imaging DD 002

    FD

    1

    Unique Noise Band

    (2001,xx21)

    Philips Imaging DD 002

    FD

    1

    Unique Noise Step

    (2001,xx22)

    Philips Imaging DD 002

    FD

    1

    Unique Noise Compensation

    (2001,xx23)

    Philips Imaging DD 002

    FD

    1

    Unique Structure Boost

    (2001,xx24)

    Philips Imaging DD 002

    FD

    1

    Unique Strong Contrast Limit

    (2001,xx25)

    Philips Imaging DD 002

    FD

    1

    Unique Strong Contrast Factor

    (2001,xx26)

    Philips Imaging DD 002

    FD

    1

    Unique Structure Boost Offset

    (2001,xx27)

    Philips Imaging DD 002

    FD

    1

    Unique Weak Contrast Limit

    (2001,xx28)

    Philips Imaging DD 002

    US

    1

    Unique Smooth Gain

    (2001,xx29)

    Philips Imaging DD 002

    US

    1

    Unique Level

    (2001,xx2a)

    Philips Imaging DD 002

    US

    1

    Unique Gain Up Single

    (2001,xx2b)

    Philips Imaging DD 002

    SS

    1

    Unique Smh Limit One

    (2001,xx2c)

    Philips Imaging DD 002

    FD

    1

    Unique Film Density Min

    (2001,xx2d)

    Philips Imaging DD 002

    FD

    1

    Unique Film Density Max

    (2001,xx2e)

    Philips Imaging DD 002

    SS

    1

    Unique Version

    (2001,xx2f)

    Philips Imaging DD 002

    SS

    1

    Ranger Version

    (2001,xx30)

    Philips Imaging DD 002

    SS

    1

    Ranger Mode

    (2001,xx31)

    Philips Imaging DD 002

    SS

    1

    Ranger Field1

    (2001,xx32)

    Philips Imaging DD 002

    SS

    1

    Ranger Field2

    (2001,xx33)

    Philips Imaging DD 002

    SS

    1

    Ranger Percentile Key1

    (2001,xx34)

    Philips Imaging DD 002

    SS

    1

    Ranger Percentile Key2

    (2001,xx35)

    Philips Imaging DD 002

    FD

    1

    Ranger Dose1

    (2001,xx36)

    Philips Imaging DD 002

    FD

    1

    Ranger Dose2

    (2001,xx37)

    Philips Imaging DD 002

    FD

    1

    Ranger Manual Dose1

    (2001,xx38)

    Philips Imaging DD 002

    FD

    1

    Ranger Manual Dose2

    (2001,xx39)

    Philips Imaging DD 002

    CS

    1

    Unique Rox Shape

    (2001,xx3a)

    Philips Imaging DD 002

    SQ

    1

    Ranger Set Sequence

    (2001,xx3b)

    Philips Imaging DD 002

    SQ

    0-n

    Rox Sequence

    (2001,xx3c)

    Philips Imaging DD 002

    SQ

    1-n

    Xray Edge Enhancement Sequence

    (2001,xx3d)

    Philips Imaging DD 002

    SQ

    0-1

    Edr Lut Sequence

    (2001,xx3e)

    Philips Imaging DD 002

    SS

    1

    Unique Dose Decades

    (2001,xx3f)

    Philips Imaging DD 002

    SS

    1

    Unique Dose Unit

    (2001,xx40)

    Philips Imaging DD 002

    SS

    1

    Unique Density Unit

    (2001,xx50)

    Philips Imaging DD 002

    CS

    1

    Workflow Status

    (2001,xx52)

    Philips Imaging DD 002

    LO

    1

    Workflow Step Id

    (2001,xx53)

    Philips Imaging DD 002

    CS

    1

    Workflow Step Status

    (2001,xx57)

    Philips Imaging DD 002

    SQ

    0-1

    Workflow Step Input Sequence

    (2001,xx58)

    Philips Imaging DD 002

    SQ

    0-1

    Workflow Step Output Sequence

    (2001,xx5a)

    Philips Imaging DD 002

    LO

    1

    Workflow Step Type

    (2001,xx5c)

    Philips Imaging DD 002

    LO

    1

    Workflow Id

    (2001,xx5d)

    Philips Imaging DD 002

    UL

    1

    Pixel Data Representation Rows

    (2001,xx5e)

    Philips Imaging DD 002

    UL

    1

    Pixel Data Representation Columns

    (2001,xx5f)

    Philips Imaging DD 002

    SQ

    0-1

    Private Dicom Extension Sequence

    (2001,xx63)

    Philips Imaging DD 002

    ST

    1

    Isyntax Reference

    (2001,xx64)

    Philips Imaging DD 002

    SQ

    0-1

    Workflow Step Job Params Sequence

    (2001,xx65)

    Philips Imaging DD 002

    CS

    1

    Preserve Aspect

    (2001,xx66)

    Philips Imaging DD 002

    CS

    1

    Interpolated

    (2001,xx67)

    Philips Imaging DD 002

    LO

    1

    Error Flag

    (2001,xx68)

    Philips Imaging DD 002

    LO

    1

    Error Message Id

    (2001,xx6b)

    Philips Imaging DD 002

    LO

    0-n

    Suitable For

    (2001,xx71)

    Philips Imaging DD 002

    CS

    1

    Submit Mpps Job

    (2001,xx72)

    Philips Imaging DD 002

    FL

    2

    Displayed Area Bottom Right Hand Corner Fraction

    (2001,xx73)

    Philips Imaging DD 002

    FL

    2

    Displayed Area Top Left Hand Corner Fraction

    (2001,xx74)

    Philips Imaging DD 002

    LO

    1

    Interpolation Mode

    (2001,xx75)

    Philips Imaging DD 002

    SS

    0-n

    Graphic Annotation Id Reference

    (2001,xx01)

    Philips Imaging DD 097

    SQ

    1

    View Geometry

    (2001,xx02)

    Philips Imaging DD 097

    FD

    3

    Frame Geometry Origin

    (2001,xx03)

    Philips Imaging DD 097

    FD

    2

    Frame Geometry Extent

    (2001,xx04)

    Philips Imaging DD 097

    FD

    6

    Frame Geometry Orientation

    (2001,xx05)

    Philips Imaging DD 097

    SQ

    1-n

    Visual Sequence

    (2001,xx06)

    Philips Imaging DD 097

    SQ

    0-n

    Cut Sequence

    (2001,xx07)

    Philips Imaging DD 097

    FD

    1

    Visual Opacity

    (2001,xx08)

    Philips Imaging DD 097

    SQ

    1

    Opacity Map Sequence

    (2001,xx0a)

    Philips Imaging DD 097

    SQ

    1-n

    Light Sequence

    (2001,xx0b)

    Philips Imaging DD 097

    SQ

    1

    Color Map Sequence

    (2001,xx0d)

    Philips Imaging DD 097

    FD

    1

    Visual Threshold

    (2001,xx0e)

    Philips Imaging DD 097

    SQ

    0-n

    Scene Sequence

    (2001,xx0f)

    Philips Imaging DD 097

    FD

    2

    Frame Geometry Slab

    (2001,xx12)

    Philips Imaging DD 097

    SQ

    1

    Gradient Map Sequence

    (2001,xx17)

    Philips Imaging DD 097

    US

    1

    Display Rows

    (2001,xx18)

    Philips Imaging DD 097

    US

    1

    Display Columns

    (2001,xx19)

    Philips Imaging DD 097

    LO

    1

    Frame Geometry Type

    (2001,xx1a)

    Philips Imaging DD 097

    FD

    1

    Light Intensity

    (2001,xx1b)

    Philips Imaging DD 097

    UL

    1

    Light Color

    (2001,xx1c)

    Philips Imaging DD 097

    FD

    3

    Light Origin

    (2001,xx1d)

    Philips Imaging DD 097

    FD

    3

    Light Direction

    (2001,xx1e)

    Philips Imaging DD 097

    FD

    4-n

    Color Map Samples

    (2001,xx1f)

    Philips Imaging DD 097

    FD

    2-n

    Opacity Map Samples

    (2001,xx21)

    Philips Imaging DD 097

    UL

    1

    Visual Color

    (2001,xx22)

    Philips Imaging DD 097

    FD

    1

    Illumination Ambient

    (2001,xx23)

    Philips Imaging DD 097

    FD

    1

    Illumination Diffuse

    (2001,xx24)

    Philips Imaging DD 097

    FD

    1

    Illumination Specular

    (2001,xx25)

    Philips Imaging DD 097

    FD

    1

    Illumination Specular Power

    (2001,xx26)

    Philips Imaging DD 097

    FD

    1

    Depth Cue Begin

    (2001,xx27)

    Philips Imaging DD 097

    FD

    1

    Depth Cue Lambda

    (2001,xx28)

    Philips Imaging DD 097

    LO

    1

    Depth Cue Function

    (2001,xx2a)

    Philips Imaging DD 097

    LO

    1

    Cut Set Type

    (2001,xx2b)

    Philips Imaging DD 097

    FD

    3

    Cut Plane Origin

    (2001,xx2c)

    Philips Imaging DD 097

    FD

    3

    Cut Plane Normal

    (2001,xx2d)

    Philips Imaging DD 097

    UL

    1

    Volume Definition Number

    (2001,xx2e)

    Philips Imaging DD 097

    SQ

    0-1

    Volume Mask Sequence

    (2001,xx2f)

    Philips Imaging DD 097

    OB

    1

    Volume Mask Data

    (2001,xx30)

    Philips Imaging DD 097

    SL

    3

    Volume Mask Offset

    (2001,xx31)

    Philips Imaging DD 097

    SL

    3

    Volume Mask Size

    (2001,xx32)

    Philips Imaging DD 097

    SL

    2

    Volume Mask Alignment

    (2001,xx36)

    Philips Imaging DD 097

    LO

    1

    Light Anchor

    (2001,xx37)

    Philips Imaging DD 097

    FD

    3

    Cone Geometry Origin

    (2001,xx38)

    Philips Imaging DD 097

    FD

    9

    Cone Geometry Orientation

    (2001,xx39)

    Philips Imaging DD 097

    FD

    1

    Cone Geometry View Distance

    (2001,xx3a)

    Philips Imaging DD 097

    FD

    2

    Cone Geometry Slab Extent

    (2001,xx3b)

    Philips Imaging DD 097

    FD

    2

    Cone Geometry Field Of View

    (2001,xx3c)

    Philips Imaging DD 097

    SQ

    1

    Intensity Map Sequence

    (2001,xx3d)

    Philips Imaging DD 097

    FD

    1-n

    Intensity Map Samples

    (2001,xx3e)

    Philips Imaging DD 097

    SQ

    0-n

    Mesh Sequence

    (2001,xx40)

    Philips Imaging DD 097

    UL

    1

    Mesh Color

    (2001,xx41)

    Philips Imaging DD 097

    LO

    1

    Mesh Draw Style

    (2001,xx42)

    Philips Imaging DD 097

    SQ

    0-n

    Mesh Section Sequence

    (2001,xx44)

    Philips Imaging DD 097

    LO

    1

    Mesh Section Vertex Connectivity

    (2001,xx45)

    Philips Imaging DD 097

    SL

    1

    Mesh Section Vertex Size

    (2001,xx46)

    Philips Imaging DD 097

    LO

    1

    Mesh Section Vertex Format

    (2001,xx47)

    Philips Imaging DD 097

    OB

    1-n

    Mesh Section Vertex Data

    (2001,xx49)

    Philips Imaging DD 097

    SQ

    1

    Referenced Volume Definition Sequence

    (2001,xx4a)

    Philips Imaging DD 097

    OB

    1-n

    Mesh Section Index Data

    (2001,xx4b)

    Philips Imaging DD 097

    SL

    1

    Mesh Section Index Size

    (2001,xx4c)

    Philips Imaging DD 097

    LO

    1

    Shutter Interaction Type

    (2001,xxa1)

    Philips Imaging DD 097

    CS

    1-2

    Volume Type

    (2001,xxa2)

    Philips Imaging DD 097

    FD

    3

    Volume Origin

    (2001,xxa3)

    Philips Imaging DD 097

    FD

    9

    Volume Axis

    (2001,xxa4)

    Philips Imaging DD 097

    FD

    2

    Volume Pixel Spacing

    (2001,xxa5)

    Philips Imaging DD 097

    FD

    1-n

    Volume Slice Spacing

    (2001,xxa6)

    Philips Imaging DD 097

    US

    1

    Volume Slices

    (2001,xxa8)

    Philips Imaging DD 097

    IS

    1-n

    Referenced Volume Definition Number

    (2001,xxa9)

    Philips Imaging DD 097

    SQ

    0-n

    Linear Modality Gl Trafo Sequence

    (2001,xxaa)

    Philips Imaging DD 097

    FD

    1-n

    Volume Slice Offsets

    (2001,xxab)

    Philips Imaging DD 097

    IS

    1

    Number Of Volume Definitions

    (2001,xx00)

    Philips Imaging DD 129

    SQ

    1

    Presentation State Sequence

    (2001,xx01)

    Philips Imaging DD 129

    SQ

    1

    Embedded Original Presentation State Sequence

    (2001,xx02)

    Philips Imaging DD 129

    SQ

    0-1

    Planar Intersection Sequence

    (2001,xx03)

    Philips Imaging DD 129

    UL

    1

    Plane Separator Line Color

    (2001,xx04)

    Philips Imaging DD 129

    SQ

    1-n

    Plane Sequence

    (2001,xx05)

    Philips Imaging DD 129

    FD

    4

    Plane Equation

    (2001,xx06)

    Philips Imaging DD 129

    FD

    1

    Plane Opacity

    (2001,xx07)

    Philips Imaging DD 129

    CS

    1

    Plane Enabled

    (2001,xx08)

    Philips Imaging DD 129

    CS

    1

    Plane Selected

    (2001,xx09)

    Philips Imaging DD 129

    UL

    1

    Plane Highlight Color

    (0025,xx01)

    Philips ST80i

    OW

    1

    ST80i Stress Study file data

    (0019,xx0C)

    SIEMENS MR HEADER

    IS

    1

    B Value

    (0019,xx0D)

    SIEMENS MR HEADER

    CS

    1

    Diffusion Directionality

    (0019,xx0E)

    SIEMENS MR HEADER

    FD

    3

    Diffusion Gradient Direction

    (0019,xx27)

    SIEMENS MR HEADER

    FD

    6

    B Matrix

    (0043,xx39)

    GEMS_PARM_01

    IS

    4

    1stvalue is B Value

    (0043,xx6F)

    GEMS_PARM_01

    DS

    3-4

    Scanner Table Entry + Gradient Coil Selected

    (0025,xx07)

    GEMS_SERS_01

    SL

    1

    Images in Series

    (7E01,xx01)

    HOLOGIC, Inc.

    LO

    1

    Codec Version

    (7E01,xx02)

    HOLOGIC, Inc.

    SH

    1

    Codec Content Type

    (7E01,xx10)

    HOLOGIC, Inc.

    SQ

    1

    High Resolution Data Sequence

    (7E01,xx11)

    HOLOGIC, Inc.

    SQ

    1

    Low Resolution Data Sequence

    (7E01,xx12)

    HOLOGIC, Inc.

    OB

    1

    Codec Content

    (0099,xx01)

    NQHeader

    UI

    1

    Version

    (0099,xx02)

    NQHeader

    UI

    1

    Analyzed Series UID

    (0099,xx04)

    NQHeader

    SS

    1

    Return Code

    (0099,xx05)

    NQHeader

    LT

    1

    Return Message

    (0099,xx10)

    NQHeader

    FL

    1

    MI

    (0099,xx20)

    NQHeader

    SH

    1

    Units

    (0099,xx21)

    NQHeader

    FL

    1

    ICV

    (0199,xx01)

    NQLeft

    FL

    1

    Left Cortical White Matter

    (0199,xx02)

    NQLeft

    FL

    1

    Left Cortical Gray Matter

    (0199,xx03)

    NQLeft

    FL

    1

    Left 3rd Ventricle

    (0199,xx04)

    NQLeft

    FL

    1

    Left 4th Ventricle

    (0199,xx05)

    NQLeft

    FL

    1

    Left 5th Ventricle

    (0199,xx06)

    NQLeft

    FL

    1

    Left Lateral Ventricle

    (0199,xx07)

    NQLeft

    FL

    1

    Left Inferior Lateral Ventricle

    (0199,xx08)

    NQLeft

    FL

    1

    Left Inferior CSF

    (0199,xx09)

    NQLeft

    FL

    1

    Left Cerebellar White Matter

    (0199,xx0a)

    NQLeft

    FL

    1

    Left Cerebellar Gray Matter

    (0199,xx0b)

    NQLeft

    FL

    1

    Left Hippocampus

    (0199,xx0c)

    NQLeft

    FL

    1

    Left Amygdala

    (0199,xx0d)

    NQLeft

    FL

    1

    Left Thalamus

    (0199,xx0e)

    NQLeft

    FL

    1

    Left Caudate

    (0199,xx0f)

    NQLeft

    FL

    1

    Left Putamen

    (0199,xx10)

    NQLeft

    FL

    1

    Left Pallidum

    (0199,xx11)

    NQLeft

    FL

    1

    Left Ventral Diencephalon

    (0199,xx12)

    NQLeft

    FL

    1

    Left Nucleus Accumbens

    (0199,xx13)

    NQLeft

    FL

    1

    Left Brain Stem

    (0199,xx14)

    NQLeft

    FL

    1

    Left Exterior CSF

    (0199,xx15)

    NQLeft

    FL

    1

    Left WM Hypo

    (0199,xx16)

    NQLeft

    FL

    1

    Left Other

    (0299,xx01)

    NQRight

    FL

    1

    Right Cortical White Matter

    (0299,xx02)

    NQRight

    FL

    1

    Right Cortical Gray Matter

    (0299,xx03)

    NQRight

    FL

    1

    Right 3rd Ventricle

    (0299,xx04)

    NQRight

    FL

    1

    Right 4th Ventricle

    (0299,xx05)

    NQRight

    FL

    1

    Right 5th Ventricle

    (0299,xx06)

    NQRight

    FL

    1

    Right Lateral Ventricle

    (0299,xx07)

    NQRight

    FL

    1

    Right Inferior Lateral Ventricle

    (0299,xx08)

    NQRight

    FL

    1

    Right Inferior CSF

    (0299,xx09)

    NQRight

    FL

    1

    Right Cerebellar White Matter

    (0299,xx0a)

    NQRight

    FL

    1

    Right Cerebellar Gray Matter

    (0299,xx0b)

    NQRight

    FL

    1

    Right Hippocampus

    (0299,xx0c)

    NQRight

    FL

    1

    Right Amygdala

    (0299,xx0d)

    NQRight

    FL

    1

    Right Thalamus

    (0299,xx0e)

    NQRight

    FL

    1

    Right Caudate

    (0299,xx0f)

    NQRight

    FL

    1

    Right Putamen

    (0299,xx10)

    NQRight

    FL

    1

    Right Pallidum

    (0299,xx11)

    NQRight

    FL

    1

    Right Ventral Diencephalon

    (0299,xx12)

    NQRight

    FL

    1

    Right Nucleus Accumbens

    (0299,xx13)

    NQRight

    FL

    1

    Right Brain Stem

    (0299,xx14)

    NQRight

    FL

    1

    Right Exterior CSF

    (0299,xx15)

    NQRight

    FL

    1

    Right WM Hypo

    (0299,xx16)

    NQRight

    FL

    1

    Right Other

    (2005,xx0D)

    Philips MR Imaging DD 001

    FL

    1

    Scale Intercept

    (2005,xx0E)

    Philips MR Imaging DD 001

    FL

    1

    Scale Slope

    (0119,xx00)

    SIEMENS Ultrasound SC2000

    LO

    1

    Acoustic Meta Information Version

    (0119,xx01)

    SIEMENS Ultrasound SC2000

    OB

    1

    Common Acoustic Meta Information

    (0119,xx02)

    SIEMENS Ultrasound SC2000

    SQ

    1

    Multi Stream Sequence

    (0119,xx03)

    SIEMENS Ultrasound SC2000

    SQ

    1

    Acoustic Data Sequence

    (0119,xx04)

    SIEMENS Ultrasound SC2000

    OB

    1

    Per Transaction Acoustic Control Information

    (0119,xx05)

    SIEMENS Ultrasound SC2000

    UL

    1

    Acoustic Data Offset

    (0119,xx06)

    SIEMENS Ultrasound SC2000

    UL

    1

    Acoustic Data Length

    (0119,xx07)

    SIEMENS Ultrasound SC2000

    UL

    1

    Footer Offset

    (0119,xx08)

    SIEMENS Ultrasound SC2000

    UL

    1

    Footer Length

    (0119,xx09)

    SIEMENS Ultrasound SC2000

    SS

    1

    Acoustic Stream Number

    (0119,xx10)

    SIEMENS Ultrasound SC2000

    SH

    1

    Acoustic Stream Type

    (0119,xx11)

    SIEMENS Ultrasound SC2000

    1

    Stage Timer Time

    (0119,xx12)

    SIEMENS Ultrasound SC2000

    1

    Stop Watch Time

    (0119,xx13)

    SIEMENS Ultrasound SC2000

    IS

    1

    Volume Rate

    (0119,xx21)

    SIEMENS Ultrasound SC2000

    SH

    1

    (0129,xx00)

    SIEMENS Ultrasound SC2000

    SQ

    1

    MPR View Sequence

    (0129,xx02)

    SIEMENS Ultrasound SC2000

    UI

    1

    Bookmark UID

    (0129,xx03)

    SIEMENS Ultrasound SC2000

    1

    Plane Origin Vector

    (0129,xx04)

    SIEMENS Ultrasound SC2000

    1

    Row Vector

    (0129,xx05)

    SIEMENS Ultrasound SC2000

    1

    Column Vector

    (0129,xx06)

    SIEMENS Ultrasound SC2000

    SQ

    1

    Visualization Sequence

    (0129,xx07)

    SIEMENS Ultrasound SC2000

    UI

    1

    Bookmark UID

    (0129,xx08)

    SIEMENS Ultrasound SC2000

    OB

    1

    Visualization Information

    (0129,xx09)

    SIEMENS Ultrasound SC2000

    SQ

    1

    Application State Sequence

    (0129,xx10)

    SIEMENS Ultrasound SC2000

    OB

    1

    Application State Information

    (0129,xx11)

    SIEMENS Ultrasound SC2000

    SQ

    1

    Referenced Bookmark Sequence

    (0129,xx12)

    SIEMENS Ultrasound SC2000

    UI

    1

    Referenced Bookmark UID

    (0129,xx20)

    SIEMENS Ultrasound SC2000

    SQ

    1

    Cine Parameters Sequence

    (0129,xx21)

    SIEMENS Ultrasound SC2000

    OB

    1

    Cine Parameters Schema

    (0129,xx22)

    SIEMENS Ultrasound SC2000

    OB

    1

    Values of Cine Parameters

    (0129,xx29)

    SIEMENS Ultrasound SC2000

    OB

    1

    (0129,xx30)

    SIEMENS Ultrasound SC2000

    CS

    1

    Raw Data Object Type

    (0139,xx01)

    SIEMENS Ultrasound SC2000

    SL

    1

    Physio Capture ROI

    (0149,xx01)

    SIEMENS Ultrasound SC2000

    FD

    1-n

    Vector of BROI Points

    (0149,xx02)

    SIEMENS Ultrasound SC2000

    FD

    1-n

    Start/End Timestamps of Strip Stream

    (0149,xx03)

    SIEMENS Ultrasound SC2000

    FD

    1-n

    Timestamps of Visible R-waves

    (7FD1,xx01)

    SIEMENS Ultrasound SC2000

    OB

    1

    Acoustic Image and Footer Data

    (7FD1,xx09)

    SIEMENS Ultrasound SC2000

    UI

    1

    Volume Version ID

    (7FD1,xx10)

    SIEMENS Ultrasound SC2000

    OB

    1

    Volume Payload

    (7FD1,xx11)

    SIEMENS Ultrasound SC2000

    OB

    1

    After Payload

    (7FD1,xx01)

    SIEMENS SYNGO ULTRA-SOUND TOYON DATA STREAMING

    OB

    1

    Padding

    (7FD1,xx09)

    SIEMENS SYNGO ULTRA-SOUND TOYON DATA STREAMING

    UI

    1

    Version ID

    (7FD1,xx10)

    SIEMENS SYNGO ULTRA-SOUND TOYON DATA STREAMING

    OB

    1

    Volume Payload

    (7FD1,xx11)

    SIEMENS SYNGO ULTRA-SOUND TOYON DATA STREAMING

    OB

    1

    After Payload

  2. One approach to retaining Private Attributes safely, either when the VR is encoded explicitly or known from a data dictionary (such as may be derived from published DICOM Conformance Statements or previously encountered instances, perhaps by adaptively extending the data dictionary as new explicit VR instances are received), is to retain those Attributes that are numeric only. For example, one might retain US, SS, UL, SS, FL and FD binary Values, and IS and DS string Values that contain only valid numeric characters. One might assume that other string Value Representations are unsafe in the absence of definite confirmation from the vendor to the contrary; code strings (CS) may be an exception. Bulk binary data in OB Value representations is particularly unsafe, and may often contain entire proprietary format headers in binary or text or XML form that includes the patient's name and other identifying information.

The safe Private Attributes that are retained shall be described in the Conformance Statement.

E.3.11 Retain Institution Identity Option

Information about the identity of the institution where the acquisition was performed is recognized as having a potential for leakage of identity because it may constrain the number of possible individuals that could be the imaging subject, though only if there is access to other information about the individuals concerned to match it against.

However, there are applications that require such institution information to perform the analysis or interpretation. There may be a need to maintain a record of the institution for regulatory or registry purposes, yet the acquisition site may not maintain an adequate electronic audit trail.

When this Option is specified in addition to the Basic Application Level Confidentiality Profile, information about the identity of the institution in the Attributes shall be retained, as described in Table E.1-1.

F Network Address Management Profiles

F.1 Basic Network Address Management Profile

The Basic Network Address Management Profile utilizes DHCP to provide services to assign and manage IP parameters for machines remotely. The DHCP server is manually configured to establish the rules for assigning IP addresses to machines. The rules may be explicit machine by machine assignments and may be assignment of a block of IP addresses to be assigned dynamically as machines are attached and removed from the network. The DHCP client can obtain its IP address and a variety of related parameters such as NTP server address from the DHCP server during startup. The DHCP server may dynamically update the DNS server with new relationships between IP addresses and DNS hostnames.

The DNS Client can obtain the IP number for another host by giving the DNS hostname to a DNS Server and receive the IP number in response. This transaction may be used in other profiles or in implementations that do not conform to the Basic Network Address Management Profile.

The Basic Network Address Management Profile applies to the actors DHCP Server, DHCP Client, DNS Server, and DNS Client. The mandatory and optional transactions are described in the table and sections below.

Table F.1-1. Basic Network Address Management Profile

Actor

Transaction

Optionality

Section

DHCP Server

Configure DHCP Server

M

F.1.2

Find and Use DHCP Server

M

F.1.3

Maintain Lease

M

F.1.4

Resolve Hostname

M

F.1.1

DDNS Coordination

O

F.1.5

DHCP Client

Find and Use DHCP Server

M

F.1.3

Maintain Lease

M

F.1.4

DNS Server

DDNS Coordination

O

F.1.5

Resolve Hostname

M

F.1.1

DNS Client

Resolve Hostname

M

F.1.1

F.1.1 Resolve Hostname

F.1.1.1 Scope

The DNS Client can obtain the IP number for a host by giving the DNS hostname to a DNS Server and receive the IP number in response.

F.1.1.2 Use Case Roles

Resolve Hostname

Figure F.1-1. Resolve Hostname


Actor:

DNS Client

Role:

Needs IP address, has the DNS Hostname

Actor:

DNS Server

Role:

Provides current IP address when given the DNS Hostname

F.1.1.3 Referenced Standards

The standards and their relationships for the family of DNS protocols are shown in Figure F.1-2. The details of transactions, transaction diagrams, etc. are contained within the referenced RFC's.

DNS Referenced Standards

Figure F.1-2. DNS Referenced Standards


F.1.1.4 DNS Security Considerations (Informative)

The issue of security is under active development by the Internet Engineering Task Force and its various working groups. The security related RFCs and drafts are identified in Figure F.1-2. Some of these are completed. Others are still in the draft stage. The Basic Network Address Management Profile does not include specific requirements for support of DNS security extensions by the DNS Client.

The Basic Network Address Management profile should not be used outside a secured environment. At a minimum there should be:

  1. Firewall or router protections to ensure that only approved external hosts are used for DNS services.

  2. Agreements for VPN and other access should require that DNS clients use only approved DNS servers over the VPN.

Other network security procedures such as automated intrusion detection may be appropriate in some environments. Security features beyond this minimum should be established by the local security policy and are beyond the scope of DICOM.

The purpose of the selected security is to limit the scope of the threat to insider attacks. The DNS system discloses only hostnames and IP addresses, so there is little concern about eavesdropping. The protections are to limit the exposure to denial of service attacks by counterfeit servers or clients.

F.1.1.5 DNS Implementation Considerations (Informative)

Client caches may cause confusion during updates. Many DNS clients check for DNS updates very infrequently and might not reflect DNS changes for hours or days. Manual steps may be needed to trigger immediate updates. Details for controls of cache and update vary for different DNS clients and DNS servers, but DNS caching and update propagation delays are significant factors and implementations have mechanisms to manage these issues.

DNS Server failure management should be considered. Redundant servers and fallback host files are examples of possible error management tools.

F.1.1.6 Support For Service Discovery

The DNS server may provide additional optional information in support of configuration management. See Section H.2 for the specification of this information and additional RFC's to be supported.

F.1.2 Configure DHCPserver

F.1.2.1 Scope

The DHCP server shall be configurable by site administration so that

  1. DHCP clients can be added and removed.

  2. DHCP clients configurations can be modified to set values for attributes used in later transactions.

  3. pre-allocation of fixed IP addresses for DHCP clients is supported

This Standard does not specify how this configuration is to be performed.

Note

Most DHCP servers support the pre-allocation of fixed IP addresses to simplify the transition process for legacy systems. This permits a particular device to switch to DHCP while retaining the previously assigned IP address. This enables the use of a central site management of IP addresses without breaking compatibility with older systems that require fixed IP addresses.

F.1.2.2 Use Case Roles

Configure DHCP Server

Figure F.1-3. Configure DHCP Server


Actor:

DHCP Server

Role:

Maintains internal configuration files.

Actor:

Site Administrator

Role:

Updates configuration information to add, modify, and remove descriptions of clients and servers.

Actor:

Service Staff

Role:

Provides initial configuration requirements for many devices when installing a new network, and for individual devices when installing or modifying a single device.

F.1.2.3 Referenced Standards

None

F.1.3 Find and Use DHCP Server

F.1.3.1 Scope

This is the support for the normal startup process. The DHCP client system boots up, and very early in the booting process it finds DHCP servers, selects one of the DHCP servers to be its server, queries that server to obtain a variety of information, and continues DHCP client self-configuration using the results of that query. DHCP servers may optionally provide a variety of information, such as server locations, normal routes. This transaction identifies what information shall be provided by a compliant DHCP server, and identifies what information shall be requested by a compliant DHCP client. A compliant DHCP server in not required to provide this optional information.

F.1.3.2 Use Case Roles

Find and Use DHCP Server

Figure F.1-4. Find and Use DHCP Server


Actor:

DHCP Server

Role:

Responds to DHCP acquisition queries. Multiple actors may exist. The DHCP client will select one.

Actor:

DHCP client

Role:

Queries for DHCP Servers. Selects one responding server.

F.1.3.3 Referenced Standards

[RFC 2131] DHCP Protocol

[RFC 2132] DHCP Options

[RFC 2563] Auto Configuration control

F.1.3.4 Interaction Diagram

DHCP Interactions

Figure F.1-5. DHCP Interactions


The DHCP client shall comply with [RFC 2131] (DHCP Protocol), [RFC 2132] (DHCP Options), [RFC 2563] (Auto Configuration Control), and their referenced RFCs.

The DHCP client shall query for available DHCP servers. It shall select the DHCP server to use.

The DHCP client shall query for an IP assignment. The DHCP Server shall determine the IP parameters in accordance with the current DHCP configuration, establish a lease for these parameters, and respond with this information. (See below for lease maintenance and expiration.) The DHCP client shall apply these parameters to the TCP/IP stack. The DHCP client shall establish internal lease maintenance activities.

The DHCP client shall query for the optional information listed in Table F.1-2 when required by additional profiles used by the client system. If the DHCP server does not provide this information, the default values shall be used by the DHCP client.

Table F.1-2. DHCP Parameters

DHCP Option

Description

Default

NTP

List of NTP servers

Empty list

DNS

List of DNS servers

Empty list

Router

Default router

Empty list

Static routes

Nil

Hostname

Requested machine name

Domain name

Nil

Subnet mask

Derived from network value

Broadcast address

Derived from network value

Default router

Nil

Time offset

Site configurable

MTU

Hardware dependent

Auto-IP permission

From NVRAM

The DHCP client shall make this information available for other actors within the DHCP client machine.

F.1.4 Maintain Lease

F.1.4.1 Scope

The DHCP client normally maintains the IP lease in compliance with the RFCs. Sometimes the server will not renew the lease. Non-renewal is usually part of network service operations. The loss of the IP lease requires connections using that IP address to cease.

F.1.4.2 Use Case Roles

Maintain Lease

Figure F.1-6. Maintain Lease


Actor:

DHCP client

Role:

Deals with lease renewal and expiration.

Actor:

DHCP Server

Role:

Renewing or deliberately letting leases expire (sometimes done as part of network service operations).

F.1.4.3 Referenced Standards

[RFC 2131] DHCP Protocol

[RFC 2132] DHCP Options

F.1.4.4 Normal Interaction

The DHCP client shall maintain a lease on the IP address in accordance with the DHCP protocol as specified in [RFC 2131] and [RFC 2132]. There is a possibility that the DHCP Server may fail, or may choose not to renew the lease.

In the event that the DHCP lease expires without being renewed, any still active DICOM connections may be aborted (AP-Abort).

Note

There is usually a period (typically between several minutes and several days) between the request for lease extension and actual expiration of the lease. The application might take advantage of this to perform a graceful association release rather than the abrupt shutdown of an AP-Abort.

F.1.5 DDNS Coordination

F.1.5.1 Scope

DHCP servers may coordinate their IP and hostname assignments with a DNS server. This permits dynamic assignment of IP addresses without interfering with access to DHCP Clients by other systems. The other systems utilize the agreed hostname (which DHCP can manage and provide to the client) and obtain the current IP address by means of DNS lookup.

Dynamic DNS (DDNS) provides the capability to the client to update DNS records hosted on the DNS server. The client can be a DHCP server, Active Directory or LDAP servers, or even an application announcing the systems IP address and optionally any available services.

A DHCP Server complies with this optional part of the Basic Network Address Management Profile if it maintains and updates the relevant DNS entry so as to maintain the hostname and IP relationships in the DNS database when they change.

F.1.5.2 Use Case Roles

DDNS Coordination

Figure F.1-7. DDNS Coordination


Actor:

DHCP Server

Role:

Responded to DHCP acquisition queries and assigned IP address to client.

Actor:

DNS Server

Role:

Maintains the DNS services for the network.

F.1.5.3 Referenced Standards

[RFC 2136] Dynamic Updates in the Domain Name System

F.1.5.4 Basic Course of Events

The DHCP server assigns an IP address to a DHCP client, then informs the DDNS server that the hostname associated with the DHCP client has been given an assigned IP address. The DDNS server updates the DNS database and links the IP address to the hostname. DNS queries for this hostname are directed to the assigned IP address. If the assigned IP address changes or expires, the DHCP server informs the DDNS server, which updates the DNS database.

F.1.6 DHCP Security Considerations (Informative)

The Basic Network Address Management Profile Profile has two areas of security concerns:

  1. Protection against denial of service attacks against the DHCP client/server traffic.

  2. Protection against denial of service attacks against the DHCP server to DDNS server update process.

The Basic Network Address Management Profile Profile should not be used outside a secured environment. At a minimum there should be:

  1. Firewall and or router protections to ensure that only approved hosts are used for DHCP and DNS services.

  2. Agreements for VPN and other access should require that DNS clients on the hospital network use only approved DHCP or DNS servers over the VPN.

Other network security procedures such as automated intrusion detection may be appropriate in some environments. Security features beyond this minimum should be established by the local security policy and are beyond the scope of DICOM.

The purpose of the selected security is to limit the scope of the threat to insider attacks. The DHCP and DNS systems disclose only hostnames and IP addresses, so there is little concern about eavesdropping. The protections are to limit the exposure to denial of service attacks by counterfeit servers or clients. The specific DNS security extensions are described in Section F.1.1.4. This profile does not utilize the DHCP security extensions because they provide very limited added security and the attacks are insider denial of service attacks. Intrusion detection and other network level protection mechanisms are the most effective next level of protections for the DHCP process.

The DNS update is optional in this profile to accommodate the possibility that the DHCP server and DNS server cannot reach a mutually acceptable security process. Support of this option may require support of the DNS security protocols that are in the process of development. See Section F.1.1.4 for a discussion of the DNS security profile standards and drafts.

F.1.7 DHCP Implementation Considerations (Informative)

The DHCP configuration file can be a very useful form of documentation for the local network hardware configuration. It can be prepared in advance for new installations and updated as clients are added. Including information for all machines, including those that do not utilize DHCP, avoids accidental IP address conflicts and similar errors.

Most DHCP servers have a configuration capability that permits control of the IP address and other information provided to the client. These controls can pre-allocate a specific IP address, etc. to a machine based on the requested machine name or MAC address. These pre-allocated IP addresses then ensure that these specific machines are always assigned the same IP address. Legacy systems that do not utilize DNS can continue to use fixed tables with IP addresses when the DHCP server has pre-allocated the IP addresses for those services.

F.1.8 Conformance

An implementation that supports this profile shall state in its Conformance Statement whether it supports DHCP as DHCP Client or DHCP Server.

An implementation that supports this profile as a DHCP Client shall state in its Conformance Statement how the DHCP Server is discovered (see Section F.1.3).

An implementation that supports this profile shall state in its Conformance Statement whether it supports DNSSEC [RFC 4033] [RFC 4034] [RFC 4035] for the interactions described in this profile, in which case either the options supported shall be stated or a reference provided to the DNSSEC support for this product.

G Time Synchronization Profiles

G.1 Basic Time Synchronization Profile

The Basic Time Synchronization Profile defines services to synchronize the clocks on multiple computers. It employs the Network Time Protocol (NTP) services that have been used for this purpose by many other disciplines. NTP permits synchronization to a local server that provides a local time source, and synchronization to a variety of external time services. The accuracy and precision controls are not explicitly part of the protocol. They are determined in large part by the selection of clock hardware and network topology.

An extensive discussion of implementation strategies for NTP can be found at http://www.ntp.org.

The Basic Time Synchronization Profile applies to the actors DHCP Client, DHCP Server, SNTP Client, NTP Client and NTP Server. The mandatory and optional transactions are described in the table and sections below.

Table G.1-1. Basic Time Synchronization Profile

Actor

Transaction

Optionality

Section

NTP Server

Maintain Time

M

G.1.2

Find NTP Servers

O

G.1.1

NTP Client

Maintain Time

M

G.1.2

Find NTP Servers

O

G.1.1

SNTP Client

Maintain Time

M

G.1.2

DHCP Server

Find NTP Servers

O

G.1.1

DCHP Client

Find NTP Servers

M

G.1.1

G.1.1 Find NTP Servers

The optional NTP protocol elements for NTP autoconfiguration and NTP autodiscovery can significantly simplify installation. The NTP specification for these is defined such that they are truly optional for both client and server. In the event that a client cannot find an NTP server automatically using these services, it can use the DHCP optional information or manually configured information to find a server. Support for these services is recommended but not mandatory.

This transaction exists primarily as a means of documenting whether particular models of equipment support the automatic discovery. This lets installation and operation plan their DHCP and equipment installation procedures in advance.

G.1.1.1 Scope

This applies to any client that needs the correct time, or that needs to have its time stamps synchronized with those of another system. The accuracy of synchronization is determined by details of the configuration and implementation of the network and NTP servers at any specific site.

Both the NTP and SNTP clients shall utilize the NTP server information if it is provided by DHCP and NTP services have not been found using autodiscovery. Manual configuration shall be provided as a backup. Autodiscovery or DHCP are preferred.

G.1.1.2 Use Case Roles

Find NTP Servers

Figure G.1-1. Find NTP Servers


DHCP Server

Provides UTC offset, provides list of NTP servers

DHCP Client

Receives UTC offset and list of NTP servers

NTP Client

Maintains client clock

SNTP Client

Maintains client clock

NTP Servers

External time servers. These may have connections to other time servers, and may be synchronized with national time sources.

G.1.1.3 Referenced Standards

[RFC 2030] Simple Network Time Protocol (SNTP) Version 4

[RFC 5905] Network Time Protocol Version 4: Protocol and Algorithms Specification

[RFC 5906] Network Time Protocol Version 4: Autokey Specification

[RFC 8633] Network Time Protocol Best Current Practices

G.1.1.4 Basic Course of Events.

The NTP Client uses a list of NTP Servers, which may be:

  • obtained through optional NTP discovery mechanisms (see [RFC 5905]Section 3.1),

  • provided by a DHCP Server, see Annex F on DHCP, and/or

  • manually configured.

If the list is not empty, the client shall attempt to maintain time synchronization with at least one of the NTP servers. The client synchronization shall be in compliance with either [RFC 5905] (NTP) or [RFC 2030] (SNTP). If the list is empty, the client may choose an alternative method of time synchronization.

SNTP provides much lower accuracy than NTP. If time synchronization of better than 1s mean error is required, the client should use NTP. [RFC 5905] and [RFC 8633] discuss implementation and accuracy considerations.

A DHCP server may provide to the DHCP Client a UTC offset between the local time at the machine and UTC, which the client shall use for converting between UTC and local time.

G.1.1.5 Alternative Paths

If there is no UTC offset information from the DHCP or NTP server, then the UTC offset will be obtained in a device specific manner (e.g., service, CMOS, internal battery clock).

G.1.1.6 Assumptions

The local battery clock time is set to UTC, or the local operating system has proper support to manage both battery clock time, NTP clock time, and system clock time. The NTP time is always in UTC.

G.1.1.7 Postconditions

The client will remain synchronized with its selected time source. In an environment with one or more NTP servers, this will be good time synchronization. In the absence of NTP servers, the selected source will be the internal client clock.

G.1.2 Maintain Time

G.1.2.1 Scope

This applies to any client that needs the correct time, or that needs to have its time stamps synchronized with those of another system. The accuracy of synchronization is determined by details of the configuration and implementation of the network and NTP servers at any specific site.

G.1.2.2 Use Case Roles

Maintain Time

Figure G.2-1. Maintain Time


NTP/SNTP Client

Maintains client clock

NTP Servers

External time servers. These may have connections to other time servers, and may be synchronized with national time sources.

G.1.2.3 Referenced Standards

[RFC 2030] Simple Network Time Protocol (SNTP) Version 4

[RFC 2827] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

[RFC 5905] Network Time Protocol Version 4: Protocol and Algorithms Specification

[RFC 5906] Network Time Protocol Version 4: Autokey Specification

[RFC 8633] Network Time Protocol Best Current Practices

G.1.2.4 Basic Course of Events.

The detail on Maintain Time transactions is described in [RFC 5905] and [RFC 2030]. The most common and the mandatory minimum mode for NTP operation uses a series of messages between client and servers. The client sends requests to the servers, which fill in time related fields in a response, and the client performs optimal estimation of the present time based on that information. The RFCs deal with issues of lost messages, estimation formulae, etc. Once the clocks are in synchronization these message exchanges typically stabilize at roughly 1000 second intervals.

The client machine uses the time estimate to maintain the internal operating system clock. This clock is then used by applications that need time information. This approach eliminates the application visible difference between synchronized and unsynchronized time. The RFCs provide guidance on proper implementations.

G.1.3 NTP Security Considerations (Informative)

NTP security considerations ([RFC 5905] Section 8, [RFC 5906], and [RFC 8633]) may be applicable based on site-specific environment and threat considerations. Locations with NTP Servers should also consider [RFC 2827] and implementing access controls on the use of the server.

Security Policies and Procedures for NTP are maintained at http://www.nwtime.org/security-policy/ as part of the Network Time Foundation.

G.1.4 NTP Implementation Considerations (Informative)

NTP compliant servers always support both NTP and SNTP clients. The difference is one of synchronization accuracy, not communications compatibility. Although in theory both NTP and SNTP clients could run at the same time on the same system, this is not recommended. The SNTP updates will simply degrade the time accuracy. When other time protocol clients, such as IRIG, are also being used, these clients must be coordinated with the NTP client to avoid synchronization problems.

These and other considerations, such as multiple clock types, accuracy implications, and configuration alternatives, are documented at http://www.ntp.org.

G.1.5 Conformance

The Conformance Statement for the NTP Server and NTP Client shall state whether secure transactions ([RFC 5906]) are supported.

The Conformance Statement for the NTP Server shall state whether it is also an NTP Client.

The Conformance Statement for the NTP Client shall state how it manages time when no NTP Server is available.

H Application Configuration Management Profiles

H.1 Application Configuration Management Profile

The Application Configuration Management Profile applies to the actors LDAP Server, LDAP Client, and DNS Server. The mandatory and optional transactions are described in the table and sections below.

Table H.1-1. Application Configuration Management Profiles

Actor

Transaction

Optionality

Section

LDAP Server

Query LDAP Server

M

H.1.4.2

Update LDAP Server

O

H.1.4.3

Maintain LDAP Server

M

H.1.4.4

LDAP Client

Find LDAP Server

M

H.1.4.1

Query LDAP Server

M

H.1.4.2

Update LDAP Server

O

H.1.4.3

DNS Server

Find LDAP Server

M

H.1.4.1

H.1.1 Data Model Component Objects

The normative definition of the schema can be found in Section H.1.3. This section gives additional informative descriptions of the objects and information defined in that schema and makes normative statements regarding DICOM system behavior.

The Application Configuration Data Model has the following component objects:

Device

The description of the device

Network AE

The description of the network application entity

Network Connection

The description of the network interface

Transfer Capability

The description of the SOP classes and syntaxes supported by a Network AE.

Application Configuration Data Model

Figure H.1-1. Application Configuration Data Model


In addition there are a number of other objects used in the LDAP schema (see Section H.1.2 and Figure H.1-2) :

DICOM Configuration Root

The root of DICOM Configuration Hierarchy

DICOM Devices Root

The root of the DICOM Devices Hierarchy

DICOM Unique AE-Title Registry Root

The root of the Unique DICOM AE-Title Registry

DICOM Unique AE Title

A unique AE Title within the AE Title Registry

LDAP permits extensions to schema to support local needs (i.e., an object may implement a single structural and multiple auxiliary LDAP classes). DICOM does not mandate client support for such extensions. Servers may support such extensions for local purposes. DICOM Clients may accept or ignore extensions and shall not consider their presence an error.

H.1.1.1 Device

The "device" is set of components organized to perform a task rather than a specific physical instance. For simple devices there may be one physical device corresponding to the Data Model device. But for complex equipment there may be many physical parts to one "device".

The "device" is the collection of physical entities that supports a collection of Application Entities. It is uniquely associated with these entities and vice versa. It is also uniquely associated with the network connections and vice versa. In a simple workstation with one CPU, power connection, and network connection the "device" is the workstation.

An example of a complex device is a server built from a network of multiple computers that have multiple network connections and independent power connections. This would be one device with one application entity and multiple network connections. Servers like this are designed so that individual component computers can be replaced without disturbing operations. The Application Configuration Data Model does not describe any of this internal structure. It describes the network connections and the network visible Application Entities. These complex devices are usually designed for very high availability, but in the unusual event of a system shutdown the "device" corresponds to all the parts that get shut down.

Table H.1-2. Attributes of Device Object

Information Field

Multiplicity

Description

Device Name

1

A unique name (within the scope of the LDAP database) for this device. It is restricted to legal LDAP names, and not constrained by DICOM AE Title limitations.

Description

0..1

Unconstrained text description of the device.

Manufacturer

0..1

Should be the same as the Value of Manufacturer (0008,0070) in SOP instances created by this device.

Manufacturer Model Name

0..1

Should be the same as the Value of Manufacturer Model Name (0008,1090) in SOP instances created by this device.

Software Version

0..N

Should be the same as the Values of Software Versions (0018,1020) in SOP instances created by this device.

Station Name

0..1

Should be the same as the Value of Station Name (0008,1010) in SOP instances created by this device.

Device Serial Number

0..1

Should be the same as the Value of Device Serial Number (0018,1000) in SOP instances created by this device.

Primary Device Type

0..N

Represents the kind of device and is most applicable for acquisition modalities. Types should be selected from the list of codes for Code Value (0008,0100) for CID 30 “DICOM Device” when applicable.

Institution Name

0..N

Should be the same as the Value of Institution Name (0008,0080) in SOP Instances created by this device.

Institution Address

0..N

Should be the same as the Value of Institution Address (0008,0081) attribute in SOP Instances created by this device.

Institutional Department Name

0..N

Should be the same as the Value of Institutional Department Name (0008,1040) in SOP Instances created by this device.

Institutional Department Type Code Sequence

0..N

Should be the same as the Value of Institutional Department Type Code Sequence (0008,1041) in SOP Instances created by this device.

Issuer of Patient ID

0..1

Default Value for the Issuer of Patient ID (0010,0021) for SOP Instances created by this device. May be overridden by the values received in a worklist or other source.

Related Device Reference

0..N

The DNs of related device descriptions outside the DICOM Configuration hierarchy. Can be used to link the DICOM Device object to additional LDAP objects instantiated from other schema and used for separate administrative purposes.

Authorized Node Certificate Reference

0..N

The DNs for the certificates of nodes that are authorized to connect to this device. The DNs need not be within the DICOM configuration hierarchy.

This Node Certificate Reference

0..N

The DNs of the public certificate(s) for this node. The DNs need not be within the DICOM configuration hierarchy.

Vendor Device Data

0..N

Device specific vendor configuration information

Installed

1

Boolean to indicate whether this device is presently installed on the network. (This is useful for pre-configuration, mobile vans, and similar situations.)

The "Authorized Node Certificate Reference" is intended to allow the LDAP server to provide the list of certificates for nodes that are authorized to communicate with this device. These should be the public certificates only. This list need not be complete. Other network peers may be authorized by other mechanisms.

The "This Node Certificate Reference" is intended to allow the LDAP server to provide the certificate(s) for this node. These may also be handled independently of LDAP.

Note

A device may have multiple Primary Device Type entries. It may be a multifunctional device, e.g., combined PET and CT. It may be a cascaded device, e.g., image capture and ultrasound.

Table H.1-3. Child Objects of Device Object

Information Field

Multiplicity

Description

Network Application Entity

1..N

The application entities available on this device (see Section H.1.1.2)

Network Connection

1..N

The network connections for this device (see Section H.1.1.3)

H.1.1.2 Network Application Entity

A Network AE is an application entity that provides services on a network. A Network AE will have the same functional capability regardless of the particular network connection used. If there are functional differences based on selected network connection, then these are separate Network AEs. If there are functional differences based on other internal structures, then these are separate Network AEs.

Table H.1-4. Attributes of Network AE Object

Information Field

Multiplicity

Description

AE Title

1

Unique AE title for this Network AE

Description

0..1

Unconstrained text description of the application entity.

Vendor Data

0..N

AE specific vendor configuration information

Application Cluster

0..N

Locally defined names for a subset of related applications. E.g. "neuroradiology".

Preferred Called AE Title

0..N

AE Title(s) that are preferred for initiating associations.

Preferred Calling AE Title

0..N

AE Title(s) that are preferred for accepting associations.

Association Acceptor

1

A Boolean value. True if the Network AE can accept associations, false otherwise.

Association Initiator

1

A Boolean value. True if the Network AE can accept associations, false otherwise.

Network Connection Reference

1..N

The DNs of the Network Connection objects for this AE

Supported Character Set

0..N

The Character Set(s) supported by the Network AE for Data Sets it receives. The value shall be selected from the Defined Terms for Specific Character Set (0008,0005) in PS3.3. If no values are present, this implies that the Network AE supports only the default character repertoire (ISO IR 6).

Installed

0..1

A Boolean value. True if the AE is installed on network. If not present, information about the installed status of the AE is inherited from the device

The "Application Cluster" concept provides the mechanism to define local clusters of systems. The use cases for Configuration Management require a "domain" capability for DICOM applications that would be independent of the network topology and administrative domains that are used by DNS and other TCP level protocols. The Application Cluster is multi-valued to permit multiple clustering concepts for different purposes. It is expected to be used as part of a query to limit the scope of the query.

The "Preferred Called AE Title" concept is intended to allow a site administrator to define a limited default set of AEs that are preferred for use as communication partners when initiating associations. This capability is particularly useful for large centrally administered sites to simplify the configuration possibilities and restrict the number of configured AEs for specific workflow scenarios. For example, the set of AEs might contain the AE Titles of assigned Printer, Archive, RIS and QA Workstations so that the client device could adapt its configuration preferences accordingly. The "Preferred Called AE Title" concept does not prohibit association initiation to unlisted AEs. Associations to unlisted AEs can be initiated if necessary.

The "Preferred Calling AE Title" concept is intended to allow a site administrator to define a default set of AEs that are preferred when accepting assocations. The "Preferred Calling AE Title" concept does not prohibit accepting associations from unlisted AEs.

The "Network Connection Reference" is a link to a separate Network Connection object. The referenced Network Connection object is a sibling the AE object (i.e., both are children of the same Device object).

Table H.1-5. Child Objects of Network AE Object

Information Field

Multiplicity

Description

Transfer Capability

1..N

The Transfer Capabilities for this Network AE. See Section H.1.4


H.1.1.3 Network Connection

The "network connection" describes one TCP port on one network device. This can be used for a TCP connection over which a DICOM association can be negotiated with one or more Network AEs. It specifies the hostname and TCP port number. A network connection may support multiple Network AEs. The Network AE selection takes place during association negotiation based on the called and calling AE-titles.

Table H.1-6. Attributes of Network Connection Object

Information Field

Multiplicity

Description

Common Name

0..1

An arbitrary name for the Network Connections object. Can be a meaningful name or any unique sequence of characters. Can be used as the RDN.

Note

The "cn" attribute type is a basic LDAP defined type and is a synonym for Common Name.

Hostname

1

This is the DNS name for this particular connection. This is used to obtain the current IP address for connections. Hostname must be sufficiently qualified to be unambiguous for any client DNS user.

Port

0..1

The TCP port that the AE is listening on. (This may be missing for a network connection that only initiates associations.)

TLS CipherSuite

0..N

The TLS CipherSuites that are supported on this particular connection. TLS CipherSuites shall be described using an [RFC 2246] string representation (e.g., "TLS_RSA_WITH_RC4_128_SHA")

Installed

0..1

A Boolean value. True if the Network Connection is installed on the network. If not present, information about the installed status of the Network Connection is inherited from the device.

Inclusion of a TLS CipherSuite in a Network Connection capable of accepting associations implies that the TLS protocol must be used to successfully establish an association on the Network Connection.

A single Network AE may be available on multiple network connections. This is often done at servers for availability or performance reasons. For example, at a hospital where each floor is networked to a single hub per floor, the major servers may have direct connections to each of the hubs. This provides better performance and reliability. If the server does not change behavior based on the particular physical network connection, then it can be described as having Network AEs that are available on all of these multiple network connections. A Network AE may also be visible on multiple TCP ports on the same network hardware port, with each TCP port represented as a separate network connection. This would allow, e.g., a TLS-secured DICOM port and a classical un-secured DICOM port to be supported by the same AE.

H.1.1.4 Transfer Capabilities

Each Network AE object has one or more Transfer Capabilities. Each transfer capability specifies the SOP class that the Network AE can support, the mode that it can utilize (SCP or SCU), and the Transfer Syntax(es) that it can utilize. A Network AE that supports the same SOP class in both SCP and SCU modes will have two Transfer Capabilities objects for that SOP class.

Table H.1-7. Attributes of Transfer Capability Object

Information Field

Multiplicity

Description

Common Name

0..1

An arbitrary name for the Transfer Capability object. Can be a meaningful name or any unqiue sequence of characters. Can be used as the RDN.

SOP Class

1

SOP Class UID

Role

1

Either "SCU" or "SCP"

Transfer Syntax

1..N

The transfer syntax(es) that may be requested as an SCU or that are offered as an SCP.

H.1.1.5 DICOM Configuration Root

This structural object class represents the root of the DICOM Configuration Hierarchy. Only a single object of this type should exist within an organizational domain. Clients can search for an object of this class to locate the root of the DICOM Configuration Hierarchy.

Table H.1-8. Attributes of the DICOM Configuration Root Object

Information Field

Multiplicity

Description

Common Name

1

The Name for the Configuration Root. Should be used as the RDN. The name shall be "DICOM Configuration".

Description

0..1

Unconstrained text description.

Table H.1-9. Child Objects of DICOM Configuration Root Object

Information Field

Multiplicity

Description

Devices Root

1

The root of the DICOM Devices Hierarchy

Unique AE Titles Registry Root

1

The root of the Unique AE Titles Registry

H.1.1.6 Devices Root

This structural object class represents the root of the DICOM Devices Hierarchy. Only a single object of this type should exist as a child of DICOM Configuration Root. Clients can search for an object of this class to locate the root of the DICOM Devices Hierarchy.

Table H.1-10. Attributes of the Devices Root Object

Information Field

Multiplicity

Description

Common Name

1

The Name for the Devices Root. Should be used as the RDN. The name shall be "Devices".

Description

0..1

Unconstrained text description.

Table H.1-11. Child Objects of Devices Root Object

Information Field

Multiplicity

Description

Device

0..N

The individual devices installed within this organizational domain.

H.1.1.7 Unique AE Titles Registry Root

This structural object class represents the root of the Unique AE-Titles Registry Hierarchy. Only a single object of this type should exist as a child of the DICOM Configuration Root. Clients can search for an object of this class to locate the root of the Unique AE Titles Registry.

Table H.1-12. Attributes of the Unique AE Titles Registry Root Object

Information Field

Multiplicity

Description

Common Name

1

The Name for the Unique AE Titles Registry Root. Should be used as the RDN. The name shall be "Unique AE Titles Registry".

Description

0..1

Unconstrained text description.

Table H.1-13. Child Objects of Unique AE Titles Registry Root Object

Information Field

Multiplicity

Description

Unique AE Title

0..N

The unique AE Titles installed within this organizational domain (see Section H.1.1.8)

H.1.1.8 Unique AE Title

This structural object class represents a Unique Application Entity Title. Objects of this type should only exist as children of the Unique AE-Titles Registry Root. The sole purpose of this object class is to enable allocation of unique AE Titles. All operational information associated with an AE Title is maintained within a separate Network AE object.

Table H.1-14. Attributes of the Unique AE Title Object

Information Field

Multiplicity

Description

AE Title

1

The Unique AE Titles.

H.1.2 Application Configuration Data Model Hierarchy

The LDAP structure is built upon a hierarchy of named objects. This hierarchy can vary from site to site. The DICOM configuration management function needs to find its objects within this hierarchy in a predictable manner. For this reason, three specific object classes are defined for the three objects at the top of the DICOM hierarchy. These three object classes must not be used in this tree relationship anywhere else in the LDAP hierarchy.

The DICOM portion of the hierarchy shall begin at a root object of class dicomConfigurationRoot with a Common Name of "DICOM Configuration". Below this object shall be two other objects:

  1. An object of class dicomDevicesRoot with a Common Name of "Devices". This is the root of the tree of objects that correspond to the Application Configuration Data Model structure of Section H.1.1.

  2. An object of class dicomUniqueAETitlesRegistryRoot with a common name of "Unique AE Titles Registry". This is the root of a flat tree of objects. Each of these objects is named with one of the AE titles that are presently assigned. This is the mechanism for finding available AE titles.

The three object classes dicomConfigurationRoot, dicomDevicesRoot, and dicomUniqueAETitleRegistryRoot are used by LDAP clients to establish the local root of the DICOM configuration information within an LDAP hierarchy that may be used for many other purposes.

Note

During system startup it is likely that the DICOM configuration application will do an LDAP search for an entry of object class dicomConfigurationRoot and then confirm that it has the dicomDevicesRoot and dicomUniqueAETitlesRegistryRoot entries directly below it. When it finds this configuration, it can then save the full location within the local LDAP tree and use that as the root of the DICOM tree.

The objects underneath the dicomUniqueAETitlesRegistryRoot are used to provide the uniqueness required for DICOM AE-titles. The dicomUniqueAETitle objects have a single attribute representing a unique AE Title. When a new AE-Title is required, a tentative new name is selected. The new name is reserved by using the LDAP create facility to create an object of class dicomUniqueAETitle with the new name under the AE-Title object. If this name is already in use, the create will fail. Otherwise, this reserves the name. LDAP queries can be used to obtain the list of presently assigned AE-titles by obtaining the list of all names under the dicomUniqueAETitlesRegistryRoot object.

DICOM Configuration Hierarchy

Figure H.1-2. DICOM Configuration Hierarchy


Note

  1. LDAP uses a root and relative hierarchical naming system for objects. Every object name is fully unique within the full hierarchy. This means that the names of the objects beneath "Unique AE Titles Registry" will be unique. It also means that the full names of Network AEs and Connections will be within their hierarchy context. E.g., the DN for one of the Network AEs in Figure H.1-2 would be:

    • dicomAETitle=CT_01, dicomDeviceName=Special Research CT, cn=Devices, cn=DICOM Configuration, o=Sometown Hospital

  2. In theory, multiple independent DICOM configuration hierarchies could exist within one organization. The LDAP servers in such a network should constrain local device accesses so that DICOM configuration clients have only one DICOM Configuration Hierarchy visible to each client.

  3. The merger of two organizations will require manual configuration management to merge DICOM Configuration hierarchies. There are likely to be conflicts in AE-titles, roles, and other conflicts.

H.1.3 LDAP Schema For Objects and Attributes

The individual LDAP attribute information is summarized in the comments at the beginning of the schema below. The formal definition of the objects and the attributes is in the schema below. This schema may be extended by defining an additional schema that defines auxiliary classes, sub-classes derived from this schema, or both.

The formal LDAP schema for the Application Configuration Data Model and the DICOM Configuration Hierarchy is:

# 3 Attribute Type Definitions
# 
#    The following attribute types are defined in this document:
# 
#	Name                                    Syntax    Multiplicity
#	--------------------------------        ------    ------------
#	dicomDeviceName                         string    Single
#	dicomDescription                        string    Single
#	dicomManufacturer                       string    Single
#	dicomManufacturerModelName              string    Single
#	dicomSoftwareVersion                    string    Multiple
#	dicomVendorData                         binary    Multiple
#	dicomAETitle                            string    Single
#	dicomNetworkConnectionReference         DN        Multiple
#	dicomApplicationCluster                 string    Multiple
#	dicomAssociationInitiator               bool      Single
#	dicomAssociationAcceptor                bool      Single
#	dicomHostname                           string    Single
#	dicomPort                               integer   Single
#	dicomSOPClass                           OID       Single
#	dicomTransferRole                       string    Single
#	dicomTransferSyntax                     OID       Multiple
#	dicomPrimaryDeviceType                  string    Multiple
#	dicomRelatedDeviceReference             DN        Multiple
#	dicomPreferredCalledAETitle             string    Multiple
#	dicomTLSCipherSuite                     string    Multiple
#	dicomAuthorizedNodeCertificateReference DN        Multiple
#	dicomThisNodeCertificateReference       DN        Multiple
#	dicomInstalled                          bool      Single
#	dicomStationName                        string    Single
#	dicomDeviceSerialNumber                 string    Single
#	dicomInstitutionName                    string    Multiple
#	dicomInstitutionAddress                 string    Multiple
#	dicomInstitutionDepartmentName          string    Multiple
#	dicomIssuerOfPatientID                  string    Single
#	dicomPreferredCallingAETitle            string    Multiple
#	dicomSupportedCharacterSet              string    Multiple
#	dicomInstitutionDepartmentType          string    Multiple
#


# 3.1 dicomDeviceName                     string    Single
# 
#    This attribute stores the unique name (within the scope of the LDAP database) 
#    for a DICOM Device.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
# 
attributetype ( 1.2.840.10008.15.0.3.1
	NAME 'dicomDeviceName'
	DESC 'The unique name for the device'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.2 dicomDescription                    string    Single
# 
#    This attribute stores the (unconstrained) textual description for a DICOM entity.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
# 
attributetype ( 1.2.840.10008.15.0.3.2
	NAME 'dicomDescription'
	DESC 'Textual description of the DICOM entity'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.3 dicomManufacturer                   string    Single
#
#    This attribute stores the Manufacturer name for a DICOM Device.
#    Should be identical to the Value of the DICOM attribute Manufacturer (0008,0070) [VR=LO]
#    contained in SOP Instances created by this device.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.3
	NAME 'dicomManufacturer'
	DESC 'The device Manufacturer name'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.4 dicomManufacturerModelName          string    Single
#
#    This attribute stores the Manufacturer Model Name for a DICOM Device.
#    Should be identical to the Value of the DICOM attribute Manufacturer 
#    Model Name (0008,1090) [VR=LO]
#    contained in SOP Instances created by this device.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.4
	NAME 'dicomManufacturerModelName'
	DESC 'The device Manufacturer Model Name'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.5 dicomSoftwareVersion                string    Multiple
#
#    This attribute stores the software version of the device and/or its subcomponents.
#    Should be the same as the Values of Software Versions (0018,1020) in 
#    SOP instances created by this device.
#
#    It is a multi-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.5
	NAME 'dicomSoftwareVersion'
	DESC 'The device software version. Should be the same as the Values of Software
	      Versions (0018,1020) in SOP instances created by this device.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.6 dicomVendorData                     binary    Multiple
#
#    This attribute stores vendor specific configuration information.
#
#    It is a multi-valued attribute. 
#    This attribute's syntax is 'Binary'.
#    Neither equality nor substring matches are applicable to binary data.
#
attributetype ( 1.2.840.10008.15.0.3.6
	NAME 'dicomVendorData'
	DESC 'Arbitrary vendor-specific configuration information (binary data)'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

# 3.7 dicomAETitle                        name      Single
#
#    This attribute stores an Application Entity (AE) title.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'IA5 String'.
#    Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.7
	NAME 'dicomAETitle'
	DESC 'Application Entity (AE) title'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
	SINGLE-VALUE )

# 3.8 dicomNetworkConnectionReference     DN        Multiple
# 
#    This attribute stores the DN of a dicomNetworkConnection object 
#    used by an Application Entity.
#
#    It is a multi-valued attribute. 
#    This attribute's syntax is 'Distinguished Name'.
# 
attributetype ( 1.2.840.10008.15.0.3.8
	NAME 'dicomNetworkConnectionReference'
	DESC 'The DN of a dicomNetworkConnection object used by an Application Entity'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 3.9 dicomApplicationCluster             string    Multiple
#
#    This attribute stores an application cluster name for an Application 
#    Entity (e.g., "Neuroradiology Research")
#
#    It is a multi-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
# 
attributetype ( 1.2.840.10008.15.0.3.9
	NAME 'dicomApplicationCluster'
	DESC 'Application cluster name for an Application Entity (e.g., "Neuroradiology Research")'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.10 dicomAssociationInitiator          bool      Single
#
#    This attribute indicates if an Application Entity is capable of initiating 
#    network associations.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Boolean'.
# 
attributetype ( 1.2.840.10008.15.0.3.10
	NAME 'dicomAssociationInitiator'
	DESC 'Indicates if an Application Entity is capable of initiating network associations'
	EQUALITY booleanMatch 
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
	SINGLE-VALUE )

# 3.11 dicomAssociationAcceptor           bool      Single
#
#    This attribute indicates if an Application Entity is capable of accepting 
#    network associations.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Boolean'.
# 
attributetype ( 1.2.840.10008.15.0.3.11
	NAME 'dicomAssociationAcceptor'
	DESC 'Indicates if an Application Entity is capable of accepting network associations'
	EQUALITY booleanMatch 
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
	SINGLE-VALUE )

# 3.12 dicomHostname                      string    Single
#
#    This attribute stores a DNS hostname for a connection.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.12
	NAME 'dicomHostname'
	DESC 'DNS hostname'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.13 dicomPort                          integer   Single
#
#    This attribute stores a TCP port number for a connection.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Integer'.
#
attributetype ( 1.2.840.10008.15.0.3.13
	NAME 'dicomPort'
	DESC 'TCP Port number'
	EQUALITY  integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE )

# 3.14 dicomSOPClass                      OID       Single
#
#    This attribute stores a SOP Class UID
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'OID'.
#
attributetype ( 1.2.840.10008.15.0.3.14
	NAME 'dicomSOPClass'
	DESC 'A SOP Class UID'
	EQUALITY  objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
	SINGLE-VALUE )

# 3.15 dicomTransferRole                  String    Single
#
#    This attribute stores a transfer role (either "SCU" or "SCP").
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Directory String'.
#    Its case is not significant for equality and substring matches.
#
attributetype ( 1.2.840.10008.15.0.3.15
	NAME 'dicomTransferRole'
	DESC 'Transfer role (either "SCU" or "SCP")'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.16 dicomTransferSyntax                OID       Multiple
#
#    This attribute stores a Transfer Syntax UID
#
#    It is a multi-valued attribute. 
#    This attribute's syntax is 'OID'.
#
attributetype ( 1.2.840.10008.15.0.3.16
	NAME 'dicomTransferSyntax'
	DESC 'A Transfer Syntax UID'
	EQUALITY  objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

# 3.17 dicomPrimaryDeviceType             string    Multiple
#	
#    This attribute stores the primary type for a DICOM Device. 
#    Types should be selected from the list of code values (0008,0100) 
#    for Context ID 30 in DICOM Part 16 when applicable. 
#
#    It is a multiple-valued attribute. 
#    This attribute's syntax is 'IA5 String'.
#    Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.17
	NAME 'dicomPrimaryDeviceType'
	DESC 'The device Primary Device type'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 3.18 dicomRelatedDeviceReference        DN        Multiple
#
#    This attribute stores a reference to a related device description outside 
#    the DICOM Configuration Hierachy. Can be used to link the DICOM Device object to 
#    additional LDAP objects instantiated from other schema and used for 
#    separate administrative purposes. 
#
#    This attribute's syntax is 'Distinguished Name'.
#    It is a multiple-valued attribute. 
#
attributetype ( 1.2.840.10008.15.0.3.18
	NAME 'dicomRelatedDeviceReference'
	DESC 'The DN of a related device description outside the DICOM Configuration Hierachy'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 3.19 dicomPreferredCalledAETitle        string    Multiple
#
#    AE Title(s) to which associations may be preferably initiated. 
#
#    It is a multiple-valued attribute. 
#    This attribute's syntax is 'IA5 String'.
#    Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.19
	NAME 'dicomPreferredCalledAETitle'
	DESC 'AE Title(s) to which associations may be preferably initiated.'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 3.20 dicomTLSCipherSuite                string    Multiple
#
#    The attribute stores the supported TLS CipherSuites.
#    TLS CipherSuites shall be described using a RFC-2246 string representation 
#    (e.g., "TLS_RSA_WITH_RC4_128_SHA").
#
#    It is a multiple-valued attribute. 
#    This attribute's syntax is 'IA5 String'.
#    Its case is significant.
# 
attributetype ( 1.2.840.10008.15.0.3.20
	NAME 'dicomTLSCipherSuite'
	DESC 'The supported TLS CipherSuites'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 3.21  dicomAuthorizedNodeCertificateReference DN Multiple
#
#    This attribute stores a reference to a TLS public certificate for a DICOM
#    node that is authorized to connect to this node. The certificate 
#    is not necessarily stored within the DICOM Hierarchy
#
#    This attribute's syntax is 'Distinguished Name'.
#    It is a multiple-valued attribute. 
#
attributetype ( 1.2.840.10008.15.0.3.21
	NAME 'dicomAuthorizedNodeCertificateReference'
	DESC 'The DN of a Certificate for a DICOM node that is authorized to connect to this node'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 3.22 dicomThisNodeCertificateReference DN Multiple
#
#    This attribute stores a reference to a TLS public certificate for
#    this node. It is not necessarily stored as part of
#    the DICOM Configuration Hierachy.
#
#    This attribute's syntax is 'Distinguished Name'.
#    It is a multiple-valued attribute. 
#
attributetype ( 1.2.840.10008.15.0.3.22
	NAME 'dicomThisNodeCertificateReference'
	DESC 'The DN of a related device description outside the DICOM Configuration Hierachy'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 3.23 dicomInstalled                     bool      Single
#
#    This attribute indicates whether the object is presently installed.
#
#    It is a single-valued attribute. 
#    This attribute's syntax is 'Boolean'.
# 
attributetype ( 1.2.840.10008.15.0.3.23
	NAME 'dicomInstalled'
	DESC 'Indicates if the DICOM object (device, Network AE, or Port) is presently installed'
	EQUALITY booleanMatch 
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
	SINGLE-VALUE )

# 3.24	dicomStationName                  string    Single
#
#    This attribute stores the station name of the device.
#    Should be the same as the value of Station Name (0008,1010) in 
#    SOP instances created by this device.
#
#    It is a single-valued attribute.
#    This attribute's syntax is 'Directory String'.
# 
attributetype ( 1.2.840.10008.15.0.3.24
	NAME 'dicomStationName'
	DESC 'Station Name of the device. Should be the same as the value of Station
	      Name (0008,1010) in SOP instances created by this device.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE)

# 3.25	dicomDeviceSerialNumber           string    Single
#
#    This attribute stores the serial number of the device.
#    Should be the same as the value of Device Serial Number (0018,1000) 
#    in SOP instances created by this device.
#
#    It is a single-valued attribute.
#    This attribute's syntax is 'Directory String'.
# 
attributetype ( 1.2.840.10008.15.0.3.25
	NAME 'dicomDeviceSerialNumber'
	DESC 'Serial number of the device. Should be the same as the value of Device Serial
	      Number (0018,1000) in SOP instances created by this device.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE)

# 3.26	dicomInstitutionName              string    Multiple
#
#    This attribute stores the institution name of the device.
#    Should be the same as the value of Institution Name (0008,0080) 
#    in SOP Instances created by this device.
#
#    It is a multi-valued attribute.
#    This attribute's syntax is 'Directory String'.
# 
attributetype ( 1.2.840.10008.15.0.3.26
	NAME 'dicomInstitutionName'
	DESC 'Institution name of the device. Should be the same as the value of Institution
	      Name (0008,0080) in SOP Instances created by this device.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.27	dicomInstitutionAddress           string    Multiple
#
#    This attribute stores the institution address of the device.
#    Should be the same as the value of Institution Address (0008,0081) 
#    attribute in SOP Instances created by this device.
#
#    It is a multi-valued attribute.
#    This attribute's syntax is 'Directory String'.
# 
attributetype ( 1.2.840.10008.15.0.3.27
	NAME 'dicomInstitutionAddress'
	DESC 'Institution address of the device. Should be the same as the value of Institution
	      Address (0008,0081) attribute in SOP Instances created by this device.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.28	dicomInstitutionDepartmentName    string   Multiple
#
#    This attribute stores the institution department name of the device. 
#    Should be the same as the value of Institutional Department Name (0008,1040) 
#    in SOP Instances created by this device.
#
#    It is a multi-valued attribute.
#    This attribute's syntax is 'Directory String'.
# 
attributetype ( 1.2.840.10008.15.0.3.28
	NAME 'dicomInstitutionDepartmentName'
	DESC 'Institution department name of the device. Should be the same as the value of Institutional
	      Department Name (0008,1040) in SOP Instances created by this device.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.29	dicomIssuerOfPatientID            string    Single
#
#    This attribute stores the Default value for the Issuer of Patient ID (0010,0021) 
#    for SOP Instances created by this device. May be overridden by the values 
#    received in a worklist or other source.
#
#    It is a multi-valued attribute.
#    This attribute's syntax is 'Directory String'.
# 
attributetype ( 1.2.840.10008.15.0.3.29
	NAME 'dicomIssuerOfPatientID'
	DESC 'Default value for the Issuer of Patient ID (0010,0021) for SOP Instances created by this device.
	      May be overridden by the values received in a worklist or other source.'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.30	dicomPreferredCallingAETitle      string    Multiple
#
#    AE Title(s) to which associations may be preferably accepted. 
#
#    It is a multiple-valued attribute. 
#    This attribute's syntax is 'IA5 String'.
#    Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.30
	NAME 'dicomPreferredCallingAETitle'
	DESC 'AE Title(s) to which associations may be preferably accepted.'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 3.31	dicomSupportedCharacterSet        string    Multiple
#
#    The Character Set(s) supported by the Network AE for Data Sets it receives. 
#    Contains one of the Defined Terms for Specific Character Set (0008,0005). 
#    If not present, this implies that the Network AE supports only the default 
#    character repertoire (ISO IR 6). 
#
#    It is a multiple-valued attribute. 
#    This attribute's syntax is 'IA5 String'.
#    Its case is significant.
#
attributetype ( 1.2.840.10008.15.0.3.31
	NAME 'dicomSupportedCharacterSet'
	DESC 'The Character Set(s) supported by the Network AE for Data Sets it receives.'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 3.31 dicomInstitutionDepartmentType    string   Multiple
#
#    This attribute stores the institution department type of the device. 
#    Should be the same as the value of Institutional Department Type Code 
#    Sequence (0008,1041) in SOP Instances created by this device.
#    Types should be selected from the list of code values (0008,0100) 
#    for Context ID 7030 in DICOM Part 16 when applicable. 
#
#    It is a multi-valued attribute.
#    This attribute's syntax is 'IA5 String'.
# 
attributetype ( 1.2.840.10008.15.0.3.31
 NAME 'dicomInstitutionDepartmentType'
 DESC 'Institution department type of the device. Should be the same as the value of Institutional
       Department Type Code Sequence (0008,1041) in SOP Instances created by this device.'
 EQUALITY caseIgnoreMatch
 SUBSTR caseIgnoreSubstringsMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 4 Object Class Definitions
# 
#    The following object classes are defined in this document. All are
#    structural classes.
# 
#	Name                            Description
#	---------------------------     --------------------------
#	dicomConfigurationRoot          root of the DICOM Configuration Hierarchy
#	dicomDevicesRoot                root of the DICOM Devices Hierarchy
#	dicomUniqueAETitlesRegistryRoot	root of the Unique DICOM AE-Titles Registry Hierarchy
#	dicomDevice                     Devices
#	dicomNetworkAE                  Network AE
#	dicomNetworkConnection          Network Connections
#	dicomUniqueAETitle              Unique AE Title
#	dicomTransferCapability         Transfer Capability

# 
# 4.1 dicomConfigurationRoot
#
#    This structural object class represents the root of the DICOM Configuration Hierarchy. 
#    Only a single object of this type should exist within an organizational domain.
#    Clients can search for an object of this class to locate the root of the 
#    DICOM Configuration Hierarchy.
#
objectclass ( 1.2.840.10008.15.0.4.1
	NAME 'dicomConfigurationRoot'
	DESC 'Root of the DICOM Configuration Hierarchy'
	SUP top
	STRUCTURAL
	MUST ( cn ) 
	MAY ( description ) )

#
# 4.2 dicomDevicesRoot			
#
#    This structural object class represents the root of the DICOM Devices Hierarchy. 
#    Only a single object of this type should exist as a child of dicomConfigurationRoot.
#
objectclass ( 1.2.840.10008.15.0.4.2
	NAME 'dicomDevicesRoot'
	DESC 'Root of the DICOM Devices Hierarchy'
	SUP top
	STRUCTURAL
	MUST ( cn ) 
	MAY ( description ) )

#
# 4.3 dicomUniqueAETitlesRegistryRoot			
#
#    This structural object class represents the root of the Unique DICOM AE-Titles 
#    Registry Hierarchy. 
#    Only a single object of this type should exist as a child of dicomConfigurationRoot.
#
objectclass ( 1.2.840.10008.15.0.4.3
	NAME 'dicomUniqueAETitlesRegistryRoot'
	DESC 'Root of the Unique DICOM AE-Title Registry Hierarchy'
	SUP top
	STRUCTURAL
	MUST ( cn ) 
	MAY ( description ) )

#
# 4.4 dicomDevice
#
#    This structural object class represents a DICOM Device.
#
objectclass ( 1.2.840.10008.15.0.4.4
	NAME 'dicomDevice'
	DESC 'DICOM Device related information'
	SUP top
	STRUCTURAL
	MUST ( 
		dicomDeviceName $
		dicomInstalled ) 
	MAY  ( 
		dicomDescription $
		dicomManufacturer $
		dicomManufacturerModelName $
		dicomSoftwareVersion $
		dicomStationName $
		dicomDeviceSerialNumber $
		dicomInstitutionName $
		dicomInstitutionAddress $
		dicomInstitutionDepartmentName $
		dicomIssuerOfPatientID $
		dicomVendorData $
		dicomPrimaryDeviceType $
		dicomRelatedDeviceReference $
		dicomAuthorizedNodeCertificateReference $
		dicomThisNodeCertificateReference) )

#
# 4.5 dicomNetworkAE
#
#    This structural object class represents a Network Application Entity
#
objectclass ( 1.2.840.10008.15.0.4.5
	NAME 'dicomNetworkAE'
	DESC 'DICOM Network AE related information'
	SUP top
	STRUCTURAL
	MUST (
		dicomAETitle $ 
		dicomNetworkConnectionReference $
		dicomAssociationInitiator $
		dicomAssociationAcceptor )
	MAY ( 
		dicomDescription $
		dicomVendorData $
		dicomApplicationCluster $
		dicomPreferredCalledAETitle $
		dicomPreferredCallingAETitle $
		dicomSupportedCharacterSet $
		dicomInstalled ) )

#
# 4.6 dicomNetworkConnection
#
#    This structural object class represents a Network Connection
#
objectclass ( 1.2.840.10008.15.0.4.6
	NAME 'dicomNetworkConnection'
	DESC 'DICOM Network Connection information'
	SUP top
	STRUCTURAL
	MUST ( dicomHostname )
	MAY ( 
		cn $
		dicomPort $
		dicomTLSCipherSuite $
		dicomInstalled ) )

#
# 4.7 dicomUniqueAETitle
#
#    This structural object class represents a Unique Application Entity Title
#
objectclass ( 1.2.840.10008.15.0.4.7
	NAME 'dicomUniqueAETitle'
	DESC 'A Unique DICOM Application Entity title'
	SUP top
	STRUCTURAL
	MUST ( dicomAETitle ) )

#
# 4.8 dicomTransferCapability
#
#    This structural object class represents Transfer Capabilities for an Application Entity
#
objectclass ( 1.2.840.10008.15.0.4.8
	NAME 'dicomTransferCapability'
	DESC 'Transfer Capabilities for an Application Entity'
	SUP top
	STRUCTURAL
	MUST (
		dicomSOPClass $
		dicomTransferRole $
		dicomTransferSyntax)
	MAY (
		cn) )

H.1.4 Transactions

H.1.4.1 Find LDAP Server

H.1.4.1.1 Scope

The [RFC 2782] A DNS RR for specifying the location of services (DNS SRV) specifies a mechanism for requesting the names and rudimentary descriptions for machines that provide network services. The DNS client requests the descriptions for all machines that are registered as offering a particular service name. In this case the service name requested will be "LDAP". The DNS server may respond with multiple names for a single request.

H.1.4.1.2 Use Case Roles

Find LDAP Server

Figure H.1-3. Find LDAP Server


DNS Server

Provides list of LDAP servers

LDAP Client

Requests list of LDAP servers

H.1.4.1.3 Referenced Standards

[RFC 2181] Clarifications to the DNS Specification

[RFC 2219] Use of DNS Aliases for Network Services

[RFC 2782] A DNS RR for specifying the location of services (DNS SRV)

other RFC's are included by reference from [RFC 2181], [RFC 2219], and [RFC 2782].

H.1.4.1.4 Interaction Diagram

Select LDAP Server

Figure H.1-4. Select LDAP Server


The DNS client shall request a list of all the LDAP servers available. It will use the priority, capacity, and location information provided by DNS to select a server ([RFC 2782] recommends the proper use of these parameters). It is possible that there is no LDAP server, or that the DNS server does not support the SRV RR request.

Note

  1. Multiple LDAP servers providing access to a common replicated LDAP database is a commonly supported configuration. This permits LDAP servers to be located where appropriate for best performance and fault tolerance. The DNS server response information provides guidance for selecting the most appropriate server.

  2. There may also be multiple LDAP servers providing different databases. In this situation the client may have to examine several servers to find the one that supports the DICOM configuration database. Similarly a single LDAP server may support multiple base DNs, and the client will need to check each of these DNs to determine which is the DICOM supporting tree.

H.1.4.1.5 Alternative Paths

The client may have a mechanism for manual default selection of the LDAP server to be used if the DNS server does not provide an LDAP server location.

H.1.4.2 Query LDAP Server

H.1.4.2.1 Scope

The [RFC 2251] "Lightweight Directory Access Protocol (v3)" specifies a mechanism for making queries of a database corresponding to an LDAP schema. The LDAP client can compose requests in the LDAP query language, and the LDAP server will respond with the results for a single request.

H.1.4.2.2 Use Case Roles

Query LDAP Server

Figure H.1-5. Query LDAP Server


LDAP Server

Provides query response

LDAP Client

Requests LDAP information

H.1.4.2.3 Referenced Standards

[RFC 2251] Lightweight Directory Access Protocol (v3). LDAP support requires compliance with other RFC's invoked by reference.

H.1.4.2.4 Interaction Description

The LDAP client may make a wide variety of queries and cascaded queries using LDAP. The LDAP client and server shall support the Application Configuration Data Model .

Note

Multiple LDAP servers providing access to a common replicated LDAP database is a commonly supported configuration. This permits LDAP servers to be located where appropriate for best performance and fault tolerance. The replications rules chosen for the LDAP servers affect the visible data consistency. LDAP permits inconsistent views of the database during updates and replications.

H.1.4.3 Update LDAP Server

H.1.4.3.1 Scope

The [RFC 2251] "Lightweight Directory Access Protocol (v3)" specifies a mechanism for making updates to a database corresponding to an LDAP schema. The LDAP client can compose updates in the LDAP query language, and the LDAP server will respond with the results for a single request. Update requests may be refused for security reasons.

H.1.4.3.2 Use Case Roles

Update LDAP Server

Figure H.1-6. Update LDAP Server


LDAP Server

Maintains database

LDAP Client

Updates LDAP information

H.1.4.3.3 Referenced Standards

[RFC 2251] Lightweight Directory Access Protocol (v3). LDAP support requires compliance with other RFC's invoked by reference.

H.1.4.3.4 Interaction Description

The LDAP client may make a request to update the LDAP database. The LDAP client shall support the data model described above. The LDAP server may choose to refuse the update request for security reasons. If the LDAP server permits update requests, is shall support the data model described above.

Note

Multiple LDAP servers providing access to a common replicated LDAP database is a commonly supported configuration. This permits LDAP servers to be located where appropriate for best performance and fault tolerance. Inappropriate selection of replication rules in the configuration of the LDAP server will result in failure for AE-title uniqueness when creating the AE-titles objects.

H.1.4.3.5 Special Update For Network AE Creation

The creation of a new Network AE requires special action. The following steps shall be followed:

  1. A tentative AE title shall be selected. Various algorithms are possible, ranging from generating a random name to starting with a preset name template and incrementing a counter field. The client may query the Unique AE Titles Registry sub-tree to obtain the complete list of names that are presently in use as part of this process.

  2. A new Unique AE Title object shall be created in the Unique AE Titles Registry portion of the hierarchy with the tentative name. The LDAP server enforces uniqueness of names at any specific point in the hierarchy.

  3. If the new object creation was successful, this shall be the AE Title used for the new Network AE.

  4. If the new object creation fails due to non-unique name, return to a) and select another name.

H.1.4.4 Maintain LDAP Server

The LDAP server shall support a separate manual or automated means of maintaining the LDAP database contents. The LDAP server shall support the [RFC 2849] file format mechanism for updating the LDAP database. The LDAP Client or service installation tools shall provide [RFC 2849] formatted files to update LDAP server databases manually. The LDAP server may refuse client network updates for security reasons. If this is the case, then the maintenance process will be used to maintain the LDAP database.

The manual update procedures are not specified other than the requirement above that at least the minimal LDAP information exchange file format from [RFC 2849] be supported. The exact mechanisms for transferring this information remain vendor and site specific. In some situations, for example the creation of AE-titles, a purely manual update mechanism may be easier than exchanging files.

The conformance statement shall document the mechanisms available for transferring this information. Typical mechanisms include:

  1. floppy disk

  2. CD-R

  3. SSH

  4. Secure FTP

  5. FTP

  6. email

  7. HTTPS

Note

  1. There are many automated and semi-automatic tools for maintaining LDAP databases. Many LDAP servers provide GUI interfaces and updating tools. The specifics of these tools are outside the scope of DICOM. The LDAP [RFC 2849] requires at least a minimal data exchange capability. There are also XML based tools for creating and maintaining these files.

  2. This mechanism may also be highly effective for preparing a new network installation by means of a single pre-planned network configuration setup rather than individual machine updates.

H.1.5 LDAP Security Considerations (Informative)

H.1.5.1 Threat Assessment

The threat and value for the LDAP based configuration mechanisms fall into categories:

  1. AE-uniqueness mechanism

  2. Finding (and updating) Network AE descriptions

  3. Finding (and updating) device descriptions

These each pose different vulnerabilities to attack. These are:

  1. Active Attacks

    1. The AE-title uniqueness mechanism could be attacked by creating vast numbers of spurious AE-titles. This could be a Denial of Service (DoS) attack on the LDAP server. It has a low probability of interfering with DICOM operations.

    2. The Network AE information could be maliciously updated. This would interfere with DICOM operations by interfering with finding the proper server. It could direct connections to malicious nodes, although the use of TLS authentication for DICOM connections would detect such misdirection. When TLS authentication is in place this becomes a DoS attack.

    3. The device descriptions could be maliciously modified. This would interfere with proper device operation.

  2. Passive Attacks

    1. There is no apparent value to an attacker in obtaining the current list of AE-titles. This does not indicate where these AE-titles are deployed or on what equipment.

    2. The Network AE information and device descriptions might be of value in determining the location of vulnerable systems. If it is known that a particular model of equipment from a particular vendor is vulnerable to a specific attack, then the Network AE Information can be used to find that equipment.

H.1.5.2 Available LDAP Security Mechanisms

The security mechanisms for LDAP are highly variable in actual implementations. They are a mixture of administrative restrictions and protocol implementations. The widely available options for security methods are:

  1. Anonymous access, where there is no restriction on performing this function over the network.

  2. Basic, where there is a username and password exchange prior to granting access to this function. The exchange is vulnerable to snooping, spoofing, and man in the middle attacks.

  3. TLS, where there is an SSL/TLS exchange during connection establishment.

  4. Manual, where no network access is permitted and the function must be performed manually at the server, or semi-automatically at the server. The semi-automatic means permit the use of independently exchanged files (e.g., via floppy) together with manual commands at the server.

The categories of functions that may be independently controlled are:

  1. Read related, to read, query, or otherwise obtain a portion of the LDAP directory tree

  2. Update related, to modify previously existing objects in the directory tree

  3. Create, to create new objects in the directory tree.

Finally, these rules may be applied differently to different subtrees within the overall LDAP structure. The specific details of Access Control Lists (ACLs), functional controls, etc. vary somewhat between different LDAP implementations.

H.1.5.3 Recommendations (Informative)

The LDAP server should be able to specify different restrictions for the AE-Title list and for the remainder of the configuration information. To facilitate interoperability, Table H.1-15 defines several patterns for access control. They correspond to different assessments of risk for a network environment.

Table H.1-15. LDAP Security Patterns

TLS

TLS-Manual

Basic

Basic-Manual

Anonymous

Anonymous-Manual

Read AE-title

Anonymous, TLS

Anonymous, TLS

Anonymous, Basic

Anonymous, Basic

Anonymous

Anonymous

Create AE-Title

TLS

Manual

Basic

Manual

Anonymous

Manual

Read Config

TLS

TLS

Basic

Basic

Anonymous

Anonymous

Update Config

TLS

Manual

Basic

Manual

Anonymous

Manual

Create Config

TLS

Manual

Basic

Manual

Anonymous

Manual

TLS

This pattern provides SSL/TLS authentication and encryption between client and server. It requires additional setup during installation because the TLS certificate information needs to be installed onto the client machines and server. Once the certificates are installed the clients may then perform full updating operations.

TLS-Manual

This pattern provides SSL/TLS controls for read access to information and require manual intervention to perform update and creation functions.

Basic

This pattern utilizes the LDAP basic security to gain access to the LDAP database. It requires the installation of a password during client setup. It does not provide encryption protection. Once the password is installed, the client can then perform updates.

Basic-Manual

This pattern utilizes basic security protection for read access to the configuration information and requires manual intervention to perform update and creation functions.

Anonymous

This pattern permits full read/update access to all machines on the network.

Anonymous-Manual

This pattern permits full read access to all machines on the network, but requires manual intervention to perform update and creation.

A client or server implementation may be capable of being configured to support multiple patterns. This should be documented in the conformance claim. The specific configuration in use at a specific site can then be determined at installation time.

H.1.6 Implementation Considerations (Informative)

The LDAP database can be used as a documentation tool. Documenting the configuration for both managed and legacy machines makes upgrading easier and reduces the error rate for manually configured legacy equipment.

There are various possible implementation strategies for clients performing lookups within the LDAP database. For example, before initiating a DICOM association to a specific AE, a client implementation could either:

  1. Query the LDAP database to obtain hostname and port for the specific AE Title immediately prior to initiating a DICOM association.

  2. Maintain a local cache of AE Title, hostname and port information and only query the LDAP database if the specific AE Title is not found in the local cache.

The advantages of maintaining a local cache include performance (by avoiding frequent lookups) and reliability (should the LDAP server be temporarily unavailable). The disadvantage of a cache is that it can become outdated over time. Client implementations should provide appropriate mechanisms to purge locally cached information.

Client caches may cause confusion during updates. Manual steps may be needed to trigger immediate updates. LDAP database replication also may introduce delays and inconsistencies. Database replication may also require manual intervention to force updates to occur immediately.

One strategy to reduce client cache problems is to re-acquire new DNS and LDAP information after any network association information. Often the first symptom of stale cache information is association failures due to the use of obsolete configuration information.

Some LDAP servers do not support a "modify DN" operation. For example, in the case of renaming a device on such a server, a tree copy operation may be needed to create a new object tree using the new name, followed by removal of the old object tree. After such a rename the device may need to search using other attributes when finding its own configuration information, e.g., the device serial number.

H.1.7 Conformance

The Conformance Statement for an LDAP Client or LDAP Server implementation shall specify the security pattern(s) that it supports.

H.2 DNS Service Discovery

H.2.1 Scope

Service discovery mechanisms provide a means for devices to announce their presence and seek information about the existence of other services on the network. Many of these mechanisms are DNS-based.

The exact use of such protocols as DNS Service Discovery (DNS-SD), Multi-cast DNS (mDNS) and DNS Dynamic Updates is defined in RFC's referenced by DICOM. This section standardizes the name to be used in DNS SRV records for such purposes, and the DNS TXT records that encode accompanying parameters.

Security issues associated with self-discovery are out of scope. See Section F.1.1.4 for the informative discussion on DNS Security issues.

H.2.2 Use Case Roles

Find DICOM Service

Figure H.2-1. Find DICOM Service


DNS Server

Provides list of DICOM Association Acceptors

DNS Client

Requests list of DICOM Association Acceptors

H.2.3 Referenced Standards

[RFC 2136] DNS Dynamic Updates

[RFC 2181] Clarifications to the DNS Specification

[RFC 2219] Use of DNS Aliases for Network Services

[RFC 2782] A DNS RR for specifying the location of services (DNS SRV)

[RFC 6762] Multicast DNS

[RFC 6763] DNS-Based Service Discovery

[RFC 8553] DNS AttrLeaf Changes

[DNS-SD] DNS Self-Discovery

The name to be used in the DNS SRV to advertise DICOM Association Acceptors, regardless of the SOP Class(es) supported, shall be

  • "dicom" for unsecured DICOM communication

  • "dicom-tls" for the Basic TLS Secure Transport Connection Profile

  • "dicom-iscl" for ISCL Transport Connection Profile

  • "dicomweb" for DICOM web services over unsecured http

  • "dicomweb-tls" for DICOM web services over https

Note

These choices are consistent with the names registered with IANA to define the mapping of IP ports to services, which is conventional for this usage. The choice "dicom" is used rather than the "acr-nema" alternative for clarity. There is no implied port choice by the usage in the DNS SRV Service Type, since the port is explicitly conveyed.

The DNS TXT record may contain the following parameters:

  • AET= <application entity title>, where the value <application entity title>is to be used as the Called Application Entity Title when initiating Associations to the device

  • PrimaryDeviceType= <primary device type>, where the value <primary device type>is as defined Table H.1-2 Attributes of Device Object

  • DICOMWebPath= <service>, where the value <service> is the path component of the DICOM Web Service root as defined in PS3.18

In the absence of a DNS TXT record, or the AET parameter of the DNS TXT record, then the Instance Name preceding the Service Type in the DNS SRV record used for DICOM service discovery shall be the AET.

Note

Further parameters are not specified, for example to indicate the SOP Classes supported or other information, since the size of DNS records encoded as UDP datagrams is strictly limited, and furthermore, the envisaged multicast usage encourages the exchange of the minimal information necessary. The existing DICOM association negotiation mechanism can be used to explore the SOP Classes offered once the IP address, port number and AET are known. The primary device type is supplied because it is useful to indicate to users the type of device, which is not conveyed during association establishment.

H.2.4 Examples

Example SRV record:

  • _dicomweb-tls._tcp. examplehospital.org 86400 IN SRV 10 60 443 dicomweb.examplehospital.org.

Example TXT record:

  • dicomweb.examplehospital.org IN TXT "DICOMWebPath=apps/dicom-rs"

The above examples would combine to define a DICOM web service root of:

  • "https://dicomweb.examplehospital.org:443/apps/dicom-rs"

H.2.5 Conformance

An implementation that supports this profile shall state in its Conformance Statement whether it supports reading (DNS Client) or writing DNS (DNS Server) records.

An implementation that supports this profile shall state in its Conformance Statement whether it supports DNSSEC [RFC 4033] [RFC 4034] [RFC 4035] for the interactions described in this profile, in which case either the options supported shall be stated or a reference provided to the DNSSEC support for this product.