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ą 😉

5 Shares:
33 comments
  1. Pingback: viagra online
  2. Pingback: viagra for sale
  3. Pingback: cialis generic
  4. Pingback: tadalafil 5mg
  5. Pingback: write my thesis
  6. Pingback: order cialis
  7. Pingback: cialis pills
  8. Pingback: viagra generic
  9. Pingback: Valtrex
  10. Pingback: buy drugs online
  11. Pingback: viagra
  12. Pingback: cialis generic
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

Znów dane medyczne udostępnione publicznie czyli kolejny “wyciek”

Podziel się

“Setki zrzutów ekranu i dokumentów z danymi osobowymi i medycznymi pacjentów oraz dane finansowe dziesiątek szpitali, w tym dane dostępowe do różnych systemów informatycznych oraz dane osobowe pracowników szpitali — takie informacje znajdowały się w publicznie dostępnym katalogu systemu stosowanego do obsługi placówek opieki zdrowotnej, obsługiwanego przez firmę Konsultant IT. Pobrać je mógł każdy. Ilość ujawnionych danych jest znaczna i może dotyczyć wielu szpitali z całej Polski, w tym szpitali psychiatrycznych.” – poinformował wczoraj serwis Niebezpiecznik.pl .

Pełną treść informacji można znaleźć tutaj: https://niebezpiecznik.pl/post/dane-pacjentow-i-szpitali-wyciekly-z-helpdesku-eskulapa-szpitale-powinny-zmienic-hasla/

Generalnie, podobnie jak w przypadku “wycieku” danych ze szpitala w Kole sprawa jest trywialna pod kątem bezpieczeństwa. Na koncie FTP na którym znajduje się system helpdeskowy firmy Konsultant IT udostępniony był przynajmniej do odczytu folder w którym znajdowały się wszystkie pliki załączników ze zgłoszeń systemu helpdeskowego firmy. Wśród tych załączników były m.in. zrzuty ekranu systemu Eskulap. Zrzuty zawierające między innymi dane osobowe pacjentów, rozpoznania chorób itp. Oprócz tego można tam było znaleźć dane finansowe w plikach Excel. Wśród tych plików były także dane osobowe pacjentów. Dodatkowo udostępniono dane dostępowe VPN do szpitali, pliki SQL.

Firma Konsultant IT wydała w tej sprawie oświadczenie, w którym poinformowano, że:

“System helpdesk zainstalowany jest na zewnętrznym serwerze, stworzyła go dla nas i realizuje nadzór autorski Firma DIMIMO. Do udostępnienia danych doszło na skutek błędu podczas migracji przez DIMIMO helpdesku, na nowy serwer. Katalog, który był zabezpieczony w oparciu o plik .htaccess został przeniesiony na serwer, na którym konfiguracja serwera www nie dopuszczała zmian w oparciu o ten plik. W ten sposób zabezpieczenie zostało zniwelowane. Po migracji zweryfikowano wiele zabezpieczeń, niestety prawdopodobnie z powodu rutyny popełniono błąd.”

Idąc za ciosem postanowiłem napisać maila do firmy Konsultant IT z pytaniami, które mnie nurtują:

Szanowni Państwo,
Zaniepokojony informacjami o umieszczeniu do publicznej wiadomości danych medycznych i osobowych w używanym przez Państwa systemie helpdeskowym, biorąc pod uwagę, że oprócz tego, że zawodowo zajmuję się ochroną danych osobowych i medycznych w systemach IT jestem także pacjentem kilku ośrodków w Polsce proszę o odpowiedzi na poniższe pytania ponieważ istnieje prawdopodobieństwo, że niepowołane osoby otrzymały dostęp m.in. do danych moich lub mojej rodziny na co kategorycznie nie wyrażałem zgody.

  1. Czy dla potrzeb świadczenia usług wsparcia użytkowników, biorąc pod uwagę, że jak mniemam mają Państwo dostęp do systemów zawierających dane osobowe i medyczne przetwarzane przez klienta, podpisywali Państwo ze współpracującymi szpitalami umowy powierzenia danych osobowych?
  2. Czy posiadają Państwo politykę bezpieczeństwa i instrukcję zarządzania systemami informatycznymi?
  3. Czy podpisują Państwo ze swoimi pracownikami jakiekolwiek klauzule poufności odnośnie danych przetwarzanych przez nich podczas świadczenia usług?
  4. Poproszę listę Państwa klientów korzystających z systemu helpdeskowego w woj. łodzkim i mazowieckim ponieważ tam korzystam usług ośrodków. Chcę wiedzieć czy szpitale, które przetwarzają moje dane stosują praktyki robienia zrzutów ekranu z danymi wrażliwymi do tego typu systemów jak Państwa helpdesk.
  5. Czy biorąc pod uwagę, że system helpdeskowy tworzyła dla Państwa firma zewnętrzna i jak się domyślam świadczyła usługi wsparcia mieli Państwo z nimi podpisaną przynajmniej umowę o powierzenie danych osobowych? Czy Państwa klienci wiedzieli o tym, że dane udostępniane są jeszcze komuś?

Proszę o pilne odniesienie się do zadanych pytań i potraktowanie sprawy poważnie. Przykro mi, że padło akurat na Państa ale w obliczu RODO temat ochrony tego typu danych jest szczególnie ważny i tego typu sytuacje pokazują jak wiele jeszcze jest w tym zakresie do zrobienia. Także w świadomości użytkowników i usługodawców..

Czekam na odpowiedź.

Zbierając to wszystko nasuwa mi się tylko jedno. Po raz kolejny przerażające jest jak wielka jest niewiedza i nieświadomość wszystkich osób zaangażowanych w tą sytuację.

Po pierwsze użytkowników systemów, co bardziej bolesne podejrzewam, że często także działów IT szpitali. Jak można załączać do systemu helpdeskowego takie dane? Zrozumiałe jest, że w pracy pewne rzeczy robi się na szybko, że problemy muszą być skutecznie rozwiązywane ale kompletnie nie jest to usprawiedliwieniem tego typu działań. Robienie zrzutów z hasłami dostępowymi do VPN itp. pozostawię bez komentarza.

Niestety w tej całej sytuacji nieprofesjonalna jest też postawa firmy udzielającej wsparcia a tłumaczenie się, że system ten robiła firma zewnętrzna jest śmieszne. Poza wszystkim już to właśnie oni powinni zwrócić uwagę swoim klientom na to, że takich rzeczy się robić nie powinno..

Dopóki nie zbudujemy we wszystkich na około świadomości i potrzeby bezpiecznego przetwarzania tego typu danych wszystkie konferencje odnośnie RODO, prawnicze wykłady na ten temat lub nawet próby egzekwowania nie dadzą żadnego efektu. Trzeba zacząć od zupełnych podstaw.

Microsoft Healthcare Day

Podziel się

Miło mi poinformować, że w najbliższy wtorek – 5 czerwca będę miał przyjemność powiedzieć coś więcej o potrzebach szpitali w zakresie nowych technologii jako przedstawiciel Polskiej Federacji Szpitali podczas wydarzenia Microsoft Healthcare Day .

Jest to wydarzenie inaugurujące ścieżkę Startberry Digital Health dla startupów z sektora zdrowia. Bardzo się cieszę, że wydarzeń tego typu jest coraz więcej – potrzeby branży są ogromne więc pole do kreowania jest ogromne!

Ramowa agenda:

9.30 – 10.00 – Rejestracja
10.00 – 10.45 – Michał Jaworski, “Wpływ nowych regulacji (GDPR, NIS) na IT w medycynie”
10.45 – 11.30 – Waldemar Skrzypiec, “Azure jako platforma dla rozwiązań telemedycznych?”
11.30 – 11.45 – Przerwa kawowa
11.45 – 12.30 – Artur Pruszko, “Nowe kierunki rozwoju eZdrowia”
12.30 – 13.15 – Polska Federacja Szpitali, “Potrzeby szpitali w zakresie nowych technologi”
13.15 – 14.00 – Lunch
14.00 – 16.00 – Sesje tematyczne

Lokalizacja:

Startberry
ul. Grochowska 306/308, Warszawa

Bezpłatna rejestracja pod adresem: https://www.microsoftevents.com/profile/form/index.cfm?PKformID=0x4234341abcd

W jaki sposób uruchomić darmowy system wideokonferencyjny w placówce medycznej? część 1

Podziel się

Ścieżek pewnie jest wiele, przedstawię jedną z nich. Na przykładzie bardzo ostatnio popularnego wśród placówek medycznych systemu typu Unified Communications3cx . A co to w ogóle jest i w jakim celu nam to jest potrzebne?

To bardzo dobre pytanie. Systemy tego typu to połączenie systemów VOiP (w dużym skrócie – telekomunikacyjnych) oraz wszystkich innych funkcjonalności związanych z poprawą komunikacji w organizacji. Jednolitą komunikację definiuje się jako proces, w którym wszystkie środki komunikacji, urządzenia i media są zintegrowane, pozwalając użytkownikom pozostawać ze sobą w kontakcie w czasie rzeczywistym bez względu na miejsce pobytu. Celem jednolitej komunikacji jest optymalizacja procedur biznesowych i ułatwienie komunikacji międzyludzkiej dzięki upraszczaniu procesów. A

le po co nam to w placówce medycznej ktoś zapyta? Jak to po co? 🙂 To idealne narzędzie zapewniające optymalizację wielu problemów z komunikacją na linii placówka-lekarz, rejestracja-pacjent, pacjent-lekarz . W dobie legislacji dążącej do ułatwień związanych z telekonsultacjami oraz tematami związanymi z opieką koordynowaną tego typu rozwiązania to idealne narzędzia do komunikacji. Tym bardziej, że umożliwiają także bezpieczną wymianę dokumentów, czy przeprowadzanie prezentacji.

Nie będę jednak w tym wpisie zajmował się roztrząsaniem wszystkich funkcjonalności tego typu systemów i możliwości wykorzystania w naszych placówkach, zostawię to na później. Dziś skupię się na pokazaniu w jaki sposób postawić sobie w pełni działający system.

Licencjonowanie i wymagania sprzętowe

Licencjonowanie produktu jest możliwe na dwa sposoby. Z jednej strony można wykupić licencję roczną, z drugiej licencje wieczystą. W tym drugim przypadku jednak darmowe wsparcie mamy na rok. Później trzeba je komercyjnie przedłużyć. W obu wspomnianych przypadkach cena  licencji jest zależna od dwóch rzeczy:

– liczby jednoczesnych połączeń – zarówno wewnętrznych jak i zewnętrzne

– wersji oprogramowania. Mamy do wyboru trzy. Standard, Professional oraz Enterprise. Do wideokonferencji wystarczy Standard i na ten moment na tym poprzestańmy. Jakby ktoś chciał więcej info o różnicach pomiędzy wersjami to może sobie poczytać tutaj: https://www.3cx.com/phone-system/edition-comparison/ .

Producent oprogramowania 3cx oferuje darmową licencje w wersji Standard do 16 jednoczesnych połączeń na 1 rok. Po roku licencja ta zostaje darmowa (w przypadku gdy nie opłacimy jej przedłużenia), zmienia się tylko ilość jednoczesnych połączeń – jest zmniejszana do 4. Co dla nas (biorąc pod uwagę temat wpisu) najważniejsze – w tym rodzaju licencji mamy funkcjonalność wideokonferencji do 25 jednoczesnych uczestników. Wykorzystajmy to zatem!

Aha.. jeszcze wymagania sprzętowe.. Tutaj mamy dwie drogi. Jedna z nich to instalacja naszego serwera 3cx na którejś z maszyn w naszej placówce. Dostępna jest wersja dla Windowsa i Linuxa. Wymagania nie są bardzo wyżyłowane. Zgodnie z dokumentację w wersji do 16 jednoczesnych połączeń to:

CPU Intel® Core™ i3-3210 Processor (3M Cache, 3.20 GHz)
Memory 2 GB
HDD SATA 30GB
Can be Virtualized Yes
NETWORK 100/1000 Mbit/s

Więcej szczegółów odnośnie wymagań sprzętowych i konkretnych wersji systemów operacyjnych, które są wpierane znajdziecie na https://www.3cx.com/docs/recommended-hardware-specifications-for-3cx/ oraz https://www.3cx.com/docs/supported-operating-systems/ .

System możemy zainstalować lokalnie lub wykorzystać swoje konto w chmurze publicznej. 3cx jest kompatybilny z następującymi dostawcami:

– Google Cloud

– OVH

– AWS

– 1&1

lub z każdym innym wspierającym protokół OpenStack API w wersji 2.0. Przez kompatybilność rozumiem, że cała potrzebna do utworzenia instancji serwera infrastruktura tworzy się automatycznie. Nasza rola ogranicza się do podania dostawcy chmury u którego mamy konto oraz do wybrania po jego stronie parametrów maszyn wirtualnych, które chcemy wykorzystać do instalacji.

Instalacja systemu

Instalację zaczynami od wejścia na stronę www.3cx.com do zakładki Try. Wypełniamy  tam swoje dane i klikamy Submit & Download . Number of extensions jest to orientacyjna liczba numerów wewnętrznych/użytkowników, których będziemy chcieli skonfigurować w systemie.

Po wypełnieniu formularza otrzymamy dostęp do strony z instalkami oraz dokumentacją systemu. Jeżeli chcemy instalować oprogramowanie na własnej maszynie to jest dobry moment aby pobrać pliki instalacyjne. Otrzymamy też na maila link potwierdzający aplikację o nową licencję. Po jego kliknięciu będziemy mieć dostępny nasz klucz licencyjny oraz możliwość wyboru rodzaju instalacji. My idziemy do chmury, wybieramy zatem Deploy in Your Cloud.

Otworzy nam się dokładnie to samo co dzieje się podczas instalacji systemu on-premise na własnym serwerze. Na początek konfigurujemy strefę czasową, numeracyjną oraz język.

W kolejnym kroku wybieramy swoją nazwę dla serwera oraz domenę. Podczas instalacji zostanie wygenerowany automatycznie darmowy na okres 1 roku certyfikat ssl.

oraz ilość znaków numeru wewnętrznego, których potrzebujemy. Uwaga – proponuje to dobrze przemyśleć, to co tutaj zaznaczymy zostaje już na zawsze 😉

Nadszedł czas na wybór dostawcy chmury.  Ja wybieram Azure. Wpisuję id swojej subskrypcji i w kolejnym kroku jestem proszony o podanie poświadczeń do swojego konta Azure i o akceptację dostępu do niego przez aplikację 3cxapp, która zrobi za nas całą robotę.

Później idąc tropem minimalnych wymagań przedstawionych wyżej wybieramy rodzaj maszyny na której chcemy postawić nasza instalację oraz wybieramy region. I to generalnie tyle.

UWAGA! Raz czy dwa po kroku wyboru  maszyny wirtualnej zdarzyło mi się, że system wrócił do kroku w którym należy podać strefę czasową, numeracyjną itp. Instalacja jednak się utworzyła. Temat zgłosiłem. Nie dzieje się tak dla Google Cloud. Podejrzewam, że może to być spowodowane tym, że 3cx spiął się z Azure w tamtym tygodniu jakoś i jeszcze nie wszystko jest w 100% dopracowane.

Czekamy cierpliwie aż nasza infrastruktura wirtualna zostanie utworzona. Zostaniemy o tym poinformowani komunikatem:

W przypadku Azure stworzona infrastruktura wygląda w ten sposób:

Po poprawnym zakończeniu instalacji otrzymujemy wiadomości mailowe. Jedną z danymi związanymi z dostępem do konsoli zarządzania oraz innymi rzeczami związanymi z administrowaniem systemem:

oraz drugi – z danymi potrzebnymi zwykłemu użytkownikowi systemu. Takiego maila otrzyma każdy, któremu utworzymy w systemie konto.

W ten dość prosty i szybki sposób mamy do pracy gotowy system.

W przypadku gdy instalację robiliśmy  na własnym serwerze pierwszą rzecz jaką polecam do zrobienia po zalogowaniu do konsoli to sprawdzenie FirewallCheckera. Biorąc pod uwagę, że system 3cx korzysta z zewnętrznych (z perspektywy naszej instalacji) serwerów do wideokonferencji musimy mieć do i z maszyny otwarty port 443:

W przypadku instalacji cloudowej wszystkie porty potrzebne do usług 3cx otwierają się automatycznie I nie musimy się tym przejmować (testowałem dla Azure, OVH oraz dla Google Cloud). Na wszelki wypadek jednak dobrze to zweryfikować.

Odsapnijmy teraz i w oczekiwaniu na część drugą w której omówimy funkcjonalności związane z tworzeniem, obsługą i możliwościami wideokonferencji cieszmy się piękną wiosną 🙂

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

Podziel się

Czas powolutku zmierzać w stronę także postów czysto technicznych. Jeszcze na spokojnie ale do tego zmierzamy, żeby sobie przetestować różne rozwiązania itp. Żeby jednak zacząć ustalmy najpierw pewne rzeczy na najwyższym poziomie abstrakcji. No to jedziemy.

Zgodnie z definicją Wikipedii  Chmura obliczeniowa to model przetwarzania danych oparty na użytkowaniu usług dostarczonych przez usługodawcę. Czyli co tak właściwie ? To po prostu różnego rodzaju usługi IT z których użytkownik może korzystać na różnym stopniu złożoności, zależnie od tego jakiego sposobu potrzebuje i chce. To generalnie nie żadna innowacja, marketingowo od kilku lat stało to się hitem. Usługi tego typu są wygodne dla klienta bo bardzo elastyczne – możemy dopasowywać sobie pakiety, parametry i jesteśmy za to najczęściej elastycznie rozliczani. Ze względu na wspomnianą złożoność chmurę możemy podzielić na różnego rodzaju modele:

  • SaaS (Software as a Service czyli aplikacja jako usługa) – najlepiej chyba będzie na przykładzie. Używacie może usługi Googla do poczty (Gmail)?Albo macie pocztę na nazwa.pl, na Onecie gdziekolwiek? A może dostęp do oprogramowania Waszej placówki macie “przez Internet” – z poziomu jakiejś ogólnodostępnej strony www? To jest właśnie ten model chmury. Nie interesuje Was warstwa serwerowa, oprogramowanie wirtualizacyjne i milion innych rzeczy na którym jest zainstalowane to oprogramowanie. Nie przejmujecie się tym, żeby to zawsze działało, przezroczyste są dla Was kopie zapasowe. Po prostu ma działać aplikacja a Wy z niej korzystacie.
  • PaaS (Platform as a Service czyli platforma jako usługa) – no tutaj już będzie bardziej informatycznie jeżeli ktoś nie ma za wiele wspólnego z IT 🙂 Platforma to środowisko troszkę niższego poziomu. Na platformie możemy tworzyć bazy danych do obsługi jakiejś aplikacji, dyski do przechowywania danych, możemy łączyć naszych użytkowników z Active Directory nie posiadając serwera AD, korzystać z różnego rodzaju platform integrujących oprogramowanie. Platforma daje też możliwości udostępniania środowisk programistycznych do budowy jakiś aplikacji. Rynek tak prężnie się rozwija, że w tym modelu zaczynają być już budowane ogromne aplikacje do zarządzania przedsiębiorstwem – tzw. systemy ERP. Także generalnie – wszystko zmierza w tym kierunku 🙂
  • IaaS (Infrastructure as a Service – infrastruktura jako usługa) – tutaj schodzimy na jeszcze niższy poziom. Możemy na przykład tworzyć maszyny wirtualne dla różnych usług – na przykład na swój serwer oprogramowania MMedica, KS-PPS, możemy chcieć mieć naszą usługę Active Directory nie na swoim serwerze w placówce tylko u sprawdzonego dostawcy .Po co nam to? Po to, żeby cały czas nie przejmować się najniższym poziomem – czyli sprzętem oraz systemami operacyjnymi. Nie musimy kupować serwera i zastanawiać się co zrobimy jak on nie działa. Po prostu płacimy miesięcznie za usługę i mamy swoją bazę czy system operacyjny którym zarządzamy. To po prostu wygodne i cały czas nie trzeba inwestować w sprzęt i kompetencje w zarządzanie na tym poziomie. A gdy brakuje nam jakiś zasobów – na przykład chcemy wdrożyć w placówce VoIP (czyli w skrócie rozmowy telefoniczne “przez Internet” – temat ten będzie rozwijany) nie musimy kupować do tego celu drogiego serwera. Wystarczy, że u naszego dostawcy chmury podamy odpowiednie parametry maszyny i w kilka chwil serwer jest nasz.

Rys. Rodzaje chmury obliczeniowej (źródło: Wikipedia)

Dobrze. Zejdźmy teraz na ziemię z tej chmury. Postaram się przedstawić kilka zastosowań chmury obliczeniowej w naszej codziennej pracy. Inspirowałem się w tych zastosowaniach artykułem mojego mentora w kwestii chmur – https://chmurowisko.pl/ , chociaż obciąłem je do takich, które mogą Was zainteresować. Na Chmurowisku znajdziecie w każdym razie solidną porcję wiedzy na ten temat, chociaż nie ukrywam, że u mnie także ten temat będzie się przewijał. Bo po prostu teraz chmury się używa 🙂

  1. Dysk w chmurze

Każdy chyba słyszał o DropBox, Google Drive? To nic innego jak wirtualne dyski w chmurze. W kontekście naszych placówek (nie tylko zresztą przy tym punkcie) z pewnością pojawi się pytanie – czy to bezpieczne, co z danymi medycznymi, RODO itp.? Na ten moment się tym nie przejmujcie – do tego wrócimy. Na razie poznajmy możliwości tego typu rozwiązań.

2. Backup i archiwizacja danych

Backup wszystkiego. Od pojedynczego komputera na Windowsie czy Linuxie ( Backblaze, Mozy by EMC, Arq, Carbonite) poprzez backupy baz danych czy maszyn wirtualnych ( Amazon Storage Gateway, Zerto, Ctera, Carbonite, Veeam Cloud Connect, NetApp SteelStore).

3. Odtwarzanie danych po awarii

Tak, wcale nie trzeba mieć skomplikowanych mechanizmów wirtualizacyjnych u siebie w placówce. Usługi tego typu polegają mniej więcej na tym, że w przypadku awarii np. naszego serwera odpalamy sobie nasze środowisko, czy aplikację w chmurze. Przykłady: Azure Site Recovery, Double Take oraz CloudEndure .

4.  Bazy danych

Wspominałem o tym wyżej. Dzięki usłudze chmurowej możemy skupić się na danych w bazie, jej strukturze i obróbce – nie musimy przejmować się mechanizmami replikacji czy kwestiami wydajnościowymi. Po prostu łączymy się ze swoją bazą i robimy co chcemy. Można zerknąć tutaj: Amazon RDS, Microsoft Azure SQL, Salesforce Database.com .

5. Poczta elektroniczna

To chyba komentarza nie wymaga. Zresztą, opisałem wcześniej – Office 365, Google Works, Amazon WorkMail

6. Narzędzia biurowe

Znowu trzeba kupić Office na jakiś komputer bo lekarz potrzebuje Excela nie wiadomo do czego? Nie trzeba 🙂 Można skorzystać z chmury, wyjdzie pewnie taniej a jak już oprogramowanie potrzebne nie będzie to można z niego po prostu zrezygnować. Wygoda użytkowania, elastyczność i optymalizacja kosztów. To cała chmura.

7. Komunikacja

Usługi telefoni, chat firmowy, wideokonferencje z pacjentami.. Nie trzeba do tego kupować dedykowanych urządzeń typu centrale telefoniczne, bramki VoIP, mostki telekonferencyjne. Można skorzystać z usług typu 3cx, Salesforce Chatter, Slack, Sqwiggle, Hipchat i mieć wszystko. Sam wdrażam klientom tego typu rozwiązania (nie tylko w branży  medycznej) i to naprawdę dobre rozwiązanie. I z pewnością tańsze.

8. Strony www

Od prostych Landing Pages do skomplikowanych stron z bajerami dla pacjentów. To wszystko można sobie po prostu wyklikać. Gdzie? Na przykład tutaj: LeadPages, Launch Effect, LaunchRock

9. Bezpieczeństwo – systemy SIEM, firewalle, rozbudowane zarządzanie DNS, antywirus, ochrona przed atakami typu DDoS

Przed wyzwaniem RODO to ciekawe rzeczy, którym warto się przyjrzeć. CloudFlare, F5, Barracuda, Citrix, Scuri .

9. Monitoring infrastruktury

Ciągnąc temat  bezpieczeństwa pewnie w mniejszym czy większym stopniu każda placówka monitoruje (lub chciałaby) swoje systemy i infrastrukturę. Czy to switche, czy komputery użytkowników, serwery. To przydatna wiedza i jest porządek gdy jest zebrana w jednym miejscu. Ja często lokalnie używam Nagiosa. Ale są też systemy chmurowe. Np.: New Relic, Server Density, Librato .

10. VDI

Czyli wirtualne pulpity w chmurze. A to akurat jedna z moich ulubionych i jeszcze niezbyt rozpowszechnionych zastosowań. Centralne zarządzanie końcówkami użytkowników, zapewnione mechanizmy bezpieczeństwa i wydajność. Super sprawa i naprawdę bardzo się rozwinęła w ostatnim czasie. Ten temat rozwinę jeszcze z pewnością nie raz. Do poczytania: Horizon, Citrix .

11. Obsługa użytkowników

Ja zawszę traktuję użytkowników końcowych jak klientów działu IT. Przy takim podejściu wszyscy są zadowoleni a praca zawsze jest sprawna i ułożona. Można sobie pomóc w chmurze: SalesForce Service Cloud, HelpScout, Groove, FreshDesk , dlaczego nie?

12. Autoryzacja użytkowników

Usługa AD w chmurze, synchronizacja danych pomiędzy różnymi aplikacjami i wszędzie jeden login a u nas żadnego serwera? To możliwe dzięki JumpCloud i OneLogin .

Najlepsze jest to, że te zastosowania można by mnożyć i mnożyć.. Zatrzymajmy się jednak tutaj, chociaż jeżeli macie ciekawe pomysły na wykorzystanie chmury to chętnie się o nich dowiem.

Zakładam, że do tej pory większość z Was kojarzyła chmurę z aplikacją do zarządzania przychodnią i w tym kontekście zastanawialiście się jak to jest i , że na pewno jest to niebezpieczne. Moim zadaniem było zmienić ten obraz i pokazać, że w swoich placówkach pewnie często z chmury korzystacie chociaż nawet o tym nie wiecie. Nie ma co się jej bać. Kwestia RODO też jest do ogarnięcia ale tak jak wspominałem wcześniej to temat na oddzielny wątek i na tym też się skupię. Żeby było jasne – nie chcę też tutaj na siłę nikogo namawiać. Nie byłoby to zresztą do końca zgodne z moim biznesem, ponieważ zajmuję się wdrożeniami najróżniejszych systemów – także niechmurowych. Chciałem tylko pokazać możliwości i trochę rozjaśnić temat.

Elektroniczna Dokumentacja Medyczna – podstawowe zasady przetwarzania obowiązujące wszystkich – czy się chce czy nie

Podziel się

 

No właśnie.. RODO, GIODO, ABI, IOD, wytyczne CSIOZ odnośnie przetwarzania danych medycznych, dziesiątki przepisów, ustaw, rozporządzeń dotyczących definicji danych osobowych, danych medycznych i kwestii ich prawidłowego przetwarzania, różne interpretacje – jednym słowem nie wiadomo czym się kierować w przypadku chęci prawidłowego podejścia do tematu. Spróbujmy wyłuskać z powyższego absolutne must have dla wszystkich przetwarzających dane medyczne.

A co to tak właściwie są te dane medyczne? Niestety w Polskim prawodawstwie, jak to często bywa jest kilka nieścisłości w kwestii prawidłowego uszeregowania danych medycznych w kontekście danych osobowych itp. Na szczęście nie jest to blog prawniczy, bo te kwestie wydają się nierozstrzygalne i są często kwestią interpretacji. Szczegółowe informacje na ten temat można znaleźć chociażby tutaj . Na nasze potrzeby – nazwijmy je organizacyjno-informatycznymi, przyjmijmy, że dane medyczne są danymi osobowymi o charakterze wrażliwym. I z takim przeświadczeniem powinniśmy je przetwarzać.

I tutaj trzeba zacząć od RODO – tak, trzymajmy się tej wersji bo na nią trzeba być przygotowanym – od 25 maja 2018 będzie obowiązywało wszystkich. Co to jest RODO? RODO czyli GDPR, zwane także „Ogólnym Rozporządzeniem o Ochronie Danych” to Rozporządzenie Parlamentu Europejskiego i Rady (UE)2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE. Nie możemy zapomnieć także o UODO ponieważ dokument ten nakłada na podmioty przetwarzające tego typu dane liczne zobowiązania, które należy uwzględnić podczas projektowania systemów informatycznych mających przetwarzać dane osobowe w tym dane wrażliwe.

Idąc od najwyższego poziomu abstrakcji Art. 5 ust. RODO wskazuje na sześć podstawowych zasad przetwarzania danych osobowych:

1. Zasada zgodności z prawem, rzetelności i przejrzystości przetwarzania – w skrócie oznacza ona, że podmiot przetwarzający zawsze i na każdym etapie
przetwarzania danych jest zobowiązany dbać o interesy osoby, której dane dotyczą

2. Zasada ograniczoności celu – dane osobowe muszą być zbierane w konkretnych, wyraźnych i prawnie uzasadnionych celach

3. Zasada minimalizacji danych – przetwarzane dane osobowe muszą być adekwatne, stosowne oraz ograniczone do tego, co niezbędne do celów, w których są przetwarzane. Nie wolno zbierać i przetwarzać danych, które nie są niezbędne do osiągnięciu celu przetwarzania i są w stosunku do niego nadmiarowe. Czyli w przypadku danych medycznych numer buta nie jest nam potrzebny 🙂

4. Zasada prawidłowości – przetwarzane dane osobowe muszą być prawidłowe i w razie potrzeby uaktualniane – wydaje się oczywiste ale niech rzuci kamieniem ten, który jest bez winy. Dbanie o aktualność danych jest zawsze zmorą w organizacjach.

5. Zasada ograniczoności przechowywania – dane osobowe muszą być przechowywane w formie umożliwiającej identyfikację osoby, której dane dotyczą, przez okres nie dłuższy, niż jest to niezbędne do celów, w których dane te są przetwarzane. To jest bardzo ciekawe zagadnienie, które mam nadzieje będzie jeszcze okazja poruszyć. Ciekawa ponieważ jednocześnie mając na uwadze zapisy art. 25 ust. 1 oraz art. 32 ust. 1 RODO w zakresie uwzględniania ochrony danych w fazie projektowania oraz domyślnej ochrony danych i
bezpieczeństwa przetwarzania, placówka medyczna prowadząca dokumentację w postaci elektronicznej powinna zorganizować sposób gromadzenia informacji w taki sposób, aby nie można ich było już przypisać konkretnej osobie, której dane dotyczą, bez użycia dodatkowych informacji pod warunkiem, że informacje te są objęte środkami technicznymi i organizacyjnymi uniemożliwiającymi
ich przypisanie zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. Trochę się to wyklucza ale to zagadnienie (dotyczące pseudonimizacji) to temat na oddzielny wpis.

Co trzeba zrobić, żeby to spełniać? Oczywiście niezależnie od tego czy przetwarzamy dane w praktyce lekarskiej, małej przychodni, większej placówce chociażby specjalistycznej czy szpitalu. Obowiązek ten wymusza sam fakt przetwarzania danych.

 

1. Powołanie IOD (Inspektora Ochrony Danych) w starej nomenklaturze (jeszcze obowiązującej ) to mniej więcej ABI (Administrator Bezpieczeństwa Informacji).

 

Administrator danych może nie powoływać takiego kogoś – wtedy sam przejmuje jego obowiązki. Jeżeli jest to osoba zatrudniona w danej placówce powinna ona mieć to wpisane w zakres obowiązków, w przypadku gdy zdecydujemy się powierzyć tę rolę osobie/firmie zewnętrznej potrzebujemy umowy powierzenia.

 

2. Identyfikacja wszystkich osób, które przetwarzają dane osobowe

 

Osoby te powinny otrzymać upoważnienia do przetwarzania danych osobowych zgodnie z art. 37 UODO, jednocześnie powinny zostać zapoznane z przepisami o ochronie danych osobowych. Zapoznanie z przepisami powinno zostać potwierdzone przez pracownika upoważnianego stosownym oświadczeniem a oświadczenie to powinno zostać dołączone do akt osobowych pracownika zgodnie z art. 36a ust. 2 pkt 1 lit. c UODO a od 2018 r zgodnie z art. 39 ust. 1 pkt a i b  RODO. Wszystkie osoby, które zostały upoważnione i dopuszczone do przetwarzania danych osobowych, powinny zostać zobowiązane do zachowania danych oraz sposobu ich zabezpieczenia w tajemnicy jednocześnie zapewniając spisanie potwierdzenia takiego zobowiązania oraz dołączenia go do akt pracowniczych (art. 39 ust. 2 UODO).

 

3. Ustalenie procedur mających na celu cykliczne sprawdzanie zgodności przetwarzania danych osobowych z przepisami o ochronie danych osobowych

 

Sprawdzenia takiego dokonuje nasz Inspektor Ochrony Danych. Najpierw musi on jednak ustalić plan sprawdzeń obejmujących minimalnie kwartał a maksymalnie rok – w tym okresie musi odbyć się co najmniej jedna taka analiza.

 

Powinna ona obejmować 4 elementy:

 

  • inwentaryzację zbiorów
  • sprawdzenie, czy są realizowane obowiązki z ustawy o ochronie danych osobowych UODO,
  • sprawdzenie, czy zbiory i systemy przetwarzające dane osobowe są odpowiednio
    zabezpieczone,
  • weryfikacja i aktualizacja dokumentacji z zakresu ochrony danych osobowych oraz weryfikacja przestrzegania zasad i procedur w niej zawartych.

Procedura ta składa się z przepisów zawartych w UODO oraz w Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych
(Dz.U. 2004 r. Nr 100 poz. 1024). Trochę tego jest, dlatego tutaj sczegóły odpuszczam – w razie potrzeby proszę pytać.

Należy pamiętać, że trzeba prowadzić sprawozdania z wykonywania tych czynności.

4. Opracowanie polityki bezpieczeństwa ochrony danych osobowych

Musi ona zawierać:

  • wykaz budynków, pomieszczeń lub części pomieszczeń, tworzących obszar, w którym przetwarzane są dane osobowe
  • wykaz zbiorów danych osobowych wraz ze wskazaniem programów zastosowanych do przetwarzania tych danych
  • opis struktury zbiorów danych wskazujący zawartość poszczególnych pól informacyjnych i powiązania między nimi
  • sposób przepływu danych pomiędzy poszczególnymi systemami
  • określenie środków technicznych i organizacyjnych niezbędnych dla zapewnienia poufności, integralności i rozliczalności przetwarzanych danych.

4. Opracowanie instrukcji zarządzania systemami informatycznymi zawierająca w szczególności:

  •  procedury nadawania uprawnień do przetwarzania danych i rejestrowania tych uprawnień w systemie informatycznym oraz wskazanie osoby odpowiedzialnej za te czynności
  • stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem
  • procedury rozpoczęcia, zawieszenia i zakończenia pracy przeznaczone dla użytkowników systemu
  • procedury tworzenia kopii zapasowych zbiorów danych oraz programów i narzędzi programowych służących do ich przetwarzania
  • sposób, miejsce i okres przechowywania: elektronicznych nośników informacji zawierających dane osobowe, kopii zapasowych
  • sposób zabezpieczenia systemu informatycznego przed działalnością oprogramowania, którego celem jest uzyskanie nieuprawnionego dostępu do systemu informatycznego
  • sposób realizacji wymogów w zakresie odnotowywania przez system informacji o odbiorcach,w rozumieniu art. 7 pkt 6 UODO, którym dane osobowe zostały udostępnione, dacie i 50 zakresie tego udostępnienia, chyba że system informatyczny używany jest do przetwarzania danych zawartych w zbiorach jawnych
  • sposób realizacji wymogów w zakresie odnotowywania przez system informacji o odbiorcach, w rozumieniu art. 7 pkt 6 UODO, którym dane osobowe zostały udostępnione, dacie i zakresie tego udostępnienia
  • procedury wykonywania przeglądów i konserwacji systemów oraz nośników informacji służących do przetwarzania danych.

5. Bezpieczeństwo fizyczne w obszarach przetwarzania danych osobowych i wrażliwych

Na podstawie przeprowadzonej analizy ryzyka i planu postępowania z ryzykiem, których obowiązek przeprowadzenia wynika z art. 36 ust. 1 UODO każdy podmiot ma obowiązek wdrożenia odpowiednich środków bezpieczeństwa. W związku z tym w zakresie ochrony fizycznej należy rozważyć wyznaczenie obszarów bezpiecznych oraz podział na strefy w zależności od ich dostępności zarówno dla personelu, jak i pacjentów oraz przedstawicieli podmiotów współpracujących.

Podział na strefy umożliwia dobór stosowanych zabezpieczeń fizycznych (np. identyfikatory osobowe, system kontroli dostępu, zarządzanie kluczami tradycyjnymi oraz elektronicznymi w postaci kart dostępu, system monitorowania wizyjnego, systemy przeciwwłamaniowe,, zabezpieczenie okien i drzwi, służba ochrony całodobowa lub po godzinach pracy, systemy przeciwpożarowe lub gaśnice, klimatyzacja, czujniki temperatury i wilgotności.

6. Wdrożenie Systemu Zarządzania Bezpieczeństwem informacji

System ten w telegraficznym skrócie zbiera wszystko co powyżej, identyfikuje zagrożenia związane z przetwarzaniem danych oraz tworzy plan postępowania z ryzykiem i politykę zarządzania incydentami bezpieczeństwa.

Mniej więcej tyle trzeba mieć na początek. A właściwie inaczej – teraz można przejść do wybierania odpowiedniego dla nas modelu przetwarzania danych informatycznych bo wszystkie formalności i organizację pracy mamy załatwione. Szczerze mówiąc sam zebrałem to do kupy w jednym miejscu po raz pierwszy i widzę, że jest tego sporo i sporo rzeczy wymaga uszczegółowienia i głębszej analizy. Będziemy nad tym pracować 😉

Źródła:

  1. Ustawa o Ochronie danych osobowych 
  2. Rekomendacje Centrum Systemów Informacyjnych Ochrony Zdrowia w zakresie bezpieczeństwa oraz rozwiązań technologicznych stosowanych podczas przetwarzania dokumentacji medycznej w postaci elektronicznej
  3. Sylwia Czub – blog
  4. Ochrona danych medycznych – bartakalinski.pl
  5. Ustawa z dnia 28 kwietnia 2011 r. o systemie informacji w ochronie zdrowia (Dz.U. z 2016r. poz. 1535)
  6. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2016 r. poz. 113)
  7. Rozporządzenie Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U.2016 poz. 1626)
  8. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 25 lutego 2016 r. w sprawie rodzajów, zakresu i wzorów oraz sposobu przetwarzania dokumentacji medycznej w podmiotach leczniczych utworzonych przez ministra właściwego do spraw wewnętrznych (Dz.U. 2016 poz. 249)
  9. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/680 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych przez właściwe organy do celów zapobiegania przestępczości, prowadzenia postępowań przygotowawczych, wykrywania i ścigania czynów zabronionych i wykonywania kar, w sprawie swobodnego przepływu takich danych oraz uchylająca decyzję ramową Rady 2008/977/WSiSW
  10. Norma PN-EN 13609-1:2007 Informatyka w ochronie zdrowia

Rusza dofinansowanie opieki koordynowanej w projekcie POZ Plus – czy jest to szansa na rozwój IT w placówkach?

Podziel się

Pomijając zupełnie warunki finansowe podmiotów, które będą mogły ubiegać się o udział w pilotażu (małe placówki z małych miast, miasteczek lub wsi) pierwszą rzeczą, która rzuca się w oczy to wymagania techniczne jakie są przed nimi stawiane i punktowane przy wniosku o dofinansowanie. To szereg mało precyzyjnych wymagań dotyczących systemów informatycznych do przetwarzania dokumentacji medycznej oraz dotyczących bezpieczeństwa przetwarzania danych osobowych i medycznych, które można w obecnym kształcie dość mocno interpretować. Bez jasno określonych wytycznych można spodziewać się nieścisłości w procesie oceny wniosków – na ten moment punkty przyznawane podczas „audytu ex-ante”  będą mogły być przyznawane na podstawie „widzi mi się” członków komisji. Warto także zaznaczyć, że przynajmniej jeden z punktów jest niekoniecznie możliwy do spełnienia. Chodzi o to „Czy świadczeniodawca prowadzi elektroniczną dokumentację medyczną (EDM w rozumieniu przepisów ustawy o systemie w ochronie zdrowia, zgodnie z art. 11 ust. 1 tej ustawy)”. Istnieją bowiem poważne wątpliwości co do tego, czy którykolwiek z istniejących na rynku systemów spełnia to wymaganie biorąc pod uwagę brak centralnego Systemu Informacji Medycznej.

Kolejną sprawą jest to, że dużo i nośnie mówi się o opiece koordynowanej w kontekście projektu POZ Plus w tematach związanych z ułatwieniami komunikacji na styku lekarz-pacjent chociażby poprzez wykorzystanie nowoczesnych narzędzi telemedycznych czy telediagnostycznych. Można było wręcz odnieść wrażenie, że projekt to umożliwi i pozwoli właśnie tym mniejszym podmiotom korzystać z dobrodziejstw telekonsultacji czy telediagnostyki a pacjenci dostaną szansę na korzystanie z różnego rodzaju narzędzi edukujących i wspierających w związku z chorobami przewlekłymi z którymi się borykają. Rzeczywistość jednak wygląda inaczej. Tzw. „grant technologiczny” przyznawany w maksymalnej wersji w kwocie 50 000 zł w trzech na cztery obszary w których można go dostać dotyczy sprawozdawczości związanej z projektem POZ Plus. W czwartym punkcie można będzie otrzymać dofinansowanie na integrację „…z systemami: Zintegrowany Informator Pacjenta (ZIP) i System Informatyczny Monitorowania Profilaktyki (SIMP) w celu pobierania informacji o świadczeniach udzielonych pacjentom objętym opieką koordynowaną”. Tutaj problemy są dwa – po pierwsze nie wiadomo w jakim konkretnie zakresie a po drugie brak jest w tych systemach mechanizmów (tzw. API programistyczne), które umożliwiałyby jakąkolwiek integracje.

Biorąc pod uwagę powyższe oraz inne problemy o których mówi się po pojawieniu się dokumentacji należałoby się zastanowić czy obecny kształt projektu jest właściwym kierunkiem. Na szczęście to tylko pilotaż z którego będzie można wyciągnąć wnioski. I oby finał był szczęśliwy zarówno dla placówek jak i dla pacjentów bo chyba o to w ochronie zdrowia chodzi.