ГОСТ Р 54472—2011/ISO/TS 13606-4:2009
мощью идентификатора rc_id конкретного тома FOLDER или путем указания списка конкретных компо-
нентов RECORD_COMPONENT (в частности, некоторых из тех, которые передаются в той же самой вы-
писке EHR_EXTRACT). Альтернативой может служить определение частей ЭМК с помощью множества
архетипов и/или периода времени. Это позволяет, например, задавать политику, применяемую ко всем
результатам микробиологических исследований, полученных с 2003 по 2005 годы. Могут включаться и
другие критерии отбора в форме строковых выражений.
Как и в случае спецификации запроса, список элементов ELEMENT подраздела ENTRY задает
условия отбора, соединяемые оператором ИЛИ, а подразделы ENTRY раздела SECTION целевых дан-
ных (EHR_target) задают условия отбора, соединяемые оператором И.
Раздел SECTION, описывающий правила доступа, используется, чтобы задать разрешения, при-
меняемые к запросам, удовлетворяющим спецификации запроса данных, совпадающей со специфи-
кацией целевых данных. В простейшем случае правило может состоять в разрешении или отказе пол-
ного доступа к целевым данным. Однако для обеспечения определенной гибкости подраздел ENTRY,
описывающий архетип максимальной категории чувствительности, представляет разрешение доступа в
форме целого числа, указывающего максимальную категорию, необходимую для получения доступа.
Значения категорий чувствительности описаны в таблице 2. Если указано целое значение 1, то это
означает, что к данным частям ЭМК предоставляется полный доступ, а если значение 6 — полный
отказ в доступе. В архетипе максимальной категории чувствительности отдельно указываются целые
значения категорий, необходимых для доступа к существующим данным ЭМК, для создания новых дан-
ных, изменения данных и передачи данных третьей стороне. Такой набор четырех значений разрешает
получателю ЭМК, например, иметь право доступа на чтение данных ЭМК без права передачи третьей
стороне или читать существующие данные без права их изменения и добавления новых данных к этой
части электронной медицинской карты.
Другая часть раздела правил доступа используется для указания, разрешается ли доступ ко всем
историческим версиям данных ЭМК или только к текущей (наиболее недавней) версии. Такое указание
может требоваться в некоторых политиках доступа для соответствия действующему законодательству
по защите данных.
Дополнительные правила могут быть заданы в строковом виде. Если используются такие строко-
вые спецификации, то их однозначная интерпретация людьми и/или компьютерами должна обеспечи-
ваться сторонами, совместно использующими ЭМК.
Общее назначение архетипа, описанного в композиции COMPOSITION, — обеспечить представ-
ление базовой информации политики доступа в простой и интероперабельной форме, допускающей
включение и передачу более сложных правил. Однако поставщик ЭМК должен быть уверен, что полу-
чатель ЭМК способен понять и применить такие дополнительные правила, иначе их включение не при-
несет никакой пользы.
В разных ведомствах и в разных системах ведения ЭМК уровни структуры ЭМК, на которых за-
даются и реализуются ограничения доступа, различаются. Ясно, что задание ограничений доступа на
очень низком уровне (например, на уровне подразделов ENTRY или даже еще ниже) приведет к тому,
что разные классы пользователей будут получать совершенно разную информацию из одной и той же
композиции COMPOSITION, что создаст клинические риски и риски управления версиями. Если ограни-
чения доступа указаны в выписке EHR_EXTRACTна более низком уровне, чем способна воспроизвести
система, получающая выписку, то этой системе будет трудно правильно выполнить эти ограничения. В
таких случаях требуется принимать решение, надо ли минимизировать клинический риск (например,
применяя ко всей композиции COMPOSITION политику, эквивалентную наименьшему ограничению на
содержание композиции) или же минимизировать возможные юридические последствия (например,
применяя ко всей композиции COMPOSITION политику, эквивалентную наивысшему ограничению). По-
этому рекомендуется, чтобы ведомства по возможности санкционировали применение политик на уров-
не отдельных композиций или их групп, а не на уровне разделов SECTION или подразделов ENTRY.
Необходимо принять во внимание, что такое представление предназначено для передачи инфор-
мации о политике внутри выписки EHR_EXTRACT и не должно интерпретироваться ни как модель по-
литики в компонентах подсистем безопасности, ни как спецификация политик при передаче из одной
подсистемы безопасности в другую.
6.2 Архетип композиции политики доступа
7
На рисунке 4 показана структура дерева архетипа политик доступа. Отступы вправо означают
вложение. Каждый класс компонентов RECORD_COMPONENT показан с использованием следующих
обозначений (включая цветовые выделения, хотя они и не требуются для интерпретации рисунка):