Funkcjonalność systemów EDM

System Elektronicznej
Dokumentacji Zdrowotnej
Model Funkcjonalny
PN-EN ISO 10781:2011
Krzysztof Nyczaj
ekspert Izby Gospodarczej Medycyna Polska,
konsultant w Gabinecie Prezesa Głównego Urzędu Statystycznego
dziennikarz tygodnika Służba Zdrowia
Uwierzytelnianie
•
Polecenie: Uwierzytelnić użytkowników
Systemu EHR i/lub podmioty przed
umożliwieniem dostępu do Systemu EHR.
•
•
•
•
System MUSI uwierzytelniać podmioty przed
ich dostępem do aplikacji lub danych
systemu EHR.
System MUSI zapobiegać dostępowi do
aplikacji lub danych systemu EHR przez
wszystkie podmioty nieuwierzytelnione
System POWINIEN zapewniać możliwość
implementacji wszelkich mających
zastosowanie uzgodnień dotyczących
Łańcuchów Zaufania.
JEZELI brak odpowiednich mechanizmów
uwierzytelniania, TO system MUSI
uwierzytelniać podmioty wykorzystując co
najmniej jeden z następujących
mechanizmów uwierzytelniania: nazwa
użytkownika/hasło, certyfikat cyfrowy,
bezpieczny token lub biometria.
Autoryzacja (1)
•
•
•
•
•
Użytkownicy Systemu EHR są autoryzowani do wykorzystania komponentów Systemu EHR
zgodnie z ich tożsamością, rolą, przydziałem prac, lokalizacją i/lub bieżącym stanem pacjenta
oraz zakresem praktyki Użytkownika Systemu EHR wynikającym z prawa jurysdykcji.
Autoryzacja oparta na tożsamości Użytkownika odnosi się do zezwoleń przyznanych lub
odmówionych na podstawie tożsamości osoby. Przykładem autoryzacji opartej na tożsamości
Użytkownika jest określona przez pacjenta odmowa dostępu do całości lub części
dokumentacji określonej stronie z przyczyn związanych z prywatnością. Innym przykładem
autoryzacji opartej na tożsamości użytkownika jest dostęp urządzenia tele-monitoringu lub
robota do Systemu EHR w celu pozyskania danych o przepisanych wskazaniach i innych
danych wejściowych.
Autoryzacja oparta na rolach odnosi się do odpowiedzialności lub funkcji wykonywanej w
określonym działaniu lub procesie. Przykładowe role obejmują: aplikację lub urządzenie
((tele-monitor lub robot); lub pielęgniarkę, dietetyka, administratora, opiekuna prawnego i
audytora.
Autoryzacja Kontekstowa jest określona w normie ISO 10181-3 – Techniczne Podstawy
Normy Kontroli Dostępu – jako stosowne dla bezpieczeństwa własności kontekstu, w którym
występuje żądanie dostępu, bezpośrednio podany czas, lokalizacja, trasa dostępu i jakość
uwierzytelniania. Na przykład, System EHR mógłby tylko umożliwiać autoryzację kontekstową
nadzorujących świadczeniodawców w celu poświadczania wpisów proponowanych przez
rezydentów będących pod ich nadzorem.
Przykładem opartym na kontekście jest autoryzacja przyznana przez pacjenta określonej
trzeciej stronie na ograniczony okres czasu do przeglądania określonych zapisów EHR. Innym
przykładem jest prawo, przyznane na ograniczony okres czasu, do przeglądania tych, i tylko
tych zapisów EHR, które są związane z określonym tematem badań.
Autoryzacja (2)
•
•
•
•
•
•
•
System MUSI zapewniać możliwość tworzenia i aktualizacji zbiorów zezwoleń
kontroli dostępu przyznanych podmiotowi.
System MUSI być zgodny z funkcją IN.2.2 (Dokumentacja Podlegająca
Audytowi) dla potrzeb dokumentacji wszystkich działań autoryzacyjnych.
System MUSI zapewniać administratorom bezpieczeństwa Systemu EHR
możliwość przyznawania autoryzacji podmiotom zgodnie z zakresem
zastosowania, polityką organizacyjną lub prawem jurysdykcji.
System MUSI zapewniać administratorom bezpieczeństwa Systemu EHR
możliwość przyznawania autoryzacji dla ról zgodnie z zakresem zastosowania,
polityką organizacyjną lub prawem jurysdykcji.
System MUSI zapewniać administratorom bezpieczeństwa Systemu EHR
możliwość przyznawania autoryzacji kontekstowej zgodnie z zakresem
zastosowania, polityką organizacyjną lub prawem jurysdykcji.
System MOŻE zapewniać możliwość definiowania kontekstu dla potrzeb
autoryzacji podmiotu w oparciu o tożsamość, rolę, przydział pracy, bieżący
stan, lokalizację, zgodę pacjenta lub bieżący stan pacjenta
System MOŻE zapewniać możliwość definiowania kontekstu w oparciu o
wymagania prawne lub warunki chorobowe.
Kontrola Dostępu dla Podmiotu
• System MUSI być zgodny z funkcją IN.1.1 (Uwierzytelnianie
Podmiotu).
• System MUSI być zgodny z funkcją IN.1.2 (Autoryzacja Podmiotu).
• System MUSI zapewniać możliwość definiowania reguł dostępu do
systemu i danych.
• System MUSI egzekwować reguły dostępu do systemu I danych dla
wszystkich zasobów Systemu EHR (na poziomie komponentu,
aplikacji lub użytkownika, lokalnie albo zdalnie).
ZARZĄDZANIE DOSTĘPEM PACJENTA
•
•
Organizacja świadcząca ochronę zdrowia
będzie miała możliwość zarządzania
możliwością przeglądania przez pacjenta
swojej elektronicznej dokumentacji
medycznej w oparciu o zakres zastosowania,
politykę organizacyjną lub prawo jurysdykcji.
W typowym przypadku pacjent ma prawo
przeglądać swoją elektroniczną
dokumentację medyczną oraz prawo
nakładania ograniczeń na to, kto może
przeglądać części lub całość tej dokumentacji.
Na przykład, w pewnych systemach prawnych
mniejszości mają prawo do ograniczania
rodzicom/opiekunom dostępu do swoich
danych.
Jednym z przykładów zarządzania dostępem
pacjenta do swoich danych jest rozszerzenie
kontroli dostępu użytkowników na
pacjentów.
•
System MUSI być zgodny z funkcją IN.1. 3
(Kontrola Dostępu dla Podmiotu) w celu
umożliwienia organizacji świadczącej
ochronę zdrowia zarządzania dostępem
pacjenta do swoich informacji związanych z
ochroną zdrowia.
NIEZAPRZECZALNOŚĆ
•
•
•
•
Opis: System EHR umożliwia wprowadzanie danych i
dostęp do danych w elektronicznej dokumentacji
zdrowotnej pacjenta, a może to być dokonane przez
nadawcę lub odbiorcę informacji dotyczącej
ochrony zdrowia. Niezaprzeczalność gwarantuje, że
źródło zapisu danych nie może później zaprzeczyć,
że jest źródłem; że nadawca lub odbiorca
komunikatu nie może późnij zaprzeczyć, że wysłał
lub odebrał komunikat. Niezaprzeczalność może być
osiągnięta przez zastosowanie:
podpisu cyfrowego, służącego jako niepowtarzalny
identyfikator osoby (podobnie jak podpis
własnoręczny na dokumencie papierowym),
usługi potwierdzania, wykorzystującej agenta
przesyłającego komunikat do tworzenia cyfrowego
dowodu (dostarczając potwierdzenia, że komunikat
został wysłany i/lub odebrany) i
znakowania czasem, które dowodzi, że dokument
istniał w pewnym dniu i o pewnej godzinie.
•
•
•
•
System MUSI znakować czasem początkowy wpis,
modyfikację lub wymianę danych, oraz
identyfikować aktora/podmiot biorącego w tym
udział zgodnie z wymaganiami zakresu
zastosowania przez użytkowników, polityki
organizacyjnej i prawa jurysdykcji.
System MUSI zapewniać dodatkową funkcjonalność
niezaprzeczalności tam, gdzie jest to wymagane
przez zakres zastosowania przez użytkowników,
politykę organizacyjną i prawo jurysdykcji.
System MOŻE być zgodny z funkcją IN 2.2
(Dokumentacja Podlegająca Audytowi) w celu
zapobiegania zaprzeczaniu pochodzenia, otrzymania
lub dostępu do danych.
System MOŻE być zgodny z funkcją IN.1.8
(Poświadczanie Informacji) w celu zapewnienia
integralności wymiany danych i dzięki temu
zapobiegania zaprzeczaniu pochodzenia lub
otrzymania danych.
BEZPIECZNA WYMIANA DANYCH
•
•
Opis: Jeśli kiedykolwiek następuje wymiana
informacji EHR, to wymaga to
odpowiedniego uwzględniania
bezpieczeństwa i prywatności, włącznie z
zaciemnianiem danych, a także
uwierzytelnianiem przeznaczenia i źródła,
jeśli jest to konieczne. Na przykład, może być
konieczne szyfrowanie danych wysyłanych do
zdalnych lub zewnętrznych miejsc
przeznaczenia.
Bezpieczna wymiana danych wymaga, by
istniała całkowita koordynacja dotycząca
informacji wymienianej między podmiotami
Systemu EHR, a także tego, jakiego przebiegu
wymiany się oczekuje. Polityki stosowane w
różnych lokalizacjach muszą być spójne lub
wzajemnie zgodne w celu zapewnienia , że
informacja jest chroniona podczas
przekraczania granicy między podmiotami w
Systemie EHR lub zewnętrznymi w stosunku
do tego systemu.
•
•
•
•
•
System MUSI zabezpieczać wszystkie tryby
wymiany danych EHR.
System POWINIEN być zgodny z IN.1.7
(Bezpieczne Przekazywanie Danych).
System MOŻE zapewniać możliwość
zaciemniania danych.
System MUSI szyfrować i deszyfrować dane
EHR wymieniane niezabezpieczonym łączem.
JEŻELI do bezpiecznej wymiany danych
wykorzystywane jest szyfrowanie, TO system
MUSI wspierać oparte na normach
szyfrowanie zgodnie z polityką organizacyjną
lub prawem jurysdykcji.
BEZPIECZNE PRZEKAZYWANIE DANYCH (1)
•
•
•
•
System EHR potrzebuje zapewnienia, że jest to wymiana informacji EHR z podmiotami
(aplikacjami, instytucjami, katalogami), których się spodziewa. Ta funkcja zależy od autoryzacji i
uwierzytelniania podmiotów dostępnych w systemie.
Przykładowo, aplikacja zarządzająca praktyką lekarską w Systemie EHR mogłaby wysłać
informację dołączoną do roszczenia do podmiotu zewnętrznego. Aby tego dokonać, aplikacja
musi zastosować metodę bezpiecznego przekazywania zapewniającą, że zarówno strona
wysyłająca, jak i odbierająca są autoryzowane do uczestnictwa w wymianie informacji.
Znane źródła i miejsca przeznaczenia można ustanowić podczas statycznego ustawiania lub mogą
one być określone dynamicznie.
Przykładami statycznego ustawiania są: rejestrowanie adresów IP lub nazw DNS. Dla
dynamicznego określania znanych źródeł i miejsc przeznaczenia systemy mogą wykorzystać
mechanizmy uwierzytelniania opisane w IN.1.1. Przykładowo:
–
–
•
wysłanie zlecenia badań laboratoryjnych z Systemu EHR do systemu laboratoryjnego w tej samej
organizacji można wykorzystać proste statyczne ustawianie dla przekazywania,
wysłanie zlecenia badań laboratoryjnych do referencyjnego laboratorium poza organizacją będzie
wymagało pewnego rodzaju procesu uwierzytelniania.
Ogólnie, gdy wykorzystywana infrastruktura sieciowa jest bezpieczna (np. bezpieczna sieć LAN
lub VPN), wtedy stosuje się proste statyczne ustawianie.
BEZPIECZNE PRZEKAZYWANIE DANYCH (2)
• System MUSI automatycznie przekazywać
elektronicznie wymieniane dane EHR tylko od i do
znanych źródeł i miejsc przeznaczenia i tylko
bezpiecznymi sieciami.
• System POWINIEN przekazywać elektronicznie
wymieniane dane EHR tylko od i do uwierzytelnionych
źródeł i miejsc przeznaczenia (być zgodny z funkcją
IN.1.1 (Uwierzytelnianie Podmiotu)).
• System POWINIEN być zgodny z funkcją IN 2.2
(Dokumentacja Podlegająca Audytowi) w celu
dostarczania informacji dla potrzeb audytu dotyczącej
uzupełnień i zmian w statusie miejsc przeznaczenia i
źródeł.
POŚWIADCZANIE INFORMACJI
•
•
•
•
Celem poświadczania jest wskazanie autorstwa oraz
przydzielenie odpowiedzialności za działanie,
zdarzenie, warunek, stan, opinię lub diagnozę.
Każdy wpis w dokumentacji zdrowotnej musi być
zidentyfikowany na podstawie jego autora i nie
powinien być wykonany lub podpisany przez kogoś
innego niż autor. (Uwaga: Transkrypcjonista może
transkrybować zapisy autora, zaś lekarz naczelny
może poświadczyć dokładność czyjegoś
oświadczenia dotyczącego zdarzenia.)
Poświadczanie jest wymagane dla (papierowych lub
elektronicznych) wpisów, takich jak uwagi opisowe
lub o postępie, oceny, diagramy przepływowe i
zamówienia.
W implementacji poświadczeń dokumentów można
stosować podpisy cyfrowe. Jeżeli do dokumentu
przychodzącego jest dołączony zapis
poświadczający, to jest on przechowywany.
Funkcjonalność poświadczania musi spełniać normy
i wymagania prawne, nadzoru i inne mające
zastosowanie.
•
•
•
•
•
•
•
System MUSI być zgodny z funkcją IN.1.1
(Uwierzytelnianie Podmiotu).
System MUSI być zgodny z funkcją IN.1.2
(Autoryzacja Podmiotu).
System MUSI zapewniać możliwość powiązania
każdej poświadczonej treści dodanej lub zmienionej
w EHR z autorem tej treści (na przykład będąc
zgodnym z funkcją IN.2.2 (Dokumentacja
Podlegająca Audytowi).
System MUSI zapewniać możliwość poświadczania
treści EHR podlegającej poświadczaniu przez autora
tej treści.
System MUSI wskazywać status podlegających
poświadczaniu danych, które nie zostały
poświadczone.
System MOŻE zapewniać możliwość poświadczania
treści EHR przez właściwie uwierzytelnionych i
autoryzowanych użytkowników nie będących
autorem, zgodnie z wymaganiami zakresu
zastosowania przez użytkowników, polityki
organizacyjnej i prawa jurysdykcji.
System MOŻE zapewniać możliwość stosowania
podpisów cyfrowych jako środków poświadczania.
PRYWATNOŚĆ I POUFNOŚĆ PACJENTA
•
•
•
•
•
•
•
•
•
System MUSI być zgodny z funkcją IN.1.1 (Uwierzytelnianie Podmiotu).
System MUSI być zgodny z funkcją IN.1.2 (Autoryzacja Podmiotu).
System MUSI być zgodny z funkcją IN.1.3 (Kontrola Dostępu dla Podmiotu).
System POWINIEN być zgodny z funkcją IN.1.5 (Niezaprzeczalność).
System POWINIEN być zgodny z funkcją IN.1.6 (Bezpieczna Wymiana
Danych).
System POWINIEN być zgodny z funkcją IN 2.2 (Dokumentacja Podlegająca
Audytowi).
System MUSI zapewniać możliwość obsługiwania zmieniających się
poziomów poufności zgodnie z zakresem zastosowania przez użytkowników,
polityką organizacyjną i prawem jurysdykcji.
System MUSI zapewniać możliwość maskowania części elektronicznej
dokumentacji zdrowotnej (np. leków i leczenia, stanu, dokumentów
wrażliwych) w celu ochrony przed ujawnieniem zgodnie z zakresem
zastosowania przez użytkownika, polityką organizacyjną i prawem
jurysdykcji.
System MUSI zapewniać możliwość znoszenia maskowania w przypadkach
zagrożeń lub innych specyficznych sytuacjach, zgodnie z zakresem
zastosowania przez , polityką organizacyjną i prawem jurysdykcji.
PRZECHOWYWANIE, DOSTĘPNOŚĆ I NISZCZENIE DANYCH (1)
• Oddzielne i ustrukturyzowane dane, zapisy i sprawozdania
Systemu EHR muszą być:
– udostępniane użytkownikom we właściwym czasie;
– przechowywane i wyszukiwane w sposób rozumny i użyteczny (na
przykład, chronologicznie, retrospektywnie dla danej choroby lub
zdarzenia albo zgodnie z wymaganiami biznesowymi, lokalnymi
politykami lub wymaganiami prawnymi);
– przechowywane przez prawnie wyznaczony okres czasu;
– niszczone w systematyczny sposób zgodnie z mającym zastosowanie
okresem przechowywania.
• System EHR musi także pozwolić organizacji wskazywania
danych/zapisów przeznaczonych do zniszczenia oraz przeglądania i
akceptowania zniszczenia przed jego realizacją.
• W takim przypadku system powinien przekazując dokumentację
do innego podmiotu przekazać wraz z istniejącymi danymi
informację o dacie zniszczenia tej dokumentacji.
PRZECHOWYWANIE, DOSTĘPNOŚĆ I NISZCZENIE DANYCH (2)
•
•
•
•
•
•
•
•
System MUSI zapewniać możliwość przechowywania i wyszukiwania danych dokumentacji
zdrowotnej oraz dokumentów klinicznych przez prawnie wyznaczony okres czasu.
System MUSI zapewniać możliwość przechowywania przychodzących danych lub dokumentów
(związanych z dokumentacją zdrowotną) w oryginalnej otrzymanej formie (niezmienionej,
włącznie z metodą ich otrzymania) przez prawnie organizacyjnie wyznaczony czas, zgodnie z
zakresem zastosowania przez użytkowników, polityką organizacyjną i prawem jurysdykcji.
System MUSI przechowywać zawartość przychodzących danych (związanych z dokumentacją
zdrowotną) w oryginalnej otrzymanej formie przez prawnie wyznaczony czas.
System POWINIEN zapewniać możliwość wyszukiwania zarówno informacji, jak i danych
związanych z kontekstem biznesowym, w którym ta informacja została uzyskana.
System POWINIEN zapewniać możliwość wyszukiwania wszystkich elementów objętych definicją
legalnej dokumentacji zdrowotnej.
System MOŻE zapewniać możliwość wskazywania określonych danych/zapisów EHR do
zniszczenia, przeglądu i potwierdzenia zniszczenia przed jego realizacją, oraz implementowania
funkcji IN.2.2 (Dokumentacja Podlegająca Audytowi).
System MOŻE zapewniać możliwość niszczenia danych/zapisów EHR w taki sposób, by wszystkie
ślady były nieodwracalnie usunięte, zgodnie z polityką i prawnie określonymi okresami
przechowywania.
System POWINIEN przekazując dokumentację do innego podmiotu przekazywać wraz z
istniejącymi danymi informację o dacie zniszczenia tej dokumentacji..
DOKUMENTACJA PODLEGAJĄCA AUDYTOWI (1)
Opis: Funkcjonalność audytu obejmuje audyty bezpieczeństwa, audyty danych,
audyty wymiany danych oraz możliwość generowania sprawozdań z audytu.
Przykłady obszarów podlegających audytowi obejmują:
•
•
•
Audyt bezpieczeństwa, który rejestruje próby uzyskania dostępu i wykorzystania
zasobów, włącznie z rejestracją użytkownika, dostępem do plików, różnymi innymi
działaniami, oraz to, czy wystąpiły jakiekolwiek rzeczywiste lub zamierzone
naruszenia bezpieczeństwa
Audyt danych, rejestrujący kto, kiedy i za pomocą którego systemu utworzył,
zaktualizował, przetłumaczył, przeglądał, dokonywał wyciągu lub (jeżeli zezwala na
to polityka lokalna) usunął zapis z EHR. Dane audytu mogą odnosić się do danych
konfiguracyjnych systemu lub do danych klinicznych i zarządzających pacjenta
Audyt wymiany danych, rejestrujący wymiany danych między aplikacjami Systemu
EHR (na przykład dla aplikacji wysyłającej: rodzaj, historia i treść wymienianej
informacji); oraz informacje dotyczące przekształcania danych (na przykład
tłumaczenia słownikowe, szczegóły zdarzeń związanych z rejestracją, itp.)
DOKUMENTACJA PODLEGAJĄCA AUDYTOWI (2)
•
•
•
•
•
•
•
•
•
•
Sprawozdania z audytu powinny być elastyczne i być ukierunkowane na różne potrzeby
użytkownika. Na przykład, organ prawny może chcieć wiedzieć ilu pacjentów dany
świadczeniodawca leczył podczas zawieszenia jego licencji. Podobnie w niektórych przypadkach
może oczekiwać sprawozdania dotyczącego wszystkich, którzy modyfikowali lub przeglądali pewna
dokumentację pacjenta.
Ścieżki audytu bezpieczeństwa i danych są wykorzystywane do weryfikacji egzekwowania reguł
biznesowych, dotyczących integralności danych, bezpieczeństwa i kontroli dostępu
-Wymaga się ścieżek audytu systemu dla następujących zdarzeń:
>Ładowanie nowych wersji lub zmiany w systemie klinicznym;
>Ładowanie nowych wersji kodów i baz wiedzy;
>Pobieranie i odtwarzanie kopii zapasowych;
>Zmiana daty i czasu tam, gdzie system kliniczny to umożliwia;
>Archiwizacja wszelkich danych;
>Ponowna aktywacja zarchiwizowanej dokumentacji pacjenta;
>Wejście i wyjście z system klinicznego;
>Połączenia zdalnego dostępu, włącznie z wynikającymi z działań wspierających i utrzymujących
system
DOKUMENTACJA PODLEGAJĄCA AUDYTOWI (3)
•
•
•
•
•
•
•
•
•
•
•
•
System MUSI zapewniać możliwości audytu dla rejestracji próby uzyskania dostępu i wykorzystania systemów,
danych i zasobów organizacyjnych.
System MUSI być zgodny z funkcją IN.1.1 (Uwierzytelnianie Podmiotu).
System MUSI zapewniać możliwości audytu wskazujące znacznik czasu dla utworzenia obiektu lub danych.
System MUSI zapewniać możliwości audytu wskazujące znacznik czasu dla modyfikacji obiektu lub danych, zgodnie
z zakresem zastosowania przez użytkowników, polityką organizacyjną lub prawem jurysdykcji.
System MUSI zapewniać możliwości audytu wskazujące znacznik czasu dla pobierania informacji dotyczących
obiektu lub danych, zgodnie z zakresem zastosowania przez użytkowników, polityką organizacyjną lub prawem
jurysdykcji.
System MUSI zapewniać możliwości audytu wskazujące znacznik czasu dla wymiany obiektów lub danych.
System POWINIEN zapewniać możliwości audytu wskazujące znacznik czasu dla przeglądu obiektów lub danych.
System MUSI zapewniać możliwości audytu wskazujące znacznik czasu dla usuwania obiektów lub danych, zgodnie
z zakresem zastosowania przez użytkowników, polityką organizacyjną lub prawem jurysdykcji.
System MUSI zapewniać możliwości audytu wskazujące autora zmiany, zgodnie z zakresem zastosowania przez
użytkowników, polityką organizacyjną lub prawem jurysdykcji.
System POWINIEN zapewniać możliwości audytu wskazujące przeglądającego zbiór danych.
System MOŻE zapewniać możliwości audytu wskazujące wartości danych przed zmianą.
System MOŻE zapewniać możliwości audytu zbierania informacji o zdarzeniach w systemie na poziomie
architektury sprzętu i oprogramowania.
DOKUMENTACJA PODLEGAJĄCA AUDYTOWI (4)
•
•
•
•
•
•
•
•
•
•
•
•
•
System MUSI być zgodny z funkcją IN.1.3 (Kontrola Dostępu dla Podmiotu) w celu ograniczenia dostępu do
informacji w zapisach audytu do odpowiednich podmiotów, zgodnie z zakresem zastosowania przez
użytkowników, polityką organizacyjną lub prawem jurysdykcji.
System MUSI zapewniać możliwość generowania sprawozdania z audytu.
System MUSI zapewniać możliwość przeglądania historii zmian dla określonej dokumentacji lub zbioru danych,
zgodnie z zakresem zastosowania przez użytkowników, polityką organizacyjną lub prawem jurysdykcji..
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu i dotyczących
ładowania nowych wersji lub zmian w systemie klinicznym.
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu i dotyczących
ładowania nowych wersji kodów i baz wiedzy.
System POWINIEN zapewniać możliwość rejestrowania zmiany daty i czasy tam, gdzie system kliniczny to
umożliwia.
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu i dotyczących
tworzenia i odtwarzania kopii zapasowych.
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu dotyczących
archiwizacji wszelkich danych.
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu dotyczących
ponownej aktywacji zarchiwizowanej dokumentacji pacjenta.
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu dotyczących
wejścia i wyjścia z Systemu EHR.
System POWINIEN zapewniać możliwość rejestrowania zdarzeń związanych z utrzymaniem systemu dotyczących
połączeń zdalnego dostępu, włącznie z wynikającymi z działań wspierających i utrzymujących system.
System POWINIEN wykorzystywać utrzymywanie znormalizowanego czasu (na przykład stosując spójny profil czasu
IHE).
System POWINIEN zapewniać możliwość rejestrowania I sprawozdawania informacji dotyczących audytu stosując
oparty na normach format zapisu audytu (na przykład RFC 3881).
SYNCHRONIZACJA
•
•
•
System EHR może się składać ze zbioru
komponentów lub aplikacji; każda aplikacja
zarządza podzbiorem informacji ochrony
zdrowia.
Dlatego ważne jest, by za pomocą różnych
mechanizmów interoperacyjności System
EHR synchronizował wszystkie stosowne
informacje dotyczące dokumentacji
zdrowotnej. Na przykład, jeśli lekarz zleca
wykonanie obrazowanie rezonansu
magnetycznego, zostanie utworzony zbiór
obrazów diagnostycznych i sprawozdanie
radiologiczne.
Dane demograficzne pacjenta, zlecenie
wykonania MRI, obrazy diagnostyczne
związane ze zleceniem oraz sprawozdanie
związane z badaniem muszą być
zsynchronizowane w celu umożliwienia
pracownikom klinicznym przeglądu
kompletnej dokumentacji.
•
•
•
•
System MUSI być zgodny z funkcją IN.5.1
(Normy Dotyczące Wymiany Danych).
System MUSI być zgodny z funkcją IN.3
(Usługi Rejestrowe i Katalogowe) w celu
umożliwienia wykorzystania rejestrów i
katalogów.
System POWINIEN zapewniać możliwość
łączenia podmiotów iż informacjami
zewnętrznymi.
System POWINIEN przechowywać informację
o lokalizacji każdego znanego komponentu
dokumentacji zdrowotnej w celu
umożliwienia autoryzowanego dostępu do
kompletnej logicznej dokumentacji
zdrowotnej wtedy, gdy EHR jest rozproszona
pomiędzy kilka aplikacji w Systemie EHR.
Wyciąg Informacji z Dokumentacji Zdrowotnej
•
•
•
System EHR umożliwia uprawnionemu użytkownikowi,
takiemu jak pracownik kliniczny, dostęp I agregację
rozproszonej informacji odpowiadającej dokumentacji
zdrowotnej potrzebnej dla przeglądu, sprawozdawczości,
ujawniania, itp.
System EHR musi wspierać działania związane z wyciągiem
danych w stosunku do całego zbioru danych tworzących
dokumentację zdrowotną osoby i zapewniać dane wyjściowe
w pełni dokumentujące proces ochrony zdrowia.
Wyciągi danych są wykorzystywane jako dane wejściowe w
celu koordynacji świadczeń ochrony zdrowia pacjenta
pomiędzy miejscami, organizacjami i placówkami. Ponadto
wyciągi danych można wykorzystywać dla potrzeb
administracyjnych, finansowych, badawczych, analizy jakości i
publicznej ochrony zdrowia oraz w celu odtworzenia kopii
importowanych do różnych aplikacji EHR i umożliwienia
archiwizacji danych pacjenta.
•
•
•
•
•
•
•
•
•
•
•
System MUSI zapewniać możliwość sporządzania wyciągu
informacji z dokumentacji zdrowotnej.
System POWINIEN być zgodny z funkcją IN.1.6 (Bezpieczna
Wymiana Danych) w celu zapewnienia możliwości
bezpiecznej wymiany danych.
System POWINIEN zapewniać możliwość odpersonalizowania
uzyskanej z wyciągu informacji.
System POWINIEN być zgodny z funkcją IN.5.1 (Normy
Dotyczące Wymiany Danych) w celu umożliwienia uzyskania z
wyciągu danych w znormalizowanych formatach.
System POWINIEN zapewniać możliwość wykonania działań
związanych z wyciągiem danych w stosunku do całego zbioru
danych tworzących dokumentację zdrowotną osoby w
systemie.
System MOŻE zapewniać możliwość wykonania działań
związanych z wyciągiem, w których dane wyjściowe w pełni
dokumentują proces ochrony zdrowia.
System POWINIEN zapewniać możliwość sporządzania
wyciągu danych dla potrzeb administracyjnych.
System POWINIEN zapewniać możliwość sporządzania
wyciągu danych dla potrzeb finansowych.
System POWINIEN zapewniać możliwość sporządzania
wyciągu danych dla potrzeb badawczych.
System POWINIEN zapewniać możliwość sporządzania
wyciągu danych dla potrzeb analizy jakości.
System POWINIEN zapewniać możliwość sporządzania
wyciągu danych dla potrzeb publicznej ochrony zdrowia.
Przechowywanie i Zarządzanie Informacją
Dokumentacji Zdrowotnej (1)
•
•
•
•
•
Nieustrukturyzowana informacja z dokumentacji
zdrowotnej jest informacją nie podzieloną na
oddzielne pola I nie jest reprezentowana jako dane
numeryczne, wyliczeniowe ani zakodowane.
Ogólne przykłady nieustrukturyzowanej informacji
dokumentacji zdrowotnej obejmują:
- tekst
- dokument utworzony przez edytor tekstu
- obraz
- multimedia
•
•
•
•
•
•
Specyficzne przykłady obejmują:
- komunikat tekstowy dla lekarza
- fotografię pacjenta
- list od rodziny
- zeskanowany obraz legitymacji ubezpieczeniowej
- podyktowane sprawozdanie (zapis głosu)
•
•
•
•
•
•
•
•
•
•
Ustrukturyzowana informacja dokumentacji
zdrowotnej jest podzielona na oddzielne pola i może być
wyliczeniowa, numeryczna lub skodyfikowana.
Przykłady ustrukturyzowanej informacji dokumentacji
zdrowotnej obejmują:
- adres pacjenta (pole oddzielne, lecz nie skodyfikowane)
- rozkurczowe ciśnienie krwi (numeryczne)
- zakodowany rezultat obserwacji
- zakodowana diagnoza
- kwestionariusz oceny ryzyka pacjenta z odpowiedziami
wielokrotnego wyboru
Kontekst może określać czy dane są
nieustrukturyzowane, czy nie, np. notatka dotycząca
postępu mogłaby być znormalizowana i
ustrukturyzowana w pewnym Systemie EHR (np.
Subiektywna / Obiektywna / Ocena / Plan), lecz
nieustrukturyzowana w innych.
Zarządzanie danymi ochrony zdrowia obejmuje
zbieranie, pozyskiwanie, usuwanie, korygowanie,
poprawianie i uzupełnianie. Uzupełnianie odnosi się do
dostarczania dodatkowej informacji dotyczących danych
ochrony zdrowia, które same w obie nie są częścią
danych, np. łączenie zgody pacjenta lub autoryzacji z
danymi ochrony zdrowia pacjenta.
Przechowywanie i Zarządzanie Informacją
Dokumentacji Zdrowotnej
•
•
•
•
•
Nieustrukturyzowana informacja z dokumentacji
zdrowotnej jest informacją nie podzieloną na
oddzielne pola I nie jest reprezentowana jako dane
numeryczne, wyliczeniowe ani zakodowane.
Ogólne przykłady nieustrukturyzowanej informacji
dokumentacji zdrowotnej obejmują:
- tekst
- dokument utworzony przez edytor tekstu
- obraz
- multimedia
•
•
•
•
•
•
Specyficzne przykłady obejmują:
- komunikat tekstowy dla lekarza
- fotografię pacjenta
- list od rodziny
- zeskanowany obraz legitymacji ubezpieczeniowej
- podyktowane sprawozdanie (zapis głosu)
•
•
•
•
•
•
•
•
•
•
Ustrukturyzowana informacja dokumentacji
zdrowotnej jest podzielona na oddzielne pola i może być
wyliczeniowa, numeryczna lub skodyfikowana.
Przykłady ustrukturyzowanej informacji dokumentacji
zdrowotnej obejmują:
- adres pacjenta (pole oddzielne, lecz nie skodyfikowane)
- rozkurczowe ciśnienie krwi (numeryczne)
- zakodowany rezultat obserwacji
- zakodowana diagnoza
- kwestionariusz oceny ryzyka pacjenta z odpowiedziami
wielokrotnego wyboru
Kontekst może określać czy dane są
nieustrukturyzowane, czy nie, np. notatka dotycząca
postępu mogłaby być znormalizowana i
ustrukturyzowana w pewnym Systemie EHR (np.
Subiektywna / Obiektywna / Ocena / Plan), lecz
nieustrukturyzowana w innych.
Zarządzanie danymi ochrony zdrowia obejmuje
zbieranie, pozyskiwanie, usuwanie, korygowanie,
poprawianie i uzupełnianie. Uzupełnianie odnosi się do
dostarczania dodatkowej informacji dotyczących danych
ochrony zdrowia, które same w obie nie są częścią
danych, np. łączenie zgody pacjenta lub autoryzacji z
danymi ochrony zdrowia pacjenta.
Zarządzanie Nieustrukturyzowaną Informacją
Dokumentacji Zdrowotnej
•
•
•
•
•
•
•
•
•
System MUSI zbierać nieustrukturyzowaną informację dokumentacji zdrowotnej jako część EHR
pacjenta.
System MUSI wyszukiwać nieustrukturyzowaną informację dokumentacji zdrowotnej jako część
EHR pacjenta.
System MUSI zapewniać możliwość aktualizacji nieustrukturyzowanej informacji dokumentacji
zdrowotnej.
System MUSI być zgodny z funkcją IN.2.1 (Przechowywanie, Dostępność i Niszczenie Danych) w celu
zapewnienia możliwości deaktywacji, wycofywania z użycia lub niszczenia nieustrukturyzowanej
informacji dokumentacji zdrowotnej..
System POWINIEN zapewniać możliwość sporządzania sprawozdań dotyczących
nieustrukturyzowanej informacji dokumentacji zdrowotnej.
System MOŻE monitorować zmiany w czasie nieustrukturyzowanej informacji dokumentacji
zdrowotnej.
System MUSI zapewniać możliwość dodawania skorygowanej nieustrukturyzowanej informacji
dokumentacji zdrowotnej do oryginalnej nieustrukturyzowanej informacji dokumentacji
zdrowotnej. Nie zakłada się określonego rodzaju implementacji.
System MUSI zapewniać możliwość dodawania nieustrukturyzowanej informacji dokumentacji
zdrowotnej do oryginalnej nieustrukturyzowanej informacji dokumentacji zdrowotnej. Nie zakłada
się określonego rodzaju implementacji.
System MUSI zapewniać możliwość dodawania uzupełniającej nieustrukturyzowanej informacji
dokumentacji zdrowotnej do oryginalnej nieustrukturyzowanej informacji dokumentacji
zdrowotnej. Nie zakłada się określonego rodzaju implementacji.
Zarządzanie ustrukturyzowaną Informacją
Dokumentacji Zdrowotnej
•
•
•
•
•
•
•
•
•
•
System MUSI zbierać ustrukturyzowaną informację dokumentacji zdrowotnej jako część EHR
pacjenta.
System MUSI wyszukiwać ustrukturyzowaną informację dokumentacji zdrowotnej jako część EHR
pacjenta.
System MUSI zapewniać możliwość aktualizacji ustrukturyzowanej informacji dokumentacji
zdrowotnej.
System MUSI być zgodny z funkcją IN.2.1 (Przechowywanie, Dostępność i Niszczenie Danych) w celu
zapewnienia możliwości deaktywacji, wycofywania z użycia lub niszczenia ustrukturyzowanej
informacji dokumentacji zdrowotnej.
System POWINIEN zapewniać możliwość sporządzania sprawozdań dotyczących ustrukturyzowanej
informacji dokumentacji zdrowotnej.
System MOŻE śledzić zmiany w czasie ustrukturyzowanej informacji dokumentacji zdrowotnej.
System POWINIEN zapewniać możliwość wyszukiwania każdej pozycji ustrukturyzowanej informacji
dokumentacji zdrowotnej oddzielnie w kontekście pacjenta.
System MUSI zapewniać możliwość dodawania skorygowanej ustrukturyzowanej informacji
dokumentacji zdrowotnej do oryginalnej ustrukturyzowanej informacji dokumentacji zdrowotnej.
Nie zakłada się określonego rodzaju implementacji.
System MUSI zapewniać możliwość dodawania ustrukturyzowanej informacji dokumentacji
zdrowotnej do oryginalnej ustrukturyzowanej informacji dokumentacji zdrowotnej. Nie zakłada się
określonego rodzaju implementacji.
System MUSI zapewniać możliwość dodawania uzupełniającej ustrukturyzowanej informacji
dokumentacji zdrowotnej do oryginalnej ustrukturyzowanej informacji dokumentacji zdrowotnej.
Nie zakłada się określonego rodzaju implementacji.
Usługi Rejestrowe i Katalogowe (1)
•
•
•
Funkcje usług rejestrowych i katalogowych są krytyczne dla pomyślnego
zarządzania bezpieczeństwem, interoperacyjnością i spójnością danych
dokumentacji zdrowotnej w Systemie EHR. Te usługi umożliwiają łączenie
stosownych informacji z wielu źródeł informacji w Systemie EHR lub zewnętrznych
w stosunku do Systemu w celu ich wykorzystania w aplikacjach.
Katalogi i rejestry wspierająk omunikację między Systemami EHR i mogą być
zorganizowane hierarchicznie lub w sposób sfederowany. Na przykład, pacjent
leczony przez lekarza rodzinnego na chorobę chroniczną może zachorować podczas
nieobecności w mieście. System EHR nowego świadczeniodawcy odpytuje rejestr
lokalny, regionalny i krajowy w celu odnalezienia poprzedniej dokumentacji
pacjenta. Z dokumentacji utworzonej przez lekarza rodzinnego zdalny System EHR
pozyskuje stosowne informacje zgodnie z mającymi zastosowanie regułami
dotyczącymi prywatności pacjenta i poufności jego danych..
Przykładem wykorzystania lokalnego rejestru jest aplikacja Systemu EHR wysyłająca
zapytanie do Systemu Informatycznego Szpitala w celu pozyskania danych
demograficznych pacjenta.
Usługi Rejestrowe i Katalogowe (2)
•
•
•
•
•
•
•
•
•
•
•
•
•
System MUSI zapewniać możliwość wykorzystywania usług rejestrowych i katalogów.
System POWINIEN zapewniać możliwość bezpiecznego wykorzystywania usług rejestrowych i katalogów.
System MUSI być zgodny z funkcją IN.5.1 (Normy Dotyczące Wymiany Danych) w celu zapewnienia możliwości
wymiany znormalizowanych danych podczas wykorzystywania usług rejestrowych i katalogów.
System POWINIEN się komunikować z lokalnymi usługami rejestrowymi za pomocą znormalizowanych interfejsów.
System POWINIEN się komunikować z nielokalnymi usługami rejestrowymi (to znaczy z usługami rejestrowymi
zewnętrznymi w stosunku do Systemu EHR) za pomocą znormalizowanych interfejsów.
System POWINIEN zapewniać możliwość wykorzystywania rejestrów lub katalogów do jednoznacznej identyfikacji
pacjentów w celu zapewnienia świadczeń ochrony zdrowia.
System POWINIEN zapewniać możliwość wykorzystywania rejestrów lub katalogów do jednoznacznej identyfikacji
świadczeniodawców w celu zapewnienia świadczeńochrony zdrowia.
System MOŻE zapewniać możliwość wykorzystania rejestrów lub katalogów do wyszukania połączeń stosownych
dla informacji ochrony zdrowia dotyczącej pacjenta.
System MOŻE zapewniać możliwość wykorzystania rejestrów do dostarczenia połączeń stosownych dla informacji
ochrony zdrowia dotyczącej pacjenta.
System MOŻE zapewniać możliwość wykorzystania rejestrów lub katalogów do identyfikacji płatników, planów
ochrony zdrowia i sponsorów dla potrzeb administracyjnych i finansowych.
System MOŻE zapewniać możliwość wykorzystania rejestrów lub katalogów do identyfikacji pracodawców dla
potrzeb administracyjnych i finansowych.
System MOŻE zapewniać możliwość wykorzystania rejestrów lub katalogów do identyfikacji agencji publicznej
ochrony zdrowia dla potrzeb ochrony zdrowia
System MOŻE zapewniać możliwość wykorzystania rejestrów lub katalogów do identyfikacji zasobów i urządzeń
ochrony zdrowia dla potrzeb zarządzania zasobami.