...

1. Будь-який запит до медичних даних пацієнта повинен реєструватися у системі e-Health, із зазначенням дати та часу запиту, користувача та ЗОЗ від імені яких виконано запит, контексту запиту.
2. Можливість виконання будь-якої дії користувачем, надання доступу до ресурсу чи даних, регулюється сукупністю:
   1. ролей та скоупів, зазначених для ролі (Scopes model#Rolesscopes[AH] Scopes model v.2 [04.09.24]#Rolesscopes)
   2. конфігурації, яка визначає набір даних, які дозволено відображати у Patient Summary
   3. поточних значень параметрів користувача, ЗОЗ, та атрибутів сутностей, до яких виконується запит згідно правилам доступу за атрибутами атрибутами 
   4. обмежень, та валідацій, діючих на рівні кожного API
   5. (підлягяє уточненню та реалізації у наступних етапах проекту) обмежень на доступ до інформації на підставі:
      1. законодавства (наприклад, mental diseases)
      2. рішення пацієнта закрити доступ до безумовного доступу до даних (Patient Summary) та/або до конкретних епізодів (що також може впливати на склад Patient Summary)

Anchor
Правила Правила

Правила доступу за атрибутами

1. Завжди: ЗОЗ, від імені якого виконується запит, повинне бути активним
2. Завжди: Користувач, від імені якого виконується запит, повинен бути активним
3. Завжди: У користувача, повинен бути хоча б один активний співробітник у ЗОЗ
4. Якщо наведені вище правила виконуються, доступ визначається наступним чином:

...

1 - декларація вважається активною, коли коли її стан дорівнює Active

2 - ЗОЗ визначається в залежності від сутності, для якої перевіряються права доступу

3 - Ланка, яка створила запис визначається в залежності від сутності:

...

4 - Направлення вважається використаним, коли воно знаходиться у стані  "Використане" (In UseQueue)

5 - Для дій можливе надання доступу на конкретну дію чи перелік дій, наприклад для направлень у разі, якщо вони підписані лікарем іншої ланки, або іншого ЗОЗ, можливе виконання тільки дій використання, відміни використання та закриття направлення через процес надання зворотнього зв'язку за направленням (закриття епізоду, який посилається на направлення)

...

Ланка визначається виходячи зі спеціальності співробітника 

PRM.employee.speciality ->> 'speciality'

із типу медичного закладу

Маємо наступні ланки (рівні) медичних послуг:

Для реалізації даного правила необхідно визначити відповідні атрибути користувача (Consumer), що звертається до ресурсу та відповідні атрибути самого ресурсу (Resource)

...

Токен містить наступну інформацію

1. Необхідно визначити пов'язаний party_id з даним user_id за допомогою party_users

...

3. Визначити ланки, наявні в даного користувача виходячи з таблиці, що наведена вище

Користувач має доступ до ресурсу через направлення

...

Визначення ланки для ресурсу (Resource)

В даному правилі та контексті маємо на увазі наступні ресурси

Дані ресурси мають наступну ієрархію:

-- patient
	-- episodes
		-- encounters
			-- conditions
			-- observations
			-- immunizations
			-- allergy_intolerances

Для визначення ланки співробітника, що створив ресурс - необхідно визначити по ієрархії епізод, до якого належить ресурс, взяти $.episodes[:id].care_manager та визначити його ланку.

Технічний опис правил ABAC наведено на сторінці  ABAC rules.

Питання