DICOM PS3.15 2026b - Профили безопасности и управления системой
Copyright © 2026 NEMA
Содержание
- Уведомление и отказ от ответственности
- Предисловие
- 1. Область применения
- 2. Нормативные ссылки
- 3. Определения
- 4. Символы и сокращения
- 5. Соглашения
- 6. Обзор профилей безопасности и управления системой
-
- 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. Профили конфигурации
- A. Secure Use Profiles (профили защищенного использования) (нормативное)
-
- A.1. Online Electronic Storage Secure Use Profile (профиль защищенного использования онлайн-электронного хранения)
- 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 (базовый профиль защищенного использования цифровых подписей SR)
- A.5. Audit Trail Message Format Profile (профиль формата сообщений журнала аудита)
-
- A.5.1. DICOM Audit Message Schema (схема сообщения аудита DICOM)
-
- 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.1.2.5. Network Access Point 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.2.7. RoleIDCode (код роли)
- A.5.3. DICOM Specific Audit Messages (специальные сообщения аудита DICOM)
-
- A.5.3.1. Application Activity (активность приложения)
- A.5.3.2. Audit Log Used (использование журнала аудита)
- A.5.3.3. Begin Transferring DICOM Instances (начало передачи экземпляров DICOM)
- A.5.3.4. Data Export (экспорт данных)
- A.5.3.5. Data Import (импорт данных)
- A.5.3.6. DICOM Instances Accessed (доступ к экземплярам DICOM)
- A.5.3.7. DICOM Instances Transferred (экземпляры DICOM переданы)
- A.5.3.8. DICOM Study Deleted (исследование DICOM удалено)
- 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. Профиль передачи сообщений аудиторского следа - SYSLOG-TLS
- A.7. Профиль передачи сообщений аудиторского следа - SYSLOG-UDP
- B. Профили защищённого транспортного соединения (нормативное)
-
- B.1. Basic TLS Secure Transport Connection Profile (базовый профиль защищённого TLS-соединения)
- B.2. ISCL Secure Transport Connection Profile (профиль защищённого соединения ISCL)
- B.3. AES TLS Secure Transport Connection Profile (профиль защищённого TLS-соединения AES)
- B.4. Basic User Identity Association Profile (базовый профиль идентификации пользователя при ассоциации)
- B.5. User Identity Plus Passcode Association Profile (профиль идентификации пользователя с кодом доступа при ассоциации)
- B.6. Kerberos Identity Negotiation Association Profile (профиль согласования идентификации Kerberos при ассоциации)
- B.7. Generic SAML Assertion Identity Negotiation Association Profile (профиль согласования идентификации с утверждением SAML при ассоциации)
- B.8. Secure Use of Email Transport (безопасное использование транспорта электронной почты)
- B.9. BCP 195 TLS Secure Transport Connection Profile (профиль защищённого TLS-соединения BCP 195)
- B.10. Non-Downgrading BCP 195 TLS Secure Transport Connection Profile (профиль BCP 195 TLS без понижения защиты)
- B.11. Extended BCP 195 TLS Profile Secure Transport Connection Profile (расширенный профиль защищённого TLS-соединения BCP 195)
- B.12. BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile (профиль защищённого TLS-соединения BCP 195 RFC 8996, 9325)
- B.13. Modified BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile (модифицированный профиль защищённого TLS-соединения BCP 195 RFC 8996, 9325)
- C. Digital Signature Profiles (Normative) (профили цифровой подписи)
-
- C.1. Base RSA Digital Signature Profile (базовый профиль цифровой подписи RSA)
- C.2. Creator RSA Digital Signature Profile (профиль цифровой подписи создателя на основе RSA)
- C.3. Authorization RSA Digital Signature Profile (профиль авторизационной цифровой подписи RSA)
- C.4. Structured Report RSA Digital Signature Profile (профиль цифровой подписи структурированного отчёта RSA)
- D. Media Storage Security Profiles (Normative) (профили безопасности хранения на носителях)
- E. Attribute Confidentiality Profiles (Normative) (профили конфиденциальности атрибутов)
-
- E.1. Application Level Confidentiality Profile (профиль конфиденциальности на уровне приложения)
- 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 (опция сохранения UID)
- 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) (вопросы безопасности DNS, справочно)
- F.1.1.5. DNS Implementation Considerations (Informative) (особенности реализации DNS, справочно)
- F.1.1.6. Support For Service Discovery (поддержка обнаружения служб)
- F.1.2. Configure DHCPserver (настройка DHCP-сервера)
- F.1.3. Find and Use DHCP Server (поиск и использование DHCP-сервера)
- F.1.4. Maintain Lease (поддержание аренды адреса)
- F.1.5. DDNS Coordination (координация DDNS)
- F.1.6. DHCP Security Considerations (Informative) (вопросы безопасности DHCP, справочно)
- F.1.7. DHCP Implementation Considerations (Informative) (особенности реализации DHCP, справочно)
- F.1.8. Conformance (соответствие)
- G. Time Synchronization Profiles (профили синхронизации времени)
-
- G.1. Basic Time Synchronization Profile (базовый профиль синхронизации времени)
-
- G.1.1. Find NTP Servers (поиск NTP-серверов)
-
- 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.3. NTP Security Considerations (Informative) (вопросы безопасности NTP, справочно)
- G.1.4. NTP Implementation Considerations (Informative) (особенности реализации NTP, справочно)
- 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 (корень конфигурации DICOM)
- H.1.1.6. Devices Root (корень устройств)
- H.1.1.7. Unique AE Titles Registry Root (корень реестра уникальных AE Title)
- H.1.1.8. Unique AE Title (уникальный AE Title)
- H.1.2. Application Configuration Data Model Hierarchy (иерархия модели данных конфигурации приложений)
- H.1.3. LDAP Schema For Objects and Attributes (схема LDAP для объектов и атрибутов)
- H.1.4. Transactions (транзакции)
-
- H.1.4.1. Find LDAP Server (поиск LDAP-сервера)
- H.1.4.2. Query LDAP Server (запрос к LDAP-серверу)
- H.1.4.3. Update LDAP Server (обновление LDAP-сервера)
-
- 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 (специальное обновление при создании Network AE)
- H.1.4.4. Maintain LDAP Server (обслуживание LDAP-сервера)
- H.1.5. LDAP Security Considerations (Informative) (вопросы безопасности LDAP, справочно)
- H.1.6. Implementation Considerations (Informative) (особенности реализации, справочно)
- H.1.7. Conformance (соответствие)
- H.2. DNS Service Discovery (обнаружение служб DNS)
List of Figures
- 7-1. Transactions and Actors (транзакции и акторы)
- F.1-1. Resolve Hostname (разрешение имени хоста)
- F.1-2. DNS Referenced Standards (используемые стандарты DNS)
- F.1-3. Configure DHCP Server (настройка DHCP-сервера)
- F.1-4. Find and Use DHCP Server (поиск и использование DHCP-сервера)
- F.1-5. DHCP Interactions (взаимодействия DHCP)
- F.1-6. Maintain Lease (поддержание аренды адреса)
- F.1-7. DDNS Coordination (координация DDNS)
- G.1-1. Find NTP Servers (поиск NTP-серверов)
- G.2-1. Maintain Time (поддержание времени)
- H.1-1. Application Configuration Data Model (модель данных конфигурации приложений)
- H.1-2. DICOM Configuration Hierarchy
- H.1-3. Find LDAP Server (поиск LDAP-сервера)
- H.1-4. Select LDAP Server (выбор LDAP-сервера)
- H.1-5. Query LDAP Server (запрос к LDAP-серверу)
- H.1-6. Update LDAP Server (обновление LDAP-сервера)
- H.2-1. Find DICOM Service (поиск службы DICOM)
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.1.2.5-1. Network Access Point Type Code Values
- A.5.2-1. General Message Format
- A.5.2.6-1. Participant Object Type Code Role Values
- A.5.3.1-1. Application Activity Message
- A.5.3.2-1. Сообщение Audit Log Used
- A.5.3.3-1. Сообщение аудита для Begin Transferring DICOM Instances
- A.5.3.4-1. Сообщение аудита для Data Export
- A.5.3.5-1. Сообщение аудита для Data Import
- A.5.3.6-1. Сообщение аудита для DICOM Instances Accessed
- A.5.3.7-1. Сообщение аудита для DICOM Instances Transferred
- A.5.3.8-1. Сообщение аудита для DICOM Study Deleted
- A.5.3.9-1. Сообщение аудита для Network Entry
- A.5.3.10-1. Сообщение аудита для Query
- A.5.3.11-1. Сообщение аудита для Security Alert
- A.5.3.12-1. Сообщение аудита для User Authentication
- A.5.3.13-1. Сообщение аудита для Order Record
- A.5.3.14-1. Сообщение аудита для Patient Record
- A.5.3.15-1. Сообщение аудита для Procedure Record
- B.4-1. Минимальные механизмы для функций согласования ассоциации DICOM - Basic User Identity Association Profile
- B.5-1. User Identity Plus Passcode Association Profile - минимальные механизмы для функций согласования ассоциации DICOM
- B.6-1. Kerberos Identity Negotiation Association Profile - минимальные механизмы для функций согласования ассоциации DICOM
- B.7-1. Generic SAML Assertion Identity Negotiation Association Profile - минимальные механизмы для функций согласования ассоциации DICOM
- 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 (коды Concept Name для Content Item)
- E.3.10-1. Safe Private Attributes (безопасные частные атрибуты)
- F.1-1. Basic Network Address Management Profile (базовый профиль управления сетевыми адресами)
- F.1-2. DHCP Parameters (параметры DHCP)
- 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
Информация в этой публикации на момент ее разработки была признана технически обоснованной консенсусом лиц, участвовавших в разработке и утверждении документа. Консенсус не обязательно означает единогласное согласие каждого лица, участвовавшего в разработке этого документа.
Стандарты и руководящие публикации NEMA, к которым относится данный документ, разрабатываются в рамках добровольного процесса разработки стандартов на основе консенсуса. Этот процесс объединяет добровольных участников и/или учитывает мнения лиц, заинтересованных в теме, рассматриваемой в данной публикации. Хотя NEMA администрирует процесс и устанавливает правила, способствующие справедливости при достижении консенсуса, NEMA не пишет документ и самостоятельно не проверяет, не оценивает и не подтверждает точность или полноту какой-либо информации либо обоснованность каких-либо суждений, содержащихся в ее стандартах и руководящих публикациях.
NEMA отказывается от ответственности за любые травмы, ущерб имуществу или иной ущерб любого характера, включая специальный, косвенный, последующий или компенсационный ущерб, прямо или косвенно возникающий в результате публикации, использования, применения этого документа или доверия к нему. NEMA отказывается от каких-либо гарантий, явных или подразумеваемых, в отношении точности или полноты опубликованной здесь информации, а также не гарантирует, что информация в этом документе будет соответствовать каким-либо конкретным целям или потребностям пользователя. NEMA не берет на себя обязательств гарантировать характеристики продуктов или услуг какого-либо отдельного производителя или продавца в силу этого стандарта или руководства.
Публикуя и предоставляя этот документ, NEMA не берет на себя оказание профессиональных или иных услуг для какого-либо лица или организации либо от их имени, а также не берет на себя выполнение обязанностей, которые какое-либо лицо или организация несет перед третьими лицами. Любой пользователь этого документа должен полагаться на собственное независимое суждение или, при необходимости, обращаться за советом к компетентному специалисту при определении разумной степени осторожности в конкретных обстоятельствах. Информация и другие стандарты по теме этой публикации могут быть доступны из других источников, к которым пользователь может обратиться для получения дополнительных мнений или информации, не охваченных данной публикацией.
NEMA не обладает полномочиями и не берет на себя обязательств контролировать или обеспечивать соблюдение содержания этого документа. NEMA не сертифицирует, не испытывает и не инспектирует продукты, проекты или установки в целях безопасности или охраны здоровья. Любая сертификация или иное заявление о соответствии любой информации, связанной со здоровьем или безопасностью, содержащейся в этом документе, не может относиться к NEMA и является исключительно ответственностью лица, выполняющего сертификацию или делающее такое заявление.
Этот стандарт DICOM был разработан в соответствии с процедурами Комитета по стандартам DICOM.
Стандарт DICOM построен как многочастный документ с использованием руководящих принципов, установленных в [ISO/IEC Directives, Part 2].
DICOM® является зарегистрированным товарным знаком National Electrical Manufacturers Association (Национальная ассоциация производителей электрооборудования) для публикаций ее стандартов, относящихся к цифровой передаче медицинской информации; все права защищены.
HL7® и CDA® являются зарегистрированными товарными знаками Health Level Seven International; все права защищены.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology Standards Development Organisation (IHTSDO), all rights reserved.
LOINC® является зарегистрированным товарным знаком Regenstrief Institute, Inc; все права защищены.
Эта часть стандарта DICOM определяет профили безопасности и управления системой, соответствие которым могут заявлять реализации. Профили безопасности и управления системой определяются посредством ссылок на внешне разработанные стандартные протоколы, такие как TLS, ISCL, DHCP и LDAP, с учетом их использования в системе, применяющей протоколы стандарта DICOM для обмена информацией.
Стандарт DICOM не рассматривает вопросы политик безопасности, хотя очевидно, что соблюдение надлежащих политик безопасности необходимо для любого уровня безопасности. Стандарт предоставляет только механизмы, которые могут использоваться для реализации политик безопасности применительно к обмену объектами DICOM между Application Entities. Например, политика безопасности может предписывать некоторый уровень контроля доступа. Этот стандарт не рассматривает политики контроля доступа, но предоставляет технологические средства, позволяющие участвующим Application Entities обмениваться достаточной информацией для реализации политик контроля доступа.
Этот стандарт предполагает, что Application Entities, участвующие в обмене DICOM, реализуют надлежащие политики безопасности, включая, помимо прочего, контроль доступа, журналы аудита, физическую защиту, поддержание конфиденциальности и целостности данных, а также механизмы идентификации пользователей и их прав доступа к данным. По существу, каждая Application Entity (прикладная сущность) должна обеспечить безопасность своей локальной среды еще до попытки установить защищенную связь с другими Application Entities.
Когда Application Entities согласуют обмен информацией через DICOM посредством согласования ассоциации, они фактически соглашаются на некоторый уровень доверия к другим Application Entities. В первую очередь Application Entities доверяют своим партнерам по связи в том, что те будут поддерживать конфиденциальность и целостность данных, находящихся под их контролем. Разумеется, этот уровень доверия может определяться локальными политиками безопасности и контроля доступа.
Application Entities могут не доверять каналу связи, по которому они взаимодействуют с другими Application Entities. Поэтому этот стандарт предоставляет механизмы, позволяющие Application Entities безопасно аутентифицировать друг друга, обнаруживать любое вмешательство или изменение передаваемых сообщений и защищать конфиденциальность этих сообщений при прохождении по каналу связи. Application Entities могут дополнительно использовать любой из этих механизмов в зависимости от уровня доверия, который они оказывают каналу связи.
Этот стандарт предполагает, что Application Entities могут безопасно идентифицировать локальных пользователей Application Entity (прикладная сущность), а также роли или полномочия таких пользователей. Следует учитывать, что пользователями могут быть люди или абстрактные сущности, например организации или единицы оборудования. Когда Application Entities согласуют обмен информацией через DICOM, они также могут обмениваться информацией о пользователях Application Entity (прикладная сущность) через сертификаты, передаваемые при установлении защищенного канала. Затем Application Entity (прикладная сущность) может учитывать информацию, содержащуюся в сертификатах о пользователях, локальных или удаленных, при реализации политики контроля доступа или при формировании журналов аудита.
Этот стандарт также предполагает, что Application Entities имеют средства для определения того, разрешили ли «владельцы» информации (например, пациент или учреждение) конкретным пользователям или классам пользователей доступ к информации. Кроме того, стандарт предполагает, что такое разрешение может учитываться в контроле доступа, предоставляемом Application Entity (прикладная сущность). В настоящее время этот стандарт не рассматривает, как такое разрешение может передаваться между Application Entities, хотя это может стать предметом рассмотрения в будущем.
Этот стандарт также предполагает, что Application Entity (прикладная сущность), использующая TLS, имеет защищенный доступ к сертификатам ключей [ITU-T X.509] для пользователей прикладной сущности или может безопасно получить такие сертификаты. Кроме того, стандарт предполагает, что Application Entity (прикладная сущность) имеет средства для проверки сертификата [ITU-T X.509], который она получает. Механизм проверки может использовать локально администрируемые центры, общедоступные центры или доверенную третью сторону.
Этот стандарт предполагает, что Application Entity (прикладная сущность), использующая ISCL, имеет доступ к соответствующей системе управления ключами и их распространения (например, смарт-картам). Характер и использование такой системы управления и распространения ключей выходят за рамки DICOM, хотя она может быть частью политик безопасности, используемых на конкретных площадках.
Профили управления системой, указанные в этой части, предназначены для поддержки автоматизации процессов управления конфигурацией, необходимых для эксплуатации системы, использующей протоколы стандарта DICOM для обмена информацией.
Эта часть предполагает, что Application Entities могут работать в различных сетевых средах разной сложности. Такие среды могут варьироваться от нескольких устройств, работающих в изолированной сети, до сети уровня отделения с некоторыми ограниченными централизованными сетевыми службами поддержки и до сети уровня предприятия со значительными службами сетевого управления. Следует отметить, что профили управления системой обычно адресованы реализации, а не Application Entities. Одни и те же профили должны поддерживаться различными приложениями в сети.
Следующие стандарты содержат положения, которые посредством ссылки в этом тексте составляют положения настоящего стандарта. На момент публикации указанные редакции были действующими. Все стандарты подлежат пересмотру, и сторонам соглашений, основанных на настоящем стандарте, рекомендуется изучать возможность применения наиболее новых редакций указанных ниже стандартов.
Примечание
Нормативные RFC часто обновляются путем выпуска последующих RFC. Исходный более старый RFC не изменяется для включения ссылок на более новые RFC.
[ISO/IEC Directives, Part 2] 2021. 9.0. Rules for the structure and drafting of International Standards. http://www.iso.org/sites/directives/current/part2/index.xhtml .
[ISO 7498-1] 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
[ISO 7498-2] 1989. Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security Architecture.
[ISO/TR 8509] Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .
[ISO 8649] 1988. Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).
[ISO/IEC 10118-3] 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] March 1996. The ECMA GSS-API Mechanism. http://www.ecma-international.org/publications/standards/Ecma-235.htm .
[DNS-SD] DNS Self-Discovery. http://www.dns-sd.org/ .
[ITU-T X.509] 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] Domain Name System (DNS). http://www.rfc-editor.org/info/rfc1035 .
[RFC 2030] Simple Network Time Protocol (SNTP) Version 4. http://www.rfc-editor.org/info/rfc2030 .
[RFC 2131] Dynamic Host Configuration Protocol. http://www.rfc-editor.org/info/rfc2131 .
[RFC 2132] Dynamic Host Configuration Protocol Options. http://www.rfc-editor.org/info/rfc2132 .
[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE). http://www.rfc-editor.org/info/rfc2136 .
[RFC 2181] Clarifications to the DNS Specification. http://www.rfc-editor.org/info/rfc2181 .
[RFC 2219] Use of DNS Aliases for Network Services. http://www.rfc-editor.org/info/rfc2219 .
[RFC 2246] Transport Layer Security (TLS) 1.0 Internet Engineering Task Force. http://www.rfc-editor.org/info/rfc2246 .
[RFC 2251] Lightweight Directory Access Protocol (v3). http://www.rfc-editor.org/info/rfc2251 .
[RFC 2313] March 1998. PKCS #1: RSA Encryption, Version 1.5. http://www.rfc-editor.org/info/rfc2313 .
[RFC 2437] October 1998. PKCS #1: RSA Cryptography Specifications - Version 2.0. http://www.rfc-editor.org/info/rfc2437 .
[RFC 2563] DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients. http://www.rfc-editor.org/info/rfc2563 .
[RFC 2782] A DNS RR for specifying the location of services (DNS SRV). http://www.rfc-editor.org/info/rfc2782 .
[RFC 2827] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. http://www.rfc-editor.org/info/rfc2827 .
[RFC 2849] The LDAP Data Interchange Format (LDIF). http://www.rfc-editor.org/info/rfc2849 .
[RFC 2898] September 2000. PKCS #5: Password-Based Cryptography Specification Version 2.0. http://www.rfc-editor.org/info/rfc2898 .
[RFC 3161] March 2000. Internet X.509 Public Key Infrastructure - Time-Stamp Protocol (TSP). http://www.rfc-editor.org/info/rfc3161 .
[RFC 3164] August 2001. The BSD syslog Protocol. http://www.rfc-editor.org/info/rfc3164 .
[RFC 3211] December 2001. Password-based Encryption for CMS. http://www.rfc-editor.org/info/rfc3211 .
[RFC 3268] June 2002. Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS). http://www.rfc-editor.org/info/rfc3268 .
[RFC 3447] February 2003. PKCS #1 RSA Cryptography Specifications Version 2.1. http://www.rfc-editor.org/info/rfc3447 .
[RFC 3370] August 2002. Cryptographic Message Syntax (CMS) Algorithms. http://www.rfc-editor.org/info/rfc3370 .
[RFC 3565] 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] Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification. http://www.rfc-editor.org/info/rfc3851 .
[RFC 3853] S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP). http://www.rfc-editor.org/info/rfc3853 .
[RFC 3881] September 2004. Security Audit and Access Accountability Message - XML Data Definitions for Healthcare Applications. http://www.rfc-editor.org/info/rfc3881 .
[RFC 3986] January 2005. Uniform Resource Identifier (URI): Generic Syntax. http://www.rfc-editor.org/info/rfc3986 .
[RFC 4033] March 2005. DNS Security Introduction and Requirements. http://www.rfc-editor.org/info/rfc4033 .
[RFC 4034] March 2005. Resource Records for the DNS Security Extensions. http://www.rfc-editor.org/info/rfc4034 .
[RFC 5246] August 2008. The Transport Layer Security (TLS) Protocol Version 1.2. http://www.rfc-editor.org/info/rfc5246 .
[RFC 5322] October 2008. Internet Message Format. http://www.rfc-editor.org/info/rfc5322 .
[RFC 5424] The Syslog Protocol. http://www.rfc-editor.org/info/rfc5424 .
[RFC 5425] Transport Layer Security (TLS) Transport Mapping for Syslog. http://www.rfc-editor.org/info/rfc5425 .
[RFC 5426] Transmission of Syslog Messages over UDP. http://www.rfc-editor.org/info/rfc5426 .
[RFC 5652] September 2009. Cryptographic Message Syntax. http://www.rfc-editor.org/info/rfc5652 .
[RFC 5905] Network Time Protocol Version 4: Protocol and Algorithms Specification. http://www.rfc-editor.org/info/rfc5905 .
[RFC 5906] Network Time Protocol Version 4: Autokey Specification. http://www.rfc-editor.org/info/rfc5906 .
[RFC 6762] February 2013. Multicast DNS. http://www.rfc-editor.org/info/rfc6762 .
[RFC 6763] February 2013. DNS-Based Service Discovery. http://www.rfc-editor.org/info/rfc6763 .
[RFC 8446] August 2018. The Transport Layer Security (TLS) Protocol Version 1.3. http://www.rfc-editor.org/info/rfc8446 .
[RFC 8553] DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names. http://www.rfc-editor.org/info/rfc8553 .
[RFC 8633] RFC8633 Network Time Protocol Best Current Practices. http://www.rfc-editor.org/info/rfc8633 .
[RFC 8996] March 2021. Deprecating TLS 1.0 and TLS 1.1. BCP 195. http://www.rfc-editor.org/info/rfc8996 .
[RFC 9325] 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] Information on BCP 195. References RFC 8996 and RFC 9325. http://www.rfc-editor.org/info/bcp195 .
Для целей настоящего стандарта применяются следующие определения.
3.1 Определения эталонной модели
В этой части стандарта используются следующие термины, определенные в [ISO 7498-1]:
- Application Entity (прикладная сущность)
-
См. [ISO 7498-1].
- Protocol Data Unit (протокольный блок данных)
-
См. [ISO 7498-1].
- Transport Connection
-
См. [ISO 7498-1].
3.2 Определения архитектуры безопасности эталонной модели
В этой части стандарта используются следующие термины, определенные в [ISO 7498-2]:
- Data Confidentiality
-
См. [ISO 7498-2].
- Data Origin Authentication
-
См. [ISO 7498-2].
- Data Integrity
-
См. [ISO 7498-2].
- Key Management
-
См. [ISO 7498-2].
- Digital Signature
-
См. [ISO 7498-2].
3.3 Определения службы ACSE
В этой части стандарта используются следующие термины, определенные в [ISO 8649]:
- Association
-
См. [ISO 8649].
3.4 Определения безопасности
В этой части стандарта используются следующие термины, определенные в [ECMA 235]:
- Security Context
-
См. [ECMA 235].
3.5 Определения из введения и обзора DICOM
В этой части стандарта используются следующие термины, определенные в PS3.1:
- Attribute
- Service Object Pair Class (SOP Class)
-
См. Service-Object Pair (пара служба-объект) Class в PS3.1 .
3.6 Определения соответствия DICOM
В этой части стандарта используются следующие термины, определенные в PS3.2:
3.7 Определения информационных объектов DICOM
В этой части стандарта используются следующие термины, определенные в PS3.3:
3.8 Определения классов служб DICOM
В этой части стандарта используются следующие термины, определенные в PS3.4:
- Service Class
- Service-Object Pair (пара служба-объект) Instance (SOP Instance)
-
См. Service-Object Pair (пара служба-объект) Instance в PS3.4 .
3.9 Определения поддержки коммуникаций DICOM
В этой части стандарта используются следующие термины, определенные в PS3.8:
3.10 Определения профилей безопасности DICOM
Следующие определения обычно используются в этой части стандарта DICOM:
- Secure Transport Connection
-
Transport Connection, обеспечивающее некоторый уровень защиты от вмешательства, прослушивания и маскировки.
- Message Authentication Code (код аутентификации сообщения)
-
Дайджест или хэш-код, полученный из подмножества Data Elements.
- Certificate
-
Электронный документ, который идентифицирует сторону, а также публичный алгоритм шифрования, параметры и ключ этой стороны. Certificate также включает, среди прочего, идентичность и цифровую подпись сущности, создавшей сертификат. Содержимое и формат Certificate определены рекомендацией ITU-T X.509.
3.11 Структуры данных и кодирование DICOM
В этой части стандарта используются следующие термины, определенные в PS3.5:
3.12 Определения кодов и контролируемой терминологии
В этой части стандарта используются следующие термины, определенные в PS3.16:
3.13 Определения хранения на носителях и формата файлов DICOM
В этой части стандарта используются следующие термины, определенные в PS3.10:
В этой части стандарта используются следующие символы и сокращения.
- ACR
-
American College of Radiology (Американский колледж радиологии)
- AE
- AES
-
Advanced Encryption Standard (расширенный стандарт шифрования)
- ANSI
-
American National Standards Institute (Американский национальный институт стандартов)
- CEN TC251
-
Comite European de Normalisation-Technical Committee 251-Medical Informatics (Европейский комитет по стандартизации, технический комитет 251, медицинская информатика)
- CBC
- CCIR
-
Consultative Committee, International Radio (Международный консультативный комитет по радио)
- CN
- DES
- DHCP
-
Dynamic Host Configuration Protocol (протокол динамической настройки узла)
- DICOM
-
Digital Imaging and Communications in Medicine (цифровые изображения и обмен ими в медицине)
- DN
- DNS
- DDNS
-
Dynamic Domain Name System (динамическая система доменных имен)
- ECMA
-
European Computer Manufacturers Association (Европейская ассоциация производителей компьютеров)
- EDE
-
Encrypt-Decrypt-Encrypt (шифрование-расшифрование-шифрование)
- HL7
- 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
- MAC
- MD-5
- MEDIS-DC
-
Medical Information System Development Center (центр разработки медицинских информационных систем)
- MPPS
-
Modality Performed Procedure Step (выполненный этап процедуры модальности)
- MTU
- NEMA
-
National Electrical Manufacturers Association (Национальная ассоциация производителей электрооборудования)
- NTP
- OID
- PDU
- RDN
- RDSR
-
Radiation Dose Structured Report (структурированный отчет о дозе излучения)
- RFC
-
Request For Comment (документ RFC, используемый для стандартов IETF)
- RR
- RSA
- SCP
- SCU
- SHA
- SNTP
-
Simple Network Time Protocol (простой протокол сетевого времени)
- SOP
- SSH
- SSL
- TLS
-
Transport Layer Security (безопасность транспортного уровня)
- UID
- UTC
-
Universal Coordinated Time (всемирное координированное время)
Реализация может заявлять соответствие любому из профилей безопасности и управления системой по отдельности. Она также может заявлять соответствие более чем одному Security или System Management Profile. В своем Conformance Statement она должна указать, как выбирает профили для использования в каждой конкретной транзакции.
Реализация может заявлять соответствие одному или нескольким Secure Use Profiles. Такие профили описывают использование атрибутов и других Security Profiles определенным способом.
Secure Use Profiles указаны в Приложении A.
Реализация может заявлять соответствие одному или нескольким Secure Transport Connection Profiles.
Secure Transport Connection Profile включает следующую информацию:
Secure Transport Connection Profiles указаны в Приложении B.
Реализация может заявлять соответствие одному или нескольким Digital Signature Profiles.
Digital Signature Profile состоит из следующей информации:
-
Список Attributes, которые должны быть включены в Digital Signature.
-
Механизмы, которые должны использоваться для создания или проверки Digital Signature, включая:
-
Алгоритм и соответствующие параметры, которые должны использоваться для создания MAC или хэш-кода, включая значение, используемое для атрибута MAC Algorithm (0400,0015).
-
Алгоритм шифрования и соответствующие параметры, которые должны использоваться для шифрования MAC или хэш-кода при формировании Digital Signature.
-
Тип сертификата или механизм распространения ключей, который должен использоваться, включая значение, используемое для атрибута Certificate Type (0400,0110).
-
Любые требования к атрибутам Certified Timestamp Type (0400,0305) и Certified Timestamp (0400,0310).
-
-
Любые другие факторы, необходимые для создания, проверки или интерпретации Digital Signature
Digital Signature Profiles указаны в Приложении C.
Реализация может заявлять соответствие одному или нескольким Media Storage Application Profiles, которые, в свою очередь, требуют соответствия одному или нескольким Media Storage Security Profiles.
Примечание
Реализация не может заявлять соответствие Media Storage Security Profile без заявления соответствия Media Storage Application Profile.
Media Storage Security Profile включает следующие спецификации:
Media Storage Security Profiles указаны в Приложении D.
Реализация может заявлять соответствие одному или нескольким Network Address Management Profiles. Такие профили описывают использование сетевых протоколов, не относящихся к DICOM, для получения сетевых адресов реализации.
Network Address Management Profiles указаны в Приложении F.
Реализация может заявлять соответствие одному или нескольким Time Synchronization Profiles. Такие профили описывают использование протоколов, не относящихся к DICOM, для установки текущего времени в реализации.
Time Synchronization Profiles указаны в Приложении G.
Реализация может заявлять соответствие одному или нескольким Application Configuration Management Profiles. Такие профили описывают использование сетевых протоколов, не относящихся к DICOM, для получения описаний, адресов и возможностей других устройств, с которыми реализация может взаимодействовать с использованием DICOM Protocol. Они также задают использование этих не-DICOM протоколов для публикации или объявления реализацией своего описания, адресов и возможностей. Кроме того, они задают, как устройства могут получать специфичную для реализации конфигурационную информацию.
Application Configuration Management Profiles указаны в Приложении H.
Реализация может заявлять соответствие одному или нескольким Audit Trail Profiles. Такие профили описывают формирование и транспортировку сообщений аудита для обеспечения политик безопасности и конфиденциальности.
Audit Trail Profiles указаны в Приложении A.
Реализация может заявлять соответствие Basic Application Level Confidentiality Profile и одному или нескольким Basic Application Level Confidentiality Options. Этот профиль и параметры поддерживают деидентификацию Data Sets для предотвращения утечки информации, позволяющей идентифицировать отдельное лицо, по причинам конфиденциальности.
Basic Application Level Confidentiality Profile и его Options указаны в Приложении E.
Поддержка управления конфигурацией реализуется с помощью протоколов, определенных в стандартах, отличных от стандарта DICOM. Эти протоколы описываются здесь в терминах actors, transactions и profiles.
Actors аналогичны Application Entities, используемым в профиле DICOM. Actor представляет собой совокупность аппаратных и программных процессов, выполняющих определенную роль. Когда устройство предоставляет или использует службу, оно включает actor для обработки соответствующей сетевой активности. DICOM Configuration actors могут сосуществовать с другими Application Entities на одном устройстве. Некоторые DICOM Configuration actors существуют как части ИТ-оборудования общего назначения. Как и в случае Application Entity, спецификация Actor не подразумевает каких-либо деталей фактической реализации.
Взаимодействия actors определяются в терминах Transactions. Каждой transaction присваивается имя. В свою очередь transaction может включать различные виды активности. Все transactions определяются через взаимодействующих actors. Отношения между actors в transaction могут быть сложнее, чем простые роли SCU и SCP в действиях DICOM. Если transaction включает взаимодействие с человеком, такие transactions могут реализовываться пользовательскими интерфейсами, съемными носителями и другими механизмами. Человек описывается как actor с точки зрения модели варианта использования transaction. Чаще transactions представляют собой последовательность сетевых действий, выполняющих конкретную операцию.
Transaction включает как обязательные, так и необязательные компоненты. Actor, реализующий transaction, обязан реализовать все обязательные компоненты.
Некоторые transactions включают человеческих actors в определение transaction. Эти actors не определяются как actors в других местах и не включаются в описания profiles. Они существуют для указания, что должен быть предоставлен некоторый механизм, позволяющий этим людям взаимодействовать с компьютерным actor. Другие детали предоставления такого пользовательского интерфейса этим стандартом не задаются. Пример см. в определении transaction Configure DHCP.
Соответствие дополнительно управляется с помощью Profiles. Profile определяется через то, какие transactions являются обязательными для actor и какие transactions являются необязательными. Реализация конкретного actor документируется указанием того, какие необязательные transactions и компоненты transactions реализованы. Реализация, в которой отсутствуют какие-либо обязательные transactions или компоненты, не может заявлять, что является реализацией этого Actor.
Например, в Network Address Management Profile DHCP Server обязан выполнять три Transactions: настраивать DHCP server, находить и использовать DHCP servers, а также поддерживать DHCP leases. Он также может поддерживать transaction для обновления DNS server посредством DDNS coordination.
Profile включает определения более чем одного Actor. Он задает transactions для всех actors, которые совместно выполняют функцию. Например, Network Address Management Profile охватывает actor DHCP Server, actor DHCP client и actor DNS Server. Чтобы система была полезной, в ней должны быть как минимум один DHCP Server и один DHCP Client. Сам DNS Server является необязательным, поскольку DHCP Server не обязан реализовывать transaction DDNS Coordination. Если DNS Server является частью системы, DDNS coordination обязательна, и ожидается, что DHCP Server будет участвовать в transaction DDNS Coordination.
Примечание
В той же сети, что и DHCP Server, может присутствовать DNS server, но если он не предоставляет actor DNS Server из этого профиля, он не является частью действий DICOM Configuration.
Profiles, actors и transactions кратко изложены в следующих разделах. Подробное описание actor и transactions для каждого конкретного profile приведено в приложениях для каждого profile. Transactions документируются в терминах параметров и терминов из исходного документа стандарта, например RFC для интернет-протоколов. Полные детали transaction в приложении не описываются; приводятся только отдельные детали, относящиеся к применению этой transaction в DICOM. Полные сведения об этих внешних протоколах документированы в соответствующих документах стандартов для внешних протоколов. Соответствие требованиям конкретного profile должно включать соответствие этим внешним документам протоколов.
DHCP Server представляет собой компьютерную/программную функцию, которой предоставляется описание сетевой конфигурации и которая предоставляет службы начальной конфигурации в соответствии с протоколом DHCP.
DHCP Client представляет собой программную функцию, используемую для получения параметров TCP/IP при запуске компьютера. Она продолжает работать для поддержания действительности этих параметров.
DNS server представляет собой компьютерную/программную функцию, которая предоставляет информацию, связанную с IP, в ответ на запросы клиентов, использующих протокол DNS. Он является частью федеративной базы данных, поддерживающей актуальную базу соответствия имен машин информации об IP-адресах. DNS server также может быть изолирован от всемирной федеративной базы данных и предоставлять только локальные службы DNS.
DNS client как компьютерная/программная функция использует протоколы DNS для получения IP-информации по заданным именам хостов. Имена хостов могут находиться в конфигурационных или других файлах вместо явных IP-адресов. При необходимости имена хостов динамически преобразуются в IP-адреса. DNS client использует DNS server для предоставления необходимой информации.
NTP server представляет собой компьютерную/программную функцию, которая предоставляет службы времени в соответствии с протоколом NTP или SNTP.
NTP client представляет собой программное обеспечение, которое получает информацию о времени от NTP server и поддерживает время клиента синхронизированным с сигналами времени от NTP server.
SNTP client представляет собой программное обеспечение, которое получает информацию о времени от NTP server и поддерживает время клиента приблизительно синхронизированным с сигналами времени от NTP server. Синхронизация SNTP client не поддерживается с той точностью или прецизионностью, которую обеспечивает NTP.
LDAP server представляет собой компьютерную/программную функцию, которая поддерживает внутреннюю базу данных различной справочной информации. Часть этой справочной информации соответствует схеме DICOM Configuration. LDAP server предоставляет сетевой доступ для чтения и обновления справочной информации. LDAP server предоставляет механизм внешней загрузки, выгрузки и резервного копирования справочной информации. LDAP server может быть частью федеративной сети серверов, предоставляющей согласованное представление федеративной базы данных каталога в соответствии с правилами протоколов LDAP.
LDAP client использует протокол LDAP для выполнения запросов к LDAP server. LDAP server поддерживает базу данных и отвечает на эти запросы на основе содержимого этой базы данных.
Следующие transactions используются для обеспечения взаимодействия между actors в соответствии с одним или несколькими протоколами DICOM Configuration.
Эта transaction изменяет конфигурацию на DHCP server, чтобы отразить добавления, удаления и изменения IP-параметров, установленных для этой сети.
Эта transaction представляет собой последовательность сетевых сообщений, соответствующих правилам протокола DHCP. Она позволяет DHCP client находить доступные DHCP servers и выбирать сервер, подходящий для этого клиента. Эта transaction получает от DHCP server обязательную информацию об IP-параметрах и дополнительные необязательные параметры.
Обслуживающий персонал использует эту transaction для задания начальной конфигурации клиента.
Эта transaction описывает, как DHCP client должен вести себя, если его аренда IP не продлена.
Эта transaction документирует, координируется ли DHCP server с DNS server, чтобы доступ к DHCP client мог поддерживаться с использованием имени хоста, назначенного DHCP client.
Эта transaction получает IP-адрес компьютера по заданному имени хоста.
Эти transactions представляют собой действия, необходимые NTP или SNTP client для поддержания синхронизации времени с основной службой времени.
Эта transaction является процедурой автообнаружения, определенной для NTP. Она может использовать широковещательный метод или метод, поддерживаемый DHCP.
В этой transaction выполняется запрос к DNS server для получения IP-адреса, порта и имени LDAP server.
В этой transaction выполняется запрос к LDAP server относительно содержимого базы данных LDAP.
Эта transaction обновляет базу данных конфигурации с использованием инструкций обновления LDAP от настраиваемого клиента.
Эта transaction обновляет базу данных конфигурации с использованием локальных служб LDAP server.
Рисунок 7-1 показывает actors и их transactions. Обычное устройство будет иметь NTP Client, DHCP Client и LDAP client в дополнение к actors других приложений. Transactions "Configure DHCP Server", "Configure Client" и "Maintain LDAP Server" не показаны, поскольку эти transactions выполняются между программным actor и человеческим actor. DICOM не задает средства или пользовательский интерфейс. Он требует только поддержки определенных возможностей.
Профиль Online Electronic Storage Secure Use Profile позволяет Application Entity отслеживать и проверять состояние SOP Instances в тех случаях, когда локальные политики безопасности требуют контроля исходного Data Set и последующих копий.
В Conformance Statement должно быть указано, каким образом система ограничивает удаленный доступ.
Реализация, соответствующая профилю Online Electronic Storage Secure Use Profile, должна соблюдать следующие правила использования атрибута SOP Instance Status (0100,0410) для SOP Instances, передаваемых с использованием Storage Service Class:
-
Application Entity, поддерживающая Online Electronic Storage Secure Use Profile и создающая SOP Instance, предназначенный для диагностического использования в онлайн-электронном хранилище, должна:
-
Application Entity, у которой находится SOP Instance со значением SOP Instance Status Original (OR), может изменить SOP Instance Status на Authorized Original (AO) при соблюдении следующих правил:
-
Application Entity должна определить, что уполномоченная сторона сертифицировала SOP Instance как пригодный для диагностических целей.
-
Application Entity должна изменить SOP Instance Status на Authorized Original (AO). SOP Instance UID не должен изменяться.
-
Application Entity должна установить для атрибутов SOP Authorization Date and Time (0100,0420) и Authorization Equipment Certification Number (0100,0426) соответствующие значения. Она также может добавить соответствующий атрибут SOP Authorization Comment (0100,0424).
-
-
Должна существовать только одна Application Entity, у которой находится SOP Instance со значением SOP Instance Status Original (OR) или Authorized Original (AO). Application Entity, у которой находится такой SOP Instance, не должна удалять его.
-
При обмене с Application Entity, поддерживающей Online Electronic Storage, Application Entity, у которой находится SOP Instance со значением SOP Instance Status Original (OR) или Authorized Original (AO), может передать этот SOP Instance другой Application Entity, также соответствующей Online Electronic Storage Secure Use Profile, если соблюдаются следующие правила:
-
Передача должна выполняться через Secure Transport Connection.
-
Две Application Entities, участвующие в передаче, должны взаимно аутентифицировать друг друга и в ходе аутентификации подтвердить, что другая сторона поддерживает Online Electronic Storage Secure Use Profile.
-
Принимающая Application Entity должна отклонить запрос на сохранение и отбросить полученный SOP Instance, если проверки целостности данных после передачи показывают, что SOP Instance был изменен во время передачи.
-
Передача должна подтверждаться с использованием push-модели Storage Commitment Service Class. Пока это подтверждение не завершено, принимающая Application Entity не должна пересылать SOP Instance или Authorized Copies этого SOP Instance какой-либо другой Application Entity.
-
После подтверждения, что принимающая Application Entity успешно зафиксировала SOP Instance в хранилище, отправляющая Application Entity должна выполнить одно из следующих действий со своей локальной копией SOP Instance:
-
-
При обмене с Application Entity, поддерживающей Online Electronic Storage, Application Entity, у которой находится SOP Instance со значением SOP Instance Status Authorized Original (AO) или Authorized Copy (AC), может отправить Authorized Copy этого SOP Instance другой Application Entity при соблюдении следующих правил:
-
Передача должна выполняться через Secure Transport Connection.
-
Две Application Entities, участвующие в передаче, должны взаимно аутентифицировать друг друга и в ходе аутентификации подтвердить, что другая сторона поддерживает Online Electronic Storage Secure Use Profile.
-
Отправляющая Application Entity должна установить в отправляемой копии SOP Instance Status либо в Not Specified (NS), либо в Authorized Copy (AC). SOP Instance UID не должен изменяться.
-
Принимающая Application Entity должна отклонить запрос на сохранение и отбросить копию, если проверки целостности данных после передачи показывают, что SOP Instance был изменен во время передачи.
-
-
Если обмен выполняется с системой, которая не поддерживает Online Electronic Storage Secure Use Profile, или если обмен выполняется не через Secure Transport Connection, то:
-
Отправляющая Application Entity, соответствующая этому Security Profile, должна либо установить SOP Instance Status в значение Not Specified (NS), либо исключить SOP Instance Status и связанные параметры из любых SOP Instances, которые она отправляет через незащищенное Transport Connection или в системы, не поддерживающие Online Electronic Storage Secure Use Profile.
-
Принимающая Application Entity, соответствующая этому Security Profile, должна установить SOP Instance Status в значение Not Specified (NS) для любого SOP Instance, полученного через незащищенное Transport Connection или от систем, не поддерживающих Online Electronic Storage Secure Use Profile.
-
-
Принимающая Application Entity должна сохранять SOP Instances в соответствии с Storage Level 2 (Full), как определено в Storage Service Class, то есть все атрибуты, включая Private Attributes, как требуется Storage Commitment Storage Service Class, и не должна принудительно изменять никакие атрибуты, кроме SOP Instance Status, SOP Authorization Date and Time, Authorization Equipment Certification Number и SOP Authorization Comment.
-
За исключением описанных выше изменений атрибутов SOP Instance Status, SOP Authorization Date and Time, Authorization Equipment Certification Number и SOP Authorization Comment, а также изменений атрибутов длины группы, необходимых для учета этих изменений, Application Entity не должна изменять значения каких-либо атрибутов.
Реализация, которая проверяет и создает Digital Signatures, может заявлять соответствие Basic Digital Signatures Secure Use Profile. Любая реализация, заявляющая соответствие этому Security Profile, должна соблюдать следующие правила при обработке Digital Signatures:
-
Реализация должна сохранять любые полученные SOP Instances таким образом, чтобы защищать SOP Instance от любых несанкционированных изменений.
-
Везде, где это возможно, реализация должна проверять Digital Signatures внутри любого полученного SOP Instance.
-
Если реализация отправляет SOP Instance другой Application Entity, она должна выполнить следующее:
-
удалить любые Digital Signatures, которые могли стать недействительными из-за допустимых изменений формата значений атрибутов, например удаления заполнения или альтернативного представления чисел,
-
создать одну или несколько новых Digital Signatures, охватывающих Data Elements, которые реализация смогла проверить при получении SOP Instance.
-
Реализация, которая сохраняет и пересылает SOP Instances, может заявлять соответствие Bit-Preserving Digital Signatures Secure Use Profile. Любая реализация, заявляющая соответствие этому Security Profile, должна соблюдать следующие правила при обработке Digital Signatures:
-
Реализация должна сохранять любые полученные SOP Instances таким образом, чтобы при пересылке SOP Instance другой Application Entity поля Value всех атрибутов были побитно идентичными копиями первоначально полученных полей.
-
При отправке полученного SOP Instance другой Application Entity через DICOM реализация не должна удалять или изменять какой-либо Data Element этого SOP Instance. Это включает любые полученные Digital Signatures.
-
При передаче объекта другой Application Entity реализация не должна изменять VR какого-либо полученного Data Element.
Любая реализация, заявляющая соответствие этому Security Profile, должна соблюдать следующие правила при создании Structured Report или Key Object Selection Document, включающего Digital Signatures:
-
Когда реализация подписывает SOP Instance типа Structured Report или Key Object Selection Document, Digital Signatures должны создаваться в соответствии с Structured Report RSA Digital Signature Profile.
-
В каждом созданном подписанном SOP Instance типа Structured Report или Key Object Selection Document все ссылочные SOP Instances, перечисленные в элементах Referenced SOP Sequence в Current Requested Procedure Evidence Sequence (0040,A375) и Pertinent Other Evidence Sequence (0040,A385), должны включать либо Referenced Digital Signature Sequence, либо Referenced SOP Instance MAC Sequence. Ссылки могут включать оба варианта.
Реализация, заявляющая соответствие, должна описать в своем conformance statement условия, при которых она будет подписывать или не будет подписывать Structured Report либо Key Object Selection Document.
Чтобы обеспечить конфиденциальность и безопасность медицинской информации в автоматизированных системах, необходимо собирать данные об использовании. Эти данные проверяются административным персоналом, чтобы убедиться, что медицинские данные используются в соответствии с требованиями поставщика медицинских услуг к безопасности данных, и чтобы обеспечить подотчетность такого использования. Этот процесс сбора и анализа данных называется аудитом безопасности, а сами данные образуют журнал аудита. Журналы аудита могут использоваться для наблюдения и выявления значимых событий, которые требуют дальнейшего расследования.
Этот профиль определяет формат собираемых данных и минимальный набор атрибутов, которые медицинские прикладные системы должны фиксировать для последующего использования приложением анализа. Данные включают записи о том, кто обращался к медицинским данным, когда, для какого действия, откуда и с какими записями пациентов это было связано. Поведенческие требования к тому, когда генерируются сообщения аудита или какие действия должны выполняться при их получении, здесь не задаются. Эти вопросы определяются локальными политиками и правовыми требованиями.
Любая реализация, заявляющая соответствие этому Security Profile, должна:
-
форматировать сообщения журнала аудита в соответствии с XML-схемой, указанной в Разделе A.5.1, таким образом, чтобы эти сообщения можно было проверить на соответствие данной XML-схеме, следуя общим соглашениям, указанным в Разделе A.5.2.
-
для событий, описанных в этом профиле, соблюдать ограничения, установленные данным профилем в Разделе A.5.3, и описывать в своем conformance statement любые расширения.
-
описать в своем conformance statement события, которые она может обнаруживать и о которых может сообщать,
-
описать в своем conformance statement обработку, которую она может выполнять при получении сообщения,
-
описать в своем conformance statement, как могут настраиваться формирование сообщений о событиях и их обработка.
Реализации, заявляющие соответствие этому профилю, должны использовать следующую XML-схему для форматирования сообщений журнала аудита. Эта схема получена из схемы, указанной в [RFC 3881], в соответствии с рекомендацией W3C "XML Schema Part 1: Structures", версия 1.0, май 2001 г., и включает расширения и ограничения DICOM, описанные в Разделе A.5.2.
Эта схема приведена в формате Relax NG Compact.
Примечание
Эта схема может быть преобразована в эквивалентную XML Schema или другой электронный формат. Она включает некоторые изменения схемы [RFC 3881], отражающие практический опыт применения требований к сообщениям аудита. Она расширяет схему [RFC 3881].
Ниже приведено содержимое схемы сообщения аудита:
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
# Определяет тип кодированного значения. Комментарий показывает шаблон, который можно
# использовать для дополнительного ограничения token форматом OID. Не все программные
# реализации схем поддерживают параметр pattern для token.
other-csd-attributes =
(attribute codeSystemName { token } | # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"
attribute codeSystemName { token }), # Уточняет, что codeSystemName является
# либо OID, либо строкой
attribute displayName { token }?,
attribute originalText { token } # Примечание: это также соответствует DICOM "Code Meaning"
CodedValueType =
attribute csd-code { token },
other-csd-attributes
# Определение идентификации события, используется далее
EventIdentificationContents =
element EventID { CodedValueType },
element EventTypeCode { CodedValueType }*, # Примечание: DICOM/IHE определяет и использует это
# иначе, чем RFC 3881
attribute EventActionCode { # Необязательный код действия
"C" | ## Создание
"R" | ## Чтение
"U" | ## Обновление
"D" | ## Удаление
"E" ## Выполнение
}?,
attribute EventDateTime { xsd:dateTime },
attribute EventOutcomeIndicator {
"0" | ## Номинальный успех (используется, если статус иначе неизвестен или неоднозначен)
"4" | ## Незначительный сбой (по определению отчитывающегося приложения)
"8" | ## Серьезный сбой (по определению отчитывающегося приложения)
"12" ## Критический сбой (отчитывающееся приложение теперь недоступно)
},
element EventOutcomeDescription { text }?
# Определение AuditSourceIdentification, используется далее
AuditSourceIdentificationContents =
attribute AuditEnterpriseSiteID { token }?,
attribute AuditSourceID { token },
element AuditSourceTypeCode { AuditSourceTypeCodeContent }*
# Определение AuditSourceTypeCodeContent так, чтобы было допустимо отдельное
# однозначное значение либо token с другими csd-атрибутами, чтобы также можно
# было использовать любую контролируемую терминологию.
AuditSourceTypeCodeContent =
attribute csd-code {
"1" | ## Устройство отображения конечного пользователя, диагностическое устройство
"2" | ## Устройство или инструмент сбора данных
"3" | ## Процесс или поток веб-сервера
"4" | ## Процесс или поток сервера приложений
"5" | ## Процесс или поток сервера базы данных
"6" | ## Сервер безопасности, например контроллер домена
"7" | ## Сетевой компонент уровней ISO 1-3
"8" | ## Операционное программное обеспечение уровней ISO 4-6
"9" | ## прочее
token }, ## другие значения допустимы, если присутствует codeSystemName
other-csd-attributes? ## Если они присутствуют, они определяют значение кода
# Определение ActiveParticipantType, используется далее
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" | ## Имя машины, включая DNS-имя
"2" | ## IP-адрес
"3" | ## Номер телефона
"4" | ## Адрес электронной почты
"5" }? ## URI (каталог пользователя, HTTP PUT, ftp и т. д.)
# BinaryValuePair используется в описаниях ParticipantObject для фиксации параметров.
# Все значения, даже обычно являющиеся простым текстом, кодируются как xsd:base64Binary.
# Это нужно для сохранения деталей кодирования, например null-значений, и для защиты от
# текстового содержимого, включающего XML-фрагменты. Это известные точки атак на приложения,
# поэтому журналам безопасности может требоваться фиксировать их без изменения процессом
# кодирования аудита.
ValuePair =
# уточнение имени
attribute type { token },
attribute value { xsd:base64Binary } # используется для кодирования потенциально двоичного, некорректного XML-текста и т. д.
# Определение ParticipantObjectIdentification, используется далее
# Participant Object Description, используется далее
DICOMObjectDescriptionContents =
element MPPS {
attribute UID { token } # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"
}*,
element Accession {
attribute Number { token }
}*,
element SOPClass { # SOP Class для одного 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 } | # либо имя, либо
element ParticipantObjectQuery { xsd:base64Binary }), # поле ID запроса,
element ParticipantObjectDetail { ValuePair }*, # необязательные детали; они могут быть
# многочисленными и большими
element ParticipantObjectDescription { DICOMObjectDescriptionContents }*,
attribute ParticipantObjectID { token }, # обязательный ID
attribute ParticipantObjectTypeCode { # необязательный тип
"1" | ## Человек
"2" | ## Системный объект
"3" | ## Организация
"4" ## Другое
}?,
attribute ParticipantObjectTypeCodeRole { ## необязательная роль
"1" | ## Пациент
"2" | ## Местоположение
"3" | ## Отчет
"4" | ## Ресурс
"5" | ## Основной файл
"6" | ## Пользователь
"7" | ## Список
"8" | ## Врач
"9" | ## Подписчик
"10" | ## Гарант
"11" | ## Сущность пользователя безопасности
"12" | ## Группа пользователей безопасности
"13" | ## Ресурс безопасности
"14" | ## Определение гранулярности безопасности
"15" | ## Поставщик
"16" | ## Назначение данных
"17" | ## Архив данных
"18" | ## Расписание
"19" | ## Заказчик
"20" | ## Задание
"21" | ## Поток заданий
"22" | ## Таблица
"23" | ## Критерии маршрутизации
"24" | ## Запрос
"25" | ## Источник данных
"26" ## Элемент обработки
}?,
attribute ParticipantObjectDataLifeCycle { # необязательная стадия жизненного цикла
"1" | ## Возникновение, создание
"2" | ## Импорт/копирование
"3" | ## Изменение
"4" | ## Проверка
"5" | ## Перевод
"6" | ## Доступ/использование
"7" | ## Деидентификация
"8" | ## Агрегация, обобщение, получение производных данных
"9" | ## Отчет
"10" | ## Экспорт
"11" | ## Раскрытие
"12" | ## Получение раскрытых сведений
"13" | ## Архивирование
"14" | ## Логическое удаление
"15" }?, ## Безвозвратное стирание, физическое уничтожение
attribute ParticipantObjectSensitivity { token }?
# Базовое сообщение
message =
element AuditMessage {
(element EventIdentification { EventIdentificationContents }, # Событие должно быть идентифицировано
element ActiveParticipant { ActiveParticipantContents }+, # Оно имеет одного или нескольких активных
# участников
element AuditSourceIdentification { # О нем сообщает один источник
AuditSourceIdentificationContents
},
element ParticipantObjectIdentification { # В нем могут участвовать другие объекты
ParticipantObjectIdentificationContents
}*)
}
# И наконец магическое выражение: message является корнем всего.
start = message
В приведенной выше схеме сообщения аудита определены следующие наборы значений. Они не являются кодированной терминологией. Это значения, смысл которых зависит от их использования в правильном месте сообщения.
Значения Audit Source Type Code задают тип источника, в котором возникло событие. Для AuditSourceTypeCode также могут использоваться коды из кодированных терминологий и коды, определенные реализацией.
Таблица A.5.1.2.1-1. Значения Audit Source Type Code
Participant Object Type Code Role является атрибутом ParticipantObjectIdentification и не расширяется. Этот атрибут может быть опущен либо ему может быть присвоено одно из следующих значений. Кодированные терминологии не поддерживаются.
Participant Object Data Life Cycle является атрибутом ParticipantObjectIdentification и не расширяется. Этот атрибут может быть опущен либо ему может быть присвоено одно из следующих значений. Кодированные терминологии не поддерживаются.
Participant Object ID Type Code описывает идентификатор, содержащийся в Participant Object ID. Для ParticipantObjectTypeCodeRole также могут использоваться коды из кодированных терминологий и коды, определенные реализацией.
В следующей таблице перечислены основные поля из DICOM Audit Message Schema, указанной в Разделе A.5.1, с дополнительными инструкциями, соглашениями и ограничениями относительно того, как приложения DICOM должны заполнять значения полей. Имена полей являются конечными элементами и атрибутами, присутствующими в схеме. Следует учитывать, что эти поля могут быть заключены в другие XML-элементы, как указано в схеме.
Примечание
Эта схема, коды и содержимое изначально были получены из [RFC 3881]. [RFC 3881] не сопровождается и не обновляется IETF, поэтому постепенно разошелся со схемой и кодами DICOM. Существуют другие документы, которые ссылаются на [RFC 3881] как на базовый стандарт. [RFC 3881] не включает исправления и дополнения к схеме сообщений аудита, внесенные в DICOM начиная с 2004 года.
Хотя XML допускает пустые элементы и атрибуты со значением пустой строки, Audit Messages не должны содержать пустые элементы и не должны содержать атрибуты со значением пустой строки.
В последующих таблицах для обозначения обязательности используется следующая нотация:
- M
- U
-
Этот элемент или атрибут является необязательным по выбору пользователя. Создатель может включить его или опустить.
- MC
-
Этот элемент или атрибут является обязательным, если заданное условие истинно.
- UC
-
Этот элемент или атрибут может присутствовать только при истинности заданного условия, если пользователь решил включить его.
Таблица A.5.2-1. Общий формат сообщения
|
Идентификатор семейства события. Например, "User Authentication". |
||||
|
Индикатор типа действия, выполненного во время события, для которого сформирован аудит. |
|
|||
|
Всемирное координированное время (UTC), то есть указание даты/времени, однозначное относительно локальных часовых поясов. |
Время, в которое произошло аудируемое событие. См. Раздел A.5.2.5 |
|||
Если в конкретном событии одни аспекты завершились успешно, а другие с ошибкой, должно быть сформировано одно сообщение для успешных действий и одно сообщение для неуспешных действий, то есть не одно сообщение со смешанными результатами. |
||||
|
Конкретный тип или типы внутри семейства, применимые к событию, например "User Login". |
||||
|
Уникальный идентификатор пользователя, активно участвующего в событии. |
См. Раздел A.5.2.1. |
|||
|
См. Раздел A.5.2.2. |
||||
|
См. Раздел A.5.2.3. |
||||
|
Индикатор того, является ли пользователь запрашивающей стороной или инициатором аудируемого события. |
Используется для определения того, кто из участников инициировал аудируемую транзакцию. Если источник аудита не может определить, какой из участников является запрашивающей стороной, это поле должно присутствовать у всех участников со значением false. Система не должна помечать нескольких участников как UserIsRequestor. Если известно несколько запрашивающих сторон, отчитывающаяся система должна выбрать только одну как UserIsRequestor. |
|||
|
Указание роли или ролей, которые пользователь выполняет при событии, как это назначено в безопасности на основе ролевого управления доступом. |
||||
|
Коды см. в Разделе A.5.1.2.5, дополнительные сведения см. в Разделе A.5.2.4. |
||||
|
Идентификатор точки сетевого доступа пользовательского устройства. Это может быть идентификатор устройства, IP-адрес или другой идентификатор, связанный с устройством. |
Дополнительные сведения см. в Разделе A.5.2.4. |
|||
|
Логическое местоположение источника в сети медицинской организации, например больница или другое местоположение поставщика медицинских услуг в группе поставщиков из нескольких организаций. |
Служит для дополнительного уточнения Audit Source ID, поскольку Audit Source ID не обязан быть глобально уникальным. |
|||
|
Идентификация системы, которая обнаружила аудируемое событие и создала это сообщение аудита. Хотя источник аудита часто является одним из участников, он также может быть внешней системой, отслеживающей действия участников, например дополнительным устройством формирования аудита. |
||||
|
См. Раздел A.5.1.2.1. Например, устройство сбора данных может использовать "2" (устройство сбора данных), а система PACS/RIS может использовать "4" (процесс сервера приложений). |
||||
|
Код типа аудируемого объекта-участника. Это значение отличается от роли пользователя или любого отношения пользователя к Participant Object. |
|
|||
|
Код, представляющий функциональную прикладную роль аудируемого Participant Object. |
См. Раздел A.5.1.2.2. |
|||
|
Идентификатор стадии жизненного цикла данных для Participant Object. Это может использоваться для формирования журнала аудита данных во времени по мере их прохождения через систему. |
См. Раздел A.5.1.2.3. |
|||
|
Описывает идентификатор, содержащийся в ParticipantObjectID. |
См. Раздел A.5.1.2.4 и CID 404 “Audit Participant Object ID Type Code” |
|||
|
Обозначает определенную политикой чувствительность для ParticipantObjectID, например VIP, ВИЧ-статус, состояние психического здоровья или аналогичные темы. На это могут влиять значения в Sensitive Content Code Sequence (0008,001D), если они присутствуют в объекте-участнике. |
||||
|
Специфичный для экземпляра дескриптор аудируемого ParticipantObjectID, например имя человека. |
||||
|
Данные, определенные реализацией, о конкретных деталях объекта, к которому был выполнен доступ или который использовался. |
Этот элемент является парой тип-значение. Атрибут "type" представляет собой текстовую строку, определенную реализацией. Атрибут "value" содержит данные, закодированные в base64. Такое значение подходит для передачи двоичных данных. |
|||
|
UID классов SOP, на которые ссылается этот Participant Object. Требуется, если ParticipantObjectIDTypeCode равен (110180, DCM, "Study Instance UID") и в этом Participant Object присутствует любое из необязательных полей (Accession, MPPS, NumberOfInstances, Instance, Encrypted, Anonymized). Может присутствовать, если ParticipantObjectIDTypeCode равен (110180, DCM, "Study Instance UID"), даже если ни одно из необязательных полей не присутствует. |
||||
|
Accession Number или номера, связанные с этим Participant Object. |
||||
|
MPPS Instance UID или UID, связанные с этим Participant Object. |
||||
|
Количество SOP Instances, на которые ссылается этот Participant Object. |
||||
|
Единственное значение true или false, указывающее, были ли данные зашифрованы. |
||||
|
Единственное значение true или false, указывающее, была ли из данных удалена вся идентифицирующая пациента информация |
||||
|
Study Instance UID, который может использоваться, когда ParticipantObjectIDTypeCode не равен (110180, DCM, "Study Instance UID"). |
Если участник является человеком, User ID должен быть идентификатором, используемым для этого человека в данной конкретной системе, в форме loginName@domain-name.
Если участник является идентифицируемым процессом, выбранный UserID должен быть одним из идентификаторов, используемых во внутренних системных журналах. Например, User ID может быть идентификатором процесса, используемым локальной операционной системой в локальных системных журналах. Если участник является узлом, User ID может быть именем узла, назначенным системным администратором. Другие участники, такие как потоки, перемещаемые процессы, конечные точки веб-служб, диспетчеризуемые потоки веб-сервера и т. д., должны иметь соответствующий идентификатор. Реализация должна документировать используемые идентификаторы в Conformance Statement. Цель этого требования - обеспечить сопоставление идентификаторов журнала аудита с внутренними системными журналами в отчитывающихся системах.
При импорте или экспорте данных, например с использованием носителей, поле UserID используется как для идентификации людей, так и для идентификации самого носителя. Когда Role ID Code имеет значение EV (110154, DCM, "Destination Media") или EV (110155, DCM, "Source Media"), UserID может быть:
-
URI, предпочтительная форма, идентифицирующий источник или назначение,
-
описание типа носителя, например DVD, вместе с описанием его идентифицирующей метки в виде поля свободного текста,
-
описание типа носителя, например бумага или пленка, вместе с описанием местоположения создателя носителя, то есть принтера.
Поле UserID для носителей должно быть очень гибким с учетом большого разнообразия носителей и способов передачи, которые могут использоваться.
Если участник является человеком, AlternativeUserID должен быть идентификатором, используемым для этого человека в организации для целей аутентификации, например Kerberos Username (user@realm). Если участник является приложением DICOM, AlternativeUserID должен быть одним или несколькими AE Titles, участвовавшими в событии. Несколько AE Titles должны кодироваться следующим образом:
При импорте или экспорте данных, например с использованием носителей, поле AlternativeUserID используется либо для идентификации людей, либо для идентификации самого носителя. Когда RoleIDCode равен (110154, DCM, "Destination Media") или (110155, DCM, "Source Media"), AlternativeUserID может быть любым машиночитаемым идентификатором на носителе, например серийным номером носителя, меткой тома или DICOMDIR File-set ID (0004,1130).
Человекочитаемая идентификация участника. Если участник является человеком, должно использоваться имя этого человека. Если участник является процессом, должно использоваться имя процесса.
NetworkAccessPointTypeCode и NetworkAccessPointID могут быть неоднозначными для систем с несколькими физическими сетевыми подключениями. Для таких многоинтерфейсных узлов должно быть выбрано и использовано при сообщении о событиях аудита одно DNS-имя или один IP-адрес. DICOM не требует использования конкретного метода выбора сетевого подключения для идентификации, но этот метод должен быть одинаковым для всех сообщений аудита, формируемых для событий на данном узле.
EventDateTime - это дата и время, когда произошло сообщаемое событие. Некоторые события имеют значительную длительность. В таких случаях дата и время должны выбираться методом, который является согласованным и подходящим для сообщаемого события.
EventDateTime должен включать информацию о часовом поясе.
Создатели сообщений аудита могут поддерживать дополнительные секунды, но не обязаны это делать. Получатели сообщений аудита должны быть способны обрабатывать сообщения с информацией о дополнительной секунде.
ParticipantObjectTypeCodeRole определяет роль, которую объект играл в сообщаемом событии. В большинстве событий участвует несколько объектов. ParticipantObjectTypeCodeRole показывает, какой объект выполнял какую роль в событии. Он также охватывает агентов, многоцелевые сущности и сущности с несколькими ролями. Для целей события выбирается одна основная роль.
Таблица A.5.2.6-1. Значения Participant Object Type Code Role
RoleIDCode является многозначным элементом.
Одно или несколько значений идентифицируют роль или роли, выполняемые активным участником:
-
Initiator: участвующая сущность, которая инициирует обработку информации. RoleIDCode будет (110156, DCM, "Initiator Role ID").
-
Source: участвующая сущность, из которой происходит информация. RoleIDCode будет (110153, DCM, "Source Role ID").
-
Destination: участвующая сущность, которой направляется информация. RoleIDCode будет (110152, DCM, "Destination Role ID").
Дополнительные значения идентифицируют тип активного участника в этом событии, различая типы носителей и конечных точек, чтобы обеспечить прослеживаемость импортированных, экспортированных или переданных экземпляров в соответствующих системных журналах.
-
Physical media: участвующая сущность является материальным носителем с уникальной постоянной идентичностью. Например, USB-накопитель с идентификатором раздела, CDROM с меткой тома или напечатанная пленка с физической меткой. Включается (110154, DCM, "Destination Media") или (110155, DCM, "Source Media") как значение RoleIDCode. Элемент MediaType также будет присутствовать.
-
Digital media: участвующая сущность является цифровым ресурсом с уникальной постоянной идентичностью. Например, сообщение электронной почты с Message-IDs по [RFC 5322], объекты облачного хранилища с уникальными URI или сетевые файловые ресурсы с конкретными путями. Включается (110154, DCM, "Destination Media") или (110155, DCM, "Source Media") как значение RoleIDCode. Элемент MediaType также будет присутствовать.
-
Network access points: участвующая сущность является сетевой конечной точкой с уникальной идентичностью. Например, DICOM Application Entity с AE Title и/или идентификатором точки сетевого доступа. Включается (110153, DCM, "Source Role ID") или (110152, DCM, "Destination Role ID") как значение RoleIDCode. Также могут присутствовать элементы MediaType, MediaIdentifier и NetworkAccessPointID.
-
Applications: участвующая сущность является службой, которая не может предоставить уникальную идентификацию для отдельных транзакций, сообщений или элементов носителей. Например, менеджеры буфера обмена, которые не могут уникально идентифицировать содержимое буфера обмена, системы обмена сообщениями без отслеживания отдельных сообщений и некоторые системы электронной почты, которые не предоставляют Message-IDs. Включается (110150, DCM, "Application") как значение RoleIDCode. Applications могут идентифицироваться значениями в других элементах, например mailto://person@example.com, именем процесса или идентификатором службы.
-
Person: участвующая сущность является лицом, связанным с постоянной идентичностью, предоставленной организацией. Например, врач с provider ID или сотрудник больницы с сетевым логином. Включается (110153, DCM, "Source Role ID"), (110152, DCM, "Destination Role ID") или (110156, DCM, "Initiator Role ID") как значение RoleIDCode. Участники Person могут идентифицироваться значениями в других элементах, например UserID или AlternativeUserID.
В сочетании с идентификаторами в других элементах RoleIDCode облегчает:
-
Поиск идентифицируемых носителей. Например, в папках и базах данных электронной почты можно искать email Message-ID; partition-ID в системных журналах устройств можно искать для системных подключений носителей, идентифицирующих USB-устройство.
-
Обнаружение других релевантных системных журналов. Например, передача, помеченная как “to” или “from” “sms://123456789”, может указывать, что журналы SMS имеют отношение к делу.
-
Фильтрацию транзакций с участием подозрительных действующих субъектов на основе их типа и роли.
Следующие подразделы определяют специализации сообщений для использования реализациями, заявляющими соответствие DICOM Audit Trail Message Format Profile. Любое поле, то есть XML-элемент и связанные с ним атрибуты, специально не упомянутое в следующих таблицах, должно следовать соглашениям, указанным в Разделе A.5.1 и Разделе A.5.2.
Примечание
Это означает, например, что смысл полей, определенных в Разделе A.5.2, не изменяется. Кроме того, могут присутствовать любые из этих полей или другие необязательные расширения, согласованные со схемой.
Реализация, заявляющая соответствие этому профилю и сообщающая об активности, охваченной одним из сообщений аудита, определенных данным профилем, должна использовать формат сообщения, определенный в этом профиле. Однако система, заявляющая соответствие этому профилю, не обязана отправлять сообщение каждый раз, когда происходит активность, о которой сообщает такое сообщение аудита. Ожидается, что запуск сообщений аудита будет настраиваться индивидуально, чтобы можно было балансировать нагрузку на сеть и серьезность угроз в соответствии с локальными политиками безопасности.
Примечание
-
Вопрос о том, какая сущность фактически отправляет событие аудита и когда, относится к проектированию системы и находится вне области применения DICOM. Например, сообщение Query может быть создано сущностью, в которой возник запрос, сущностью, которая в итоге должна ответить на запрос, или сущностью мониторинга, не участвующей непосредственно в запросе, но создающей сообщения аудита на основе отслеживаемого сетевого трафика.
-
Для сообщения о событиях, похожих на описанные здесь, эти определения могут использоваться как основа для расширения схемы.
В последующих таблицах колонка Real-World Entities указывает реальные сущности и соответствующий им элемент, определенный в элементе AuditMessage сообщения аудита.
Это сообщение аудита описывает событие запуска или остановки Application Entity. Оно тесно связано с более общим случаем запуска или завершения работы приложения любого типа и также может подходить для таких целей.
Таблица A.5.3.1-1. Сообщение Application Activity
|
|
|||
|
Идентичность запущенного или остановленного процесса, отформатированная как указано в Разделе A.5.2.1. |
|||
|
Если процесс поддерживает DICOM, то AE Titles, как указано в Разделе A.5.2.2. |
|||
|
Лица или процессы, запускающие или останавливающие приложение. |
|||
Это сообщение описывает событие чтения человеком или процессом журнала с информацией аудиторского следа.
Примечание
Например, реализация, которая поддерживает локальный кэш информации аудита, еще не переданной в центральную точку сбора, может сформировать это сообщение, если пользователь получил доступ к ее локальному кэшу.
Таблица A.5.3.2-1. Сообщение Audit Log Used
|
|
|||
|
Active Participant: ActiveParticipant (активный участник) Лицо и/или процесс, получившие доступ к аудиторскому следу (1..2) |
Лицо или процесс, получающий доступ к аудиторскому следу. Если известны оба, должны быть включены два активных участника: и лицо, и процесс. |
||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
|
|
|||
|
См. раздел A.5.2. |
|||
|
См. раздел A.5.2. |
|||
|
См. раздел A.5.2. |
|||
|
См. раздел A.5.2. |
|||
|
См. раздел A.5.2. |
|||
|
См. раздел A.5.2. |
|||
|
См. раздел A.5.2. |
Это сообщение описывает событие, при котором система начинает передачу набора экземпляров DICOM SOP с одного узла на другой узел в пределах домена безопасности, контролируемого системой. Это сообщение может содержать информацию только об одном пациенте.
Примечание
Для завершения передачи определено отдельное сообщение DICOM Instances Transferred, позволяющее сравнить, что предполагалось отправить, с тем, что было фактически отправлено.
Таблица A.5.3.3-1. Сообщение аудита для Begin Transferring DICOM Instances
|
|
|||
|
Идентификаторы любых других известных участников, которые могут быть вовлечены, особенно третьих сторон, являющихся инициаторами запроса. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
Элемент "ContainsSOPClass" с одним или несколькими значениями UID класса SOP. |
|||
|
См. условия в разделе A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Это сообщение описывает событие экспорта данных из системы, то есть ситуацию, когда данные выходят из-под контроля домена безопасности системы. Примеры экспорта включают печать на бумаге, запись на плёнку, преобразование в другой формат для хранения в EHR, запись на съёмный носитель или отправку по электронной почте. В одном сообщении события могут быть описаны несколько пациентов.
Таблица A.5.3.4-1. Сообщение аудита для Data Export
|
|
|||
|
Идентификатор удалённого пользователя или процесса, принимающего данные. |
|||
|
См. раздел A.5.3.4.1. |
|||
|
Идентификатор локального пользователя или процесса, экспортирующего данные. Если известны оба, должны быть включены два активных участника: и лицо, и процесс. |
|||
|
См. раздел A.5.3.4.1. |
|||
|
См. раздел A.5.2.1. |
|||
|
См. раздел A.5.2.2. |
|||
|
|
|||
|
DCID 402 “Audit Active Participant Role ID Code” См. раздел A.5.2.7. |
|||
|
Обязательно, если экспорт выполняется не на физический носитель. В остальных случаях может присутствовать. |
|||
|
Обязательно, если присутствует NetworkAccessPointTypeCode. В остальных случаях может присутствовать. |
|||
|
Идентификатор тома, URI или другой идентификатор носителя. Обязательно для цифрового носителя. В остальных случаях может присутствовать. |
|||
|
DCID 405 “Media Type Code” или DCID 406 “Application Type Code” Обязательно, если NetworkAccessPointID отсутствует. В остальных случаях может присутствовать. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
См. раздел A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Это сообщение описывает событие импорта данных в организацию, подразумевая, что данные, теперь поступающие в систему, ранее не находились под контролем домена безопасности этой организации. Передача на носителе внутри организации часто рассматривается как передача данных, а не как событие импорта данных. Пример импорта - создание новых локальных экземпляров из данных на съёмном носителе. В одном сообщении события могут быть описаны несколько пациентов.
Один пользователь, локальный или удалённый, должен быть указан как инициатор запроса, то есть UserIsRequestor должен иметь значение true. Это учитывает как модели передачи push, так и модели pull для носителей.
Таблица A.5.3.5-1. Сообщение аудита для Data Import
|
|
|||
|
Идентификаторы локальных пользователей или процессов, импортирующих данные. |
|||
|
См. раздел A.5.3.5. |
|||
|
См. раздел A.5.2.1. |
|||
|
См. раздел A.5.2.2. |
|||
|
|
|||
|
DCID 402 “Audit Active Participant Role ID Code” См. раздел A.5.2.7. |
|||
|
Обязательно, если присутствует NetworkAccessPointTypeCode. В остальных случаях может присутствовать. |
|||
|
DCID 405 “Media Type Code” или DCID 406 “Application Type Code” Обязательно, если NetworkAccessPointID отсутствует. В остальных случаях может присутствовать. |
|||
|
См. раздел A.5.2.1. |
|||
|
См. раздел A.5.2.2. |
|||
|
См. раздел A.5.3.5. |
|||
|
Должно присутствовать, если присутствует Net Access Point Type Code. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
См. раздел A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Это сообщение описывает событие просмотра, использования, обновления или удаления экземпляров DICOM SOP. Сообщение должно содержать информацию только об одном пациенте и может использоваться для сводного описания всей активности по нескольким исследованиям этого пациента. Это сообщение регистрирует исследования, к которым относятся экземпляры, а не отдельные экземпляры.
Если удалены все экземпляры внутри исследования, следует использовать событие EV(110105, DCM, "DICOM Study Deleted"); см. раздел A.5.3.8.
Таблица A.5.3.6-1. Сообщение аудита для DICOM Instances Accessed
|
|
|||
|
Active Participant: ActiveParticipant (активный участник) |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
См. раздел A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Это сообщение описывает событие завершения передачи экземпляров DICOM SOP между двумя прикладными сущностями. Это сообщение может содержать информацию только об одном пациенте.
Примечание
Этому сообщению могло предшествовать сообщение Begin Transferring DICOM Instances. Сообщение Begin Transferring DICOM Instances передаёт намерение сохранить экземпляры SOP, тогда как сообщение DICOM Instances Transferred регистрирует завершение передачи. Любое расхождение между двумя сообщениями может указывать на потенциальное нарушение безопасности.
Таблица A.5.3.7-1. Сообщение аудита для DICOM Instances Transferred
|
Перечисляемое значение:
Если Audit Source не является получателем либо иначе не знает, имелись ли ранее эти экземпляры на принимающем узле, следует использовать "R" = Read. |
|||
|
DCID 402 “Audit Active Participant Role ID Code” См. раздел A.5.2.7. |
|||
|
Идентификатор тома, URI или другой идентификатор цифрового носителя. |
|||
|
DCID 405 “Media Type Code” или DCID 406 “Application Type Code” |
|||
|
DCID 402 “Audit Active Participant Role ID Code” См. раздел A.5.2.7. |
|||
|
Идентификатор тома, URI или другой идентификатор цифрового носителя. |
|||
|
DCID 405 “Media Type Code” или DCID 406 “Application Type Code” |
|||
|
Active Participant: ActiveParticipant (активный участник) Другие известные участники, особенно третьи стороны, являющиеся инициаторами запроса (0..N) |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
См. раздел A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Это сообщение описывает событие удаления одного или нескольких исследований и всех связанных с ними экземпляров SOP в рамках одного действия. Это сообщение должно содержать информацию только об одном пациенте.
Таблица A.5.3.8-1. Сообщение аудита для DICOM Study Deleted
|
|
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
См. раздел A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Это сообщение описывает событие, при котором система, например мобильное устройство, намеренно подключается к сети или покидает её.
Для этого сообщения объекты-участники не требуются.
Примечание
Машина должна попытаться отправить это сообщение до отключения. Если это невозможно, она должна сохранить сообщение в локальном буфере, чтобы отправить его позже. Затем мобильная машина может записывать сообщения аудита в локальный буфер, пока находится вне защищённого домена. При повторном подключении к защищённому домену она может отправить сообщение об отключении, если оно было буферизовано, затем буферизованные сообщения, а затем сообщение мобильной машины о повторном присоединении к защищённому домену. Временные метки в этих сообщениях соответствуют времени, когда было замечено наступление события, а не времени отправки сообщения.
Таблица A.5.3.9-1. Сообщение аудита для Network Entry
Это сообщение описывает событие выдачи или получения запроса Query. Сообщение не регистрирует ответ на запрос, а только фиксирует факт выдачи запроса. Например, оно может сообщать о запросах, использующих следующие классы DICOM SOP:
Примечание
-
Ответ на запрос может привести к появлению одного или нескольких сообщений DICOM Instances Transferred или DICOM Instances Accessed в зависимости от того, какие события произошли после запроса. Если при обработке запроса возникли связанные с безопасностью сбои, например нарушения доступа, эти сбои должны отражаться в других сообщениях аудита, например в сообщении Security Alert.
-
Это сообщение также может фиксировать запросы, не относящиеся к DICOM. Поля Participant Object ID Type Code, Participant Object ID и Query могут иметь значения, связанные с такими non-DICOM запросами.
Таблица A.5.3.10-1. Сообщение аудита для Query
|
|
|||
|
Active Participant: ActiveParticipant (активный участник) Другие известные участники, особенно третьи стороны, запросившие выполнение запроса (0..N) |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
Если ParticipantObjectIDTypeCode равен (110181, DCM, "SOP Class UID"), это поле должно содержать UID запрашиваемого класса SOP. |
|||
|
Если ParticipantObjectIDTypeCode равен (110181, DCM, "SOP Class UID"), это поле должно содержать набор данных DICOM-запроса, закодированный как xs:base64Binary. В противном случае оно должно содержать запрос в формате используемого протокола. |
|||
|
Обязательно, если ParticipantObjectIDTypeCode равен (110181, DCM, "SOP Class UID") Должен присутствовать элемент ParticipantObjectDetail с XML-атрибутом "TransferSyntax". Значением атрибута Transfer Syntax должен быть UID синтаксиса передачи запроса. Содержимое элемента должно быть закодировано как xs:base64Binary. Transfer Syntax должен быть синтаксисом передачи DICOM. |
|||
|
См. раздел A.5.2. |
|||
Это сообщение описывает любое событие, для которого узлу необходимо сообщить предупреждение безопасности, например сбой аутентификации узла при установлении защищённого канала связи.
Примечание
Событие Node Authentication может использоваться для сообщения как об успешных, так и о неуспешных результатах. Если сообщать об успешных результатах, это может сформировать очень большое количество сообщений аудита, поскольку каждая аутентифицированная DICOM-ассоциация, транзакция HL7 и HTML-соединение должны приводить к успешной аутентификации узла. Ожидается, что в большинстве ситуаций будут сообщаться только сбои.
Таблица A.5.3.11-1. Сообщение аудита для Security Alert
|
|
|||
|
Success означает информационное предупреждение. Другие значения отказа подразумевают коды предупреждений, указывающие серьёзность предупреждения. Отказ уровня Minor или Serious указывает, что меры по снижению риска оказались эффективными для сохранения безопасности системы. Отказ уровня Major указывает, что меры по снижению риска могли оказаться неэффективными и система безопасности могла быть скомпрометирована. |
|||
|
|
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
|
Для ParticipantObjectIDTypeCode со значением 12 = URI это значение должно быть URI файла или другого ресурса, являющегося предметом предупреждения. Для ParticipantObjectIDTypeCode со значением (110182, DCM, "Node ID") значение должно включать идентификацию узла, являющегося предметом предупреждения, либо в форме node_name@domain_name, либо как IP-адрес. В остальных случаях значение должно быть идентификатором предмета предупреждения того типа, который задан ParticipantObjectIDTypeCode. |
|||
|
Должен присутствовать элемент с атрибутом "type", равным "Alert Description"; его значением должно быть текстовое описание характера предупреждения в свободной форме. |
|||
|
См. раздел A.5.2. |
|||
Это сообщение описывает событие, при котором пользователь попытался войти в систему или выйти из неё. Такой отчёт может быть сформирован независимо от того, была ли попытка успешной. Для этого сообщения объекты-участники не требуются.
Примечание
Обычно для пользователя UserIsRequestor имеет значение true, но в случае таймера выхода из системы инициатором UserIsRequestor может быть узел.
Таблица A.5.3.12-1. Сообщение аудита для User Authentication
Это сообщение описывает событие создания, изменения, доступа или удаления заказа. Это сообщение может содержать информацию только об одном пациенте.
Примечание
Запись заказа обычно управляется системой, не относящейся к DICOM. Однако приложения DICOM часто работают с записями заказов, поэтому политики безопасности объекта могут обязывать их регистрировать такие события в журналах аудита.
Таблица A.5.3.13-1. Сообщение аудита для Order Record
Это сообщение описывает событие создания, изменения, доступа или удаления записи пациента.
Примечание
Существует несколько типов записей пациента, управляемых как DICOM-, так и non-DICOM системами. Приложения DICOM часто работают с записями пациента, управляемыми различными системами, поэтому политики безопасности объекта могут обязывать их регистрировать такие события в журналах аудита. Это событие аудита может использоваться для регистрации доступа к записям пациента или действий с ними, когда конкретные экземпляры DICOM SOP не задействованы.
Таблица A.5.3.14-1. Сообщение аудита для Patient Record
Это сообщение описывает событие создания, доступа, изменения или удаления записи процедуры. Это сообщение может содержать информацию только об одном пациенте.
Примечание
-
Приложения DICOM часто работают с записями процедур, например при обновлении MPPS. События запросов Modality Worklist описываются сообщением события Query.
-
Один и тот же Accession Number может встречаться с несколькими номерами заказов. Поля участника Study или всё сообщение могут повторяться, чтобы зафиксировать такие связи многие-ко-многим.
Таблица A.5.3.15-1. Сообщение аудита для Procedure Record
|
|
|||
|
Active Participant: ActiveParticipant (активный участник) Лицо и/или процесс, получающие доступ к данным или изменяющие их (1..2) |
Идентификатор лица или процесса, получающего доступ к данным или изменяющего их. Если известны оба, должны быть включены два активных участника: и лицо, и процесс. |
||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
Дополнительно не специализировано. См. условия в разделе A.5.2. |
|||
|
Participant Object: ParticipantObjectIdentification (объект-участник) |
|
||
|
|
|||
|
|
|||
Этот профиль определяет передачу сообщений аудиторского следа. [RFC 5425] предоставляет механизмы надёжной передачи, буферизации, подтверждения, аутентификации, идентификации и шифрования. [RFC 5424] указывает, что используемый TLS MUST быть TLS версии 1.2. Для этого профиля DICOM TLS MUST использоваться, а версия 1.2 или более поздняя является RECOMMENDED.
Примечание
Слова MUST и RECOMMENDED используются в соответствии со спецификацией IETF для нормативных требований.
Любая реализация, заявляющая соответствие этому профилю, должна также соответствовать профилю формата сообщений аудиторского следа. XML-сообщения аудиторского следа, созданные в формате, определённом профилем формата сообщений аудиторского следа, должны передаваться в точку сбора с использованием механизма syslog over TLS, определённого в [RFC 5425]. Системы, соответствующие этому профилю, должны поддерживать размер сообщений не менее 32768 октетов.
Примечание
-
По тому же syslog-соединению могут также передаваться сообщения аудита для других целей. Эти сообщения могут не соответствовать формату сообщений аудиторского следа.
-
[RFC 5425] устанавливает обязательную поддержку сообщений размером 2 КБ, настоятельно рекомендует поддержку не менее 8 КБ и не ограничивает максимальный размер.
-
Если полученное сообщение длиннее, чем поддерживает принимающее приложение, сообщение может быть отброшено или усечено. Отправляющее приложение не будет уведомлено.
XML-сообщение аудиторского следа должно быть помещено в часть MSG элемента SYSLOG-MSG сообщения syslog, как определено в [RFC 5424]. XML-сообщение аудита может содержать символы Unicode, закодированные по правилам UTF-8.
Примечание
UTF-8 позволяет избежать использования управляющих символов, зарезервированных протоколом syslog, однако система, не подготовленная к UTF-8, может отображать эти сообщения некорректно.
Поле PRI должно устанавливаться с использованием значения facility 10 (сообщения безопасности/авторизации). Для большинства сообщений значение severity должно быть 5 (обычное, но значимое), хотя приложения могут выбирать другие значения, если это соответствует более подробной информации в сообщении аудита. Это означает, что для большинства сообщений аудита поле PRI будет содержать значение "<85>".
Поле MSGID в HEADER элемента SYSLOG-MSG должно быть задано. Значение "DICOM+RFC3881" может использоваться для сообщений, соответствующих этому профилю.
Поле MSG элемента SYSLOG-MSG должно присутствовать и должно быть XML-структурой, соответствующей схеме DICOM Audit Message Schema (см. раздел A.5.1).
Сообщение syslog должно создаваться и передаваться, как описано в [RFC 5424].
Любая реализация, заявляющая соответствие этому профилю безопасности, должна описывать в своём заявлении о соответствии:
-
любые параметры конфигурации, относящиеся к [RFC 5424] и [RFC 5425].
-
Любые STRUCTURED-DATA, которые формируются или обрабатываются.
-
Любую схему реализации или расширения элементов сообщений для сообщений аудита.
-
Максимальный размер сообщений, которые могут быть отправлены или получены.
Этот профиль определяет передачу сообщений аудиторского следа. [RFC 5426] предоставляет механизмы быстрой передачи сообщений аудита. Это стандартизованный преемник информационного стандарта [RFC 3164], который широко используется в различных условиях.
Номер порта syslog должен быть настраиваемым, при этом номер порта (514) используется по умолчанию.
Нижележащий транспорт UDP может не принимать сообщения, длина которых превышает размер MTU за вычетом длины заголовка UDP. Это может привести к усечению более длинных сообщений syslog. При усечении таких сообщений результирующий XML может оказаться некорректным. Из-за возможности усечения сообщений и других вопросов безопасности может быть предпочтительна передача сообщений syslog по TLS (см. раздел A.6).
Поле PRI должно устанавливаться с использованием значения facility 10 (сообщения безопасности/авторизации). Для большинства сообщений значение severity должно быть 5 (обычное, но значимое), хотя приложения могут выбирать значение 4 (условие предупреждения), если это соответствует более подробной информации в сообщении аудита. Это означает, что для большинства сообщений аудита поле PRI будет содержать значение "<85>". Репозитории аудита должны быть готовы корректно обрабатывать любое входящее значение PRI.
Поле MSGID в HEADER элемента SYSLOG-MSG должно быть задано. Значение "DICOM+RFC3881" может использоваться для сообщений, соответствующих этому профилю.
Поле MSG элемента SYSLOG-MSG должно присутствовать и должно быть XML-структурой, соответствующей схеме DICOM Audit Message Schema (см. раздел A.5.1).
Сообщение syslog должно создаваться и передаваться, как описано в [RFC 5424].
Любая реализация, заявляющая соответствие этому профилю безопасности, должна описывать в своём заявлении о соответствии:
-
любые параметры конфигурации, относящиеся к [RFC 5424] и [RFC 5426].
-
Любые STRUCTURED-DATA, которые формируются или обрабатываются.
-
Любую схему реализации или расширения элементов сообщений для сообщений аудита.
-
Максимальный размер сообщений, которые могут быть отправлены или получены.
Исключено из стандарта. См. PS3.3-2018a.
Исключено из стандарта. См. PS3.3-2018a.
Исключено из стандарта. См. PS3.3-2018a.
Реализация, поддерживающая Basic User Identity Association Profile, должна принимать подэлемент согласования ассоциации User Identity для User-Identity-Type со значением 1 или 2. Она не обязана проверять код доступа. Если запрошен положительный ответ, реализация должна ответить подэлементом ответа ассоциации.
Идентификатор пользователя из Primary-field должен использоваться внутри реализации как идентификация пользователя. Такие варианты использования включают запись идентификации пользователя в сообщениях аудита.
Таблица B.4-1. Минимальные механизмы для функций согласования ассоциации DICOM - Basic User Identity Association Profile
Реализация, поддерживающая User Identity Plus Passcode Association Profile, должна отправлять/принимать подэлемент согласования ассоциации User Identity для User-Identity-Type со значением 2. Если запрошен положительный ответ, реализация, принимающая ассоциацию, должна ответить подэлементом ответа ассоциации. Информация о коде доступа должна быть доступна внутренним или внешним системам аутентификации. Идентификатор пользователя должен быть аутентифицирован с помощью кода доступа и системы аутентификации. Если аутентификация завершается неуспешно, ассоциация должна быть отклонена.
Идентификатор пользователя из Primary-field должен использоваться внутри реализации как идентификация пользователя. Такие варианты использования включают запись идентификации пользователя в сообщениях аудита.
Таблица B.5-1. User Identity Plus Passcode Association Profile - минимальные механизмы для функций согласования ассоциации DICOM
Реализация, поддерживающая Kerberos Identity Negotiation Association Profile, должна отправлять/принимать подэлемент согласования ассоциации User Identity для User-Identity-Type со значением 3. Если запрошен положительный ответ, реализация, принимающая ассоциацию, должна ответить подэлементом ответа ассоциации, содержащим серверный билет Kerberos. Информация серверного билета Kerberos должна быть доступна внутренним или внешним системам аутентификации Kerberos. Идентификатор пользователя должен быть аутентифицирован с помощью системы аутентификации Kerberos. Если аутентификация завершается неуспешно, ассоциация должна быть отклонена.
Идентификатор пользователя из Primary-field должен использоваться внутри реализации как идентификация пользователя. Такие варианты использования включают запись идентификации пользователя в сообщениях аудита.
Таблица B.6-1. Kerberos Identity Negotiation Association Profile - минимальные механизмы для функций согласования ассоциации DICOM
Реализация, поддерживающая Generic SAML Assertion Identity Negotiation Association Profile, должна отправлять/принимать подэлемент согласования ассоциации User Identity для User-Identity-Type со значением 4. Если запрошен положительный ответ, реализация, принимающая ассоциацию, должна ответить подэлементом ответа ассоциации, содержащим ответ SAML. Информация SAML Assertion должна быть доступна внутренним или внешним системам аутентификации. Идентификатор пользователя должен быть аутентифицирован с помощью системы аутентификации, использующей SAML Assertions. Если аутентификация завершается неуспешно, ассоциация должна быть отклонена.
Идентификатор пользователя из Primary-field должен использоваться внутри реализации как идентификация пользователя. Такие варианты использования включают запись идентификации пользователя в сообщениях аудита.
Таблица B.7-1. Generic SAML Assertion Identity Negotiation Association Profile - минимальные механизмы для функций согласования ассоциации DICOM
Когда набор файлов DICOM File Set отправляется по транспорту электронной почты в соответствии с этим профилем, должны соблюдаться следующие правила:
-
File Set должен быть вложением к телу сообщения электронной почты.
-
Всё сообщение электронной почты целиком (тело, вложение File Set и любые другие вложения) должно быть зашифровано с использованием AES в соответствии с [RFC 3851] и [RFC 3853].
-
Тело сообщения электронной почты и вложения могут быть сжаты в соответствии с [RFC 3851].
-
Сообщение электронной почты должно быть подписано отправителем цифровой подписью. Подписание может выполняться до или после шифрования. Эта цифровая подпись должна интерпретироваться как подтверждение отправителем своих полномочий раскрыть получателю информацию, содержащуюся в этом сообщении.
Подпись сообщения электронной почты присутствует для предоставления минимальной информации об отправителе и подтверждения целостности передачи по электронной почте (содержимого тела, вложения и т. п.). Подпись сообщения электронной почты отделена от других подписей, которые могут присутствовать в отчётах DICOM и объектах, содержащихся в File Set, вложенном в сообщение. Эти подписи определяются с точки зрения клинического использования. Любые подтверждения клинического содержимого должны кодироваться как цифровые подписи в экземплярах DICOM SOP, а не как подпись сообщения электронной почты. Сообщение электронной почты может быть составлено лицом, которое не может делать клинические подтверждения. Используя подпись сообщения электронной почты, составитель подтверждает, что он или она уполномочены передать данные получателю.
Примечание
-
Этот профиль отделён от нижележащего использования ZIP File или другой упаковки File Set для передачи по электронной почте.
-
При передаче частной информации нормативные требования большинства стран требуют использования шифрования или эквивалентных средств защиты. Этот профиль соответствует наиболее распространённым нормативным требованиям, но могут существовать дополнительные локальные требования. Дополнительные требования могут включать обязательные заявления в теле сообщения электронной почты и запреты на содержимое тела сообщения для защиты конфиденциальности пациента.
Исключено из стандарта. См. PS3.3-2022d.
Исключено из стандарта. См. PS3.3-2022d.
Исключено из стандарта. См. PS3.3-2022d.
Реализация, поддерживающая BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile, должна использовать инфраструктуру и механизм согласования, заданные протоколом Transport Layer Security. Она должна соответствовать [BCP 195], который включает [RFC 8996] и [RFC 9325]. В контексте этого профиля “client” означает сущность, инициирующую TLS-соединение, а “server” означает сущность, отвечающую на запрос инициирования этого TLS-соединения. Это может отличаться от роли, которую сущность играет в любых транзакциях DICOM поверх TLS-соединения.
Примечание
-
Устройство может поддерживать несколько профилей TLS. DICOM не определяет, как такие устройства настраиваются на месте эксплуатации или как задаются разные правила, связанные с профилями TLS. Объект определяет, какая конфигурация является подходящей.
-
Профили DICOM для TLS описывают возможности продукта. Конфигурация продукта может позволять выбор конкретного профиля и/или дополнительных правил согласования. Конкретный используемый набор шифров согласуется реализацией TLS на основе этих правил.
Серверы и клиенты должны поддерживать TLS 1.2 и могут поддерживать TLS 1.3. Клиенты должны пытаться согласовать TLS 1.3, если он поддерживается. Серверы должны предпочитать TLS 1.3, если он предложен клиентом.
В случаях, когда прикладной протокол позволяет реализациям или развертываниям выбирать между строгой конфигурацией TLS и динамическим переходом от незашифрованного трафика к трафику, защищённому TLS (например, STARTTLS), клиенты и серверы должны предпочитать строгую конфигурацию TLS.
Прикладные протоколы обычно предоставляют серверу способ предложить TLS во время начального обмена протокола, а иногда также способ объявить поддержку TLS (например, с помощью флага, указывающего, что TLS обязателен). К сожалению, такие указания отправляются до шифрования канала связи.
Клиент должен пытаться согласовать TLS, даже если указанные выше признаки не передаются сервером.
Все коммуникации должны быть зашифрованы с включёнными проверками целостности. Поэтому реализации не должны использовать NULL-протоколы обмена ключами, шифрования или подписи/хэширования.
Серверы должны поддерживать двунаправленную взаимную аутентификацию. Клиенты не обязаны, но им рекомендуется поддерживать и использовать двунаправленную взаимную аутентификацию. Сервер может быть настроен так, чтобы не использовать двунаправленную взаимную аутентификацию.
TCP-порты, на которых реализация принимает TLS-соединения для DICOMweb, должны отличаться от портов, на которых реализация принимает TLS-соединения для DIMSE. HTTP/HTTPS-соединение для DICOMweb может совместно использоваться с другим HTTP/HTTPS-трафиком.
Примечание
Рекомендуется, чтобы системы, поддерживающие этот профиль, использовали зарегистрированный номер порта "2762 dicom-tls" для DICOM Upper Layer Protocol поверх TLS, который используется DIMSE.
В заявлении о соответствии должно быть указано:
При сбое проверки целостности соединение должно быть разорвано согласно протоколу TLS, что приводит к выдаче и отправителем, и получателем индикации A-P-ABORT верхним уровням с зависящей от реализации причиной поставщика. В заявлении о соответствии должны быть документированы причины поставщика, выдаваемые реализацией.
Реализация, поддерживающая Modified BCP 195 RFC 8996, 9325 TLS Secure Transport Connection Profile, должна использовать инфраструктуру и механизм согласования, заданные протоколом Transport Layer Security. Она должна соответствовать [BCP 195], который включает [RFC 8996] и [RFC 9325], с дополнительными ограничениями, перечисленными ниже. В контексте этого профиля “client” означает сущность, инициирующую TLS-соединение, а “server” означает сущность, отвечающую на запрос инициирования этого TLS-соединения. Это может отличаться от роли, которую сущность играет в любых транзакциях DICOM поверх TLS-соединения.
Примечание
-
Устройство может поддерживать несколько профилей TLS. DICOM не определяет, как такие устройства настраиваются на месте эксплуатации или как задаются разные правила, связанные с профилями TLS. Объект определяет, какая конфигурация является подходящей.
-
Профили DICOM для TLS описывают возможности продукта. Конфигурация продукта может позволять выбор конкретного профиля и/или дополнительных правил согласования. Конкретный используемый набор шифров согласуется реализацией TLS на основе этих правил.
Клиент должен пытаться согласовать TLS, даже если указанные выше признаки не передаются сервером.
Следующие криптографические алгоритмы, сгруппированные по функциям, не должны использоваться:
Only the following cryptographic algorithms, grouped by function, are permitted:
Когда DHE используется для обмена ключами, длина ключа должна быть 2048 бит или более. Наборы шифров, содержащие DHE, не должны выбираться при использовании реализаций, которые не позволяют явно задавать длину ключа DHE.
Когда ECDHE используется для обмена ключами, длина ключа должна быть 256 бит или более.
Серверы должны поддерживать все следующие наборы шифров для TLS 1.3. Клиенты, поддерживающие TLS 1.3, должны поддерживать как минимум один из следующих наборов шифров.
Примечание
В TLS 1.3 алгоритмы Key Exchange и Signature не указываются при согласовании набора шифров. Реализации могут выбирать из приведённого выше списка разрешённых алгоритмов.
Серверы должны поддерживать все следующие наборы шифров для TLS 1.2. Клиенты должны поддерживать как минимум один из наборов шифров, определённых ниже.
Следующий список наборов шифров может использоваться, но их поддержка не является обязательной ни для серверов, ни для клиентов.
При использовании TLS 1.2 наборы шифров, отличные от перечисленных выше в обязательном или необязательном списках, не разрешены.
К сертификатам в TLS применяются следующие требования:
-
Если алгоритм открытого ключа субъекта — RSA, длина ключа должна быть 2048 бит или более.
-
Если алгоритм открытого ключа субъекта — ECC, длина ключа должна быть 256 бит или более.
-
Если алгоритм подписи сертификата — RSA, длина ключа должна быть 2048 бит или более.
-
Если алгоритм подписи сертификата — ECDSA, длина ключа должна быть 256 бит или более.
Серверы должны поддерживать как TLS 1.2, так и TLS 1.3. Клиенты должны поддерживать как минимум один из вариантов: TLS 1.2 или TLS 1.3. Клиенты должны пытаться согласовать TLS 1.3, если он поддерживается. Серверы должны предпочитать TLS 1.3, если он предложен клиентом. Реализации могут откатиться к TLS 1.2, если клиент не согласовал TLS 1.3.
В случаях, когда прикладной протокол позволяет реализациям или развертываниям выбирать между строгой конфигурацией TLS и динамическим переходом от незашифрованного трафика к трафику, защищённому TLS (например, STARTTLS), клиенты и серверы должны предпочитать строгую конфигурацию TLS.
Прикладные протоколы обычно предоставляют серверу способ предложить TLS во время начального обмена протокола, а иногда также способ объявить поддержку TLS (например, с помощью флага, указывающего, что TLS обязателен); к сожалению, такие указания отправляются до шифрования канала связи.
Серверы должны поддерживать двунаправленную взаимную аутентификацию. Клиенты не обязаны, но им рекомендуется поддерживать и использовать двунаправленную взаимную аутентификацию. Сервер может быть настроен так, чтобы не использовать двунаправленную взаимную аутентификацию.
TCP-порты, на которых реализация принимает TLS-соединения для DICOMweb, должны отличаться от портов, на которых реализация принимает TLS-соединения для DIMSE. HTTP/HTTPS-соединение для DICOMweb может совместно использоваться с другим HTTP/HTTPS-трафиком.
Примечание
Рекомендуется, чтобы системы, поддерживающие этот профиль, использовали зарегистрированный номер порта "2762 dicom-tls" для DICOM Upper Layer Protocol поверх TLS.
В заявлении о соответствии должно быть указано:
При сбое проверки целостности соединение должно быть разорвано согласно протоколу TLS, что приводит к выдаче и отправителем, и получателем индикации A-P-ABORT верхним уровням с зависящей от реализации причиной поставщика. В заявлении о соответствии должны быть документированы причины поставщика, выдаваемые реализацией.
Base RSA Digital Signature Profile описывает использование шифрования RSA для MAC при формировании Digital Signature. Этот Profile не задаёт конкретный набор Data Elements, которые требуется подписывать. Другие профили Digital Signature могут ссылаться на этот профиль, добавляя требования к подписываемым Data Elements или другие настройки.
Создатель цифровой подписи должен использовать одну из хэш-функций RIPEMD-160, MD5, SHA-1 или семейства SHA-2 (SHA256, SHA384, SHA512) для формирования MAC, который затем шифруется с помощью закрытого ключа RSA. Все средства проверки цифровых подписей должны быть способны использовать MAC, сформированный любой из указанных хэш-функций (RIPEMD-160, MD5, SHA-1 или SHA256, SHA384, SHA512).
Примечание
Использование MD5 не рекомендуется его создателями, RSA. См.: ftp://ftp.rsasecurity.com/pub/pdfs/bulletn4.pdf
Подписываемые данные должны быть дополнены до размера блока, соответствующего размеру ключа RSA, как указано в [RFC 2437] (PKCS #1). Значение MAC Algorithm (0400,0015) должно быть установлено в "RIPEMD160", "MD5", "SHA1", "SHA256", "SHA384" или "SHA512". Открытый ключ, связанный с закрытым ключом, а также идентификационные сведения Application Entity или изготовителя оборудования, которому принадлежит пара ключей RSA, должны передаваться в сертификате подписи [ITU-T X.509] (1993). Значение атрибута Certificate Type (0400,0110) должно быть установлено в "X509_1993_SIG". Локальная политика объекта определяет, как сертификаты [ITU-T X.509] формируются, аутентифицируются и распространяются. Объект может выпускать и распространять сертификаты [ITU-T X.509] напрямую, может использовать услуги Certificate Authority или применять любой разумный метод формирования и проверки сертификатов.
Если реализация использует метки времени, она должна использовать Certified Timestamp Type (0400,0305) со значением "CMS_TSP". Certified Timestamp (0400,0310) должна формироваться, как описано в [RFC 3161].
Создатель DICOM SOP Instance может формировать подписи с использованием Creator RSA Digital Signature Profile. Digital Signature, создаваемая этим Profile, служит долговременной проверкой целостности данных, с помощью которой можно убедиться, что пиксельные данные в SOP Instance не изменялись с момента его первоначального создания. Реализация, поддерживающая Creator RSA Digital Signature Profile, может включать Creator RSA Digital Signature в каждый создаваемый SOP Instance; однако она не обязана это делать.
Подпись должна использовать одну из хэш-функций RIPEMD-160, MD5, SHA-1 или семейства SHA-2 (SHA256, SHA384, SHA512) для формирования MAC, который затем шифруется с помощью закрытого ключа RSA. Все средства проверки цифровых подписей должны быть способны использовать MAC, сформированный любой из указанных хэш-функций (RIPEMD-160, MD5, SHA-1 или SHA256, SHA384, SHA512).
Примечание
Местные правила и нормативные требования могут дополнительно ограничивать разрешённые хэш-функции. Обычно такие требования ограничивают хэш-функции, которые SCP может использовать при создании новой подписи для нового SOP Instance. Например, они могут запрещать использование RIPEMD-160 и MD5. Обычно эти требования позволяют SCU проверять старую подпись, использующую алгоритм, который теперь запрещён для новых подписей. Реализации, поддерживающие этот профиль, должны учитывать такие местные требования.
Как минимум, при формировании Creator RSA Digital Signature реализация должна включать следующие Attributes:
-
SOP Creation Date и SOP Creation Time, если они присутствуют
-
все присутствующие Attributes модуля General Equipment Module
-
все присутствующие Attributes модулей Overlay Plane Module, Curve Module или Graphic Annotation Module
-
все присутствующие Attributes модулей General Image Module и Image Pixel Module
-
все присутствующие Attributes модулей SR Document General Module и SR Document Content Module
-
все присутствующие Attributes модулей Waveform Module и Waveform Annotation Module
-
все присутствующие Attributes модуля Multi-frame Functional Groups Module
-
все присутствующие Attributes модуля Enhanced MR Image Module
-
все присутствующие Attributes модуля Enhanced CT Image Module
-
все присутствующие Attributes модуля Enhanced XA/XRF Image Module
-
все присутствующие Attributes модуля Segmentation Image Module
-
все присутствующие Attributes модуля Encapsulated Document Series Module
-
все присутствующие Attributes модуля Enhanced PET Image Module
-
все присутствующие Attributes модуля Enhanced US Image Module
-
все присутствующие Attributes модуля Surface Segmentation Module
-
все присутствующие Attributes модулей Structured Display Module, Structured Display Annotation Module и Structured Display Image Box Module
-
все присутствующие Attributes модуля Implant Template Module
-
все присутствующие Attributes модуля Implant Assembly Template Module
-
все присутствующие Attributes модуля Implant Template Group Module
-
все присутствующие Attributes модуля Enhanced Mammography Image Module
-
все присутствующие Attributes модулей Tractography Results Modules
-
все присутствующие Attributes модуля Volumetric Graphic Annotation Module
-
все присутствующие Attributes модуля Microscopy Bulk Simple Annotations Module
-
все присутствующие Attributes модуля Waveform Presentation State Relationship Module
-
все присутствующие Attributes модуля Structured Waveform Annotation Module
-
все присутствующие Attributes модуля Textual Waveform Annotation Module
-
все присутствующие Attributes модуля Displayed Waveform Segment Module
-
все присутствующие Attributes модуля Montage Activation Module
-
все присутствующие Attributes модуля Waveform Presentation Montage Module
Примечание
Требование относится к Attributes, а Modules в приведённом выше списке используются для краткости документации. Например, SOP Instance типа Encapsulated STL IOD будет иметь подписанными все Attributes модуля Encapsulated Document Series Module (используемого для инкапсуляции файла STL). В нём также будут подписаны Attributes, используемые в любых изображениях-иконках, поскольку такие изображения используют Attributes, которые также являются Attributes модулей General Image Module и Image Pixel Module. Модули General Image Module и Image Pixel Module не включены в Encapsulated STL IOD и не отображаются в таблице Encapsulated STL IOD Modules.
Digital Signature должна создаваться по методике, описанной в Base RSA Digital Signature Profile. Обычно сертификат и связанный с ним закрытый ключ, используемые для создания Creator RSA Digital Signatures, являются параметрами конфигурации Application Entity, задаваемыми инженерами по обслуживанию или установке.
SCP может включать другие Attributes при формировании Creator RSA Digital Signature, а SCU должен поддерживать проверку таких подписей.
Creator RSA Digital Signatures не имеют прямой связи с другими Digital Signatures. Однако другие Digital Signatures, например Authorization Digital Signature, могут использоваться для подтверждения метки времени Creator RSA Digital Signature.
Техник или врач, утверждающий DICOM SOP Instance для использования, может запросить у Application Entity формирование подписи с использованием Authorization RSA Digital Signature Profile. Созданная Digital Signature служит долговременной проверкой целостности данных, с помощью которой можно убедиться, что пиксельные данные в SOP Instance совпадают с теми, которые техник или врач видел при утверждении.
Подпись должна использовать одну из хэш-функций RIPEMD-160, MD5, SHA-1 или семейства SHA-2 (SHA256, SHA384, SHA512) для формирования MAC, который затем шифруется с помощью закрытого ключа RSA. Все средства проверки цифровых подписей должны быть способны использовать MAC, сформированный любой из указанных хэш-функций (RIPEMD-160, MD5, SHA-1 или SHA256, SHA384, SHA512).
Как минимум, при формировании Authorization RSA Digital Signature реализация должна включать следующие Attributes:
-
любые Attributes, значения которых могут быть проверены техником или врачом (например, их значения отображаются технику или врачу)
-
все присутствующие Attributes модулей Overlay Plane, Curve или Graphic Annotation
-
все присутствующие Attributes модулей General Image и Image Pixel
-
все присутствующие Attributes модулей SR Document General и SR Document Content
-
все присутствующие Attributes модулей Waveform и Waveform Annotation
-
все присутствующие Attributes модуля Multi-frame Functional Groups
-
все присутствующие Attributes модулей Structured Display, Structured Display Annotation и Structured Display Image Box
-
все присутствующие Attributes модуля Implant Assembly Template
-
все присутствующие Attributes модуля Enhanced Mammography Image
-
все присутствующие Attributes модуля Volumetric Graphic Annotation Module
Digital Signature должна создаваться по методике, описанной в Base RSA Digital Signature Profile. Application Entity должна определить личность техника или врача и получить его сертификат с помощью локально установленной процедуры, например механизма входа в систему или смарт-карты.
Authorization RSA Digital Signatures не имеют прямой связи с другими Digital Signatures. Однако другие Digital Signatures, например Creator RSA Digital Signature, могут использоваться для подтверждения метки времени Authorization RSA Digital Signature.
Этот профиль определяет механизм добавления Digital Signatures в Structured Reports или Key Object Selection Documents, где имеется не более одного Verifying Observer. Экземпляры, следующие этому Digital Signature Profile, должны включать как минимум одну Digital Signature на верхнем уровне Data Set.
Все Digital Signatures, следующие этому профилю, должны включать атрибут Digital Signature Purpose Code Sequence (0400,0401).
Как минимум, при формировании Digital Signature, требуемой этим профилем, реализация должна включать следующие Attributes:
Если Verification Flag установлен в "VERIFIED" (и SOP Instance UID больше не может измениться), как минимум одна из Digital Signatures профиля должна иметь назначение (5, ASTM-sigpurpose, "Verification Signature") и дополнительно к указанным выше Attributes должна включать следующие Attributes:
Примечание
Система также может добавить Creator RSA Digital Signature, которая может охватывать другие Attributes, проверяемые системой.
Во всех вхождениях Referenced SOP Instance MAC Sequence (0400,0403) значение MAC Algorithm (0400,0015) должно быть установлено в "RIPEMD160", "MD5", "SHA1", "SHA256", "SHA384" или "SHA512".
Digital Signature должна создаваться по методике, описанной в Base RSA Digital Signature Profile. Application Entity должна определить личности подписантов и получить их сертификаты с помощью процедуры, специфичной для приложения, например механизма входа в систему или смарт-карты. В заявлении о соответствии должно быть указано, как приложение идентифицирует подписантов и получает сертификаты.
Basic DICOM Media Security Profile позволяет инкапсулировать DICOM File в Secure DICOM File так, чтобы были обеспечены следующие аспекты безопасности:
Этот профиль задаёт использование AES или Triple-DES для шифрования содержимого, а также RSA либо шифрования на основе пароля вместе с AES или Triple-DES для транспорта ключей шифрования содержимого. Зашифрованным содержимым является DICOM File, который может:
Примечание
Требования к алгоритмам дайджеста будут развиваться по мере развития угроз. По мере изменения требований к дайджестам этот профиль изменялся, включая дополнительные требования.
Secure DICOM File, соответствующий этому профилю безопасности, должен содержать тип содержимого Enveloped-data из Cryptographic Message Syntax, определённый в IETF STD 70 [RFC 5652], [RFC 3370] и [RFC 3565]. Данные Enveloped-data должны использовать RSA [RFC 3447], либо шифрование на основе пароля с использованием PBKDF2 [RFC 2898] как алгоритма выработки ключа и AES либо Triple-DES [RFC 3211], для транспорта ключей шифрования содержимого. Создатели Secure DICOM File, соответствующего этому профилю безопасности, могут использовать AES или Triple-DES для шифрования содержимого. Средства чтения, заявляющие соответствие этому профилю, должны быть способны расшифровывать Secure DICOM Files, использующие AES или Triple-DES. Длина ключа AES может быть любой длиной, разрешённой соответствующими RFC. Длина ключа Triple-DES составляет 168 бит, как определено в [ANSI X9.52]. Кодирование должно выполняться согласно спецификациям RSA Key Transport и Triple DES Content Encryption в [RFC 3370], а для AES Content Encryption - в [RFC 3565].
Зашифрованное содержимое типа Enveloped-data должно быть одним из следующих вариантов:
В обоих случаях SHA-1 [FIPS 180-1], SHA256, SHA384 или SHA512 [FIPS 180-2] должны использоваться как алгоритм дайджеста. В случае типа содержимого Signed-data RSA [RFC 2313] должен использоваться как алгоритм подписи.
В случае шифрования на основе пароля с использованием PBKDF2 строка октетов, содержащая пароль, используемый для формирования ключа, должна быть ограничена кодировкой и графическим представлением символов, определёнными Default Character Repertoire.
Примечание
-
Транспорт ключей шифрования содержимого с помощью RSA задан как требование в European Prestandard ENV 13608-2: Health Informatics - Security for healthcare communication - Part 2: Secure data objects.
-
Этот профиль не определяет требований к размеру асимметричных пар ключей, используемых для транспорта ключей RSA.
-
Этот профиль не определяет требований или ограничений на использование элемента SignedAttributes структуры SignerInfo типа содержимого Signed-data. SignedAttributes могут, например, использоваться для указания времени подписи или возможностей SMIME, как требуется ENV 13608-2.
-
Использование шифрования на основе пароля для транспорта ключей шифрования содержимого потенциально менее безопасно, чем шифрование на основе сертификатов, но может быть полезно, когда список получателей заранее неизвестен или когда не развёрнута инфраструктура открытых ключей. Безопасность зависит от энтропии пароля, которая при выборе пользователем может быть довольно низкой. [RFC 3211] настоятельно рекомендует использовать парольную "фразу", а не одно слово, и [RFC 2898] не устанавливает практического ограничения длины. Кроме того, метод обмена паролем или парольной фразой также может существенно влиять на уровень безопасности.
-
PBKDF2, как определено в [RFC 2898], задаёт пароль как "строку октетов произвольной длины, интерпретация которой как текстовой строки не определена". Для совместимости между отправителем и получателем должны быть определены и схема кодирования символов, и графическое представление символов. ISO IR6 (US-ASCII), являющийся Default Character Repertoire для DICOM (см. PS3.5), задан для предотвращения возможной неоднозначности, вызванной использованием других наборов символов (например, UTF-8), которые не обязательно дают одинаковые двоичные значения для конкретного графического представления символов.
Графическое представление некоторых символов в ISO IR6 определено явно, хотя то же двоичное представление может иметь другое графическое представление в других 7-битных схемах. Например, в версии ISO 646, используемой в Японии (ISO-IR 14 Romaji), 05/12 представляется как "¥", а не как обратная косая черта "\". Приложение отвечает за то, чтобы метод ввода и отображение таких символов пользователю соответствовали правильной кодировке независимо от локали. То есть, если пароль равен "123\$", он должен кодироваться как 03/01 03/02 03/03 05/12 02/04 независимо от того, вводит ли пользователь обратную косую черту "\" (U+005C) на японской или американской клавиатуре; от него не следует ожидать ввода клавиши "¥" (U+00A5) на японской клавиатуре, и 05/12 не должен отображаться как "¥", если пароль отображается как текст.
Ограничение кодировкой и графическим представлением символов ISO IR 6 (а не, например, минимальной кодировкой UTF-8) также устраняет неоднозначность, создаваемую омографами (символами, которые выглядят одинаково, но кодируются по-разному), и альтернативными кодировками с тем же значением, например одиночным немецким символом "ß" (U+00DF) вместо двух символов "ss" (U+0073 U+0073), а также использованием фонетического представления вместо идеографического для одного и того же значения, например японской хираганы "ぞう" (U+305E U+3046) по сравнению с кандзи "像" (U+50CF).
Приложение отвечает за предотвращение создания пользователем паролей с символами, которые не могут быть представлены; например, на западноевропейской клавиатуре пользователю не следует разрешать вводить символы с диакритическими знаками, такие как "é" (U+00E9) или "ö" (U+00F6), поскольку для таких символов не определено отображение в символы ISO IR 6 (например, "e" или "o").
В этом приложении рассматриваются удаление и замена Attributes в DICOM Data Set, которые потенциально могут привести к утечке Individually Identifiable Information (III) о пациенте или других лицах либо организациях, связанных с данными.
Примечание
Использование Attribute Confidentiality Profiles не гарантирует, что вся индивидуально идентифицирующая информация будет удалена, то есть деидентификация Attributes не означает деидентификацию Information Object. Использование этих профилей не заменяет процесс деидентификации, но должно быть его частью. Описание такого процесса выходит за рамки DICOM, но как минимум включало бы определение контекста деидентификации (например, для какой цели данные деидентифицируются, кто является получателем, как передаются деидентифицированные данные), интерпретацию применимых нормативных требований и оценку риска вредоносной повторной идентификации.
Profiles предоставлены для соблюдения баланса между удалением информации и необходимостью сохранять информацию, чтобы Data Sets оставались полезными для своего предполагаемого назначения.
Options используются в дополнение к Profiles, чтобы избежать комбинаторного разрастания разных Profiles.
Application Level Confidentiality Profile охватывает следующий аспект безопасности:
Другие аспекты безопасности, не рассматриваемые этим Profile и которые могут рассматриваться в других местах стандарта, включают:
Этот Profile предназначен для создания специальной деидентифицированной версии уже существующего Data Set. Он не предназначен для замены исходного SOP Instance, из которого создаётся деидентифицированный SOP Instance, и не предназначен для использования как основное представление клинических Data Sets в архивах изображений. Деидентифицированные SOP Instances полезны, например, для создания учебных или исследовательских файлов, проведения клинических испытаний или передачи в реестры, где требуется защитить личность пациента и других лиц. В некоторых случаях также необходимо обеспечить возможность восстановления идентичности уполномоченным персоналом.
Application может заявлять соответствие Basic Application Level Confidentiality Profile и Options как деидентификатор, если оно защищает и сохраняет все Attributes, как задано в Profile и Options. В этом контексте защита определяется следующим процессом:
-
Приложение может создать один или несколько экземпляров Encrypted Attributes Data Set и скопировать защищаемые Attributes в единственный item Modified Attributes Sequence (0400,0550) одного или нескольких экземпляров Encrypted Attributes Data Set.
Примечание
-
Полное восстановление исходного Data Set может быть невозможным; однако Attributes (например, SOP Instance UID) в Modified Attributes Sequence объекта Encrypted Attributes Data Set могут ссылаться обратно на исходный SOP Instance, содержащий исходный Data Set.
-
Создавать Encrypted Attributes Data Set не обязательно; более того, возможны ситуации, когда ожидается настолько длительное архивное хранение деидентифицированного Data Set, что любая современная технология шифрования может оказаться недостаточной для долгосрочной защиты от несанкционированного восстановления идентичности.
-
Другие механизмы, помогающие восстановлению идентичности или продольной согласованности заменённых UIDs, дат и времени, считаются устаревшими в пользу механизма Encrypted Attributes Data Set, предназначенного для этой цели. Например, если требуется включить зашифрованный хэш Patient's Name, его не следует кодировать в отдельном Private Data Element, реализованном для этой цели; он должен быть включён в Encrypted Attributes Data Set и закодирован стандартным механизмом. Это обеспечивает совместимость разных реализаций и безопасность, основанную на качестве и контроле ключей шифрования. Следует также учитывать, что незашифрованные хэши значительно менее безопасны и их следует избегать, поскольку они уязвимы к простым атакам по словарю.
-
-
Каждый защищаемый Attribute должен быть либо удалён из Data Set, либо его значение должно быть заменено другим «замещающим значением», не позволяющим идентифицировать пациента.
Примечание
-
Деидентификатор отвечает за то, чтобы этот процесс не ухудшал целостность Information Object Definition, то есть Dummy values могут быть необходимы для Attributes Type 1, которые защищаются, но не могут передаваться с нулевой длиной и должны храниться или обмениваться в зашифрованном виде приложениями, которые могут не знать о механизме безопасности.
-
Стандарт не предписывает использование какого-либо конкретного dummy value; более того, оно может иметь некоторый смысл, например в данных, используемых для обучения, где реальные идентифицирующие сведения пациента зашифрованы для последующего извлечения, но предоставлена осмысленная альтернативная форма идентификации. Например, фиктивное Patient's Name (0010,0010) может передавать тип патологии в учебном случае. Программное обеспечение деидентификатора или оператор-человек отвечает за то, чтобы dummy values нельзя было использовать для идентификации пациента.
-
Деидентификатор отвечает за согласованность dummy values для таких Attributes, как Study Instance UID (0020,000D) или Frame of Reference UID (0020,0052), если защищается несколько связанных SOP Instances. Фактически все Attributes каждой сущности выше уровня Instance должны оставаться согласованными для всех защищённых Instances, например Patient ID для сущности Patient, Study ID для сущности Study, Series Number для сущности Series.
-
Если защищаемый Attribute содержится в Sequence of Items, может потребоваться защита всей Sequence of Items.
-
Деидентификатор должен обеспечить отсутствие идентифицирующей информации, встроенной в пиксельные данные изображения: либо потому, что модальность изначально не формирует такую встроенную идентификацию, либо путём её удаления с использованием Clean Pixel Data Option; см. Section E.3. Если графика или наложения, не являющиеся пиксельными данными, содержат идентификацию, деидентификатор обязан удалить их или очистить, если поддерживается Clean Graphics Option. См. Section E.3.3. Способы обнаружения и удаления встроенной в изображение или графической идентифицирующей информации выходят за рамки этого стандарта.
-
-
Каждый Attribute, для которого предписано сохранение, должен быть сохранён. По усмотрению деидентификатора в защищаемый Data Set могут быть добавлены Attributes.
-
Если используется Encrypted Attributes Data Set, все его экземпляры должны быть закодированы с использованием DICOM Transfer Syntax, зашифрованы и сохранены в защищаемом Data Set как Item объекта Encrypted Attributes Sequence (0400,0500). Шифрование должно выполняться с использованием RSA [RFC 2313] для транспорта ключей шифрования содержимого. Деидентификатор, соответствующий этому security Profile, может использовать AES или Triple-DES для шифрования содержимого. Длина ключа AES может быть любой длиной, разрешённой RFC. Длина ключа Triple-DES составляет 168 бит, как определено в [ANSI X9.52]. Кодирование должно выполняться согласно спецификациям RSA Key Transport и Triple DES Content Encryption в [RFC 3370], а для AES Content Encryption - в [RFC 3565].
Примечание
-
Каждый item Encrypted Attributes Sequence (0400,0500) состоит из двух Attributes: Encrypted Content Transfer Syntax UID (0400,0510), содержащего UID Transfer Syntax, использованного для кодирования экземпляра Encrypted Attributes Data Set, и Encrypted Content (0400,0520), содержащего блок данных, полученный в результате шифрования экземпляра Encrypted Attributes Data Set.
-
Транспорт ключей шифрования содержимого с помощью RSA задан как требование в European Prestandard ENV 13608-2: Health Informatics - Security for healthcare communication - Part 2: Secure data objects.
-
-
В этой схеме конфиденциальности не определены требования к размеру асимметричных пар ключей, используемых для транспорта ключей RSA. Реализации, заявляющие соответствие Basic Application Level Confidentiality Profile как деидентификатор, должны всегда защищать (например, шифровать и заменять) Attribute SOP Instance UID (0008,0018), а также все ссылки на другие SOP Instances, содержащиеся как в основном Data Set, так и во вложенном Item объекта Sequence of Items, которые потенциально могут быть использованы неуполномоченными сущностями для идентификации пациента.
-
Attribute Patient Identity Removed (0012,0062) должен быть заменён или добавлен в Data Set со значением YES. Кроме того, один или несколько кодов из CID 7050 “De-identification Method”, соответствующих использованным Profile и Options, должны быть добавлены в De-identification Method Code Sequence (0012,0064), и/или текстовая строка, описывающая использованный метод, должна быть вставлена или добавлена в De-identification Method (0012,0063).
-
Если деидентифицируемый Data Set сохраняется в DICOM File, то File Meta Information, включая 128-байтовую преамбулу при её наличии, должна быть заменена описанием деидентифицирующего приложения. В противном случае существует риск утечки идентифицирующей информации через неизменённые File Meta Information или преамбулу. См. PS3.10. Это включает сведения об Application Entity Titles, Presentation Addresses, информации реализации и частной информации.
-
Если деидентифицируемый Data Set передаётся с помощью DICOM Real-Time Video, то File Meta Information, включая 128-байтовую преамбулу при её наличии, должна быть заменена описанием деидентифицирующего приложения. В противном случае существует риск утечки идентифицирующей информации через неизменённые File Meta Information или преамбулу. См. PS3.22. Это включает сведения об Application Entity Titles, Presentation Addresses, информации реализации и частной информации.
-
Все Data Elements с Group Number 0004 должны быть удалены из любого SOP Instance или DICOM File, кроме DICOMDIR File. Если требуется DICOMDIR File, он должен быть либо создан из деидентифицированных DICOM Files, на которые он ссылается, либо существующий DICOMDIR File должен быть деидентифицирован согласно этому Profile. Любой существующий недеидентифицированный DICOMDIR File должен быть удалён из File-set.
Attributes, перечисленные в Table E.1-1 для каждого Profile или Option, содержатся в Standard IODs или могут содержаться в Standard Extended IODs. Реализация, заявляющая соответствие Basic Application Level Confidentiality Profile как деидентификатор, должна защищать или сохранять все экземпляры Attributes, перечисленных в Table E.1-1, независимо от того, находятся ли они в Data Set верхнего уровня или вложены в Item объекта Sequence of Items. Коды действий из Table E.1-1a используются в Table E.1-1.
Table E.1-1a. De-identification Action Codes (коды действий деидентификации)
Эти коды действий применимы как к Sequence Attributes, так и к non-Sequence Attributes; в случае Sequences действие применяется к Sequence и всему её содержимому. Очистка последовательности (действие "C") означает изменение значений Attributes внутри этой Sequence, когда смысл Sequence в контексте её использования в IOD задан, либо в противном случае рекурсивное применение правил Profile к каждому Data Set в каждом Item этой Sequence. Сохранение Sequence (действие "K") требует рекурсивного применения правил Profile к каждому Data Set в каждом Item этой Sequence (например, чтобы переназначить любые UIDs, содержащиеся в этой sequence).
Требование Option, когда эта Option реализована, переопределяет любое требование базового Profile. В результате при деидентификации будет сохраняться или удаляться больше информации.
Примечание
-
Attributes, перечисленных в Table E.1-1, может быть недостаточно для гарантии конфиденциальности идентичности пациента. В частности, идентифицирующая информация может содержаться в Private Attributes, новых Standard Attributes, Retired Standard Attributes и дополнительных Standard Attributes, отсутствующих в Standard Composite IODs (как определено в PS3.3), но используемых в Standard Extended SOP Classes. Table E.1-1 указывает Attributes, используемые в Standard Composite IODs, а также Retired Attributes. В Table E.1-1 также включены некоторые Elements, которые обычно не встречаются в Data Set, но используются в Commands, Directories и Meta Information Headers и могут быть неправомерно использованы внутри Private Sequences. Textual Content Items of Structured Reports, textual annotations of Presentation States, Curves и Overlays рассматриваются отдельно. Деидентификатор отвечает за удаление всей идентифицирующей информации.
-
Следует отметить, что соответствие Basic Application Level Confidentiality Profile не обязательно гарантирует конфиденциальность. Например, если злоумышленник уже имеет доступ к исходным изображениям, Pixel Data могут быть сопоставлены, хотя вероятность и последствия такой угрозы могут считаться незначительными. Если используется Encrypted Attributes Sequence, следует понимать, что любая схема шифрования может быть уязвима к атаке. Кроме того, Security Policy организации и политика Key Management имеют значительно большее влияние на эффективность защиты.
-
Национальные и местные нормативные требования, которые могут различаться, могут требовать деидентификации дополнительных Attributes, хотя Profile и Options были разработаны так, чтобы быть достаточными для удовлетворения известных требований без ущерба для полезности деидентифицированных instances по их назначению.
-
Table E.1-1 является нормативной, но подлежит расширению по мере развития стандарта DICOM и добавления в IODs других сходных Attributes. Деидентификаторы могут учитывать эту расширяемость, например рассматривая обработку всех дат и времени на основе их Value Representation DT, DA или TM, а не только перечисленных Attributes даты и времени.
-
Profile и Options не определяют, должен ли деидентификатор проектироваться так, чтобы удалять то, что известно как риск утечки идентичности, или сохранять только то, что известно как безопасное. Первый подход может дать сбой при расширении стандарта или при добавлении поставщиком непредвиденных Standard Attributes или Private Attributes, тогда как второй требует обширного, если не полного, сопоставления каждого экземпляра с Information Object Definitions в PS3.3, чтобы избежать удаления обязательной или полезной информации. Table E.1-1 определяет минимальные действия, требуемые для соответствия.
-
Действие "C" (clean) задано не только для строковых VR, но и для Code Sequences, поскольку использование частных или локальных кодов и нестандартных значений кодов потенциально может привести к утечке идентичности.
-
Digital Signatures Sequence (FFFA,FFFA) необходимо удалить, поскольку она содержит Certificate of Signer (0400,0115); теоретически подпись можно было бы проверить, а объект повторно подписать самим деидентификатором с его собственным сертификатом, но стандарт этого не требует.
-
В общем случае в этой таблице нет CS VR Attributes, поскольку обычно безопасно предполагать, что code strings не содержат идентифицирующей информации.
-
В общем случае в этой таблице нет Code Sequence Attributes, поскольку обычно безопасно предполагать, что элементы кодированных последовательностей, включая частные коды, не содержат идентифицирующей информации. Исключениями являются коды поставщиков и персонала.
-
Clean Pixel Data и Clean Recognizable Visual Features Options не перечислены в этой таблице, поскольку они определяются описаниями операций над самими Pixel Data. Clean Pixel Data Option может применяться к Pixel Data внутри Icon Image Sequence, либо, что более вероятно, Icon Image Sequence может быть полностью создана заново после очистки Pixel Data основного Data Set. Icon Image Sequence должна быть удалена, если её Pixel Data невозможно очистить.
-
Original Attributes Sequence (0400,0561), которая в свою очередь содержит Modified Attributes Sequence (0400,0550), обычно необходимо удалить, поскольку она может содержать незашифрованные копии других Attributes, которые могли быть изменены (например, принудительно приведены к использованию локальных идентификаторов и имён при импорте внешних изображений); альтернативным подходом было бы выборочное изменение её содержимого. Это отличается от использования Modified Attributes Sequence (0400,0550) внутри Encrypted Attributes Sequence (0400,0500).
-
Table E.1-1 различает Attributes, входящие в стандартные Composite IODs, определённые в PS3.3, и Attributes, которые в них не входят; некоторые Attributes определены в PS3.3 для других IODs или имеют специфическое применение не на верхнем уровне Data Set объекта Composite IOD, но (неправильно) используются реализациями в instances как Standard Extended SOP Class на уровнях, отличных от определённых стандартом. Любые такие встреченные Attributes могут быть удалены без нарушения соответствия экземпляра стандартному IOD. Например, Verifying Observer Sequence (0040,A073) определена только в IODs структурированных отчётов и поэтому описана в Table E.1-1 как D, поскольку это Type 1C; если она встречается в экземпляре изображения, её следует просто удалить (обработать как X).
-
Использование Attribute Confidentiality Profile Option, требующей сохранения информации, которая обычно удалялась бы, потенциально повышает риск вредоносной повторной идентификации. Следование правилам деидентификации, изложенным здесь, подразумевает только сохранение или несохранение информации и не рассматривает связанные нормативные аспекты.
-
Из-за разнообразной природы инкапсулированных документов (CDA, PDF, STL/OBJ и т. д.) варианты очистки содержимого Attribute Encapsulated Document (0042,0011) стандартом не задаются, и его требуется заменить. Если De-identifier имеет дополнительные сведения о содержимом, он может попытаться очистить Attribute и документировать в Conformance Statement, как это выполняется.
Table E.1-1. Application Level Confidentiality Profile Attributes
|
Retd. (from PS3.6) |
In Std. Comp. IOD (from PS3.3) |
Clean Struct. Cont. Opt. |
||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Acquisition Context Description |
||||||||||||||
|
Acquisition Context Sequence |
||||||||||||||
|
Acquisition Device Processing Description |
||||||||||||||
|
Acquisition Field Of View Label |
||||||||||||||
|
Acquisition Protocol Description |
||||||||||||||
|
Actual Human Performers Sequence |
||||||||||||||
|
Admitting Diagnoses Code Sequence |
||||||||||||||
|
Admitting Diagnoses Description |
||||||||||||||
|
Assertion Expiration DateTime |
||||||||||||||
|
Attribute Modification DateTime |
||||||||||||||
|
Author Observer Sequence |
||||||||||||||
|
Beam Hold Transition DateTime |
||||||||||||||
|
Clinical Trial Coordinating Center Name |
||||||||||||||
|
Clinical Trial Protocol Ethics Committee Approval Number |
||||||||||||||
|
Clinical Trial Protocol Ethics Committee Name |
||||||||||||||
|
Clinical Trial Protocol ID |
||||||||||||||
|
Clinical Trial Protocol Name |
||||||||||||||
|
Clinical Trial Series Description |
||||||||||||||
|
Clinical Trial Series ID |
||||||||||||||
|
Clinical Trial Site ID |
||||||||||||||
|
Clinical Trial Site Name |
||||||||||||||
|
Clinical Trial Sponsor Name |
||||||||||||||
|
Clinical Trial Subject ID |
||||||||||||||
|
Clinical Trial Subject Reading ID |
||||||||||||||
|
Clinical Trial Time Point Description |
||||||||||||||
|
Clinical Trial Time Point ID |
||||||||||||||
|
Comments on the Performed Procedure Step |
||||||||||||||
|
Conceptual Volume Combination Description |
||||||||||||||
|
Conceptual Volume Description |
||||||||||||||
|
Confidentiality Constraint on Patient Data Description |
||||||||||||||
|
Constituent Conceptual Volume UID |
||||||||||||||
|
Consulting Physician Identification Sequence |
||||||||||||||
|
Content Creator's Identification Code Sequence |
||||||||||||||
|
Context Group Local Version |
||||||||||||||
|
Contrast/Bolus Start Time |
||||||||||||||
|
Contrast/Bolus Stop Time |
||||||||||||||
|
Current Observer (Trial) |
||||||||||||||
|
Custodial Organization Sequence |
||||||||||||||
|
Date of Document or Verbal Transaction (Trial) |
||||||||||||||
|
Date of Last Detector Calibration |
||||||||||||||
|
DateTime of Last Calibration |
||||||||||||||
|
Derivation Description |
||||||||||||||
|
Device Alternate Identifier |
||||||||||||||
|
Digital Signatures Sequence |
||||||||||||||
|
Discharge Diagnosis Description |
||||||||||||||
|
End Acquisition DateTime |
||||||||||||||
|
Equipment Frame of Reference Description |
||||||||||||||
|
Ethics Committee Approval Effectiveness End Date |
||||||||||||||
|
Ethics Committee Approval Effectiveness Start Date |
||||||||||||||
|
Ethnic Group Code Sequence |
||||||||||||||
|
Expected Completion DateTime |
||||||||||||||
|
Failed SOP Instance UID List |
||||||||||||||
|
Filler Order Number / Imaging Service Request |
||||||||||||||
|
Filter Lookup Table Description |
||||||||||||||
|
Findings Group Recording Date (Trial) |
||||||||||||||
|
Findings Group Recording Time (Trial) |
||||||||||||||
|
Flow Identifier Sequence |
||||||||||||||
|
Gender Identity Code Sequence |
||||||||||||||
|
Gender Identity Sequence |
||||||||||||||
|
GPS Dest Bearing Ref |
||||||||||||||
|
GPS Dest Distance Ref |
||||||||||||||
|
GPS Dest Longitude Ref |
||||||||||||||
|
GPS Img Direction Ref |
||||||||||||||
|
Graphic Annotation Sequence |
||||||||||||||
|
Hanging Protocol Creation DateTime |
||||||||||||||
|
Hardcopy Creation Device ID |
||||||||||||||
|
Histological Diagnoses Code Sequence |
||||||||||||||
|
HL7 Document Effective Time |
||||||||||||||
|
Human Performer's Organization |
||||||||||||||
|
Icon Image Sequence (see Note 11) |
||||||||||||||
|
Image Presentation Comments |
||||||||||||||
|
Imaging Service Request Comments |
||||||||||||||
|
Impedance Measurement DateTime |
||||||||||||||
|
Instance Coercion DateTime |
||||||||||||||
|
Institutional Department Type Code Sequence |
||||||||||||||
|
Instruction Performed DateTime |
||||||||||||||
|
Intended Fraction Start Time |
||||||||||||||
|
Intended Recipients of Results Identification Sequence |
||||||||||||||
|
Interpretation Approver Sequence |
||||||||||||||
|
Interpretation Diagnosis Description |
||||||||||||||
|
Interpretation ID Issuer |
||||||||||||||
|
Interpretation Transcription Date |
||||||||||||||
|
Interpretation Transcription Time |
||||||||||||||
|
Intervention Drug Start Time |
||||||||||||||
|
Intervention Drug Stop Time |
||||||||||||||
|
Issue Date of Imaging Service Request |
||||||||||||||
|
Issuer of Admission ID Sequence |
||||||||||||||
|
Issuer of Clinical Trial Protocol ID |
||||||||||||||
|
Issuer of Clinical Trial Series ID |
||||||||||||||
|
Issuer of Clinical Trial Site ID |
||||||||||||||
|
Issuer of Clinical Trial Subject ID |
||||||||||||||
|
Issuer of Clinical Trial Subject Reading ID |
||||||||||||||
|
Issuer of Clinical Trial Time Point ID |
||||||||||||||
|
Issuer of Service Episode ID |
||||||||||||||
|
Issuer of Service Episode ID Sequence |
||||||||||||||
|
Issuer of the Container Identifier Sequence |
||||||||||||||
|
Issuer of the Specimen Identifier Sequence |
||||||||||||||
|
Issue Time of Imaging Service Request |
||||||||||||||
|
Large Palette Color Lookup Table UID |
||||||||||||||
|
Manufacturer's Device Class UID |
||||||||||||||
|
Manufacturer's Device Identifier |
||||||||||||||
|
Media Storage SOP Instance UID |
||||||||||||||
|
Medical Record Locator |
||||||||||||||
|
Modified Attributes Sequence |
||||||||||||||
|
Multi-energy Acquisition Description |
||||||||||||||
|
Name of Physician(s) Reading Study |
||||||||||||||
|
Names of Intended Recipients of Results |
||||||||||||||
|
Nonconforming Data Element Value |
||||||||||||||
|
Nonconforming Modified Attributes Sequence |
||||||||||||||
|
Observation Subject UID (Trial) |
||||||||||||||
|
Operator Identification Sequence |
||||||||||||||
|
Order Callback Phone Number |
||||||||||||||
|
Order Callback Telecom Information |
||||||||||||||
|
Order Enterer's Location |
||||||||||||||
|
Original Attributes Sequence |
||||||||||||||
|
Other Clinical Trial Protocol IDs Sequence |
||||||||||||||
|
Other Patient IDs Sequence |
||||||||||||||
|
Palette Color Lookup Table UID |
||||||||||||||
|
Patient's Institution Residence |
||||||||||||||
|
Patient's Insurance Plan Code Sequence |
||||||||||||||
|
Patient's Mother's Birth Name |
||||||||||||||
|
Patient's Primary Language Code Sequence |
||||||||||||||
|
Patient's Primary Language Modifier Code Sequence |
||||||||||||||
|
Patient's Religious Preference |
||||||||||||||
|
Patient's Telecom Information |
||||||||||||||
|
Patient Setup Photo Description |
||||||||||||||
|
Patient Transport Arrangements |
||||||||||||||
|
Patient Treatment Preparation Method Description |
||||||||||||||
|
Patient Treatment Preparation Procedure Parameter Description |
||||||||||||||
|
Performed Procedure Step Description |
||||||||||||||
|
Performed Procedure Step End Date |
||||||||||||||
|
Performed Procedure Step End DateTime |
||||||||||||||
|
Performed Procedure Step End Time |
||||||||||||||
|
Performed Procedure Step ID |
||||||||||||||
|
Performed Procedure Step Start Date |
||||||||||||||
|
Performed Procedure Step Start DateTime |
||||||||||||||
|
Performed Procedure Step Start Time |
||||||||||||||
|
Performed Station Geographic Location Code Sequence |
||||||||||||||
|
Performed Station Name Code Sequence |
||||||||||||||
|
Performing Physician Identification Sequence |
||||||||||||||
|
Person's Telecom Information |
||||||||||||||
|
Person Identification Code Sequence |
||||||||||||||
|
Person Names to Use Sequence |
||||||||||||||
|
Physician(s) of Record |
||||||||||||||
|
Physician(s) of Record Identification Sequence |
||||||||||||||
|
Physician(s) Reading Study Identification Sequence |
||||||||||||||
|
Physician Approving Interpretation |
||||||||||||||
|
Placer Order Number / Imaging Service Request |
||||||||||||||
|
Position Acquisition Template Description |
||||||||||||||
|
Position Acquisition Template Name |
||||||||||||||
|
Prescription Notes Sequence |
||||||||||||||
|
Presentation Display Collection UID |
||||||||||||||
|
Presentation Sequence Collection UID |
||||||||||||||
|
Primary Diagnosis Code Sequence |
||||||||||||||
|
Principal Diagnosis Code Sequence |
||||||||||||||
|
Prior Treatment Dose Description |
||||||||||||||
|
Procedure Step Cancellation DateTime |
||||||||||||||
|
Product Expiration DateTime |
||||||||||||||
|
Radiation Dose Identification Label |
||||||||||||||
|
Radiation Dose In-Vivo Measurement Label |
||||||||||||||
|
Radiation Generation Mode Description |
||||||||||||||
|
Radiation Generation Mode Label |
||||||||||||||
|
Radiopharmaceutical Start DateTime |
||||||||||||||
|
Radiopharmaceutical Start Time |
||||||||||||||
|
Radiopharmaceutical Stop DateTime |
||||||||||||||
|
Radiopharmaceutical Stop Time |
||||||||||||||
|
Reason for Requested Procedure Code Sequence |
||||||||||||||
|
Reason for the Attribute Modification |
||||||||||||||
|
Reason for the Imaging Service Request |
||||||||||||||
|
Reason for the Requested Procedure |
||||||||||||||
|
Reason for Visit Code Sequence |
||||||||||||||
|
Recorded RT Control Point DateTime |
||||||||||||||
|
Referenced Conceptual Volume UID |
||||||||||||||
|
Referenced Digital Signature Sequence |
||||||||||||||
|
Referenced Dosimetric Objective UID |
||||||||||||||
|
Referenced Frame of Reference UID |
||||||||||||||
|
Referenced General Purpose Scheduled Procedure Step Transaction UID |
||||||||||||||
|
Referenced Image Sequence |
||||||||||||||
|
Referenced Observation UID (Trial) |
||||||||||||||
|
Referenced Patient Alias Sequence |
||||||||||||||
|
Referenced Patient Photo Sequence |
||||||||||||||
|
Referenced Patient Sequence |
||||||||||||||
|
Referenced Performed Procedure Step Sequence |
||||||||||||||
|
Referenced SOP Instance MAC Sequence |
||||||||||||||
|
Referenced SOP Instance UID in File |
||||||||||||||
|
Referenced Study Sequence |
||||||||||||||
|
Referenced Treatment Position Group UID |
||||||||||||||
|
Referring Physician's Telephone Numbers |
||||||||||||||
|
Referring Physician Identification Sequence |
||||||||||||||
|
Related Frame of Reference UID |
||||||||||||||
|
Request Attributes Sequence |
||||||||||||||
|
Requested Procedure Comments |
||||||||||||||
|
Requested Procedure Description |
||||||||||||||
|
Requested Procedure Location |
||||||||||||||
|
Respiratory Motion Compensation Technique Description |
||||||||||||||
|
Results Distribution List Sequence |
||||||||||||||
|
ROI Interpreter Sequence |
||||||||||||||
|
RT Accessory Device Slot ID |
||||||||||||||
|
RT Accessory Holder Slot ID |
||||||||||||||
|
RT Physician Intent Narrative |
||||||||||||||
|
Safe Position Exit Time |
||||||||||||||
|
Safe Position Return Date |
||||||||||||||
|
Safe Position Return Time |
||||||||||||||
|
Scheduled Human Performers Sequence |
||||||||||||||
|
Scheduled Patient Institution Residence |
||||||||||||||
|
Scheduled Performing Physician's Name |
||||||||||||||
|
Scheduled Performing Physician Identification Sequence |
||||||||||||||
|
Scheduled Procedure Step Description |
||||||||||||||
|
Scheduled Procedure Step End Date |
||||||||||||||
|
Scheduled Procedure Step End Time |
||||||||||||||
|
Scheduled Procedure Step Expiration DateTime |
||||||||||||||
|
Scheduled Procedure Step ID |
||||||||||||||
|
Scheduled Procedure Step Location |
||||||||||||||
|
Scheduled Procedure Step Modification DateTime |
||||||||||||||
|
Scheduled Procedure Step Start Date |
||||||||||||||
|
Scheduled Procedure Step Start DateTime |
||||||||||||||
|
Scheduled Procedure Step Start Time |
||||||||||||||
|
Scheduled Station Geographic Location Code Sequence |
||||||||||||||
|
Scheduled Station Name Code Sequence |
||||||||||||||
|
Scheduled Study Location AE Title |
||||||||||||||
|
Scheduled Study Start Date |
||||||||||||||
|
Scheduled Study Start Time |
||||||||||||||
|
Scheduled Study Stop Date |
||||||||||||||
|
Scheduled Study Stop Time |
||||||||||||||
|
Secondary Capture Device ID |
||||||||||||||
|
Secondary Diagnoses Code Sequence |
||||||||||||||
|
Segment Definition DateTime |
||||||||||||||
|
Sex Parameters for Clinical Use Category Code Sequence |
||||||||||||||
|
Sex Parameters for Clinical Use Category Comment |
||||||||||||||
|
Sex Parameters for Clinical Use Category Reference |
||||||||||||||
|
Sex Parameters for Clinical Use Category Sequence |
||||||||||||||
|
Shielding Device Description |
||||||||||||||
|
Source Conceptual Volume UID |
||||||||||||||
|
Source Image Sequence |
||||||||||||||
|
Source Strength Reference Date |
||||||||||||||
|
Source Strength Reference Time |
||||||||||||||
|
Specimen Preparation Sequence |
||||||||||||||
|
Start Acquisition DateTime |
||||||||||||||
|
Substance Administration DateTime |
||||||||||||||
|
Synchronization Frame of Reference UID |
||||||||||||||
|
Table Top Position Alignment UID |
||||||||||||||
|
Template Extension Creator UID |
||||||||||||||
|
Template Extension Organization UID |
||||||||||||||
|
Third Person Pronouns Sequence |
||||||||||||||
|
Time of Document Creation or Verbal Transaction (Trial) |
||||||||||||||
|
Time of Last Detector Calibration |
||||||||||||||
|
Timezone Offset From UTC |
||||||||||||||
|
Transducer Identification Sequence |
||||||||||||||
|
Treatment Position Group Label |
||||||||||||||
|
Treatment Tolerance Violation DateTime |
||||||||||||||
|
Treatment Tolerance Violation Description |
||||||||||||||
|
User Content Long Label |
||||||||||||||
|
Verbal Source Identifier Code Sequence (Trial) |
||||||||||||||
|
Verifying Observer Identification Code Sequence |
||||||||||||||
|
Verifying Observer Sequence |
||||||||||||||
|
Waveform Annotation Sequence |
||||||||||||||
Приложение может заявлять соответствие Basic Application Level Confidentiality Profile в роли реидентификатора, если оно способно снять защиту с защищенного SOP Instance при наличии ключей получателя, необходимых для расшифрования одного или нескольких атрибутов Encrypted Content (0400,0520) в Encrypted Attributes Sequence (0400,0500) этого SOP Instance. В данном контексте снятие защиты определяется как следующий процесс:
-
Приложение должно с использованием своего ключа получателя расшифровать один экземпляр атрибута Encrypted Content (0400,0520) в Encrypted Attributes Sequence (0400,0500) и декодировать полученный блок байтов в DICOM Data Set с использованием Transfer Syntax, указанного в Encrypted Content Transfer Syntax UID (0400,0510). Реидентификаторы, заявляющие соответствие этому профилю, должны быть способны расшифровывать Encrypted Content с использованием AES или Triple-DES со всеми возможными длинами ключей, указанными в этом профиле.
-
Приложение должно перенести все атрибуты, содержащиеся в единственном элементе Modified Attributes Sequence (0400,0550) декодированного Data Set, на верхний уровень Data Set, заменив атрибуты с "фиктивными значениями", которые могут присутствовать на верхнем уровне Data Set.
Note
-
Реидентификация не подразумевает полного восстановления исходного SOP Instance, поскольку не требуется, чтобы все защищаемые атрибуты входили в Encrypted Attributes Data Set. Если исходные UID входят в Encrypted Attributes Data Set, они могут быть использованы для доступа к исходному, незащищенному SOP Instance.
-
Наличие зашифрованного Data Set, который невозможно расшифровать, означает, что некоторые или все значения атрибутов в сообщении могут быть ненастоящими (фиктивными). Поэтому получатель не должен считать какое-либо значение в сообщении диагностически значимым.
-
-
Атрибут Patient Identity Removed (0012,0062) должен быть заменен или добавлен в Data Set со значением NO, а De-identification Method (0012,0063) и De-identification Method Code Sequence (0012,0064) должны быть удалены.
В Conformance Statement приложения, заявляющего соответствие Basic Application Level Confidentiality Profile, должно быть описано:
-
какие атрибуты заменяются фиктивными значениями и как эти фиктивные значения формируются;
-
какие атрибуты включаются в Encrypted Attributes Data Sets для последующей реидентификации, а также существенные сведения о том, как выбираются ключи для выполнения шифрования;
-
область, в пределах которой приложение способно обеспечить ссылочную целостность заменяющих значений для ссылок, таких как SOP Instance UID, Frame of Reference UID и т. п., если защищается несколько SOP Instances (например, в пределах нескольких Studies, согласованная замена при повторной обработке одного и того же Study и т. п.);
-
какие атрибуты и значения атрибутов вставляются при защите SOP Instance;
-
какие Transfer Syntaxes поддерживаются для кодирования и декодирования Encrypted Attributes Data Set;
-
любые дополнительные ограничения (например, размеры ключей для открытых ключей).
Этот профиль предназначен для использования в клинических исследованиях и других сценариях, где может требоваться деидентификация, например при создании учебных файлов, других видах публикации, а также при передаче изображений и связанной информации в реестры, такие как онкологические реестры или реестры доз облучения.
Этот Basic Application Level Confidentiality Profile задает крайне консервативный подход, при котором удаляется вся информация, относящаяся к:
если такая информация присутствует в атрибутах, не относящихся к Pixel Data, включая графику или наложения, как описано в Table E.1-1.
Note
Если не указана Clean Pixel Data Option или Clean Recognizable Visual Features Option, этот профиль не рассматривает информацию, находящуюся в пикселях.
Атрибут Longitudinal Temporal Information Modified (0028,0303) должен быть добавлен в Data Set со значением "REMOVED", если не применяется ни одна из Retain Longitudinal Temporal Information Options.
Для Basic Application Level Confidentiality Profile определены различные Options. Некоторые из этих Options требуют удаления дополнительной информации, а некоторые требуют сохранения информации, которая в противном случае была бы удалена.
Определены следующие Options, требующие удаления дополнительной информации:
Определены следующие Options, требующие обработки информации, которая в противном случае была бы удалена, но необходима для определенных вариантов использования:
Определены следующие Options, требующие сохранения информации, которая в противном случае была бы удалена, но необходима для определенных вариантов использования:
-
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 Safe Private Option (опция сохранения безопасных частных атрибутов)
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, вся информация, встроенная в Pixel Data (7FE0,0010) и соответствующая атрибутной информации, которую профиль и любые другие указанные Options требуют удалить, также должна быть удалена, как описано в Table E.1-1.
Для этого может потребоваться вмешательство оператора-человека или его подтверждение.
Атрибут Burned In Annotation (0028,0301) должен быть добавлен в Data Set со значением "NO".
Примечание
-
Эта возможность выделена как отдельная Option, поскольку на практике ее реализация может быть крайне трудоемкой и не нужна для подавляющего большинства модальностей, которые изначально не встраивают такие аннотации. Например, изображения CT обычно не содержат таких встроенных аннотаций, тогда как изображения Ultrasound часто их содержат.
-
Хотя для обнаружения наличия и расположения встроенного текста можно использовать методы обработки изображений и оптического распознавания символов, а также сопоставление с известной идентифицирующей информацией, решение о том, является ли этот текст идентифицирующей информацией или информацией другого типа, может быть нетривиальным. Соответствие этой Option требует удаления идентифицирующей информации независимо от способа его выполнения. Не требуется, чтобы информация, которую другие Options предписывают сохранять в непиксельных данных (например, физические характеристики, даты или описатели), также сохранялась во встроенном виде в пиксельных данных. Поэтому наиболее консервативный подход, при котором удаляется любой встроенный текст, будет соответствовать требованиям. Это может привести к утрате дополнительной потенциально полезной информации, такой как отметки локализатора и ручные графические аннотации.
-
Stored Pixel Values должны быть изменены (зачернены); недостаточно наложить overlay, графическую аннотацию или shutter для сокрытия Stored Pixel Data Values, поскольку принимающая система может их не игнорировать.
-
Эта Option предназначена для применения к атрибуту Pixel Data (7FE0,0010), который находится на верхнем уровне Data Set в Image Storage SOP Instance. Другое стандартное использование Pixel Data (7FE0,0010) находится в Icon Image Sequence (0088,0200), что уже описано в Table E.1-1 и сопровождающем примечании как требующее удаления. Эта Option не требует возможности вручную или автоматически обрабатывать Stored Pixel Data Values атрибута Pixel Data (7FE0,0010), расположенного где-либо кроме верхнего уровня Data Set, но и не запрещает такую обработку. Pixel Data (7FE0,0010), находящиеся внутри private Attributes, будут удалены, поскольку такие атрибуты не будут считаться безопасными.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile и Pixel Data набора экземпляров содержит достаточно визуальной информации, чтобы по самим экземплярам или по реконструкции набора экземпляров можно было распознать человека, то должно быть выполнено достаточное удаление или искажение Pixel Data для предотвращения распознавания.
Для этого может потребоваться вмешательство оператора-человека или его подтверждение.
Атрибут Recognizable Visual Features (0028,0302) должен быть добавлен в Data Set со значением "NO".
Примечание
-
Эта возможность выделена как отдельная Option, поскольку на практике ее реализация может быть крайне трудоемкой и не нужна для подавляющего большинства анатомических областей и модальностей.
-
В случае фотографий лица в анфас риск визуальной идентификации очевиден, и хорошо известны многочисленные методы деидентификации, например наложение черных прямоугольников на область глаз и т. п.
-
В случае высокоразрешающей послойной визуализации всей головы и шеи высказывалось предположение, что трехмерный объемный или поверхностный рендеринг пиксельных данных при некоторых обстоятельствах может быть достаточным для идентификации человека (или для сопоставления с ограниченным набором лиц).
-
Применение этой Option может сделать пиксельные данные непригодными для цели, ради которой они были собраны; поэтому ее использование может требовать компромисса между деидентификацией и полезностью данных на основе надлежащего этического одобрения и информированного согласия. Например, это относится к стоматологическим изображениям.
-
Поскольку Referenced Patient Photo Sequence удаляется в рамках Basic Profile, поддержка Clean Recognizable Visual Features Option не добавляет требований для этого атрибута.
Экземпляры различных Standard и Standard Extended SOP Classes, включая Images, Presentation States и другие Composite SOP Instances, могут содержать идентифицирующую информацию, закодированную в виде графики, текстовых аннотаций или наложений. Это не включает информацию, содержащуюся в Structured Report SOP Classes.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, вся информация, закодированная в графике, текстовых аннотациях или наложениях и соответствующая атрибутной информации, которую профиль и любые другие указанные Options требуют удалить, также должна быть удалена, как описано в Table E.1-1.
Для этого может потребоваться вмешательство оператора-человека.
Примечание
-
Эта возможность выделена как отдельная Option, поскольку может быть практичнее просто удалить всю такую графику, текстовые аннотации или наложения (как требуется профилем без этой Option).
-
Как и в случае встроенных в пиксельные данные аннотаций, решение о том, является ли текст идентифицирующей информацией или информацией другого типа, может быть нетривиальным. Не требуется, чтобы информация, которую другие Options предписывают сохранять в непиксельных данных (например, физические характеристики, даты или описатели), также сохранялась в графике, текстовых аннотациях или наложениях.
Экземпляры Structured Report SOP Classes могут содержать идентифицируемую информацию в Content Sequence (0040,A730), закодированную в Content Items. Экземпляры других SOP Classes могут содержать структурированное содержимое, закодированное аналогичным образом в Acquisition Context Sequence (0040,0555) или Specimen Preparation Sequence (0040,0610).
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, вся информация, закодированная в SR Content Items либо в элементах Acquisition Context или Specimen Preparation Sequence и соответствующая атрибутной информации, которую профиль и любые другие указанные Options требуют удалить, также должна быть удалена.
Примечание
-
Например, "observer", ответственный за диагностический отчет по изображению, может быть явно идентифицирован в Content Items, связанных с Observation Content, в SR.
-
Деидентификатор, который не реализует эту Option, создает значительный риск при попытке деидентифицировать Structured Report, если он не используется только для деидентификации экземпляров, о которых известно, что они не содержат идентифицирующей информации в Content Sequence.
-
По мере сопровождения этого стандарта и внешних Coding Schemes коды, указанные как Concept Name Codes, могут изменяться. Предыдущие коды считаются Retired, но реализации могут продолжать их отправлять, и от деидентификаторов ожидается способность продолжать распознавать и деидентифицировать Content Items с Retired-кодами, включая Code Value и Coding Scheme Designator, даже если текущий стандарт их не публикует.
Показательный пример - изменение по всему стандарту: вместо Code Values в стиле "SNOMED-RT" с Coding Scheme Designator "SRT", "SNM3" или "99SDM" используются числовые Code Values SNOMED CT с Coding Scheme Designator "SCT". Соответствие устаревших и новых кодов SNOMED приведено в 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
Коды Concept Name для Content Item в Clean Structured Content Option профиля конфиденциальности на уровне приложения
|
Retd. (from PS3.16) |
In Std. Tpl. (from PS3.16) |
Rtn. Inst. Id. Opt. |
Rtn. Pat. Chars. Opt. |
||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Administration of radiopharmaceutical |
|||||||||||||
|
Cath Lab Procedure Log |
|||||||||||||
|
Current procedure evidence |
|||||||||||||
|
DateTime of Recording of Log Entry |
|||||||||||||
|
Device Observer Physical Location During Observation |
|||||||||||||
|
Device Observer Serial Number |
|||||||||||||
|
Device Subject Physical Location during observation |
|||||||||||||
|
Device Subject Serial Number |
|||||||||||||
|
Identification of the X-Ray Source |
|||||||||||||
|
Identifier within Person Observer's Role |
|||||||||||||
|
Intervention attempt identifier |
|||||||||||||
|
Issuer of Parent Specimen Identifier |
|||||||||||||
|
Issuer of Specimen Identifier |
|||||||||||||
|
LV Wall Motion Segmental Findings |
|||||||||||||
|
Manufacturer Implant Template |
|||||||||||||
|
Mating Feature Set ID |
|||||||||||||
|
Parent Specimen Identifier |
|||||||||||||
|
Patient Data Used During Planning |
|||||||||||||
|
Patient Radiation Dose Model Data |
|||||||||||||
|
Patient Radiation Dose Model Data |
|||||||||||||
|
Patient Radiation Dose Model Data |
|||||||||||||
|
Patient Radiation Dose Model Reference |
|||||||||||||
|
Performed Procedure Step SOP Instance UID |
|||||||||||||
|
Person administering drug/contrast |
|||||||||||||
|
Person ID Issuer |
|||||||||||||
|
Person Observer's Organization Name |
|||||||||||||
|
Prior report for current patient |
|||||||||||||
|
Procedure Number in this admission |
|||||||||||||
|
Procedure Study Component UID |
|||||||||||||
|
Procedure Study Instance UID |
|||||||||||||
|
Protocol Time Point Identifier |
|||||||||||||
|
Radiation Dose Composite Parameters |
|||||||||||||
|
Radiation Dose Representation Data |
|||||||||||||
|
Radiation Dose Representation Data |
|||||||||||||
|
Radiopharmaceutical Administration Event UID |
|||||||||||||
|
Radiopharmaceutical Dispense Unit Identifier |
|||||||||||||
|
Radiopharmaceutical Lot Identifier |
|||||||||||||
|
Radiopharmaceutical Start DateTime |
|||||||||||||
|
Radiopharmaceutical Stop DateTime |
|||||||||||||
|
RDSR Frame of Reference Description |
|||||||||||||
|
Real World Value Map used for measurement |
|||||||||||||
|
Recommended Follow-up Date |
|||||||||||||
|
Referenced Segmentation Frame |
|||||||||||||
|
Related Patient Data Not Used During Planning |
|||||||||||||
|
Series or Instance used for Water Equivalent Diameter estimation |
|||||||||||||
|
Source image for segmentation |
|||||||||||||
|
Source series for segmentation |
|||||||||||||
|
Spatial Registration Reference |
|||||||||||||
|
Specimen Container Identifier |
|||||||||||||
|
Subject Time Point Identifier |
|||||||||||||
|
Synchronization Frame of Reference UID |
|||||||||||||
|
Tracking Unique Identifier |
|||||||||||||
|
Unique Device Identifiers |
|||||||||||||
|
User Selected Fiducial |
|||||||||||||
|
X-Ray Attenuator Model Data |
|||||||||||||
|
X-Ray Attenuator Model Data |
|||||||||||||
|
X-Ray Attenuator Model Data |
|||||||||||||
|
X-Ray Radiation Dose Report |
Хотя в стандарте DICOM многие атрибуты определены для конкретных целей, например для описания Study или Series, те из них, которые содержат обычный текст, управляемый оператором, могут включать неструктурированную информацию с идентифицирующими сведениями.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, вся информация, встроенная в текстовые или строковые атрибуты и соответствующая атрибутной информации, которую профиль и любые другие указанные Options требуют удалить, также должна быть удалена, как описано в Table E.1-1.
Примечание
-
Например, оператор может включить имя человека, демографические данные пациента или его физические характеристики в Study Description (0008,1030), возможно потому, что пользовательский интерфейс модальности не предоставляет других полей или другие системы их не отображают. Например, описание может содержать строку "CT chest abdomen pelvis - 55F Dr. Smith".
-
Один из подходов к очистке таких текстовых строк без участия человека состоит в том, чтобы извлекать и сохранять только значения, которые известны как полезные и безопасные, а все остальные отбрасывать. Например, если в Study Description (0008,1030) обнаружена строка "CT chest abdomen pelvis - 55F Dr. Smith", можно выявить и сохранить "CT chest abdomen pelvis", а остальную часть отбросить. В международной среде для этого может потребоваться обширный словарь слов, безопасных для сохранения, например для распознавания "Buik" как обозначения живота на нидерландском или "λεκάνη" как обозначения таза на греческом. Другой вариант - извлечь такую информацию и попытаться закодировать ее в других атрибутах (если они отсутствуют или пусты), например в Anatomic Region Sequence (0008,2218). Однако необходимо учитывать возможность того, что строковые значения в разных вариантах использования могут одновременно быть идентифицирующими и описательными, например "Dr. Hand" или "M. Genou".
-
Table E.1-1 выделяет конкретные атрибуты, для которых известен риск, но разработчик может рассмотреть любой атрибут, потенциально способный содержать символьные данные, хотя эта Option не требует этого. Например, все Value Representations SH, LO, ST, LT и UT потенциально могут быть использованы не по назначению. Строки кодов, CS, обычно не создают такого риска, но может выполняться проверка по известным Defined Terms и Enumerated Values. Хотя это крайне необычно, даже строка DS или IS теоретически может быть использована не по назначению, и можно проверять, что применяются только допустимые числовые символы. Любой атрибут PN очевидно находится в зоне риска. VR OB рассматривается в Retain Safe Private Option.
-
Эта Option определяет, что необходимо удалить, а не что необходимо сохранить. В зависимости от приложения может быть желательно сохранить некоторую информацию, например описание методики, но удалить другую, например диагноз, поскольку он может смещать интерпретацию в клиническом исследовании. Например, один подход состоит в удалении всех атрибутов описаний и комментариев, кроме Series Description (0008,103E), поскольку этот атрибут редко содержит идентифицирующую или диагностическую информацию и при этом обычно является надежным источником полезных сведений о методике получения данных, автоматически заполняемых из протоколов устройства модальности, хотя он все равно может быть очищен, как описано в примечании 2.
-
Следует учитывать, что если какой-либо описатель содержит информацию об особенно необычной процедуре или состоянии, то вместе с другими демографическими данными он может уменьшить число возможных лиц, которые могли быть субъектом визуализации. Однако в определенной степени это верно и тогда, когда состояние или другие необычные физические признаки очевидны при визуальном просмотре самих изображений. Например, сколько сиамских близнецов, родившихся в определенном месяце в Филадельфии, может существовать?
Даты и время признаются потенциальным источником раскрытия личности, поскольку они сужают круг возможных лиц, которые могли быть субъектом визуализации, но только при наличии доступа к другой информации об этих лицах для сопоставления.
Однако существуют приложения, которым для достижения цели необходимо наличие дат и времени. Это особенно верно для терапевтических клинических исследований, цель которых состоит в измерении изменения показателя результата во времени. Кроме того, часто необходимо сопоставлять информацию из изображений с информацией из других источников, таких как клинические и лабораторные данные, и даты с временем должны быть согласованы.
Для удовлетворения этих требований определены две взаимоисключающие Options:
Если Retain Longitudinal Temporal Information With Full Dates Option указывается дополнительно к Basic Application Level Confidentiality Profile, любые даты и время, присутствующие в атрибутах, должны быть сохранены, как описано в Table E.1-1. Атрибут Longitudinal Temporal Information Modified (0028,0303) должен быть добавлен в Data Set со значением "UNMODIFIED".
Если Retain Longitudinal Temporal Information With Modified Dates Option указывается дополнительно к Basic Application Level Confidentiality Profile, любые даты и время, присутствующие в атрибутах, перечисленных в Table E.1-1, должны быть изменены. Изменение дат и времени должно выполняться способом, который:
-
агрегирует или преобразует даты так, чтобы снизить возможность сопоставления для реидентификации
-
сохраняет общие продольные временные связи между изображениями, полученными в разные даты, в степени, необходимой для приложения
-
сохраняет точные временные связи между изображениями и событиями реального мира в степени, необходимой для анализа изображений данным приложением
Атрибут Longitudinal Temporal Information Modified (0028,0303) должен быть добавлен в Data Set со значением "MODIFIED".
Примечание
-
Агрегирование дат может выполняться различными способами, например установкой всех дат на первый день месяца, всех месяцев на первый месяц года и т. п., в зависимости от точности, требуемой приложением.
-
Можно изменить все даты и время на фиктивные значения, сдвинув их относительно произвольного события, и тем самым сохранить точные продольные временные связи в наборе исследований, если деидентификация всего набора выполняется одновременно либо если сохраняется некоторое сопоставление или база данных для повторения этого процесса в разные моменты времени. Также может быть желательно записывать тип события и временное смещение относительно этого события; для этой цели предусмотрены атрибуты Longitudinal Temporal Offset from Event (0012,0052) и Longitudinal Temporal Event Type (0012,0053), см. PS3.3 Section C.7.2.3 Clinical Trial Study Module.
-
Преобразование дат и времени следует рассматривать совместно, чтобы корректно обрабатывать исследования, переходящие через полночь.
-
Любое преобразование времени должно выполняться так, чтобы не нарушать вычисления, необходимые для анализа, например сравнение времени начала инъекции со временем получения данных для PET SUV или извлечение значений время-интенсивность из динамических исследований с контрастным усилением.
Способ изменения дат должен быть описан в Conformance Statement.
Физические характеристики пациента, документированные в атрибутах и являющиеся описательной, а не собственно идентифицирующей информацией, признаются потенциальным источником раскрытия личности, поскольку они сужают круг возможных лиц, которые могли быть субъектом визуализации, но только при наличии доступа к другой информации об этих лицах для сопоставления.
Примечание
Это отличается от физических характеристик, которые можно вывести из Pixel Data, например оценки возраста или пола по внешнему виду костей.
Однако существуют приложения, которым такие физические характеристики необходимы для выполнения вычислений, требуемых для анализа изображений и достижения цели. Один класс таких приложений связан с метаболическими показателями, например расчетом PET Standard Uptake Values (SUV) либо измерениями состава тела в DEXA или MRI, основанными на массе тела, площади поверхности тела или безжировой массе тела.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, информация о возрасте, поле, росте, весе и других характеристиках, присутствующая в атрибутах, должна быть сохранена, как описано в Table E.1-1.
Способ очистки сохраняемых атрибутов должен быть описан в Conformance Statement.
Информация об идентификации устройства, использованного для получения данных, признается потенциальным источником раскрытия личности, поскольку она может сужать круг возможных лиц, которые могли быть субъектом визуализации, но только при наличии доступа к другой информации об этих лицах для сопоставления.
Однако существуют приложения, которым такая информация об устройстве необходима для выполнения анализа или интерпретации. Тип коррекции пространственной или иной неоднородности может требовать знания конкретного серийного номера устройства. Может требоваться подтверждение того, что использовались конкретные устройства, ранее прошедшие квалификацию (например, с фантомами). Кроме того, может существовать необходимость сохранять запись об использованном устройстве для регуляторных целей или целей реестра, при том что место получения данных может не поддерживать достаточный электронный журнал аудита.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, информация об идентификации устройства в атрибутах должна быть сохранена, как описано в Table E.1-1.
Для некоторых сохраняемых значений, таких как Application Entity Titles, если они сохраняются, указано действие Cleaned, а не просто Kept, поскольку они могут содержать встроенную идентифицирующую информацию учреждения или человека, не предназначенную для раскрытия.
Примечание
Source Application Entity Title (0002,0016), Sending Application Entity Title (0002,0017) и Receiving Application Entity Title (0002,0018) не включены в список атрибутов, подлежащих удалению или сохранению, поскольку они являются частью File Meta Information (см. PS3.10), которая полностью заменяется при каждом сохранении или изменении файла во время деидентификации. См. Section E.1.1.
Хотя сами люди не имеют уникальных идентификаторов, исследованиям, сериям, экземплярам и другим сущностям в модели DICOM назначаются глобально уникальные UID. Хотя такие UID вне контекста нельзя напрямую сопоставить с конкретным человеком, при наличии доступа к исходным изображениям или к базе исходных изображений, содержащей эти UID, можно восстановить личность человека.
Однако существуют приложения, которым требуется возможность поддерживать журнал аудита до исходных изображений; хотя существуют и другие механизмы, они могут плохо масштабироваться или ненадежно реализовываться. Эта Option предусмотрена для использования в случаях, когда риск получения доступа к исходной информации через UID считается малым по сравнению с преимуществом их сохранения.
Если эта Option указывается дополнительно к Application Level Confidentiality Profile, UID должны быть сохранены, как описано в Table E.1-1.
Примечание
-
UID сущности DICOM не является тем же самым, что уникальный идентификатор человека, который может быть запрещен некоторыми нормативными актами о конфиденциальности.
-
UID создаются с использованием иерархической схемы "корней", которые осведомленный специалист может проследить до исходного владельца корня, обычно производителя устройства, но иногда организации, использующей устройство.
-
При оценке риска сопоставления UID с исходными изображениями или базой PACS следует учитывать, что даже если UID изменены, сами пиксельные данные создают аналогичный риск. В частности, пиксельные данные деидентифицированного изображения можно сопоставить с пиксельными данными исходного изображения. Такое сопоставление можно значительно ускорить, сравнивая предварительно вычисленные хеш-значения пиксельных данных. Удаление встроенной идентификации может изменить пиксельные данные, но тогда почти наверняка возможно сопоставление по подобласти пиксельных данных (например, по центральной области изображения). Даже добавления шума к изображению недостаточно для предотвращения реидентификации, поскольку могут использоваться статистические методы сопоставления. В конечном счете, если при деидентификации сохраняются какие-либо пригодные к использованию пиксельные данные, то реидентификация почти всегда возможна при наличии доступа к исходным изображениям. Следовательно, замена UID не должна создавать ложную уверенность в том, что изображения деидентифицированы более полно, чем при сохранении UID.
-
Независимо от этой Option разработчики должны следить за тем, чтобы не удалять UID, которые являются структурными и определены стандартом, в отличие от UID, связанных с экземплярами. Например, SOP Class UID никогда не следует удалять или заменять в целях деидентификации.
-
Implementation Class UID (0002,0012) не включен в список UID-атрибутов, подлежащих сохранению, поскольку он является частью File Meta Information (см. PS3.10), которая полностью заменяется при каждом сохранении или изменении файла во время деидентификации. См. Section E.1.1.
-
UID могли быть созданы с использованием механизма отметки даты и времени для обеспечения уникальности. Поэтому, если исходные UID не заменяются, они могут способствовать восстановлению личности. При этом наличие кажущейся отметки даты и времени в UID не означает, что это исходный UID, поскольку заменяющие UID могут содержать новые отметки даты и времени, связанные с моментом деидентификации экземпляра. Кроме того, UUID могут быть основаны на времени, а не на имени или случайном числе, поэтому использование механизма PS3.5 Section B.2 UUID Derived UID не обязательно устраняет эту проблему.
По определению Private Attributes содержат проприетарную информацию, характер которой во многих случаях известен только поставщику и не документирован публично.
Однако некоторые Private Attributes могут быть необходимы для требуемого приложения. Например, специальная информация о методике, такая как CT helical span pitch, или преобразование значений пикселей, например коэффициенты пересчета PET SUV, могут быть доступны только в Private Attributes, поскольку такая информация либо не определена в Standard Attributes, либо была добавлена в стандарт DICOM уже после изготовления устройства получения данных.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, Private Attributes, которые деидентификатор считает безопасными с точки зрения утечки личности, должны быть сохранены вместе с Private Creator IDs, необходимыми для полного определения сохраняемых Private Attributes; все остальные Private Attributes должны быть удалены или обработаны способом, специфичным для элемента и рекомендованным Deidentification Action (0008,0307), если он присутствует в Private Data Element Characteristics Sequence (0008,0300) (см. PS3.3 Section C.12.1).
То, считается ли атрибут безопасным, может определяться по следующим признакам:
-
его наличие в блоке Private Data Elements со значением "SAFE" в Block Identifying Information Status (0008,0303) либо индивидуальное перечисление в Nonidentifying Private Elements (gggg,0004) (внутри Private Data Element Characteristics Sequence (0008,0300); см. PS3.3 Section C.12.1)
-
его наличие в Table E.3.10-1 Safe Private Attributes
Если эта Option не указана, все Private Attributes должны быть удалены, как описано в Table E.1-1.
Если для целого Private Attribute с Sequence (SQ VR) неизвестно, что он всегда содержит только безопасное содержимое, независимо от того, состоит ли это содержимое из Standard Attributes, Private Attributes или их сочетания, то при использовании Retain Safe Private Option такой Sequence Attribute должен быть полностью разобран, а каждый вложенный атрибут должен обрабатываться по существу, вместо удаления всей Sequence без дальнейшего рассмотрения. Просмотр содержимого может быть разумной практикой даже для номинально известных безопасных Private Sequence Attributes.
Примечание
-
Ниже приведен примерный список Private Attributes, которые считаются безопасными. Поставщики не гарантируют их безопасность и не обязуются передавать их в какой-либо конкретной версии программного обеспечения (включая будущие продукты).
Table E.3.10-1. Safe Private Attributes
Безопасные частные атрибуты
-
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.
Информация об идентификации учреждения, в котором выполнялось получение данных, признается потенциальным источником раскрытия личности, поскольку она может сужать круг возможных лиц, которые могли быть субъектом визуализации, но только при наличии доступа к другой информации об этих лицах для сопоставления.
Однако существуют приложения, которым такая информация об учреждении необходима для выполнения анализа или интерпретации. Может существовать необходимость сохранять запись об учреждении для регуляторных целей или целей реестра, при том что место получения данных может не поддерживать достаточный электронный журнал аудита.
Если эта Option указывается дополнительно к Basic Application Level Confidentiality Profile, информация об идентификации учреждения в атрибутах должна быть сохранена, как описано в Table E.1-1.
Basic Network Address Management Profile использует DHCP для предоставления служб удаленного назначения и управления IP-параметрами машин. DHCP-сервер вручную настраивается для определения правил назначения IP-адресов машинам. Правила могут задавать явные назначения для отдельных машин или блок IP-адресов, динамически назначаемых при подключении и удалении машин из сети. DHCP-клиент при запуске может получить от DHCP-сервера свой IP-адрес и различные связанные параметры, например адрес NTP-сервера. DHCP-сервер может динамически обновлять DNS-сервер новыми соответствиями между IP-адресами и DNS-именами хостов.
DNS Client может получить IP-номер другого хоста, передав DNS-имя хоста DNS Server и получив в ответ IP-номер. Эта транзакция может использоваться в других профилях или в реализациях, не соответствующих Basic Network Address Management Profile.
Basic Network Address Management Profile применяется к акторам DHCP Server, DHCP Client, DNS Server и DNS Client. Обязательные и необязательные транзакции описаны в таблице и разделах ниже.
DNS Client может получить IP-номер хоста, передав DNS-имя хоста DNS Server и получив в ответ IP-номер.
Стандарты и их взаимосвязи для семейства протоколов DNS показаны на Figure F.1-2. Подробности транзакций, диаграмм транзакций и т. п. содержатся в указанных RFC.
Вопрос безопасности активно разрабатывается Internet Engineering Task Force и ее различными рабочими группами. RFC и проекты, связанные с безопасностью, указаны на Figure F.1-2. Некоторые из них завершены, другие все еще находятся на стадии проекта. Basic Network Address Management Profile не включает специальных требований к поддержке расширений безопасности DNS со стороны DNS Client.
Basic Network Address Management Profile не следует использовать вне защищенной среды. Как минимум должны быть предусмотрены:
В некоторых средах могут быть уместны другие процедуры сетевой безопасности, например автоматизированное обнаружение вторжений. Средства безопасности сверх этого минимума должны определяться локальной политикой безопасности и находятся вне области применения DICOM.
Цель выбранной защиты состоит в ограничении области угроз внутренними атаками. Система DNS раскрывает только имена хостов и IP-адреса, поэтому перехват трафика вызывает мало опасений. Защита направлена на ограничение воздействия атак отказа в обслуживании со стороны поддельных серверов или клиентов.
Кэши клиентов могут вызывать путаницу во время обновлений. Многие DNS-клиенты проверяют наличие обновлений DNS очень редко и могут не отражать изменения DNS в течение часов или дней. Для немедленного обновления могут потребоваться ручные действия. Конкретные средства управления кэшем и обновлением различаются для разных DNS-клиентов и DNS-серверов, однако кэширование DNS и задержки распространения обновлений являются существенными факторами, и реализации имеют механизмы для управления этими проблемами.
Следует учитывать управление отказами DNS Server. Избыточные серверы и резервные файлы hosts являются примерами возможных средств управления ошибками.
DNS-сервер может предоставлять дополнительную необязательную информацию для поддержки управления конфигурацией. Спецификация этой информации и дополнительных RFC, которые должны поддерживаться, приведены в разделе H.2.
DHCP-сервер должен настраиваться администрацией площадки так, чтобы:
Этот стандарт не определяет, как должна выполняться такая настройка.
Примечание
Большинство DHCP-серверов поддерживают предварительное выделение фиксированных IP-адресов для упрощения перехода унаследованных систем. Это позволяет конкретному устройству перейти на DHCP, сохранив ранее назначенный IP-адрес. Такой подход обеспечивает централизованное управление IP-адресами на площадке без нарушения совместимости со старыми системами, которым требуются фиксированные IP-адреса.
- Actor (актор):
- Role (роль):
- Actor (актор):
- Role (роль):
-
Обновляет конфигурационную информацию для добавления, изменения и удаления описаний клиентов и серверов.
- Actor (актор):
- Role (роль):
-
Предоставляет начальные требования к конфигурации для многих устройств при установке новой сети, а также для отдельных устройств при установке или изменении одного устройства.
Это поддержка обычного процесса запуска. Система DHCP-клиента загружается и на очень раннем этапе загрузки находит DHCP-серверы, выбирает один из них в качестве своего сервера, запрашивает у него различную информацию и продолжает самонастройку DHCP-клиента с использованием результатов этого запроса. DHCP-серверы могут необязательно предоставлять разнообразную информацию, например расположения серверов и обычные маршруты. Эта транзакция определяет, какую информацию должен предоставлять соответствующий DHCP-сервер и какую информацию должен запрашивать соответствующий DHCP-клиент. Соответствующий DHCP-сервер не обязан предоставлять эту необязательную информацию.
[RFC 2131] DHCP Protocol (протокол DHCP)
[RFC 2132] DHCP Options (параметры DHCP)
[RFC 2563] Auto Configuration control (управление автоконфигурацией)
DHCP-клиент должен соответствовать [RFC 2131] (DHCP Protocol), [RFC 2132] (DHCP Options), [RFC 2563] (Auto Configuration Control) и RFC, на которые они ссылаются.
DHCP-клиент должен запрашивать доступные DHCP-серверы. Он должен выбрать DHCP-сервер, который будет использоваться.
DHCP-клиент должен запрашивать назначение IP. DHCP Server должен определить IP-параметры в соответствии с текущей конфигурацией DHCP, установить аренду для этих параметров и ответить этой информацией. (См. ниже поддержание и истечение аренды.) DHCP-клиент должен применить эти параметры к стеку TCP/IP. DHCP-клиент должен установить внутренние действия по поддержанию аренды.
DHCP-клиент должен запрашивать необязательную информацию, перечисленную в Table F.1-2, когда это требуется дополнительными профилями, используемыми клиентской системой. Если DHCP-сервер не предоставляет эту информацию, DHCP-клиент должен использовать значения по умолчанию.
DHCP-клиент должен сделать эту информацию доступной другим акторам внутри машины DHCP-клиента.
DHCP-клиент обычно поддерживает аренду IP-адреса в соответствии с RFC. Иногда сервер не продлевает аренду. Непродление обычно является частью операций сетевого обслуживания. Потеря аренды IP-адреса требует прекращения соединений, использующих этот IP-адрес.
[RFC 2131] DHCP Protocol
[RFC 2132] DHCP Options (параметры DHCP)
DHCP-клиент должен поддерживать аренду IP-адреса в соответствии с протоколом DHCP, как указано в [RFC 2131] и [RFC 2132]. Возможна ситуация, когда DHCP-сервер откажет или примет решение не продлевать аренду.
Если аренда DHCP истекает без продления, любые все еще активные соединения DICOM могут быть прерваны (AP-Abort).
DHCP-серверы могут координировать назначение IP-адресов и имён хостов с DNS-сервером. Это позволяет динамически назначать IP-адреса, не нарушая доступ других систем к DHCP-клиентам. Другие системы используют согласованное имя хоста, которым DHCP может управлять и предоставлять клиенту, и получают текущий IP-адрес посредством поиска DNS.
Dynamic DNS (DDNS) предоставляет клиенту возможность обновлять DNS-записи, размещенные на DNS-сервере. Клиентом может быть DHCP-сервер, серверы Active Directory или LDAP либо даже приложение, объявляющее IP-адрес системы и, необязательно, доступные службы.
DHCP Server соответствует этой необязательной части Basic Network Address Management Profile, если он поддерживает и обновляет соответствующую DNS-запись так, чтобы при изменениях сохранять отношения имени хоста и IP в базе DNS.
[RFC 2136] Dynamic Updates in the Domain Name System
DHCP-сервер назначает IP-адрес DHCP-клиенту, затем сообщает DDNS-серверу, что имени хоста, связанному с DHCP-клиентом, был назначен IP-адрес. DDNS-сервер обновляет базу данных DNS и связывает IP-адрес с именем хоста. DNS-запросы для этого имени хоста направляются на назначенный IP-адрес. Если назначенный IP-адрес изменяется или истекает срок его действия, DHCP-сервер сообщает об этом DDNS-серверу, который обновляет базу данных DNS.
Профиль Basic Network Address Management Profile имеет две области проблем безопасности:
Basic Network Address Management Profile не следует использовать вне защищенной среды. Как минимум должны быть предусмотрены:
В некоторых средах могут быть уместны другие процедуры сетевой безопасности, например автоматизированное обнаружение вторжений. Средства безопасности сверх этого минимума должны определяться локальной политикой безопасности и находятся вне области применения DICOM.
Цель выбранной защиты состоит в ограничении области угроз внутренними атаками. Системы DHCP и DNS раскрывают только имена хостов и IP-адреса, поэтому перехват трафика вызывает мало опасений. Защита направлена на ограничение воздействия атак отказа в обслуживании со стороны поддельных серверов или клиентов. Конкретные расширения безопасности DNS описаны в Section F.1.1.4. Этот профиль не использует расширения безопасности DHCP, поскольку они дают очень ограниченное дополнительное повышение безопасности, а атаки являются внутренними атаками отказа в обслуживании. Обнаружение вторжений и другие механизмы защиты сетевого уровня являются наиболее эффективным следующим уровнем защиты для процесса DHCP.
Обновление DNS является необязательным в этом профиле, чтобы учесть возможность того, что DHCP-сервер и DNS-сервер не смогут прийти к взаимно приемлемому процессу безопасности. Поддержка этой опции может требовать поддержки протоколов безопасности DNS, которые находятся в процессе разработки. Обсуждение стандартов и проектов профиля безопасности DNS см. в Section F.1.1.4.
Файл конфигурации DHCP может быть очень полезной формой документирования конфигурации оборудования локальной сети. Его можно подготовить заранее для новых установок и обновлять по мере добавления клиентов. Включение информации обо всех машинах, включая те, которые не используют DHCP, позволяет избежать случайных конфликтов IP-адресов и аналогичных ошибок.
Большинство DHCP-серверов имеют возможности конфигурации, позволяющие управлять IP-адресом и другой информацией, предоставляемой клиенту. Эти средства управления могут заранее выделять конкретный IP-адрес и т. п. машине на основе запрошенного имени машины или MAC-адреса. Такие предварительно выделенные IP-адреса затем гарантируют, что этим конкретным машинам всегда назначается один и тот же IP-адрес. Унаследованные системы, которые не используют DNS, могут продолжать использовать фиксированные таблицы с IP-адресами, если DHCP-сервер предварительно выделил IP-адреса для этих служб.
Реализация, поддерживающая этот профиль, должна указать в своём Conformance Statement, поддерживает ли она DHCP в роли DHCP Client или DHCP Server.
Реализация, поддерживающая этот профиль как DHCP Client, должна указать в своем Conformance Statement, как обнаруживается DHCP Server (см. Section F.1.3).
Реализация, поддерживающая этот профиль, должна указать в своем Conformance Statement, поддерживает ли она DNSSEC [RFC 4033] [RFC 4034] [RFC 4035] для взаимодействий, описанных в этом профиле; в этом случае должны быть указаны либо поддерживаемые опции, либо ссылка на поддержку DNSSEC для данного продукта.
Basic Time Synchronization Profile определяет службы для синхронизации часов на нескольких компьютерах. Он использует службы Network Time Protocol (NTP), которые применяются для этой цели во многих других областях. NTP допускает синхронизацию с локальным сервером, предоставляющим локальный источник времени, а также синхронизацию с различными внешними службами времени. Средства управления точностью и прецизионностью явно не являются частью протокола. Они в значительной степени определяются выбором аппаратных часов и топологией сети.
Подробное обсуждение стратегий реализации NTP доступно на http://www.ntp.org.
Basic Time Synchronization Profile применяется к акторам DHCP Client, DHCP Server, SNTP Client, NTP Client и NTP Server. Обязательные и необязательные транзакции описаны в таблице и разделах ниже.
Необязательные элементы протокола NTP для автонастройки NTP и автоматического обнаружения NTP могут значительно упростить установку. Спецификация NTP для этих элементов определена так, что они действительно являются необязательными как для клиента, так и для сервера. Если клиент не может автоматически найти NTP-сервер с помощью этих служб, он может использовать необязательную информацию DHCP или вручную настроенную информацию для поиска сервера. Поддержка этих служб рекомендуется, но не является обязательной.
Эта транзакция существует главным образом как средство документирования того, поддерживают ли конкретные модели оборудования автоматическое обнаружение. Это позволяет службам установки и эксплуатации заранее планировать процедуры настройки DHCP и установки оборудования.
Это относится к любому клиенту, которому требуется правильное время или синхронизация его временных меток с временными метками другой системы. Точность синхронизации определяется деталями конфигурации и реализации сети и NTP-серверов на конкретной площадке.
И NTP-клиенты, и SNTP-клиенты должны использовать информацию о NTP-сервере, если она предоставлена DHCP и службы NTP не были найдены с помощью автоматического обнаружения. В качестве резервного варианта должна быть предусмотрена ручная настройка. Предпочтительны автоматическое обнаружение или DHCP.
[RFC 2030] Simple Network Time Protocol (SNTP) Version 4 (Simple Network Time Protocol (SNTP), версия 4)
[RFC 5905] Network Time Protocol Version 4: Protocol and Algorithms Specification (Network Time Protocol версии 4: спецификация протокола и алгоритмов)
[RFC 5906] Network Time Protocol Version 4: Autokey Specification (Network Time Protocol версии 4: спецификация Autokey)
[RFC 8633] Network Time Protocol Best Current Practices (рекомендуемые современные практики Network Time Protocol)
NTP Client использует список NTP Servers, который может быть:
-
получен через необязательные механизмы обнаружения NTP (см. [RFC 5905], раздел 3.1),
Если список не пуст, клиент должен попытаться поддерживать синхронизацию времени как минимум с одним из NTP-серверов. Синхронизация клиента должна соответствовать либо [RFC 5905] (NTP), либо [RFC 2030] (SNTP). Если список пуст, клиент может выбрать альтернативный метод синхронизации времени.
SNTP обеспечивает значительно меньшую точность, чем NTP. Если требуется синхронизация времени со средней ошибкой лучше 1 с, клиенту следует использовать NTP. В [RFC 5905] и [RFC 8633] обсуждаются вопросы реализации и точности.
DHCP-сервер может предоставить DHCP Client смещение UTC между локальным временем на машине и UTC; клиент должен использовать это смещение для преобразования между UTC и локальным временем.
Если от DHCP-сервера или NTP-сервера нет информации о смещении UTC, смещение UTC будет получено способом, специфичным для устройства (например, через обслуживание, CMOS, внутренние часы с батарейным питанием).
Это относится к любому клиенту, которому требуется правильное время или синхронизация его временных меток с временными метками другой системы. Точность синхронизации определяется деталями конфигурации и реализации сети и NTP-серверов на конкретной площадке.
[RFC 2030] Simple Network Time Protocol (SNTP) Version 4 (Simple Network Time Protocol (SNTP), версия 4)
[RFC 2827] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (фильтрация входящего сетевого трафика: противодействие атакам отказа в обслуживании с подменой исходного IP-адреса)
[RFC 5905] Network Time Protocol Version 4: Protocol and Algorithms Specification (Network Time Protocol версии 4: спецификация протокола и алгоритмов)
[RFC 5906] Network Time Protocol Version 4: Autokey Specification (Network Time Protocol версии 4: спецификация Autokey)
[RFC 8633] Network Time Protocol Best Current Practices (рекомендуемые современные практики Network Time Protocol)
Подробности транзакций Maintain Time описаны в [RFC 5905] и [RFC 2030]. Наиболее распространённый и минимально обязательный режим работы NTP использует серию сообщений между клиентом и серверами. Клиент отправляет запросы серверам, которые заполняют связанные со временем поля в ответе, а клиент на основе этой информации выполняет оптимальную оценку текущего времени. RFC рассматривают вопросы потерянных сообщений, формулы оценки и т. п. После синхронизации часов эти обмены сообщениями обычно стабилизируются примерно с интервалом 1000 секунд.
Клиентская машина использует оценку времени для поддержания внутренних часов операционной системы. Затем эти часы используются приложениями, которым требуется информация о времени. Такой подход устраняет видимое для приложения различие между синхронизированным и несинхронизированным временем. RFC содержат рекомендации по надлежащим реализациям.
Вопросы безопасности NTP ([RFC 5905], раздел 8, [RFC 5906] и [RFC 8633]) могут быть применимы с учётом среды конкретной площадки и рассматриваемых угроз. Площадкам с NTP Servers также следует учитывать [RFC 2827] и реализовывать средства управления доступом к использованию сервера.
Политики и процедуры безопасности для NTP поддерживаются на http://www.nwtime.org/security-policy/ как часть Network Time Foundation.
Серверы, соответствующие NTP, всегда поддерживают как NTP-клиентов, так и SNTP-клиентов. Различие заключается в точности синхронизации, а не в совместимости обмена данными. Хотя теоретически NTP-клиенты и SNTP-клиенты могут одновременно работать в одной системе, это не рекомендуется. Обновления SNTP просто ухудшат точность времени. Когда используются и другие клиенты протоколов времени, например IRIG, эти клиенты должны быть скоординированы с NTP-клиентом, чтобы избежать проблем синхронизации.
Эти и другие вопросы, такие как несколько типов часов, влияние на точность и альтернативы конфигурации, документированы на http://www.ntp.org.
В Conformance Statement для NTP Server и NTP Client должно быть указано, поддерживаются ли защищённые транзакции ([RFC 5906]).
В Conformance Statement для NTP Server должно быть указано, является ли он также NTP Client.
В Conformance Statement для NTP Client должно быть указано, как он управляет временем, когда NTP Server недоступен.
Application Configuration Management Profile применяется к акторам LDAP Server, LDAP Client и DNS Server. Обязательные и необязательные транзакции описаны в таблице и разделах ниже.
Table H.1-1. Application Configuration Management Profiles
Профили управления конфигурацией приложений
Нормативное определение схемы приведено в разделе H.1.3. В этом разделе даны дополнительные справочные описания объектов и информации, определённых в этой схеме, а также приведены нормативные положения о поведении систем DICOM.
Application Configuration Data Model содержит следующие компонентные объекты:
Кроме того, в LDAP-схеме используется ряд других объектов (см. раздел H.1.2 и Figure H.1-2):
LDAP допускает расширения схемы для поддержки локальных потребностей, то есть объект может реализовывать один структурный и несколько вспомогательных LDAP-классов. DICOM не требует от клиентов поддержки таких расширений. Серверы могут поддерживать такие расширения для локальных целей. DICOM Clients могут принимать или игнорировать расширения и не должны считать их наличие ошибкой.
«Device» представляет собой набор компонентов, организованных для выполнения задачи, а не конкретный физический экземпляр. Для простых устройств одному устройству модели данных может соответствовать одно физическое устройство. Однако для сложного оборудования одному «device» может соответствовать множество физических частей.
«Device» — это совокупность физических сущностей, поддерживающая набор Application Entities. Она однозначно связана с этими сущностями и наоборот. Она также однозначно связана с сетевыми соединениями и наоборот. В простой рабочей станции с одним CPU, одним подключением питания и одним сетевым подключением «device» является рабочая станция.
Пример сложного устройства — сервер, построенный из сети нескольких компьютеров, имеющих несколько сетевых подключений и независимые подключения питания. Это будет одно устройство с одной прикладной сущностью и несколькими сетевыми подключениями. Такие серверы проектируются так, чтобы отдельные компьютеры-компоненты можно было заменять без нарушения работы. Application Configuration Data Model не описывает эту внутреннюю структуру. Она описывает сетевые подключения и видимые в сети Application Entities. Такие сложные устройства обычно проектируются для очень высокой доступности, но в необычном случае выключения системы «device» соответствует всем частям, которые выключаются.
Table H.1-2. Attributes of Device Object
Атрибуты объекта Device
|
Уникальное имя этого устройства в пределах LDAP-базы данных. Оно ограничено допустимыми LDAP-именами и не ограничивается правилами DICOM AE Title. |
||
|
Должно совпадать со значением Manufacturer (0008,0070) в SOP Instances, создаваемых этим устройством. |
||
|
Должно совпадать со значением Manufacturer Model Name (0008,1090) в SOP Instances, создаваемых этим устройством. |
||
|
Должно совпадать со значениями Software Versions (0018,1020) в SOP Instances, создаваемых этим устройством. |
||
|
Должно совпадать со значением Station Name (0008,1010) в SOP Instances, создаваемых этим устройством. |
||
|
Должно совпадать со значением Device Serial Number (0018,1000) в SOP Instances, создаваемых этим устройством. |
||
|
Представляет тип устройства и наиболее применимо к модальностям получения данных. Если применимо, типы следует выбирать из списка кодов Code Value (0008,0100) для CID 30 “DICOM Device” в CID 30. |
||
|
Должно совпадать со значением Institution Name (0008,0080) в SOP Instances, создаваемых этим устройством. |
||
|
Должно совпадать со значением атрибута Institution Address (0008,0081) в SOP Instances, создаваемых этим устройством. |
||
|
Institutional Department Name |
Должно совпадать со значением Institutional Department Name (0008,1040) в SOP Instances, создаваемых этим устройством. |
|
|
Institutional Department Type Code Sequence |
Должно совпадать со значением Institutional Department Type Code Sequence (0008,1041) в SOP Instances, создаваемых этим устройством. |
|
|
Значение по умолчанию для Issuer of Patient ID (0010,0021) в SOP Instances, создаваемых этим устройством. Может быть переопределено значениями, полученными из worklist или другого источника. |
||
|
DN связанных описаний устройства вне иерархии DICOM Configuration. Может использоваться для связывания объекта DICOM Device с дополнительными LDAP-объектами, созданными из других схем и используемыми для отдельных административных целей. |
||
|
Authorized Node Certificate Reference |
DN сертификатов узлов, которым разрешено подключаться к этому устройству. DN не обязаны находиться внутри иерархии конфигурации DICOM. |
|
|
This Node Certificate Reference |
DN открытого сертификата или сертификатов этого узла. DN не обязаны находиться внутри иерархии конфигурации DICOM. |
|
|
Специфичная для устройства конфигурационная информация поставщика |
||
|
Boolean-значение, указывающее, установлено ли это устройство в настоящее время в сети. Это полезно для предварительной конфигурации, мобильных комплексов и подобных ситуаций. |
«Authorized Node Certificate Reference» предназначен для того, чтобы LDAP-сервер мог предоставить список сертификатов узлов, которым разрешено взаимодействовать с этим устройством. Это должны быть только открытые сертификаты. Список не обязан быть полным. Другие сетевые узлы могут быть авторизованы другими механизмами.
«This Node Certificate Reference» предназначен для того, чтобы LDAP-сервер мог предоставить сертификат или сертификаты этого узла. Они также могут обрабатываться независимо от LDAP.
Примечание
Устройство может иметь несколько записей Primary Device Type. Оно может быть многофункциональным, например совмещённым PET и CT. Оно может быть каскадным устройством, например устройство захвата изображений и ультразвуковая система.
Table H.1-3. Child Objects of Device Object
Дочерние объекты объекта Device
|
Application Entities, доступные на этом устройстве (см. раздел H.1.1.2) |
||
|
Сетевые соединения для этого устройства (см. раздел H.1.1.3) |
Network AE — это прикладная сущность, предоставляющая службы в сети. Network AE будет иметь одинаковые функциональные возможности независимо от конкретного используемого сетевого соединения. Если функциональные различия зависят от выбранного сетевого соединения, это отдельные Network AEs. Если функциональные различия зависят от других внутренних структур, это также отдельные Network AEs.
Table H.1-4. Attributes of Network AE Object
Атрибуты объекта Network AE
|
Локально определённые имена для подмножества связанных приложений. Например, "neuroradiology". |
||
|
Preferred Called AE Title |
AE Title или AE Titles, предпочтительные для инициирования ассоциаций. |
|
|
Preferred Calling AE Title |
AE Title или AE Titles, предпочтительные для принятия ассоциаций. |
|
|
Boolean-значение. True, если Network AE может принимать ассоциации; иначе false. |
||
|
Boolean-значение. True, если Network AE может принимать ассоциации; иначе false. |
||
|
Character Set(s), поддерживаемые Network AE для получаемых ею Data Sets. Значение должно выбираться из Defined Terms для Specific Character Set (0008,0005) в PS3.3. Если значения отсутствуют, это означает, что Network AE поддерживает только набор символов по умолчанию (ISO IR 6). |
||
|
Boolean-значение. True, если AE установлена в сети. Если значение отсутствует, информация об установленном состоянии AE наследуется от устройства. |
Концепция «Application Cluster» предоставляет механизм определения локальных кластеров систем. Варианты использования Configuration Management требуют для DICOM-приложений возможности «domain», независимой от сетевой топологии и административных доменов, используемых DNS и другими протоколами уровня TCP. Application Cluster является многозначным, чтобы поддерживать несколько концепций кластеризации для разных целей. Ожидается, что он будет использоваться как часть запроса для ограничения области запроса.
Концепция «Preferred Called AE Title» предназначена для того, чтобы администратор площадки мог определить ограниченный набор AE по умолчанию, предпочтительных в качестве партнёров по обмену при инициировании ассоциаций. Эта возможность особенно полезна для крупных централизованно администрируемых площадок, поскольку упрощает варианты конфигурации и ограничивает число настроенных AE для конкретных сценариев рабочего процесса. Например, набор AE может содержать AE Titles назначенных Printer, Archive, RIS и QA Workstations, чтобы клиентское устройство могло соответствующим образом адаптировать свои настройки. Концепция «Preferred Called AE Title» не запрещает инициировать ассоциации с AE, отсутствующими в списке. Ассоциации с отсутствующими в списке AE могут инициироваться при необходимости.
Концепция «Preferred Calling AE Title» предназначена для того, чтобы администратор площадки мог определить набор AE по умолчанию, предпочтительных при принятии ассоциаций. Концепция «Preferred Calling AE Title» не запрещает принимать ассоциации от AE, отсутствующих в списке.
«Network Connection Reference» является ссылкой на отдельный объект Network Connection. Указанный объект Network Connection является соседним по отношению к объекту AE, то есть оба являются дочерними объектами одного и того же объекта Device.
Table H.1-5. Child Objects of Network AE Object
Дочерние объекты объекта Network AE
|
Transfer Capabilities для этой Network AE. См. раздел H.1.4. |
«Network connection» описывает один TCP-порт на одном сетевом устройстве. Он может использоваться для TCP-соединения, по которому может быть согласована DICOM-ассоциация с одной или несколькими Network AEs. Он задаёт имя хоста и номер TCP-порта. Одно сетевое соединение может поддерживать несколько Network AEs. Выбор Network AE выполняется во время согласования ассоциации на основе вызываемого и вызывающего AE Titles.
Table H.1-6. Attributes of Network Connection Object
Атрибуты объекта Network Connection
|
Произвольное имя объекта Network Connections. Может быть осмысленным именем или любой уникальной последовательностью символов. Может использоваться как RDN. |
||
|
Это DNS-имя для данного конкретного соединения. Оно используется для получения текущего IP-адреса для соединений. Hostname должен быть достаточно квалифицированным, чтобы быть однозначным для любого клиента DNS. |
||
|
TCP-порт, на котором AE прослушивает соединения. Он может отсутствовать для сетевого соединения, которое только инициирует ассоциации. |
||
|
TLS CipherSuites, поддерживаемые на этом конкретном соединении. TLS CipherSuites должны описываться с использованием строкового представления [RFC 2246], например "TLS_RSA_WITH_RC4_128_SHA". |
||
|
Boolean-значение. True, если Network Connection установлено в сети. Если значение отсутствует, информация об установленном состоянии Network Connection наследуется от устройства. |
Включение TLS CipherSuite в Network Connection, способное принимать ассоциации, означает, что для успешного установления ассоциации через это Network Connection должен использоваться протокол TLS.
Одна Network AE может быть доступна через несколько сетевых соединений. Это часто делается на серверах по причинам доступности или производительности. Например, в больнице, где каждый этаж подключён к одному концентратору на этаж, основные серверы могут иметь прямые подключения к каждому из концентраторов. Это обеспечивает лучшую производительность и надёжность. Если поведение сервера не меняется в зависимости от конкретного физического сетевого соединения, его можно описать как имеющий Network AEs, доступные через все эти несколько сетевых соединений. Network AE также может быть видима на нескольких TCP-портах одного и того же сетевого аппаратного порта, при этом каждый TCP-порт представлен как отдельное сетевое соединение. Это позволило бы, например, одной AE поддерживать защищённый TLS DICOM-порт и классический незащищённый DICOM-порт.
Каждый объект Network AE имеет одну или несколько Transfer Capabilities. Каждая transfer capability указывает SOP Class, которую Network AE может поддерживать, режим, который она может использовать (SCP или SCU), и Transfer Syntax(es), которые она может использовать. Network AE, поддерживающая один и тот же SOP Class в режимах SCP и SCU, будет иметь два объекта Transfer Capabilities для этого SOP Class.
Table H.1-7. Attributes of Transfer Capability Object
Атрибуты объекта Transfer Capability
Этот структурный класс объекта представляет корень DICOM Configuration Hierarchy. В пределах организационного домена должен существовать только один объект этого типа. Клиенты могут искать объект этого класса, чтобы найти корень DICOM Configuration Hierarchy.
Table H.1-8. Attributes of the DICOM Configuration Root Object
Атрибуты объекта DICOM Configuration Root
Table H.1-9. Child Objects of DICOM Configuration Root Object
Дочерние объекты объекта DICOM Configuration Root
Этот структурный класс объекта представляет корень DICOM Devices Hierarchy. Только один объект этого типа должен существовать как дочерний объект DICOM Configuration Root. Клиенты могут искать объект этого класса, чтобы найти корень DICOM Devices Hierarchy.
Этот структурный класс объекта представляет корень иерархии Unique AE-Titles Registry. Только один объект этого типа должен существовать как дочерний объект DICOM Configuration Root. Клиенты могут искать объект этого класса, чтобы найти корень Unique AE Titles Registry.
Table H.1-12. Attributes of the Unique AE Titles Registry Root Object
Атрибуты объекта Unique AE Titles Registry Root
Table H.1-13. Child Objects of Unique AE Titles Registry Root Object
Дочерние объекты объекта Unique AE Titles Registry Root
|
Уникальные AE Titles, установленные в пределах этого организационного домена (см. раздел H.1.1.8) |
Этот структурный класс объекта представляет Unique Application Entity Title. Объекты этого типа должны существовать только как дочерние объекты Unique AE-Titles Registry Root. Единственная цель этого класса объектов — обеспечить выделение уникальных AE Titles. Вся эксплуатационная информация, связанная с AE Title, поддерживается в отдельном объекте Network AE.
Структура LDAP строится на иерархии именованных объектов. Эта иерархия может различаться от площадки к площадке. Функции управления конфигурацией DICOM необходимо предсказуемо находить свои объекты внутри этой иерархии. По этой причине для трёх объектов на вершине иерархии DICOM определены три специальных класса объектов. Эти три класса объектов не должны использоваться в таком древовидном отношении где-либо ещё в иерархии LDAP.
Часть иерархии DICOM должна начинаться с корневого объекта класса dicomConfigurationRoot с Common Name "DICOM Configuration". Ниже этого объекта должны находиться два других объекта:
-
Объект класса dicomDevicesRoot с Common Name "Devices". Это корень дерева объектов, соответствующих структуре Application Configuration Data Model из раздела H.1.1.
-
Объект класса dicomUniqueAETitlesRegistryRoot с common name "Unique AE Titles Registry". Это корень плоского дерева объектов. Каждый из этих объектов именуется одним из AE Titles, назначенных в настоящее время. Это механизм поиска доступных AE Titles.
Три класса объектов dicomConfigurationRoot, dicomDevicesRoot и dicomUniqueAETitleRegistryRoot используются LDAP-клиентами для установления локального корня конфигурационной информации DICOM внутри иерархии LDAP, которая может использоваться для многих других целей.
Примечание
Во время запуска системы DICOM-приложение конфигурации, вероятно, выполнит LDAP-поиск записи класса объекта dicomConfigurationRoot, а затем подтвердит, что непосредственно под ней находятся записи dicomDevicesRoot и dicomUniqueAETitlesRegistryRoot. Обнаружив такую конфигурацию, оно может сохранить полное расположение в локальном LDAP-дереве и использовать его как корень DICOM-дерева.
Объекты под dicomUniqueAETitlesRegistryRoot используются для обеспечения уникальности, требуемой для DICOM AE Titles. Объекты dicomUniqueAETitle имеют один атрибут, представляющий уникальный AE Title. Когда требуется новый AE Title, выбирается предварительное новое имя. Новое имя резервируется с помощью средства создания LDAP: создаётся объект класса dicomUniqueAETitle с новым именем под объектом AE-Title. Если это имя уже используется, создание завершится ошибкой. В противном случае имя резервируется. LDAP-запросы могут использоваться для получения списка назначенных в настоящее время AE Titles путём получения списка всех имён под объектом dicomUniqueAETitlesRegistryRoot.
Примечание
-
LDAP использует корневую и относительную иерархическую систему именования объектов. Каждое имя объекта полностью уникально в пределах полной иерархии. Это означает, что имена объектов под "Unique AE Titles Registry" будут уникальными. Это также означает, что полные имена Network AEs и Connections будут находиться в контексте их иерархии. Например, DN для одной из Network AEs на Figure H.1-2 будет:
-
Теоретически в одной организации может существовать несколько независимых иерархий конфигурации DICOM. LDAP-серверы в такой сети должны ограничивать локальные доступы устройств так, чтобы каждому DICOM configuration client была видима только одна DICOM Configuration Hierarchy.
-
Слияние двух организаций потребует ручного управления конфигурацией для объединения иерархий DICOM Configuration. Вероятны конфликты AE Titles, ролей и другие конфликты.
Информация об отдельных LDAP-атрибутах обобщена в комментариях в начале схемы ниже. Формальное определение объектов и атрибутов находится в схеме ниже. Эта схема может быть расширена путём определения дополнительной схемы, которая задаёт вспомогательные классы, подклассы, производные от этой схемы, или и то и другое.
Формальная LDAP-схема для Application Configuration Data Model и DICOM Configuration Hierarchy приведена ниже:
# 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) )
[RFC 2782] A DNS RR for specifying the location of services (DNS SRV) задаёт механизм запроса имён и базовых описаний машин, предоставляющих сетевые службы. DNS client запрашивает описания всех машин, зарегистрированных как предлагающие определённое имя службы. В этом случае запрашиваемым именем службы будет "LDAP". DNS server может ответить несколькими именами на один запрос.
[RFC 2181] Clarifications to the DNS Specification (уточнения к спецификации DNS)
[RFC 2219] Use of DNS Aliases for Network Services (использование псевдонимов DNS для сетевых служб)
[RFC 2782] A DNS RR for specifying the location of services (DNS SRV) (DNS RR для указания расположения служб)
другие RFC включены по ссылке из [RFC 2181], [RFC 2219] и [RFC 2782].
DNS client должен запросить список всех доступных LDAP-серверов. Он будет использовать сведения о приоритете, ёмкости и расположении, предоставленные DNS, для выбора сервера ([RFC 2782] рекомендует правильное использование этих параметров). Возможна ситуация, когда LDAP-сервера нет или DNS-сервер не поддерживает запрос SRV RR.
Примечание
-
Несколько LDAP-серверов, предоставляющих доступ к общей реплицированной LDAP-базе данных, являются распространённой поддерживаемой конфигурацией. Это позволяет размещать LDAP-серверы там, где это целесообразно для лучшей производительности и отказоустойчивости. Информация в ответе DNS-сервера помогает выбрать наиболее подходящий сервер.
-
Также может существовать несколько LDAP-серверов, предоставляющих разные базы данных. В такой ситуации клиенту может потребоваться проверить несколько серверов, чтобы найти тот, который поддерживает базу данных конфигурации DICOM. Аналогично один LDAP-сервер может поддерживать несколько base DNs, и клиенту потребуется проверить каждый из этих DN, чтобы определить, какое дерево поддерживает DICOM.
[RFC 2251] "Lightweight Directory Access Protocol (v3)" задаёт механизм выполнения запросов к базе данных, соответствующей LDAP-схеме. LDAP client может формировать запросы на языке запросов LDAP, а LDAP server будет отвечать результатами для одного запроса.
[RFC 2251] Lightweight Directory Access Protocol (v3). Поддержка LDAP требует соответствия другим RFC, включённым по ссылке.
LDAP client может выполнять широкий набор запросов и каскадных запросов с использованием LDAP. LDAP client и server должны поддерживать Application Configuration Data Model.
Примечание
Несколько LDAP-серверов, предоставляющих доступ к общей реплицированной LDAP-базе данных, являются распространённой поддерживаемой конфигурацией. Это позволяет размещать LDAP-серверы там, где это целесообразно для лучшей производительности и отказоустойчивости. Правила репликации, выбранные для LDAP-серверов, влияют на видимую согласованность данных. LDAP допускает несогласованные представления базы данных во время обновлений и репликаций.
[RFC 2251] "Lightweight Directory Access Protocol (v3)" задаёт механизм внесения обновлений в базу данных, соответствующую LDAP-схеме. LDAP client может формировать обновления на языке запросов LDAP, а LDAP server будет отвечать результатами для одного запроса. Запросы обновления могут быть отклонены по причинам безопасности.
[RFC 2251] Lightweight Directory Access Protocol (v3). Поддержка LDAP требует соответствия другим RFC, включённым по ссылке.
LDAP client может выполнить запрос на обновление LDAP-базы данных. LDAP client должен поддерживать модель данных, описанную выше. LDAP server может отказаться от запроса обновления по причинам безопасности. Если LDAP server разрешает запросы обновления, он должен поддерживать модель данных, описанную выше.
Примечание
Несколько LDAP-серверов, предоставляющих доступ к общей реплицированной LDAP-базе данных, являются распространённой поддерживаемой конфигурацией. Это позволяет размещать LDAP-серверы там, где это целесообразно для лучшей производительности и отказоустойчивости. Неподходящий выбор правил репликации в конфигурации LDAP-сервера приведёт к сбою обеспечения уникальности AE Title при создании объектов AE Titles.
Создание новой Network AE требует специального действия. Необходимо выполнить следующие шаги:
-
Должен быть выбран предварительный AE Title. Возможны разные алгоритмы: от генерации случайного имени до использования заранее заданного шаблона имени с увеличением поля счётчика. В рамках этого процесса клиент может запросить поддерево Unique AE Titles Registry, чтобы получить полный список имён, используемых в настоящее время.
-
В части иерархии Unique AE Titles Registry должен быть создан новый объект Unique AE Title с предварительным именем. LDAP-сервер обеспечивает уникальность имён в любой конкретной точке иерархии.
-
Если создание нового объекта было успешным, это должен быть AE Title, используемый для новой Network AE.
-
Если создание нового объекта завершилось ошибкой из-за неуникального имени, следует вернуться к пункту a) и выбрать другое имя.
LDAP server должен поддерживать отдельное ручное или автоматизированное средство обслуживания содержимого LDAP-базы данных. LDAP server должен поддерживать механизм файлового формата [RFC 2849] для обновления LDAP-базы данных. LDAP Client или средства установки службы должны предоставлять файлы в формате [RFC 2849] для ручного обновления баз данных LDAP-сервера. LDAP server может отказаться от сетевых обновлений клиента по причинам безопасности. В этом случае для обслуживания LDAP-базы данных будет использоваться процесс сопровождения.
Процедуры ручного обновления не задаются, кроме требования выше о поддержке как минимум минимального файлового формата обмена LDAP-информацией из [RFC 2849]. Точные механизмы передачи этой информации остаются специфичными для поставщика и площадки. В некоторых ситуациях, например при создании AE Titles, полностью ручной механизм обновления может быть проще, чем обмен файлами.
Conformance Statement должен документировать механизмы, доступные для передачи этой информации. Типичные механизмы включают:
Примечание
-
Существует множество автоматических и полуавтоматических инструментов для обслуживания LDAP-баз данных. Многие LDAP-серверы предоставляют GUI-интерфейсы и инструменты обновления. Конкретные особенности этих инструментов находятся вне области DICOM. LDAP [RFC 2849] требует как минимум минимальной возможности обмена данными. Также существуют XML-инструменты для создания и сопровождения таких файлов.
-
Этот механизм также может быть очень эффективен для подготовки новой сетевой установки с помощью единой заранее спланированной сетевой конфигурации вместо обновления отдельных машин.
Угрозы и ценность механизмов конфигурации на основе LDAP относятся к следующим категориям:
Каждая из них создаёт разные уязвимости для атак. Они следующие:
-
-
На механизм уникальности AE Title можно атаковать путём создания огромного числа ложных AE Titles. Это может быть атакой Denial of Service (DoS) на LDAP-сервер. Вероятность вмешательства в операции DICOM при этом невелика.
-
Информация Network AE может быть злонамеренно обновлена. Это нарушит операции DICOM, мешая поиску правильного сервера. Она может направлять соединения к вредоносным узлам, хотя использование TLS-аутентификации для DICOM-соединений обнаружит такое неправильное направление. При наличии TLS-аутентификации это становится DoS-атакой.
-
Описания устройств могут быть злонамеренно изменены. Это нарушит правильную работу устройства.
-
-
Passive Attacks
пассивные атаки-
Получение текущего списка AE Titles, по-видимому, не имеет очевидной ценности для атакующего. Этот список не показывает, где эти AE Titles развернуты и на каком оборудовании.
-
Информация Network AE и описания устройств могут быть полезны для определения расположения уязвимых систем. Если известно, что конкретная модель оборудования конкретного поставщика уязвима к определённой атаке, информация Network AE может использоваться для поиска такого оборудования.
-
Механизмы безопасности LDAP в реальных реализациях сильно различаются. Они представляют собой сочетание административных ограничений и реализаций протокола. Широко доступные варианты методов безопасности:
-
Anonymous access: нет ограничения на выполнение этой функции по сети.
-
Basic: перед предоставлением доступа к этой функции выполняется обмен именем пользователя и паролем. Такой обмен уязвим к прослушиванию, подмене и атакам man-in-the-middle.
-
TLS: во время установления соединения выполняется обмен SSL/TLS.
-
Manual: сетевой доступ не разрешён, и функция должна выполняться вручную на сервере или полуавтоматически на сервере. Полуавтоматические средства допускают использование независимо передаваемых файлов, например через дискету, вместе с ручными командами на сервере.
Категории функций, которыми можно управлять независимо:
Наконец, эти правила могут по-разному применяться к разным поддеревьям в общей структуре LDAP. Конкретные детали Access Control Lists (ACLs), функциональных средств управления и т. п. несколько различаются между реализациями LDAP.
LDAP server должен иметь возможность задавать разные ограничения для списка AE Title и для остальной конфигурационной информации. Для обеспечения совместимости Table H.1-15 определяет несколько шаблонов управления доступом. Они соответствуют различным оценкам риска для сетевой среды.
- TLS
-
Этот шаблон обеспечивает SSL/TLS-аутентификацию и шифрование между клиентом и сервером. Он требует дополнительной настройки при установке, поскольку информация о TLS-сертификатах должна быть установлена на клиентские машины и сервер. После установки сертификатов клиенты могут выполнять полные операции обновления.
- TLS-Manual
-
Этот шаблон обеспечивает средства SSL/TLS для доступа к чтению информации и требует ручного вмешательства для выполнения функций обновления и создания.
- Basic
-
Этот шаблон использует базовую безопасность LDAP для получения доступа к LDAP-базе данных. Он требует установки пароля при настройке клиента. Он не обеспечивает защиту шифрованием. После установки пароля клиент может выполнять обновления.
- Basic-Manual
-
Этот шаблон использует базовую защиту безопасности для доступа к чтению конфигурационной информации и требует ручного вмешательства для выполнения функций обновления и создания.
- Anonymous
-
Этот шаблон разрешает полный доступ на чтение и обновление всем машинам в сети.
- Anonymous-Manual
-
Этот шаблон разрешает полный доступ на чтение всем машинам в сети, но требует ручного вмешательства для выполнения обновления и создания.
Реализация клиента или сервера может быть способна настраиваться для поддержки нескольких шаблонов. Это должно быть задокументировано в заявлении о соответствии. Конкретная конфигурация, используемая на конкретной площадке, может затем определяться во время установки.
LDAP-база данных может использоваться как инструмент документирования. Документирование конфигурации как управляемых, так и устаревших машин упрощает обновление и снижает частоту ошибок для устаревшего оборудования, настроенного вручную.
Существуют различные возможные стратегии реализации для клиентов, выполняющих поиск в LDAP-базе данных. Например, перед инициированием DICOM-ассоциации с конкретной AE клиентская реализация может:
Преимущества локального кэша включают производительность за счёт исключения частых поисков и надёжность на случай временной недоступности LDAP-сервера. Недостаток кэша в том, что со временем он может устаревать. Клиентские реализации должны предоставлять соответствующие механизмы очистки локально кэшированной информации.
Кэши клиентов могут вызывать путаницу во время обновлений. Для немедленного запуска обновлений могут потребоваться ручные действия. Репликация LDAP-базы данных также может вносить задержки и несогласованности. Репликация базы данных также может требовать ручного вмешательства, чтобы принудительно выполнить обновления немедленно.
Одна стратегия уменьшения проблем с кэшем клиента — заново получать новую информацию DNS и LDAP после любой информации о сетевой ассоциации. Часто первым признаком устаревшей информации кэша являются сбои ассоциации из-за использования устаревшей конфигурационной информации.
Некоторые LDAP-серверы не поддерживают операцию "modify DN". Например, при переименовании устройства на таком сервере может потребоваться операция копирования дерева для создания нового дерева объектов с новым именем, а затем удаление старого дерева объектов. После такого переименования устройству может потребоваться поиск собственной конфигурационной информации по другим атрибутам, например по серийному номеру устройства.
Механизмы обнаружения служб позволяют устройствам объявлять о своём присутствии и искать информацию о существовании других служб в сети. Многие из этих механизмов основаны на DNS.
Точное использование таких протоколов, как DNS Service Discovery (DNS-SD), Multi-cast DNS (mDNS) и DNS Dynamic Updates, определяется RFC, на которые ссылается DICOM. Этот раздел стандартизует имя, используемое в DNS SRV records для таких целей, и DNS TXT records, кодирующие сопровождающие параметры.
Вопросы безопасности, связанные с самообнаружением, находятся вне области применения. Справочное обсуждение вопросов безопасности DNS см. в разделе F.1.1.4.
[RFC 2136] DNS Dynamic Updates (динамические обновления DNS)
[RFC 2181] Clarifications to the DNS Specification (уточнения к спецификации DNS)
[RFC 2219] Use of DNS Aliases for Network Services (использование псевдонимов DNS для сетевых служб)
[RFC 2782] A DNS RR for specifying the location of services (DNS SRV) (DNS RR для указания расположения служб)
[RFC 6762] Multicast DNS (многоадресный DNS)
[RFC 6763] DNS-Based Service Discovery (обнаружение служб на основе DNS)
[RFC 8553] DNS AttrLeaf Changes (изменения DNS AttrLeaf)
[DNS-SD] DNS Self-Discovery (самообнаружение DNS)
Имя, используемое в DNS SRV для объявления DICOM Association Acceptors независимо от поддерживаемых SOP Class(es), должно быть:
Примечание
Эти варианты согласуются с именами, зарегистрированными в IANA для определения сопоставления IP-портов со службами, что является обычным для такого использования. Вариант "dicom" используется вместо альтернативы "acr-nema" для ясности. Использование Service Type в DNS SRV не подразумевает выбора порта, поскольку порт передаётся явно.
DNS TXT record может содержать следующие параметры:
-
AET= <application entity title>, где значение <application entity title> должно использоваться как Called Application Entity Title при инициировании Associations с устройством
-
PrimaryDeviceType= <primary device type>, где значение <primary device type> задаётся в Table H.1-2 Attributes of Device Object
-
DICOMWebPath= <service>, где значение <service> является компонентом path корня DICOM Web Service, как определено в PS3.18
При отсутствии DNS TXT record или параметра AET в DNS TXT record значение Instance Name, предшествующее Service Type в DNS SRV record, используемой для обнаружения службы DICOM, должно быть AET.
Примечание
Дополнительные параметры не задаются, например для указания поддерживаемых SOP Classes или другой информации, поскольку размер DNS records, кодируемых как UDP-датаграммы, строго ограничен; кроме того, предполагаемое multicast-использование поощряет обмен минимально необходимой информацией. Существующий механизм согласования DICOM-ассоциации может использоваться для выяснения предлагаемых SOP Classes после того, как известны IP-адрес, номер порта и AET. Primary device type предоставляется потому, что он полезен для указания пользователям типа устройства, который не передаётся во время установления ассоциации.
Реализация, поддерживающая этот профиль, должна указать в своём Conformance Statement, поддерживает ли она чтение записей (DNS Client) или запись DNS-записей (DNS Server).
Реализация, поддерживающая этот профиль, должна указать в своём Conformance Statement, поддерживает ли она DNSSEC [RFC 4033] [RFC 4034] [RFC 4035] для взаимодействий, описанных в этом профиле; в этом случае должны быть указаны либо поддерживаемые опции, либо ссылка на поддержку DNSSEC для данного продукта.