Цілі

• регулювання доступності даних пацієнта в залежності від наявного контексту (декларації, направлення, прямого дозволу пацієнта тощо)

Обгрунтування

На момент опрацювання вимог до процесів роботи з направленнями, виявлені вимоги з надання повного (або часткового) тимчасового доступу до даних пацієнта для лікаря (або ЗОЗ), який надає послугу(и) за направленням. Також, необхідність передати або надати права доступу, може виникати у випадку, коли лікар, який веде активний епізод пацієнта за якихось обставин не може продовжити роботу тимчасово або постійно і потрібна заміна лікаря, а це потребує надання йому прав доступу до даних пацієнта.

Припущення

1. Власником та розпорядником медичних даних є пацієнт, якого ці дані стосуються.
2. Права доступу надаються за наявності контексту (декларації, направлення, прямого дозволу пацієнта чи епізоду, створеного у ЗОЗ). 

Вимоги

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

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

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

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

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

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

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

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

6 - У випадку Medical Events доступ надається від епізоду на всі його дочірні записи у сутностях 

• Visit
• Encounter
• Observation
• Condition
• Immunization
• Allergy_intolerance
• Merged Episodes (сутність, яка зберігає посилання на епізоди пацієнта(ів), які були об'єднані з пацієнтом епізоду)
  • Дочірні дані до Merged Episodes)

7 - доступ є

8 - доступу немає

Деталізація правил

Даний розділ деталізує правила, описані в попередньому розділі та містить інструкції по імплементації цих правил

Є активна декларація з пацієнтом

Не реалізовується правилами на ABAC. Реалізовується на IL

Користувач та ресурс належать до одного закладу

Не реалізовується правилами на ABAC. Реалізовується на IL

Ланка користувача що звертається до ресурсу та ланка користувача що створив ресурс (володіє ресурсом) співпадають

Ланка - рівень медичних послуг які виконує лікар (медичний працівник, що зареєстрований у системі eHealth)

Ланка визначається виходячи із типу медичного закладу

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

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

Визначення ланки для користувача (Consumer)

Consumer характеризується токеном доступу, з яким він звертається до ресурсу.

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

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

SELECT pu.party_id
FROM party_users pu
WHERE pu.user_id = :user_id;

2. Визначити усіх employees даного party у даному ЗОЗ

SELECT e.id, speciality ->> 'speciality' as speciality
FROM employees e
WHERE e.party_id = :party_id
AND e.legal_entity_id = :client_id;

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

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

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

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

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

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

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

Питання