| Table of Contents |
|---|
Цілі
регулювання доступності даних пацієнта в залежності від наявного контексту (декларації, направлення, прямого дозволу пацієнта тощо)
Обгрунтування
На момент опрацювання вимог до процесів роботи з направленнями, виявлені вимоги з надання повного (або часткового) тимчасового доступу до даних пацієнта для лікаря (або ЗОЗ), який надає послугу(и) за направленням. Також, необхідність передати або надати права доступу, може виникати у випадку, коли лікар, який веде активний епізод пацієнта за якихось обставин не може продовжити роботу тимчасово або постійно і потрібна заміна лікаря, а це потребує надання йому прав доступу до даних пацієнта.
Припущення
- Власником та розпорядником медичних даних є пацієнт, якого ці дані стосуються.
- Права доступу надаються за наявності контексту (декларації, направлення, прямого дозволу пацієнта чи епізоду, створеного у ЗОЗ).
Вимоги
- Будь-який запит до медичних даних пацієнта повинен реєструватися у системі e-Health, із зазначенням дати та часу запиту, користувача та ЗОЗ від імені яких виконано запит, контексту запиту.
- Можливість виконання будь-якої дії користувачем, надання доступу до ресурсу чи даних, регулюється сукупністю:
- ролей та скоупів, зазначених для ролі (Scopes model#Rolesscopes)
- конфігурації, яка визначає набір даних, які дозволено відображати у Patient Summary
- поточних значень параметрів користувача, ЗОЗ, та атрибутів сутностей, до яких виконується запит згідно правилам доступу за атрибутами
- обмежень, та валідацій, діючих на рівні кожного API
- (підлягяє уточненню та реалізації у наступних етапах проекту) обмежень на доступ до інформації на підставі:
- законодавства (наприклад, mental diseases)
- рішення пацієнта закрити доступ до безумовного доступу до даних (Patient Summary) та/або до конкретних епізодів (що також може впливати на склад Patient Summary)
Правила доступу за атрибутами
- Завжди: ЗОЗ, від імені якого виконується запит, повинне бути активним
- Завжди: Користувач, від імені якого виконується запит, повинен бути активним
- Завжди: У користувача, повинен бути хоча б один активний співробітник у ЗОЗ
- Якщо наведені вище правила виконуються, доступ визначається наступним чином:
...
7 - доступ є
8 - доступу немає
Деталізація правил
Даний розділ деталізує правила, описані в попередньому розділі та містить інструкції по імплементації цих правил
Є активна декларація з пацієнтом
Не реалізовується правилами на ABAC. Реалізовується на IL
Користувач та ресурс належать до одного закладу
Не реалізовується правилами на ABAC. Реалізовується на IL
Ланка користувача що звертається до ресурсу та ланка користувача що створив ресурс (володіє ресурсом) співпадають
Ланка - рівень медичних послуг які виконує лікар (медичний працівник, що зареєстрований у системі eHealth)
Ланка визначається виходячи зі спеціальності співробітника
| Code Block | ||
|---|---|---|
| ||
PRM.employee.speciality ->> 'speciality' |
Маємо наступні ланки (рівні) медичних послуг:
| № | Ланка | Спеціальності |
|---|---|---|
| 1 | Первинна медична допомога |
|
| 2 | Вторинна (спеціалізована) медична допомога | TBD |
| 3 | Третинна (високоспеціалізована) медична допомога | TBD |
| 4 | Паліативна допомога | TBD |
| 5 | Медична реабілітація | TBD |
Визначення ланки для користувача
Користувач має доступ до ресурсу через направлення
Відкриті питання
| Question | Answer |
|---|---|
Чи є обмеження, за яких пацієнт не зможе виключити епізод з доступних для перегляду будь-ким (наприклад, соціально-небезпечні хвороби)? | Так |
Яким чином необхідно подовжувати права доступу, які вже не дійсні? | Оскільки обрано модель регулювання доступів ABAC, права доступу припиняють дію одразу ж, як перестають діяти умови, які ці права надавали. |
| Яким чином відокремити лікарів первинної ланки від лікарів вторинної ланки для надання доступів (працюють у одному чи різних ЗОЗ)? | Ланка лікаря визначається виходячи з спеціальності за посадою на Employee PRM.employee.speciality ->> 'speciality' |
| Яким чином надавати права доступу, якщо пацієнт сам не в змозі це зробити? | |
| Як визначати ланку для направлення? |
...