Jak jest? Czyli kilka słów o stanie wdrażania Elektronicznej Dokumentacji Medycznej (EDM)

Podziel się

To zależy jak spojrzeć. Z perspektywy zainteresowanych tematem z pewnością nie za dobrze – ciągła zmiana harmonogramów, dat, sprzeczne informacje o etapach wdrożeń poszczególnych elementów mających uspójnić szeroko rozumiane zagadnienie Elektronicznej Dokumentacji Medycznej w Polsce. Chyba za dużo polityki. Ale w jaki sposób wyegzekwować ujednolicenie tak rozległego informatycznie obszaru, jak sprawić, żeby był porządek jeżeli samemu nie potrafi się tego zrobić we własnym podwórku? Ja wiem, koncepcje, przetargi, wymagania jednostek finansujących. Może w takim razie teraźniejsze podejście się sprawdzi.

Nie wszystko na raz

Zgodnie z opublikowanym 9 maja 2017 komunikatem dotyczącym regulacji prawnych w zakresie Elektronicznej Dokumentacji Medycznej “trwają prace legislacyjne dotyczące nowelizacji ustawy z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia, których celem jest m.in. doprecyzowanie definicji elektronicznej dokumentacji medycznej (EDM) oraz obowiązku stosowania Polskiej Implementacji Krajowej (PIK) HL7 CDA oraz formatów EDM, które będą publikowane w Biuletynie Informacji Publicznej Ministerstwa Zdrowia, a także zmiana terminów dotyczących obowiązku stosowania EDM”

Z konkretów natomiast są daty. I tak:

  1. e-recepta – obowiązek wystawiania recepty w postaci elektronicznej – od 1 stycznia 2020 r.;
  2. e-skierowanie – obowiązek wystawiania skierowania w postaci elektronicznej – od 1 stycznia 2021 r.;
  3. pozostała EDM (tj. dokumenty wskazane w rozporządzeniu wydanym na podstawie art. 13 ustawy):
    • obowiązek prowadzenia w postaci elektronicznej – od 1 stycznia 2019 r.;
    • obowiązek wymiany za pośrednictwem Platformy P1 – od 1 stycznia 2021 r.

Dla porządku w punkcie 3 dokumenty to: karta informacyjna leczenia szpitalnego, karta odmowy przyjęcia do szpitala, konsultacja lekarska, karta indywidualnej opieki pielęgniarskiej, opis badania diagnostycznego, sprawozdanie z badania laboratoryjnego, protokół operacyjny, wpis karty uodpornienia (zgodnie z linkiem). Na “pierwszy ogień” zatem idą głównie szpitale.

“Ponadto, projekt ustawy wyraźne przesądza (z uwagi na liczne wątpliwości), że EDM może być prowadzona i wymieniana również poza platformą P1″. Jestem w trakcie ustalania o co chodzi z tym zapisem ale w skrócie można sobie to wyobrazić tak, że wszystkie podmioty będą mogły wymieniać się danymi we własnym zakresie. Brzmi złowieszczo ale zobaczymy.

Uff  – znowu mamy czas. A pewnie i tak znowu to odłożą.. Najlepszy w tym wszystkim jest marketing firm wdrażających zarówno ogromne oprogramowanie jak i te najmniejsze – wszyscy są przygotowani w 100%. Szkoda, że ustawodawca nie i jeszcze nie wszystko jest określone 🙂

Lepiej jednak będzie zastosować taktykę pogodzenia się z losem – zarówno szpitale, jak i publiczne i prywatne przychodnie podstawowej opieki zdrowotnej czy specjalistyczne a także praktyki lekarskie na Elektroniczną Dokumentacje Medyczną przejdą. A im wcześniej tym lepiej. Wiele wątpliwości i błędów pewnie “wyjdzie w praniu” ale polska Służba Zdrowia naprawdę potrzebuje zakończenia czasów stosów segregatorów w przychodniach i starego komputera z jakimkolwiek systemem do rozliczania z NFZ pod nogami Pani z recepcji/rejestracji. A naprawdę często tak jeszcze jest.. Fakt, że dużo się zmienia (szczegółowo o tym w kolejnych wpisach) ale do zrobienia też jest ogromnie wiele. A trzymając się wersji aktualnej harmonogramu czasu wbrew pozorom nie ma dużo. Jest do wystarczająco na edukacje, zapoznanie z rynkiem i zrobienie wszystkiego w zgodzie z wymaganiami. I będzie to dużym udogodnieniem. Zresztą, nie tylko wprowadzenie samej Elektronicznej Dokumentacji Medycznej. Jest także niezliczona ilość rozwiązań IT, które mogą zostać wykorzystane w branży z korzyścią dla personelu, pacjentów i wszystkich na około.

0 Shares:
28 comments
  1. Pingback: help me essay
  2. Pingback: tadalafil for sale
  3. Pingback: viagra alternative
  4. Pingback: viagra price
  5. Pingback: viagra otc
  6. Pingback: drugs from canada
  7. Pingback: Cabgolin
  8. Pingback: viagra
Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

You May Also Like
Read More

Dofinansowanie NFZ na informatyzację POZ – szczegóły

Podziel się

Zgodnie z zamieszczonym 6 listopada Zarządzaniem Prezesa NFZ “w sprawie warunków rozliczania środków pochodzących z dotacji celowej z budżetu państwa na dofinansowanie zakupu urządzeń informatycznychi oprogramowania oraz kosztów niezbędnego szkolenia świadczeniodawców” możliwe stało się ubieganie o zwrot kosztów na informatyzację. Proces obwarowany jest kilkoma wymogami a maksymalna kwota zwrotu o jaką można się ubiegać to 3500 zł na “stanowisko lekarza”, maksymalnie na 4 stanowiska w placówce. Po Polsku – maksymalnie 14000 zł.

Pierwotnie pieniądze  były “konkretnie” na:

  • wydatki poniesione przez świadczeniodawców na zakup urządzeń informatycznych i oprogramowania oraz niezbędnego szkolenia świadczeniodawcy w 2018 r., pod warunkiem, że zostały sfinansowane ze środków własnych świadczeniodawcy, przed złożeniem wniosku o udzielenie dofinansowania
  • wydatki poniesione przez świadczeniodawców na szkolenia z zakresu kompetencji cyfrowych osób wystawiających zaświadczenia lekarskie i osób upoważnionych do wystawiania takich zaświadczeń

W związku z wieloma zapytaniami i niezgodnościami co do możliwości zwrotu poniesionych kosztów NFZ opublikował wczoraj komunikat dla świadczeniodawców POZ ubiegających się o dofinansowanie informatyzacji ze środków pochodzących z dotacji celowej z budżetu państwa gdzie precyzyjniej wskazano co autor w pierwotnym zarządzaniu miał na myśli. Cytując źródło:

“W związku z licznymi pytaniami kierowanymi do Narodowego Funduszu Zdrowia w zakresie prawidłowej kwalifikacji urządzeń informatycznych i oprogramowania do dofinansowania ze środków z dotacji celowej z budżetu państwa Narodowy Fundusz Zdrowia uprzejmie informuje:

Urządzenia informatyczne to:

  • maszyny przenośne do automatycznego przetwarzania danych o masie do 10 kg, tj.: laptopy, notebooki,
  • komputery kieszonkowe (np. notesy komputerowe) i podobne,
  • maszyny do automatycznego przetwarzania danych w formie systemów,
  • pozostałe maszyny do automatycznego przetwarzania danych, zawierające lub nie w tej samej obudowie jedno lub dwa urządzenia następującego typu: urządzenia pamięci, urządzenia wejścia i wyjścia,
  • urządzenia peryferyjne wyjścia (klawiatura, mysz itp.),
  • skanery (z wyłączeniem urządzeń wielofunkcyjnych zawierających drukarkę, skaner, kopiarkę i/lub faks),
  • drukarki atramentowe używane z urządzeniami do przetwarzania danych,
  • drukarki laserowe używane z urządzeniami do przetwarzania danych,
  • pozostałe drukarki używane z urządzeniami do przetwarzania danych,
  • jednostki wykonujące co najmniej dwie z następujących funkcji: drukowanie, skanowanie, kopiowanie, faksowanie,
  • pozostałe peryferyjne urządzenia wejścia lub wyjścia,
  • urządzenia pamięci do nieruchomych nośników informacji,
  • urządzenia pamięci do ruchomych nośników informacji,
  • pozostałe jednostki do maszyn do automatycznego przetwarzania danych,
  • części i akcesoria do maszyn liczących,
  • półprzewodnikowe urządzenia pamięci trwałej.

Oprogramowanie to:

  • systemy operacyjne
  • programy użytkowe (aplikacje) wykorzystywane do obsługi poradni,
  • oprogramowanie zabezpieczające właściwe oprogramowanie wykorzystywane do obsługi poradni (antywirus, firewall, itp.)”

Sprawa zatem powinna się bardziej rozjaśnić (podejrzewam, że dla obu stron). I nie czepiajmy się nomenklatury: “maszyny przenośne do automatycznego przetwarzania danych o masie do 10 kg, tj.: laptopy, notebooki” 🙂

Odpowiadając na pytania Klientów – tak – wdrożenie naszego rozwiązania usprawniającego pracę recepcji i koordynację kontaktu z pacjentem (3cx) zgodnie z zamieszczonym uszczegółowieniem “łapie się” do tego dofinansowania.

Miłego weekendu!

CSIOZ udostępnił dokumentację integracyjną w zakresie e-skierowania

Podziel się

Dokumentację można znaleźć pod adresem https://www.csioz.gov.pl/interoperacyjnosc/interfejsy/ . Obejmuje ona:

Dokumentacja integracyjna obejmuje:

  1. Specyfikację usług
  2. Opis i strukturę dokumentu elektronicznego skierowania
  3. Reguły biznesowe
  4. Kody wyników operacji
  5. Zasady otrzymania dostępu do środowiska integracyjnego .

Obiecano także, że pod koniec czerwca pojawi się środowisko testowe dla tej funkcjonalności.

Chmura w praktyce część 2 – bezpieczeństwo danych w chmurze (na przykładzie SQL databases w Azure)

Podziel się

 

We wpisie

Co to jest chmura i czy może nam się przydać?

jako jeden ze sposobów wykorzystania chmury w naszym środowisku informatycznym podałem wykorzystanie jej dość szeroko pojętej funkcjonalności nazwanej “baza danych”. Wpis ten jednak nie będzie roztrząsał rodzajów tego typu mechanizmów w poszczególnych typach chmury czy mechanizmów rozliczania. Uznajmy, że tego typu aspekty są do przedyskutowania na konkretnym przykładzie biznesowym. Tym wpisem chciałem zwrócić uwagę na bezpieczeństwo danych przechowywanych w mechanizmach chmurowych na przykładzie bazy danych. Wiadomo, rozwiązań chmurowych jest wiele i generalnie dostawcy radzą sobie z aspektami bezpieczeństwa na różne sposoby.

Na co warto zwrócić uwagę z punktu widzenia administratora danych osobowych i/lub pracowników działu IT w placówce medycznej?

Przepisy RODO regulują i dopuszczają powierzenie danych osobowych podmiotom trzecim, także w kontekście uwarunkowań formalno-prawnych przetwarzanie danych placówki ochrony zdrowia w chmurze nie jest wykluczone. Komisja Europejska w motywie 81 preambuły RODO wskazuje na konieczność korzystania wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych w szczególności jeżeli chodzi o wiedzę fachową, wiarygodność i zasoby, odpowiadających wymaganiom bezpieczeństwa przetwarzania, w tym wymaganiom określonym przez RODO.

Najlepszą wskazówką w szukaniu odpowiedniego usługodawcy usług chmurowych (także zgodnie z zaleceniami CZIOZ) mogą być międzynarodowe standardy postępowania z danymi osobowymi a zatem normy takie jak ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 22301 oraz normy „branżowe” np. ISO 13606-1, ISO 13606-4.

Warto zwrócić też uwagę na normę ISO/IEC 27018, która nakłada następujące wymagania względem dostawców rozwiązań chmurowych:

  • Dane osobowe mogą być przetwarzane tylko i wyłącznie za wyrażeniem zgody przez klienta oraz wyłącznie do celów nieosobistych, oprócz sytuacji wyrażenia zgody przez klienta na tego rodzaju działanie.
  •  Należy zdefiniować procesy określające: zwrot, przekazanie, zniszczenie danych osobowych.
  •  Przed zakończeniem umowy należy ujawnić wszelkie podzlecenia usług przetwarzania oraz wszystkie kraje, w których występuje przetwarzanie danych.
  • Każdego rodzaju naruszenie ochrony danych należy udokumentować – łącznie z ustalonymi krokami rozwiązywania problemów i możliwymi następstwami.
  • Naruszenie ochrony danych należy niezwłocznie zgłosić klientowi
  • Należy wspierać klientów w zakresie postrzegania swoich praw: klientom, których dane przetwarzane są w chmurze należy oferować narzędzia, pozwalające by końcowi użytkownicy mogli uzyskać dostęp do swoich danych osobowych, w celu ich zmiany, usunięcia lub korekcji.
  • Przekazanie danych osobowych organom ścigania może nastąpić tylko i wyłącznie w przypadku istnienia prawnych zobowiązań w tym zakresie. Należy poinformować klienta, objętego takim postępowaniem, o ile informacja ta nie została utajniona.
  • Oferowane usługi „danych w chmurze” należy poddać regularnym kontrolom przez osoby trzecie.

Praktyka

Normy można sprawdzić i to istotne. Warto jednak wiedzieć jak to wygląda w praktyce. Aby od tego zacząć umieszczam poniżej do obejrzenia krótki filmik Microsoftu o tym w jaki sposób wygląda fizyczne i proceduralne zabezpieczenie do centrów danych będących częścią platformy Azure. Czy w szpitalu też tak macie? 🙂

Z ciekawostek – trwają ostre przygotowania do uruchomienia w Polsce platformy Azure Stack ( https://itreseller.com.pl/wspolna-oferta-microsoft-i-beyond-pl-w-oparciu-o-azure-stack-polscy-klienci-z-mozliwoscia-przetwarzania-danych-w-chmurze-z-lokalnego-polskiego-centrum-danych/ ). W centrum danych Beyond w Poznaniu powstanie zatem nasza “lokalna” platforma Azure`owa – gdyby ktoś się uparł na trzymanie danych u nas w kraju to idealne rozwiązanie. Ja jednak takiej potrzeby nie widzę, chociaż chętnie zmigruję kogoś do PL 🙂

Dlaczego Azure?

Działam na platformie Azure po pierwsze dlatego, że ją znam i wiem w jaki sposób wykorzystać niezliczone funkcjonalności do spełnienia naszych wymagań biznesowych w szeroko pojętym świecie medycyny. Po drugie dlatego, że bogactwo funkcjonalności i tempo rozwoju platformy jest ogromne. Świadczą o tym chociażby funkcjonalności, które poniżej zaprezentuję – jeszcze niedawno ich po prostu nie było. Po trzecie dlatego, że uważam, że to jest dobry wybór. I wcale nie oznacza to, że ograniczam się w swoich rozważaniach z klientami tylko do tej platformy. Znam wiele rozwiązań (OVH, Aruba Cloud, 3s DataCenter, Infomex DC) i w większym lub mniejszym stopniu z nich korzystam. Biorąc jednak pod uwagę funkcjonalności typowo usługowe – zwłaszcza mechanizmy PaaS Azure i AWS przodują i z pewnością będą.

Meritum

Wracając jednak do tematu. Jedną z przynajmniej kilku możliwości utworzenia bazy danych w Azure jest skorzystanie z usługi SQL database. Utwórzmy zatem nową instancję. W “Select source” wybrałem “Sample” – aby jakieś dane już były. Załóżmy, że to nasza baza pacjentów (a, że w tym przykładzie dane osobowe są to dobry przykład).

Po utworzeniu bazy możemy wejść w jej Dashboard:

Pragnę skupić się na następujących aspektach:

  • Set server firewall
  • Auditing and Threat Detection
  • Vulnerability Assesment
  • Data discovery and classifications
  • Dynamic Data Masking
  • Transparent data encryption.

Set server firewall – prosta funkcjonalność pozwalająca ustalić sobie zasady dostępu do bazy danych. W ustawieniach defaultowych mając server name (his1.database.windows.net) oraz użytkownika i hasło z bazą się po prostu połączymy. Można to okroić – do konkretnych adresów IP lub do konkretnych sieci wirtualnych. W tym wypadku prosta droga do skorzystania z mechanizmów opisanych we wpisie:

Chmura w praktyce – część 1 – VPN

Auditing and Threat Detection

Opcja inspekcji i wykrywania zagrożeń może zostać uruchomiona na poziomie pojedynczej instancji bazy danych lub na poziomie całego serwera. Domyślnie opcja Server-level jest wyłączona zarówno dla audytowania jak i wykrywania zagrożeń. Przy uruchamianiu tej opcji można podać także adres e-mail, na który będą przychodzić powiadomienia z alertami. Możemy wybrać tez wybrane zagrożenia, które mają być monitorowane.

Aha.. oto tabele w naszej bazie danych. Jak wcześniej wspomniałem to przykładowa baza, wypełniona danymi.

Po konfiguracji możemy sobie wyklinać pierwszy raport. Zawiera on wszystkie monitorowane przez nas aktywności wraz ze szczegółami – czyli. np który użytkownik jaką instrukcję lub operację na bazie danych wykonał lub chciał wykonać, z jakiego adresu ip itp. Dane możemy dowolnie filtrować a w przypadku gdy chcemy skorzystać z tych danych możemy podłączyć się do mechanizmu poprzez REST API.

Vulnerability Assesment

Ocena luk w zabezpieczeniach czy jak kto woli po prostu ocena podatności pozwala na automatyczny skan konfiguracji serwera bazy danych oraz danych zawartych w bazie. Wynikiem takiego skanowania jest rozbudowany raport zabezpieczeń bazy danych w następujących obszarach:

  • inspekcja i rejestrowanie
  • uwierzytelnianie i autoryzacja
  • zmniejszenie obszaru powierzchni
  • ochrona danych.

Jak widać na zrzucie powyżej mamy wyszczególnione wszystkie zadeklarowane i przeprowadzone kontrole oraz finalny status ich wykonania a także podsumowanie ryzyk wg. statusów (wysokie, niskie średnie). Szczegółowy raport rodzaju sprawdzanego zabezpieczenia, jego kategorii, instancji której dotyczy pozwala przyjrzeć się dokładnie wszystkim obszarom ryzyka. Mało tego – klikając na dane ryzyko otrzymujemy szczegółowy opis problemu a także zalecenie jego rozwiązania. Dla naszej bazy na przykład mamy informację, że niektóre kolumny w tabelach mogą zwierać dane wrażliwe (w rozumieniu Azure – mogą to być zatem dane osobowe lub inne). Dzięki temu możemy zareagować dokładając należytej staranności w opiece nad swoimi danymi. W opisanym przypadku w celu skorygowania tego problemu zostaniemy przeniesieni do Dynamic Data Masking, którą opisałem poniżej.

Data discovery and classifications

Kolejnym obszarem do analizy pod kątem bezpieczeństwa naszych danych w bazie jest mechanizm odnajdowania i klasyfikacji danych. Jest to narzędzie pozwalające nam na oznaczenie wszystkich kolumn w tabelach typem informacji która jest w danej kolumnie zawarta (np. Contact Info, Name, CreditCard) oraz nadania etykiet poufności. Dostępne na ten moment etykiety to:

Dodatkowo system sam rozpoznaje nam według swoich algorytmów typy danych i daje propozycje konfiguracji, którą możemy zaakceptować w całości lub częściowo wykorzystać. W razie konieczności system podpowiada nam także zalecenia do wykonania dla skonfigurowanej klasyfikacji danych.

Po zapisaniu klasyfikacji otrzymujemy rozkład przydzielonych etykiet oraz rozkład typu informacji w naszej bazie danych w przystępnej, graficznej formie. Raport ten możemy wyeksportować do Excela i dołączyć do swojej dokumentacji związanej z RODO.

Dynamic Data Masking

W skrócie dynamiczne maskowanie danych pomaga zapobiegać nieautoryzowanemu dostępowi do poufnych danych, umożliwiając klientom określenie, jak wiele wrażliwych danych ma się ujawnić przy minimalnym wpływie na warstwę aplikacji. Funkcja ta pozwala przykładowo wyświetlenie tylko części danych osobowych w recepcji placówki. W celu weryfikacji rozmówcy telefonicznego w systemie osobie obsługującej zgłoszenie mogą pojawić się wybrane dane osoby dzwoniącej – np. nazwisko, miejscowość zamieszkania oraz pierwsza i trzy ostatnie cyfry numeru PESEL. Myślę, że biznesowych zastosowań tej funkcjonalności w obliczu RODO czy po prostu mając świadomość wrażliwości tego typu danych (także proceduralną) można znaleźć wiele.

Transparent data encryption

Funkcjonalność ta wykonuje w czasie rzeczywistym szyfrowanie i deszyfrowanie bazy danych, powiązanych kopii zapasowych i plików dziennika transakcji bez konieczności wprowadzania zmian w aplikacji. Do realizacji tego zadania możemy wykorzystać zdefiniowane samodzielnie klucze znajdujące się w Key Picker. Dzięki wykorzystaniu tego mechanizmy mamy pewność, że wszystkie aplikacje i sposoby komunikowania się z naszą bazą danych otrzymują i wysyłają do niej dane zaszyfrowane.


Podsumowanie

Mam nadzieję, że opisane powyżej możliwości konfiguracji i dostosowania bazy danych do swoich restrykcyjnych potrzeb odnośnie przetwarzania danych rzucą nowe światło na ten temat. Zaznaczam, że wzięta na tapetę została tutaj tylko jedna z funkcjonalności – baza danych. Mechanizmów tych, dla różnych typów usług jest dużo więcej i postaram się o nich sukcesywnie pisać. Gdyby ktoś chciał poklikać sobie na żywo zapraszam do kontaktu – udostępnię subskrypcje testową bez konieczności podawania namiarów na swoją kartę kredytową 😉

Nowe wytyczne CSIOZ

Podziel się

Na stronie CSIOZ pojawił się nowy dokument: “Rekomendacje CSIOZ w zakresie bezpieczeństwa oraz rozwiązań technologicznych stosowanych podczas przetwarzania dokumentacji medycznej w postaci elektronicznej”. Otrzymałem tym samym informacje, że “Wytyczne, zasady i rekomendacje dla usługodawców w zakresie budowy i stosowania systemu bezpiecznego przetwarzania elektronicznej dokumentacji medycznej”  (ostatnia aktualizacja marzec 2017) są nieaktualne. O tyle dobrze się składa, że miałem brać się za analizę i pod tym kątem ustawiać wpisy na blogu. Teraz będzie to miało miejsce dla najnowszego dokumentu, który jest już zrobiony z myślą o RODO, także można przewidywać, że będzie aktualny dłużej niż jego poprzednicy.

 

Dokument i załączniki znajdziecie na stronie: https://www.csioz.gov.pl/edm/

 

Zabezpieczenia danych medycznych w chmurze

Podziel się

I idąc za ciosem kolejny artykuł (żeby nie było, że nic nie publikuje ;)) Tym razem o sposobach zabezpieczeń danych medycznych na przykładzie konkretnych mechanizmów w Azure.

Przyglądamy się rozwiązaniom chmurowym pod kątem zabezpieczenia danych w sektorze medycznym w podziale na ogólnie przyjęte rodzaje platform chmurowych oraz mechanizmy, dzięki którym to bezpieczeństwo można zwiększyć, a także wykazać się zasadą rozliczalności, o której tak wiele mówi się w kontekście nowego unijnego rozporządzenia o ochronie danych osobowych.

Bardzo ważnym aspektem pojawiającym się u każdego managera IT, którego organizacja przetwarza dane o szczególnym priorytecie, jest kwestia zapewnienia bezpieczeństwa tych danych. Nie inaczej jest i w przypadku danych medycznych – ich bezpieczeństwo powinno być priorytetem. „No jak to, przecież się nie da”, „przecież muszę mieć możliwość fizycznego audytu danych, za które odpowiadam”, „trzymanie danych medycznych gdzieś za granicą jest niemożliwe i niebezpieczne” – często na konferencjach w oficjalnych pytaniach czy kuluarowych rozmowach słychać takie wątpliwości. Przyjrzyjmy się zatem w pierwszej kolejności temu, co mówią nam nowe regulacje odnośnie do wymagań, jakie trzeba spełnić z perspektywy podmiotu przetwarzającego dane osobowe w chmurze.

Zarówno przepisy uodo, jak i rodo regulują i dopuszczają powierzenie danych osobowych. Trzeba pamiętać o tym, że Komisja Europejska w motywie 81 preambuły rodo wskazuje na konieczność korzystania wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, w szczególności jeżeli chodzi o wiedzę fachową, wiarygodność i zasoby, odpowiadających wymaganiom bezpieczeństwa przetwarzania, w tym wymaganiom określonym przez rodo. Najlepszą wskazówką w szukaniu odpowiedniego usługodawcy usług chmurowych (także zgodnie z dokumentem „Rekomendacje Centrum Systemów Informacyjnych Ochrony Zdrowia w zakresie bezpieczeństwa oraz rozwiązań technologicznych stosowanych podczas przetwarzania dokumentacji medycznej w postaci elektronicznej”) mogą być międzynarodowe standardy postępowania z danymi osobowymi, a zatem normy takie jak: ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 22301 oraz normy branżowe, np. ISO 13606-1, ISO 13606-4. Warto zwrócić też uwagę na normę ISO/IEC 27018.

Oczywiście trzeba zdawać sobie sprawę z możliwych incydentów bezpieczeństwa, które są nieco odmienne dla rozwiązań chmurowych w porównaniu z rozwiązaniami on premise. Rozważaniami na ten temat na poziomie europejskim zajęła się Grupa Robocza art. 29, która w opinii 5/2012 w sprawie przetwarzania danych w chmurze obliczeniowej przyjętej w dniu 1 lipca 2012 r. przeanalizowała kwestie istotne dla dostawców usług przetwarzania danych w chmurze działających w Europejskim Obszarze Gospodarczym (EOG) oraz ich klientów, określając wszystkie mające zastosowanie zasady z dyrektywy o ochronie danych UE (95/46/WE) oraz dyrektywy o prywatności i łączności elektronicznej 2002/58/WE (zrewidowanej dyrektywą 2009/136/WE). Wtedy nie było jeszcze mowy o rodo, ale specjaliści wskazują, że w tym zakresie nie zachodzą żadne zmiany w opinii.

Główne opisane zagrożenia obejmują brak kontroli oraz brak przejrzystości (różne aspekty, m.in.: brak dostępności, brak integralności, brak odizolowania). W ramach grupy roboczej opracowano także wytyczne dla klientów i dostawców usług przetwarzania danych w chmurze. To ważny aspekt związany z bezpieczeństwem przetwarzania danych osobowych i wrażliwych (a zatem także medycznych), ponieważ właśnie te wytyczne powinny być dla działów IT podstawą do opracowywania procedur ochrony danych przetwarzanych w środowiskach, za które odpowiadają. Są one także podstawą do zrozumienia, na jakich zasadach przetwarzać w chmurze dane swojej organizacji, aby zapewnić im bezpieczeństwo oraz sobie kontrolę nad nimi. Zgodnie ze wspominanym wcześniej dokumentem opracowanym przez CSIOZ najważniejsze z nich to:

  • Odpowiedzialność klienta usługi w chmurze jako administratora – klient powinien wybrać dostawcę usługi w chmurze, który gwarantuje zgodność z przepisami w zakresie ochrony danych, co odzwierciedlają odpowiednie zabezpieczenia umowne;
  • Zabezpieczenia w przypadku powierzenia – przepisy dla podmiotów, którym powierzono realizację usług, powinny być przewidziane w każdej umowie pomiędzy dostawcą usługi w chmurze i jego klientami;
  • Przestrzeganie podstawowych zasad ochrony danych – klientowi należy zapewnić zrozumiałe informacje na temat środków technicznych i organizacyjnych wdrożonych przez dostawcę; klient w ramach dobrych praktyk powinien przekazać osobom, których dane dotyczą, informacje na temat dostawcy usługi w chmurze, jak również dane na temat lokalizacji, w których dane mogą być przechowywane lub przetwarzane;
  • Określenie i ograniczenie celu – klient powinien zapewnić zgodność z zasadami określenia i ograniczenia celu przetwarzania danych oraz zadbać o to, aby żadne dane nie były przetwarzane do innych celów przez dostawcę;
  • Zatrzymywanie danych – klient jest odpowiedzialny za zapewnienie, aby dane osobowe zostały usunięte ze wszystkich miejsc, w których są przechowywane, w przypadku gdy ich przetwarzanie nie odbywa się lub realizowane jest prawo (do zapomnienia) osoby, której dane dotyczą;
  • Zabezpieczenia umowne – umowa z dostawcą powinna zapewniać wystarczające gwarancje pod względem technicznych środków bezpieczeństwa i środków organizacyjnych;
  • Dostęp do danych – tylko upoważnione osoby powinny mieć dostęp do danych. W umowie powinna być zawarta klauzula poufności w odniesieniu do dostawcy i jego pracowników;
  • Zobowiązania do współpracy – klient powinien zapewnić, aby dostawca był zobowiązany do współpracy w związku z prawem klienta do monitorowania operacji przetwarzania, do ułatwiania realizacji praw osób, których dane dotyczą, do dostępu do/poprawiania/usuwania ich danych oraz do powiadamiania klienta usługi w chmurze o wszelkich naruszeniach ochrony danych mających wpływ na dane klienta;

źródło:  Artykuł pochodzi z czasopisma „IT Professional” nr 04/2018.

(http://www.it-professional.pl/archiwum/art,7951,zabezpieczenia-danych-medycznych-w-chmurze.html)

Chmura a potrzeby podmiotów medycznych

Podziel się

Poniżej zamieszczam treść do zajawki artykułu zamieszczonego na łamach IT Professional. Aktualnie z tego cyklu ukazały się 3 artykuły, czwarty jest w trakcie drukowania.

Informatyzacja placówek szeroko pojętej ochrony zdrowia trwa w najlepsze. Mnogość różnego rodzaju projektów, regulacji prawnych, a także zbliżające się wielkimi krokami nowe rozporządzenie o zasadach przetwarzania danych osobowych (rodo) wywołuje duże poruszenie w branży. Czy chmura odpowiada potrzebom podmiotów medycznych? Czy warto przyjrzeć się tego typu rozwiązaniom? Jak wygląda sytuacja u samych zainteresowanych?

Z  doniesień medialnych wszyscy wiemy, że nasz system ochrony zdrowia od lat zmaga się z wieloma problemami organizacyjno-finansowymi. Podobna sytuacja występuje w przypadku informatyzacji sektora. Informatyzacji rozumianej jako spójny zestaw usług na poziomie ogólnopolskim, bo nie ma co ukrywać, że prywatne podmioty oferujące usługi medyczne (zwłaszcza te duże) mają dużą świadomość informatyczną i radzą sobie znakomicie. I to radzą sobie zarówno z wykorzystaniem najnowocześniejszych technologii w celu ułatwienia życia pacjentom, jak i sprawnością systemów IT w zakresie obsługi procesów wewnątrz organizacji. Dzięki środkom unijnym także duża liczba szpitali podległych resortom czy też władzom na różnego rodzaju szczeblach samorządowych wdrożyła, bądź wdraża, nowoczesne rozwiązania. Na szczeblu ogólnopolskim sprawa jednak nie jest taka prosta. Od lat trwają prace nad Elektroniczną Platformą Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (tzw. system P1).

Na projekt ten wydano już ogromnie dużo pieniędzy, a z powodu wielu problemów został dla niego opracowany plan naprawczy. Przyjęto nowe założenia, które mówią o tym, co i kiedy ma zostać wdrożone i uruchomione.

Zgodnie z opublikowanym 9 maja 2017 r. komunikatem dotyczącym regulacji prawnych w zakresie Elektronicznej Dokumentacji Medycznej (tinyurl.com/mz-komunikat) „trwają prace legislacyjne dotyczące nowelizacji ustawy z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia, których celem jest m.in. doprecyzowanie definicji elektronicznej dokumentacji medycznej (EDM) oraz obowiązku stosowania Polskiej Implementacji Krajowej (PIK) HL7 CDA (Clinical Document Architecture) oraz formatów EDM, które będą publikowane w Biuletynie Informacji Publicznej Ministerstwa Zdrowia, a także zmiana terminów dotyczących obowiązku stosowania EDM”. Ustalono też następujące terminy obowiązywania poszczególnych usług:

  • e-recepta – obowiązek wystawiania recepty w postaci elektronicznej – od 1 stycznia 2020 r.;
  • e-skierowanie – obowiązek wystawiania skierowania w postaci elektronicznej – od 1 stycznia 2021 r.;
  • pozostała część EDM (tj. dokumenty wskazane w rozporządzeniu wydanym na podstawie art. 13 ustawy):

– obowiązek prowadzenia w postaci elektronicznej – od 1 stycznia 2019 r.;
– obowiązek wymiany za pośrednictwem Platformy P1 – od 1 stycznia 2021 r.
Na „pierwszy ogień” idą zatem głównie szpitale. Nie możemy jednak zapominać o tym, że od lipca 2018 r. Zakład Ubezpieczeń Społecznych uruchamia obowiązek wystawiania elektronicznych zwolnień lekarskich dla wszystkich lekarzy. Dodatkowo pojawiają się legislacyjne ułatwienia dla rozwiązań telemedycznych. Zgodnie z wizją opracowaną na potrzeby nowo powstającej Strategii Rozwoju e-Zdrowia dla Polski na lata 2018–2022 „(…) dzięki spójnemu rozwojowi e-zdrowia do 2022 roku system opieki zdrowotnej w Polsce stanie się bardziej skuteczny, efektywny ekonomicznie i dostępny dla obywatela (…)”.

Nie bez wpływu na potrzeby placówek ochrony zdrowia jest także mające zastosowanie dla każdej branży wchodzące w życie od maja 2018 roku unijne ogólne rozporządzenie o ochronie danych osobowych (rodo), które reguluje zasady przetwarzania tego typu danych. Biorąc pod uwagę, że w środowiskach informatycznych ochrony zdrowia mamy dodatkowo dane medyczne, które są opatrzone klauzulą szczególnej wrażliwości, nie można przejść obojętnie obok potrzeb technicznych i możliwości, jakie dają nam rozwiązania informatyczne w tym kontekście.

Jak widać, wyzwań informatycznych jest bardzo dużo. Aby mieć pełny obraz sytuacji, należy jeszcze przyjrzeć się aktualnemu stanowi informatyzacji podmiotów ochrony zdrowia.

źródło: Artykuł pochodzi z czasopisma „IT Professional” nr 03/2018.

http://www.it-professional.pl/archiwum/art,7919,chmura-a-potrzeby-podmiotow-medycznych.html