Откройте актуальную версию документа прямо сейчас
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Приложение В
(справочное)
Связь со стандартом ENV 13606-3:2000
Как уже было сказано во введении к настоящему стандарту правила распространения, представленные в стандарте ENV 13606-3:2000, были изменены по следующим причинам:
- некоторые аспекты спецификации стандарта ENV 13606-3:2000, например WHY (цель требования передачи ЭМК), определены с помощью текстовых атрибутов без формализованного словаря, что препятствует достижению интероперабельности;
- общая базовая структура предусматривала гораздо больше деталей контроля доступа, чем реализовано в большинстве современных систем ведения ЭМК, и ее реализация была бы одновременно и дорогой, и трудной;
- она потребовала бы от медицинских работников значительных дополнительных усилий по заполнению экземпляров правил в процессе оперативного ввода данных в ЭМК;
- во многих компьютеризованных системах здравоохранения принимались и принимаются общие меры безопасности, и добавление к ним средств, специфичных для ЭМК, рассматривалось бы как необоснованное.
Известно, что некоторые разработчики использовали этот предварительный стандарт в качестве основы для конструирования политик доступа к ЭМК. Однако рабочая группа по разработке настоящего стандарта не нашла каких-либо сведений о масштабной демонстрации интероперабельности правил распространения политик при обмене данными между информационными системами разных производителей. В таблице В.1 перечислены базовые информационные компоненты (классы и атрибуты) модели правил распространения в том виде, как они были опубликованы в 2000 году, и указаны причины, по которым эти компоненты не были включены в исходном виде в настоящий стандарт, или даны способы их представления в модели политики, определенной в разделе 6.
Таблица В.1 - Информационные компоненты (классы и атрибуты) модели правил распространения, опубликованные в 2000 году
Исходные атрибуты правил распространения |
Соответствие модели политики, определенной в разделе 6 |
Примечание |
|
Категория |
Атрибут |
||
DR reference (ссылка на правила распространения) |
|
|
Теперь этот класс принципиально соответствует компоненту RECORD_COMPONENT, содержащему политику доступа по ссылке |
|
Distribution rule unique identifier (уникальный идентификатор правила распространения) |
policy_id |
|
|
Applied date and time (дата и время записи) |
Момент записи в базу данных компонента RECORD_COMPONENT |
|
|
Applied by (записавший субъект) |
Субъект, инициировавший запись компонента RECORD_COMPONENT в базу данных |
|
|
Valid from (дата начала действия) |
Дата, начиная с которой должна действовать данная политика доступа |
|
|
Valid to (дата прекращения действия) |
Дата завершения действия данной политики доступа |
|
|
Negation statement (объявление отрицания) |
(Отсутствует) |
В разделе SECTION правил доступа будет определено, является ли данная декларация политики разрешением или отказом |
|
Basic distribution rule (основное правило распространения) |
(Отсутствует) |
Между базовыми и небазовыми правилами теперь нет различия |
|
Invalidated by (перезаписавший субъект) |
Субъект, инициировавший запись компонента RECORD_COMPONENT в базу данных |
Представлен с помощью нормального процесса создания версий компонентов RECORD_COMPONENT |
|
Country of application (страна применения) |
(Отсутствует) |
См. комментарий о стране, приведенный ниже раздела WHERE |
|
Consent demonstration reference |
Аттестация политики доступа |
Представлен с помощью нормального процесса аттестации RECORD_COMPONENT |
Distribution rule (правило распространения) |
|
|
|
|
Distribution rule unique identifier (уникальный идентификатор правила распространения) |
Идентификатор rc_id политики доступа |
|
|
Access type (тип доступа) |
Максимальная категория чувствительности элементов: доступ, создание, изменение, передача |
|
|
Apply DR access (применяется к доступу к правилу распространения) |
(Отсутствует) |
Если политики доступа передаются как композиции COMPOSITION, то для них тоже могут быть заданы ограничения на доступ, создание, изменение, передачу. Однако вряд ли политики доступа к политикам доступа будут часто передаваться в интероперабельной форме в выписке из ЭМК |
|
Healthcare agent in context (субъект здравоохранения в контексте) |
Автор композиции COMPOSITION, описывающей политику доступа |
|
WHO (КТО) |
|
|
|
|
Profession (профессия) |
Структурные роли |
В 2000 году не был определен или указан справочник допустимых значений, что не давало возможности обеспечить адекватный уровень интероперабельности. Переименование в "структурную роль" позволяет воспользоваться справочником, определенным в ИСО/ТС 21298 |
|
Specialization (специализация) |
Специальности |
|
|
Healthcare agent (субъект здравоохранения) |
Стороны |
Изменен, чтобы использовать пакет демографических данных, определенный в ИСО 13606-1. Тип данных заменен на II |
|
Engaged in care (вовлечен в медицинскую помощь) |
(См. функциональную роль) |
Перенесен в раздел WHY (см. ниже) |
WHEN (КОГДА) |
|
|
Интервалы времени доступа, разрешенные медицинскому персоналу, трудно определить точно, разве что ретроспективно. Несколько эпизодов оказания медицинской помощи может проходить параллельно и пересекаться по времени. Продолжение доступа к ЭМК может требоваться в течение некоторого времени после завершения эпизода, чтобы зарегистрировать осложнения или дать ответы на запрос следующих поставщиков медицинской помощи. Поэтому фасет времени WHEN был удален. Параметр срока действительности позволяет задать интервал времени, когда доступ разрешен |
|
Episode of care (эпизод лечения) |
(Отсутствует) |
См. выше |
|
Episode reference (ссылка на эпизод лечения) |
(Отсутствует) |
См. выше |
|
Episode description (описание эпизода лечения) |
(Отсутствует) |
См. выше |
WHERE (ГДЕ) |
|
|
Поскольку содержание ЭМК постепенно интернационализируется (например, может содержать композиции, созданные в разных странах) и доступ к нему тоже может требоваться в разных странах, то предполагается, что разрешение или отказ в доступе, специфичные для конкретной страны, не могут быть указаны как свойство одной или всех ЭМК. Существующие национальные правила и законы могут быть представлены с помощью критериев, определенных в разделе 6, а не путем простого указания страны или географической области. В частности, явное информированное согласие на перемещение данных внутри Европейского союза не требуется, если такое перемещение совместимо с целями доступа к данным (например, оказание медицинской помощи). Поэтому эта характеристика исключена |
|
Country specificity (специфичность для страны) |
(Отсутствует) |
См. выше |
|
Legal requirement (требование законодательства) |
(Отсутствует) |
См. выше |
|
|
Условия оказания медицинской помощи |
Этот атрибут добавлен для указания, что доступ разрешен только для определенных условий оказания медицинской помощи (типов учреждений здравоохранения или их подразделений), например, только для кожно-венерологического диспансера. Такие ограничения нередко накладываются национальным законодательством. В будущем ИСО определит для значений этого атрибута новый справочник |
WHY (ПОЧЕМУ) |
|
|
Основная сложность редактирования этой части правил распространения состояла в поиске универсального и согласованного с другими приложениями справочника целей доступа, который послужил бы удобной и масштабируемой основой для деления электронной медицинской карты на части из соображений безопасности. Имеющийся опыт показывает, что в данном контексте будет работать только самая простейшая категоризация. В противном случае возникают сложные риски отказа во вполне законном доступе медицинскому персоналу, чья медицинская помощь не была предусмотрена в момент отправки информации электронной медицинской карты в базу данных |
|
Healthcare process code (код процесса медицинской помощи) |
(Отсутствует) |
Атрибут удален, поскольку в предварительном стандарте не был определен конкретный справочник и точность определения этого атрибута не обеспечивала интероперабельного принятия решений о доступе. Вместо него можно использовать функциональную ответственность |
|
Healthcare process text (название процесса медицинской помощи) |
(Отсутствует) |
См. выше |
|
Sensitivity class (категория чувствительности) |
|
Теперь он включен в новую категорию "ЧТО" ("WHAT") (см. ниже) |
|
Purpose of use (цель применения) |
|
|
|
Purpose of use code (код цели применения) |
(Отсутствует) |
Атрибут удален, поскольку в предварительном стандарте не был определен конкретный справочник и точность определения этого атрибута не обеспечивала интероперабельного принятия решений о доступе. Вместо него можно использовать функциональную ответственность |
|
Purpose of use text (название цели применения) |
(Отсутствует) |
См. выше |
|
Specific purpose of use (специфичная цель применения) |
Функциональная ответственность |
Этот атрибут имеет тип данных CV, но для обеспечения интероперабельности сообщества разработчиков должны согласовать конкретные термины или отображение на универсальную терминологию |
|
Activity (деятельность) |
(Отсутствует) |
Атрибут удален, поскольку в предварительном стандарте не был определен конкретный справочник и точность определения этого атрибута не обеспечивала интероперабельного принятия решений о доступе. Вместо него можно использовать функциональную ответственность |
|
Subject of care (субъект медицинской помощи) |
Стороны |
Субъект медицинской помощи идентифицируется в пакете DEMOGRAPHIC_EXTRACT, определенном в ИСО 13606-1 |
|
Healthcare party role (роль стороны, оказывающей медицинскую помощь) |
|
|
|
Healthcare party code (код роли стороны, оказывающей медицинскую помощь) |
Функциональная роль |
|
|
Healthcare party text (название роли стороны, оказывающей медицинскую помощь) |
Функциональная роль |
|
HOW (КАК) |
|
|
В настоящее время принято считать, что политики безопасности этого типа, рассмотренные в стандарте ENV 13606-3 (как часть раздела HOW), должны определяться организациями, службами здравоохранения или региональными органами управления здравоохранением и не должны оговариваться на уровне отдельной ЭМК. Также считается, что задание ограничений на технологии доступа является гораздо более сложной задачей, чем те, которые можно решить с помощью первоначально определенных атрибутов этого раздела. Поэтому раздел HOW был полностью удален |
|
Access method (метод доступа) |
|
|
|
Security policy (политика безопасности) |
|
|
|
Security policy text (текст политики безопасности) |
|
|
|
Signed (подписан) |
|
|
|
Encrypted distribution (шифрованное распространение) |
|
|
|
Encrypted storage (шифрованное хранение) |
|
|
|
Operating system security rating (класс защиты операционной системы) |
|
|
|
Physical security rating (класс физической защиты) |
|
|
|
Software security rating (класс защиты программного обеспечения) |
|
|
|
Consent required (требуется информированное согласие) |
|
Теперь считается достаточным, если субъект медицинской помощи может аттестовать политику доступа (и тем самым согласиться с ее определением) и аттестовать компоненты RECORD_COMPONENT, которые ссылаются на заданную политику (и тем самым согласиться с ее применением к этим частям ЭМК). Требование информированного согласия пациента во время исполнения программного обеспечения может быть обеспечено путем ограничения доступа пациента к данным. Поэтому этот класс был удален |
|
Healthcare party (сторона, оказывающая медицинскую помощь) |
|
|
|
Consent method code (код метода получения информированного согласия) |
|
|
|
Consent method text (название метода получения информированного согласия) |
|
|
|
Healthcare party role (роль стороны, оказывающей медицинскую помощь) |
|
|
|
Healthcare party code (код роли стороны, оказывающей медицинскую помощь) |
|
|
|
Healthcare party text (название роли стороны, оказывающей медицинскую помощь) |
|
|
WHAT (ЧТО) |
|
|
Исходные правила распространения подразумевали, что на каждое правило должна быть ссылка из одного или нескольких архитектурных компонентов ЭМК. Хотя это могло бы позволить задавать детальные политики доступа, необходима также масштабируемая возможность определения некоторых политик на уровне ЭМК в целом или на уровне отдельных частей ЭМК по ссылке (например, правило могло бы применяться в соответствии с некоторым алгоритмом). Для ее реализации потребовалось добавление к спецификации категории WHAT. Этот подход позволяет также применять объявления контроля доступа к совокупности компонентов, которые уже существуют в ЭМК - БЕЗ НЕОБХОДИМОСТИ ПЕРЕСМОТРА КАТЕГОРИИ КАЖДОГО ОТДЕЛЬНОГО КОМПОНЕНТА ПРИ ДОБАВЛЕНИИ ЕГО В ЭТУ СОВОКУПНОСТЬ. Этот подход значительно облегчает эксплуатацию крупных политик, которые могут регулярно пересматриваться для отражения воли пациента |
|
|
Компоненты ЭМК |
Политика доступа применяется к одному или нескольким специфичным компонентам RECORD_COMPONENT (например, к конкретному тому FOLDER) |
|
|
Архетипы |
Этот атрибут позволяет ассоциировать объявления контроля доступа с классами данных ЭМК и тем самым автоматически распространять их на любые новые данные, добавленные к данному архетипу |
|
|
Временной период |
Этот атрибут позволяет применять политику к сегментам ЭМК в зависимости от времени их действия (в отличие от срока действия самой политики) |
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.