Ehealth Suisse стандарти и архитектурни препоръки IV (проект) комуникация между
ehealth Suisse стандарти и архитектурни препоръки 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 Технически препоръки за концепцията за разрешение. 24 6.4 Технически препоръки за одит и уведомяване. 25 7 Заключителни бележки. 27 Приложение 1: Съответни основи на архитектурата. 29 Приложение 2: Атрибути ComReg (Директория на общностите). 31
Страница 5 между различните степени на зрялост е гарантирана. Препоръки I до IV от ehealth Suisse са ограничени до ниво на зрялост 2. Понастоящем не е възможно да се прецени кога ще бъде обявено ниво на зрялост 3. Вече може да се намери понякога в институции и организации, но все още не е извън организационните граници. Фигура 2: Зрял модел на развитие на здравеопазването 1.3 Условия Общността е организационна единица на болногледачите, общността 1. участва в лечението на пациенти и 2. създава и използва информация, свързана с пациента, и 3. обменя информация, свързана с пациента, с други общности. Сътрудничеството в рамките на една общност трябва да се регулира с договор и се изисква правна форма. Отделните практикуващи могат да принадлежат към няколко общности. Определението не съдържа никакви изисквания относно размера, географското разграничение или организационната структура на общността. Следният списък предоставя информация за възможните форми на общности: Асоциация на практикуващи от различни категории (напр. Лекарски практики, физиотерапевти, болници) в регион, за да се образува мрежа за грижи, също и през кантонните граници
Фигура 3: Пространство за доверие на EPD и централни компоненти/услуги В сравнение с препоръки III (вж. Стр. 12, препоръка 3), външните портали за достъп също имат право да обменят информация чрез четене. Освен това техническият проект е дефиниран с необходимите атрибути. Всяка сертифицирана общност и всеки външен портал за достъп трябва да бъдат въведени в директорията. Той работи само с валидни, сертифицирани общности и портали за външен достъп. Вписването в указателя и поддържането на записите се извършва централизирано. Цялата необходима информация в директорията може да бъде намерена в Приложение 2 Атрибути ComReg ". Препоръка 3 Централна директория на общностите и външни портали за достъп. За осъществяване на контрола на достъпа до данни на пациента, ясно идентифицираните лекуващи лица трябва да бъдат назначени на една или повече одобрени роли. За друга важна информация, като професионална група и квалификация, се изисква услуга за индекс на здравни професионалисти в Швейцария (HPI service).
Page 11 Услугата за справочници с метаданни трябва да бъде предоставена като отделна централна услуга. Администрацията на тази директория трябва да бъде координирана в цяла Швейцария. Препоръка 7 Услуга за справочник на централните метаданни
За контрол на достъпа първо трябва да се извърши проверка на самоличността в молещата общност (технически в иницииращия шлюз), а следващата проверка на оторизацията е отговорност на отговарящата общност (технически в отговарящия шлюз). За проверка на упълномощаването наборът от атрибути на правата на пациента трябва да бъде прочетен от основната общност и оценен. Както е показано на Фигура 4, има разпределено управление на хора и достъп (управление на самоличността и достъпа). Проверка на правата за достъп Фигура 4: Разпределена идентификация и управление на достъпа и атрибути на права в основната общност Проверката на оторизацията възможно най-рано изглежда разумна, тъй като могат да бъдат избегнати ненужни последващи действия. Освен това ранното прилагане на разрешения намалява неправилното разпространение на чувствителни данни. Не всички достъпи обаче могат да бъдат решени предварително. При достъп до регистър на документи, упълномощаването може да се извърши само след достъпа, тъй като всеки резултат от търсенето трябва да се проверява индивидуално. При достъп до хранилище на документи обаче проверката трябва да се извърши преди достъп.
Page 15 Достъпът винаги трябва да се проверява възможно най-рано по отношение на разрешенията. Издаващата общност като собственик на данни решава дали са налични необходимите разрешения. Препоръка 13 Ранна проверка на правата за достъп
Page 18 Пациентът може да избере интервала за обобщение на събитията (ежедневно, седмично, месечно). Той може също да промени предварително зададеното ниво на поверителност и по този начин също така да предостави достъп на лекуващите лица. Записите за одит (напр. Промяна на правата, декларация за оставка) трябва да се запазят за неопределено време поради съображения за проследимост. Те могат да бъдат от значение за съдебни или правни въпроси много години след събитието. Пациентът обаче може по всяко време да поиска документи от съответния тип документ да не се показват повече. Периодът на съхранение на центрирани към пациента документи (включително протоколни документи) е законово определен.
Page 22 Сертифицираните портали за достъп отговарят на HONcode на фондацията „Здраве в мрежата“: Стандартите, принципите и насоките за качеството на здравната информация, достъпността и удобството за ползване на портала за достъп трябва да бъдат взети предвид при всички процеси. Препоръка 22 HONcode сертифициране Порталите за достъп трябва да могат да се използват без ограничения от всички пациенти, независимо от техните физически или технически възможности. За да се оптимизира безпрепятственият достъп до портала, както се изисква за сертифициране на HONcode, се препоръчва насоките на World Wide Web Consortium (W3C) за безпрепятствено уеб съдържание (WCAG) 2.0 и потребителския агент (уеб браузър, медиен плейър) Указания, които трябва да се следват. Доставчиците на портала могат да използват достъпността като отличителна черта. Препоръка 23 Достъпност
Page 25 Responding Gateway проверява съдържанието на предоставената идентификация и атрибути (чрез твърдение SAML от IHE: XUA) с текущите валидни разрешения и по този начин може да вземе решение за достъп или отказ. По този начин Responding Gateway се превръща в Access Enforcement Point, който решава между общностите дали дадена транзакция е разрешена или не. Връзката между разпределената идентификация и управление на достъпа (IAM) и Access Enforcement Point е показана на фигура 6. Препоръка 30 Проверка на упълномощаването чрез Responding Gateway Фигура 6: Взаимодействие в концепцията за оторизация 6.4 Технически препоръки Одит и уведомяване Профилът IHE ATNA (Audit Trail and Node Authentication) определя как са защитени хостовете и как и коя информация регистрират. Ревизионните дневници, създадени като част от ATNA, имат фина детайлност и са много технически. ATNA е ограничена до IHE афинитетен домейн "и не дефинира никакъв достъп от различни общности. Внедряване с профили на IHE Тъй като всички участващи системи и приложения имат времеви зависимости и техните събития трябва да бъдат регистрирани с надеждни времеви печати, техните времена трябва да бъдат синхронизирани.
Page 26 Сертифицираните общности синхронизират своите системи в съответствие с профила за интеграция на IHE Постоянно време (CT) Препоръка 31 Синхронизиране на времето според IHE: Сертифицираните общности регистрират тригерните събития в съответствие с профила на интеграция на IHE Audit Trail and Node Authentication (ATNA) в локален системен дневник. Препоръка 32 задействащи събития според IHE: ATNA