ГОСТ Р 57301—2016
лечащему врачу. Такая информация может быть изапечена из EHR пациента/лица. Также может существо
вать необходимость в поддержании списка одной или нескольких рабочих групп, членом которой является
пользователь. Примеры могут включать в себя хирургические бригады в определенной больнице или врачей с
привилегиями доступа в определенной больнице. Такие рабочие группы позволяли бы установление от
ношения пользователя к пациенту/лицу на основе существующих отношений между субьектом и другими
членами рабочей группы.
Важно отметить, что инфоструктура EHR не может считаться достоверным источником информации для
всех присваиваний рабочих групп, так как эти присваивания являются очень нестабильными и изменяются
слишком быстро, что не позволяет управлять ими централизованно. Предполагается, что системы POS при
необходимости будут прослеживать такие присваивания (например, в информационной системе больницы) и
что инфоструктура EHR будет полагаться на эти данные при наличии таковых. Предполагается, что инфо
структура EHR будет способна выводить заключения при условии, что между пациентом/лицом существуют
надежные отношения, а такое отношение может быть логически получено из существующих ПМД (например,
когда лечащий врач уже предоставил медицинские услуги пациенту/лицу. ввел данные в EHR пациента’лица.
назначил обследование, выписал рецепт на лекарства).
Требование безопасности 63 канадской медицинской организации Infoway
Предоставление доступа пользователем на основе связи (ассоциации)
Инфоструктура EHR и все системы POS, подключенные к инфоструктуре EHR:
a) должны связывать пользователей (лечащих врачей) с картами пациента/лица и позволять дальнейший
доступ на основе этой связи; т. е. они должны предоставлять дискреционный доступ к картам, основанный на
том. что зарегистрированный пользователь, который уже имеет разрешение на доступ к карте пациента
(картам пациентов), предоставил права доступа к этим картам другому зарегистрированному пользователю;
b
)
должны позволять пользователям предоставлять другим пользователям доступ к картам, если предостав
ляющие пользователи не располагают таким доступом к карте; обратите внимание на то. что предоставле ние
доступа другим пользователям к карте не отменяет офаничения ролевой модели управления доступом для
других пользователей.
Обоснование — Данное требование имеет существенное значение, если требование безопасности 60 долж но
точно соблюдаться. Как было отмечено ранее, дискреционное управление доступом не «превалирует» над
ролевым управлением доступом. Например, врач общей практики может предоставить другому (специ
алисту) полный доступ к карте одного из своих пациентов. Специалист может позже воспользоваться досту
пом для выписки электронного рецепта для пациента. Однако если врач предоставляет доступ медсестре,
медсестра не может позднее выписать электронный рецепт для пациента, так как ролевое управление до
ступом, как правило, будет предотвращать осуществление такой функции медсестрой.
Великобритания
Требование 3.3.2 Управления информацией Великобритании
Система должна использовать ролевую модель управления доступом для авторизации доступа пользовате
ля к функциям и данным системы.
Требование 3.3.3 Управления информацией Великобритании (требование Великобритании, относящееся к
конкретному случаю)
Система, которая объединяет ролевую модель управления доступом с CRS NHS. должна получать инфор
мацию о ролевом профиле, присвоенном пользователю, с помощью интерфейсов SAML, предусмотренных
Spine для подобных целей, в соответствии с определением в Спецификации внешнего интерфейса Spine
(EIS).
Требование 3.3.6 Управления информацией Великобритании
Система, которая объединяет ролевую модель управления доступом с CRS NHS. должна осуществлять уста
новленное государством сопоставление для всего, от служебной роли/рабочей области до основной дея
тельности. 8 соответствии с публикацией уполномоченного органа.
Система должна периодически осуществлять процесс обновления сопоставлений, установленных государ
ством для всего, от служебной роли/рабочей области до основной деятельности, в соответствии с публика
цией уполномоченного органа время от времени.
Требование 3.3.7 Управления информацией Великобритании
В случае, если поставщику существующих систем не требуется поддерживать аутентификацию SS8. систе ма
должна использовать локальные средства управления доступом на основе ролей, которые поддерживают
предоставление прав доступа в соответствии с установленными государством служебными ролями/рабочи-
ми областями и действиями. Такие локальные механизмы RBAC должны.
- ограничивать использование системы пользователями до выполнения конкретных функций, присваивае
мых только менеджером(ами) системы;
- не позволять любым пользователям осуществлять доступ к выделенным для них функциям до тех пор.
пока они не введут свою идентификационную информацию и пароль.
Средства контроля доступа должны включать возможность предоставления отдельного доступа к следую
щим функциям;
62