Стандарти Ehealth Suisse та архітектурні рекомендації IV (проект) спілкування між
ehealth Suisse Standards and Architecture Рекомендації IV (проект) Спілкування між громадами/портал доступу Доповідь для слухання Берн, 16 серпня 2012 р.
Page 2 1 Початкова ситуація. 3 1.1 Вступ. 3 1.2 Розмежування. 4 1.3 Умови. 5 2 Центральні компоненти та послуги. 8 3 Спілкування між громадами. 12 3.1 Загальні принципи. 12 3.2 Концепція дозволу. 13 4 Аудит та повідомлення. 16 5 Портал доступу. 19 6 Технічні рекомендації. 23 6.1 Технічні рекомендації щодо центральних компонентів та послуг. 23 6.2 Технічні рекомендації щодо ідентифікації та автентифікації. 6.3 Технічні рекомендації щодо концепції авторизації. 6.4 Технічні рекомендації щодо аудиту та повідомлення. 25 7 Підсумкові зауваження. 27 Додаток 1: Відповідні основи архітектури. 29 Додаток 2: Атрибути ComReg (Довідник громад). 31
Сторінка 5 між різними ступенями зрілості гарантована. Рекомендації I-IV від ehealth Suisse обмежені рівнем зрілості 2. Наразі неможливо оцінити, коли буде оголошено рівень зрілості 3. Її вже можна знайти тут і там в установах та організаціях, але поки що не через організаційні межі. Рисунок 2: Модель зрілості еволюція охорони здоров’я 1.3 Терміни Громада - це організаційна одиниця осіб, які здійснюють догляд, громада 1. бере участь у лікуванні пацієнтів, 2. створює та використовує інформацію, пов’язану з пацієнтами, та 3. обмінюється інформацією, пов’язаною з пацієнтами, з іншими громадами. Співпраця в межах громади повинна регулюватися договором та вимагати юридичної форми. Окремі практики можуть належати до кількох спільнот. Визначення не містить жодних вимог щодо розміру, географічного розмежування чи організаційної структури громади. Наступний перелік містить інформацію про можливі форми спільнот: Асоціація практикуючих з різних категорій (наприклад, лікарські практики, фізіотерапевти, лікарні) в регіоні для формування мережі допомоги, також через кантонні кордони
Page 9 Рисунок 3: Простір довіри EPD та центральні компоненти/послуги У порівнянні з рекомендаціями III (див. Сторінку 12, рекомендація 3), порталам зовнішнього доступу також дозволено обмінюватися інформацією шляхом читання. Крім того, технічний проект визначається з необхідними атрибутами. Кожне сертифіковане співтовариство та кожен зовнішній портал доступу повинні бути введені в каталог. Він працює лише з дійсними сертифікованими спільнотами та порталами зовнішнього доступу. Запис у довіднику та ведення записів здійснюються централізовано. Усю необхідну інформацію в каталозі можна знайти в Додатку 2 Атрибути ComReg ". Рекомендація 3 Центральний каталог спільнот та зовнішні портали доступу Для здійснення контролю доступу до даних пацієнта чітко визначені лікуючі особи повинні бути призначені на одну або кілька затверджених ролей. Для чіткої ідентифікації з Для іншої важливої інформації, наприклад, про професійну групу та кваліфікацію, потрібна служба швейцарського індексу охорони здоров’я (послуга HPI).
Page 11 Служба каталогів метаданих повинна бути доступною як окрема центральна служба. Адміністрація цього каталогу повинна бути узгоджена по всій Швейцарії. Рекомендація 7 Центральна служба каталогів метаданих
Для контролю доступу спочатку слід здійснити перевірку ідентичності в запитуючому співтоваристві (технічно в ініціюючому шлюзі), наступна перевірка авторизації відповідає відповідаючому співтовариству (технічно в відповідаючому шлюзі). Для перевірки авторизації набір атрибутів прав пацієнта повинен бути прочитаний із основного співтовариства та оцінений. Як показано на малюнку 4, існує розподілене управління людьми та доступом (управління ідентифікацією та доступом). Перевірка прав доступу Рисунок 4: Розподілена ідентифікація та управління доступом та атрибути прав в основному співтоваристві Перевірка авторизації якомога раніше представляється розумною, оскільки можна уникнути зайвих подальших дій. Крім того, дострокове застосування дозволів зменшує неправильне розповсюдження конфіденційних даних. Однак не всі способи доступу можна вирішити заздалегідь. При доступі до реєстру документів авторизація може бути здійснена лише після доступу, оскільки кожен результат пошуку повинен перевірятися індивідуально. Однак під час доступу до сховища документів перевірку слід проводити перед доступом.
В основному, доступ повинен перевірятися якомога раніше щодо дозволів. Спільнота видавців як власник даних вирішує, чи є необхідні дозволи. Рекомендація 13 Рання перевірка прав доступу
Сторінка 18 Пацієнт може вибрати інтервал для підведення підсумків подій (щодня, щотижня, щомісяця). Він також може змінити заданий рівень конфіденційності і, таким чином, також надати доступ лікуючим особам. Аудиторські записи (наприклад, зміна прав, заява про звільнення) повинні зберігатися необмежений час з міркувань простежуваності. Вони можуть бути актуальними для судових та юридичних питань через багато років після події. Однак пацієнт може будь-коли вимагати, щоб документи відповідного типу документа більше не відображалися. Термін зберігання документів, орієнтованих на пацієнта (включаючи документи протоколу), визначений законодавством.
Сторінка 22 Сертифіковані портали доступу відповідають HONcode фонду «Здоров’я в мережі»: стандарти, принципи та рекомендації щодо якості медичної інформації, доступності та зручності користування порталом доступу повинні враховуватися у всіх процесах. Рекомендація 22 Сертифікація HONcode. Порталами доступу слід користуватися без обмежень усіма пацієнтами, незалежно від їх фізичних або технічних можливостей. З метою оптимізації безбар’єрного доступу до порталу, як це потрібно для сертифікації HONcode, рекомендується дотримуватися рекомендацій Консорціуму Всесвітньої павутини (W3C) щодо безбар’єрного веб-вмісту (WCAG) 2.0 та агента користувача (веб-браузер, медіаплеєр) Вказівки, яких слід дотримуватися. Провайдери порталу можуть використовувати доступність як відмінну функцію. Рекомендація 23 Доступність
Шлюз, що відповідає, перевіряє вміст наданих ідентифікаційних даних та атрибутів (через твердження SAML від IHE: XUA) з діючими на даний момент повноваженнями, і таким чином може приймати рішення щодо доступу або відмови. Таким чином, Responding Gateway стає Точкою забезпечення доступу, яка вирішує між спільнотами, дозволена транзакція чи ні. Взаємозв'язок між розподіленими ідентифікаційними даними та управлінням доступом (IAM) та Точкою забезпечення доступу показаний схематично на рисунку 6. Рекомендація 30 Перевірка авторизації за допомогою шлюзу-відповіді Рисунок 6: Взаємодія в концепції авторизації 6.4 Технічні рекомендації Аудит та повідомлення Профіль IHE ATNA (Аутентифікація аудиту та вузла) визначає, як захищають хости, як і яку інформацію вони реєструють. Журнали аудиту, створені в рамках ATNA, мають точну деталізацію і дуже технічні. ATNA обмежується доменом спорідненості до IHE "і не визначає жодного доступу між спільнотами. Впровадження з профілями IHE Оскільки всі системи та додатки, що беруть участь, мають часові залежності, і їх події повинні реєструватися з надійними часовими позначками, їх час повинен бути синхронізований.
Page 26 Сертифіковані спільноти синхронізують свої системи згідно з профілем інтеграції IHE Рекомендація 31 Консистентний час (CT) 31 Синхронізація часу відповідно до IHE: Сертифіковані спільноти CT реєструють події тригера відповідно до аудиторської перевірки профілю інтеграції IHE та автентифікації вузла (ATNA) у локальному системному журналі. Рекомендація 32 ініціювати події згідно з IHE: ATNA