| DICOM PS3.17 2024c - Explanatory Information |
|---|
DICOM is not prescriptive with respect to user identification, authorization, access control, orsecure transport. However, DICOM does provide enabling capabilities for security features (see Section D.3.3.7 “User Identity Negotiation” in PS3.7), and specifies available profiles for some aspects of secure access and transport (see Annex B “Secure Transport Connection Profiles (Normative)” in PS3.15). As DICOM deals with exchange of legally protected health information, every real-world deployment must address these security features through institutional policies, procedures, and technical mechanisms. The specifics will vary with the organization and the capabilities of the technical infrastructure, including DICOM applications.
Inventories may potentially include data on all patients within a healthcare organization. Unauthorized access to inventory objects may thus potentially be a data breach affecting all patients. The breadth of the inventory makes it of particular concern for access control and transport security, and may require special attention in the institutional security policies, procedures, and technical mechanisms.
The Standard describes the use of DICOM and non-DICOM protocols to access stored SOP Instances, both Inventory objects and DICOM data in the repository (see Annex P “Stored File Access Through Non-DICOM Protocols (Normative)” in PS3.3). All such protocols support technical means for access control and transport security, which must be used in accordance with institutional security policies and procedures. Although the Inventory identifies the available access mechanisms, there are no data elements for storing access credentials, as placing them in the Inventory would present significant security vulnerabilities. Processes for a reading application to obtain access credentials must be handled by non-DICOM mechanisms.
Access control mechanisms must also address audit logs for recording access to protected health information. Both the technical means of recording user identity and the organizational policies and procedures to effectively use those technical means need to be considered.
A repository might limit disclosure or retrieval of SOP instances, studies, or patients following a variety of authorization policies and data protection rules, often based on the user's identity and/or Attributes of the instance data. Such limits might be implemented at different layers of the repository software architecture (file system, database management system, application, etc.).
The identity of the initiator of Inventory production might be known to the production application, e.g., if initiated from a local user interface, or if conveyed in the secure transport layer of the Inventory Creation service. That user identity might affect the content of an Inventory by triggering various data protection rules.
The Inventory IOD has no means of identifying whether such protection rules have been invoked, and thus whether the inventory may be incomplete with respect to the restricted data. In some cases, the fact that protection rules have been invoked, or even the existence of such rules, is not disclosed to using applications.
The implementers and users of an Inventory production application should be cognizant of the potential effect of user identity and permissions on the content of the produced Inventory SOP Instances. Implementers may disclose in the product DICOM Conformance Statement section on Application Level Security any access control features that might impact Inventory production. Users should verify that access controls are not inappropriately impacting Inventory production.
| DICOM PS3.17 2024c - Explanatory Information |
|---|