Преминете към основното съдържание

Управление на достъпа за изследвания в болничната система

LOSPOR Hospital разделя оперативните правомощия от правото на достъп до изследователски данни. Системният администратор управлява разрешенията от /status/control след вход с независимата парола за страницата за състояние. Страницата не получава клиничен JWT, редове със случаи, резултати от кохорти или файлове за износ.

Кой може да получи разрешение​

Изрично разрешение може да получи активен (потвърден имейл и неизтрит профил) клиницист, началник на отделение или администратор. Профилът RESEARCH_ONLY също се нуждае от разрешение и остава изключен от клиничните екрани.

Администраторът запазва съществуващия глобален обобщен изглед с потискане на малките клетки. Това не дава право за преглед на отделни случаи, CSV/JSON или OMOP износ, споделяне или управление на разрешения от Browser. Ролята на началник или клиницист сама по себе си не дава изследователски достъп. Изричното разрешение се прилага и за администратор, а подробният и експортният обхват остават точно посочените в него.

Непроменими подробни разрешения​

Всяко разрешение съдържа една конкретна цел, точно едно лечебно заведение или всички лечебни заведения, срок и отделни права за:

  • обобщени справки;
  • преглед на псевдонимизирани случаи;
  • CSV износ;
  • JSON износ;
  • OMOP износ; и
  • споделяне на кохорти в лечебното заведение.

Срокът по подразбиране е 90 дни, а максималният е 365 дни. OMOP изисква и съответното CSV или JSON право. Споделянето изисква право за справки. Базата данни проверява комбинациите. След издаване не могат да се променят правата, целта, обхватът, притежателят, издателят или срокът.

Промяна се прави чрез ново заместващо разрешение от страницата за състояние. Старото става окончателно и сочи новото. Отмяната също е окончателна и изисква причина. Промяната и одитният запис се записват в една транзакция.

Точно одобрение за OMOP​

Заявката за OMOP първо замразява дефиницията на кохортата, обхвата, ревизиите, броя случаи, целта, формата и единственото действащо разрешение за целия обхват. За няколко лечебни заведения е нужно едно разрешение за всички; тесни разрешения не се обединяват скрито.

Работният процес не взема заявката, докато страницата за състояние не одобри точно този набор. Одобрението е свързано с идентификаторите на износа, заявителя и разрешението, целта и формата, SHA-256 на дефиницията и моментната снимка и броя случаи. PostgreSQL проверява целия набор, точния формат, обхвата и действащото разрешение. Одобрението не може да се променя или изтрива. Работният процес и изтеглянето проверяват отново всичко; отмяна, замяна или изтичане спира обработката и достъпа.

Граници и проверки​

Управлението през Browser (/v1/research/grants) връща 404 в Hospital. Частните маршрути /v1/internal/hospital/control-plane връщат 404 извън Hospital, затова онлайн демонстрацията не може да покаже тези функции. Частният токен е достъпен само за API и Status и не дава общ достъп до API.

Има тестове за миграцията, маршрутите, обхватите, повторното потвърждение с парола, безопасните отговори и по желание PostgreSQL тригерите.

Пълният Web Playwright release suite вече доказва реалната промяна на достъпа за началник на отделение: отказ без разрешение, издаване през private Status control route на aggregate-only достъп за едно лечебно заведение, успешна обобщена справка при продължаващ отказ за преглед на случаи, отмяна с причина и незабавен отказ при следващата заявка. Определеният test appliance operator и bearer съществуват само в disposable E2E database/configuration.