System Elektronicznej Dokumentacji Zdrowotnej Model Funkcjonalny

1. System Elektronicznej Dokumentacji Zdrowotnej Model Funkcjonalny PN-EN ISO 10781:2011 Krzysztof Nyczajekspert Izby Gospodarczej Medycyna Polska, konsultant w Gabinecie Prezesa Głównego Urzędu Statystycznego dziennikarz tygodnika Służba Zdrowia

2. 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.

3. 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ń.

4. 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.

5. 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).

6. 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.

7. 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.

8. 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.

9. 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.

10. 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ł.

11. 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.

12. 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.

13. 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.

14. 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..

15. 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.)

16. 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

17. 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.

18. 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).

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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ąkomunikację 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.

26. 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.