Każdy skradziony rekord medyczny kosztuje do 20 dolarów – dwadzieścia razy więcej niż dane karty kredytowej. Aby zapobiec kradzieży tożsamości, oszustwom i szantażowi, wszystkie aplikacje dla służby zdrowia w USA muszą być zgodne z ustawą o przenoszeniu i odpowiedzialności za ubezpieczenie zdrowotne (HIPAA). Oto nasz prosty przewodnik po oprogramowaniu zgodnym z HIPAA.

Pomiędzy innymi, HIPAA chroni informacje zdrowotne pacjentów.

Anthem, największa amerykańska firma ubezpieczeniowa, nauczyła się tego w ciężki sposób.

To, co zaczęło się od prostej wiadomości phishingowej, doprowadziło do największego naruszenia danych opieki zdrowotnej w historii. Hakerzy wykradli dane 79 milionów pacjentów. Informacje obejmowały ich nazwiska, numery ubezpieczenia społecznego i identyfikatory medyczne.

Wściekli pacjenci pozwali Anthem i wygrali ugodę na 115 milionów dolarów. Chociaż firma uniknęła grzywien regulatora, będzie musiała wydać do 260 milionów dolarów, aby poprawić swoje bezpieczeństwo.

HHS Office for Civil Rights (OCR) nadzoruje zgodność z HIPAA. Tylko w 2017 roku ukarało amerykańskich dostawców usług opieki zdrowotnej grzywną w wysokości prawie 20 milionów dolarów.

Nawet jeśli jesteś małą organizacją, zaniedbanie wymagań HIPAA może prowadzić do poważnych problemów.

W 2013 roku Fresenius Medical Care North America miał pięć naruszeń danych. Łącznie naraziły one dane zaledwie 525 pacjentów. Ale firma musiała zapłacić monstrualną grzywnę w wysokości 3,5 miliona dolarów, ponieważ nie przeanalizowała właściwie zagrożeń bezpieczeństwa.

W zależności od stopnia zaniedbania istnieją cztery opony grzywien HIPAA:

Słowniczek HIPAA

Powinieneś zrozumieć te trzy kluczowe terminy, zanim zajmiesz się wymaganiami HIPAA.

  • Chronione informacje zdrowotne (PHI) – wszelkie dane, które mogą być użyte do identyfikacji pacjenta.

PHI składa się z dwóch części: informacji zdrowotnych i identyfikatorów osobowych. Te ostatnie obejmują nazwiska pacjentów, adresy, daty urodzenia, numery ubezpieczenia społecznego, dokumentację medyczną, zdjęcia itp. Fakt, że dana osoba korzystała z usług medycznych jest PHI sam w sobie.

Co jest uważane za PHI? Pełna lista.

  • Podmioty Objęte Ochroną – organizacje i osoby oferujące usługi/operacje opieki zdrowotnej lub przyjmujące za nie płatności.

Obejmują one wszystkich świadczeniodawców opieki zdrowotnej (np. szpitale, lekarzy, dentystów, psychologów), plany zdrowotne (np. ubezpieczycieli, HMO, programy rządowe, takie jak Medicare i Medicaid) oraz centra rozliczeniowe (organizacje, które działają jako pośrednicy między świadczeniodawcami opieki zdrowotnej a firmami ubezpieczeniowymi).

  • Współpracownicy biznesowi – osoby trzecie obsługujące PHI w imieniu podmiotów objętych ochroną.

Kategoria ta obejmuje twórców aplikacji dla służby zdrowia, dostawców usług hostingowych/przechowywania danych, usług poczty elektronicznej itp.

Zgodnie z przepisami HIPAA, należy podpisać umowę o współpracy biznesowej (BAA) z każdą stroną, która ma dostęp do Twoich PHI. Podjęcie decyzji o niepodpisaniu umowy BAA nie zwalnia z wymogów HIPAA.

Zarówno podmioty objęte obowiązkiem ubezpieczenia, jak i podmioty współpracujące muszą przestrzegać przepisów HIPAA. Prawo nie zawiera klauzuli „bezpiecznej przystani”, co oznacza, że musisz zachować zgodność z przepisami, nawet jeśli nieumyślnie przetwarzasz PHI.

Może istnieć wiele niezamierzonych sposobów, w jakie dane wrażliwe mogą dostać się do Twojego systemu.

Przykładem może być usługa, która pozwala lekarzom diagnozować choroby skóry na podstawie anonimowych zdjęć. Aplikacja nie obsługuje PHI, ponieważ nie można zidentyfikować jej użytkowników. Ale gdy tylko dodasz nazwisko lub adres osoby do zdjęć, stają się one PHI.

Jeśli Twoja aplikacja gromadzi, przechowuje lub przekazuje PHI do podmiotów objętych ochroną, musisz zachować zgodność z HIPAA.

Jak uzyskać zgodność z HIPAA?

Aby zachować zgodność z HIPAA, będziesz musiał dokonywać regularnych technicznych i nietechnicznych ocen swoich wysiłków na rzecz ochrony informacji zdrowotnych i dokładnie je dokumentować. Regulator opublikował przykładowy protokół audytu, który może pomóc w ocenie zgodności z HIPAA.

Możesz zatrudnić niezależnego audytora, który przeprowadzi ocenę za Ciebie. Istnieje wiele organizacji, takich jak HITRUST, które specjalizują się w tego rodzaju rzeczach. Pamiętaj tylko, że OCR nie uznaje żadnych certyfikatów innych firm.

Podczas tworzenia oprogramowania zgodnego z HIPAA będziesz musiał głównie zajmować się technicznymi i fizycznymi zabezpieczeniami nakreślonymi w Regule Bezpieczeństwa.

Techniczne zabezpieczenia. Środki bezpieczeństwa, takie jak logowanie, szyfrowanie, dostęp awaryjny, dzienniki aktywności itp. Prawo nie określa, jakich technologii należy używać w celu ochrony PHI.

Zabezpieczenia fizyczne mają na celu zabezpieczenie obiektów i urządzeń przechowujących PHI (serwery, centra danych, komputery, laptopy itp.).

W przypadku nowoczesnych rozwiązań opartych na chmurze, zasada ta dotyczy głównie hostingu zgodnego z HIPAA.

Zabezpieczenia określone w Zasadach Bezpieczeństwa mogą być „wymagane” lub „możliwe do zaadresowania”. Oba są obowiązkowe. W przypadku pominięcia zabezpieczenia „adresowalnego” należy udowodnić, że jest to wystarczająco rozsądna decyzja w danej sytuacji.

Prawo dotyczy szerokiego zakresu oprogramowania medycznego. Systemy zarządzania szpitalem (HMS) różnią się radykalnie od zdalnych aplikacji diagnostycznych. Istnieją jednak pewne cechy, które są niezbędne we wszystkich aplikacjach zgodnych z przepisami HIPAA.

Oto minimalna lista wymaganych cech oprogramowania zgodnego z przepisami HIPAA:

1. Kontrola dostępu

Każdy system, który przechowuje PHI, powinien ograniczać, kto może przeglądać lub modyfikować dane wrażliwe. Zgodnie z zasadą ochrony prywatności HIPAA nikt nie powinien widzieć więcej informacji o pacjencie, niż jest to wymagane do wykonywania jego pracy. Reguła ta określa również de-identyfikację, prawa pacjenta do przeglądania własnych danych oraz jego zdolność do udzielania lub ograniczania dostępu do swoich PHI.

Jednym ze sposobów osiągnięcia tego celu jest przypisanie każdemu użytkownikowi unikalnego identyfikatora. Pozwoliłoby to na identyfikację i śledzenie aktywności osób uzyskujących dostęp do systemu.

Następnie należy nadać każdemu użytkownikowi listę uprawnień, które pozwalają mu na przeglądanie lub modyfikowanie określonych informacji. Możesz regulować dostęp do poszczególnych encji bazy danych i adresów URL.

W najprostszej formie kontrola dostępu oparta na użytkownikach składa się z dwóch tabel bazy danych. Jedna tabela zawiera listę wszystkich przywilejów i ich identyfikatory. Druga tabela przypisuje te uprawnienia do poszczególnych użytkowników.

W tym przykładzie lekarz (identyfikator użytkownika 1) może tworzyć, przeglądać i modyfikować dokumentację medyczną, natomiast radiolog (identyfikator użytkownika 2) może ją tylko aktualizować.
Kontrola dostępu oparta na rolach to inny sposób realizacji tego wymagania. Dzięki niej można przypisać uprawnienia do różnych grup użytkowników w zależności od ich stanowiska (np. lekarze, technicy laboratoryjni, administratorzy).

2. Uwierzytelnianie osoby lub podmiotu

Po przypisaniu uprawnień system powinien być w stanie zweryfikować, czy osoba próbująca uzyskać dostęp do PHI jest tą, za którą się podaje. Prawo oferuje kilka ogólnych sposobów, w jaki można wdrożyć to zabezpieczenie:

Hasło jest jedną z najprostszych metod uwierzytelniania. Niestety, jest to również jedna z najłatwiejszych do złamania. Według Verizon, 63% przypadków naruszenia danych dzieje się z powodu słabych lub skradzionych haseł. W innym raporcie stwierdzono, że jedna piąta użytkowników korporacyjnych ma łatwe do złamania hasła.

Z drugiej strony, naprawdę bezpieczne hasło:

  • Składa się z co najmniej 8-12 znaków, w tym wielkich liter, cyfr i znaków specjalnych;
  • Wyłącza powszechnie używane kombinacje (np. „password”, „123456”, „qwerty”, i z jakiegoś niewytłumaczalnego powodu „monkey”) i słowa ze słownictwa;
  • Wyłącza wszelkie odmiany nazwy użytkownika;
  • Uniemożliwia ponowne użycie hasła.

Alternatywnie, może to być ciąg przypadkowych słów rozbitych razem jak betonowy popsicle.

Twoja aplikacja mogłaby sprawdzać te wymagania na ekranie logowania i odmawiać dostępu użytkownikom ze słabymi hasłami.

Nie ma czegoś takiego jak zbyt duże bezpieczeństwo. Źródło: mailbox.org

Niektóre organizacje zmuszają swoich pracowników do zmiany haseł co 90 lub więcej dni. Zbyt częste wykonywanie tego obowiązku może jednak zaszkodzić działaniom na rzecz bezpieczeństwa. Zmuszani do zmiany haseł, ludzie często wymyślają nieoryginalne kombinacje (np. hasło ⇒ pa$$word).

Co więcej, hakerzy mogą złamać złe hasło w ciągu kilku sekund i natychmiast je wykorzystać.

Dlatego powinieneś rozważyć użycie dwuskładnikowego uwierzytelniania. Takie systemy łączą bezpieczne hasło z drugą metodą weryfikacji. Może to być cokolwiek, od skanera biometrycznego po jednorazowy kod bezpieczeństwa otrzymany przez SMS.

Pomysł jest prosty: nawet gdyby hakerzy w jakiś sposób zdobyli Twoje hasło, musieliby ukraść Twoje urządzenie lub odciski palców, aby uzyskać dostęp do informacji PHI.

Ale bezpieczne uwierzytelnianie nie wystarczy. Niektórzy napastnicy mogą dostać się pomiędzy urządzenie użytkownika a serwery firmy. W ten sposób hakerzy mogą uzyskać dostęp do informacji PHI bez naruszania konta. Jest to znane jako porwanie sesji, rodzaj ataku typu man-in-the-middle.

Jeden z możliwych sposobów porwania sesji. Źródło: Heimdal Security

Podpis cyfrowy jest jednym ze sposobów obrony przed takimi atakami. Ponowne wpisanie hasła przy podpisywaniu dokumentu potwierdzałoby tożsamość użytkownika.

Jak role w systemie stają się bardziej złożone, autoryzacja HIPAA może przeszkadzać w udzielaniu pomocy pacjentom. Sensowne jest wdrożenie dostępu awaryjnego. Takie procedury pozwalają upoważnionym użytkownikom na przeglądanie wszelkich danych, których potrzebują, gdy wymaga tego sytuacja.

Lekarz mógłby, na przykład, uzyskać dostęp do PHI każdego pacjenta w nagłym wypadku. W tym samym czasie, system automatycznie powiadomiłby kilka innych osób i uruchomiłby procedurę przeglądu.

3. Bezpieczeństwo transmisji

Powinieneś chronić PHI, które przesyłasz przez sieć i pomiędzy różnymi warstwami systemu.

Dlatego powinieneś wymusić HTTPS dla całej komunikacji (lub przynajmniej dla ekranów rejestracji, wszystkich stron zawierających PHI i ciasteczek autoryzacyjnych). Ten bezpieczny protokół komunikacyjny szyfruje dane za pomocą SSL/TLS. Używając specjalnego algorytmu, zamienia on PHI w ciąg znaków, który jest bez znaczenia bez klucza deszyfrującego.

Plik zwany certyfikatem SSL wiąże klucz z Twoją cyfrową tożsamością.

Podczas nawiązywania połączenia HTTP z Twoją aplikacją przeglądarka żąda Twojego certyfikatu. Następnie klient sprawdza jego wiarygodność i inicjuje tzw. handshake SSL. W rezultacie powstaje zaszyfrowany kanał komunikacyjny między użytkownikiem a Twoją aplikacją.

Aby włączyć HTTPS dla swojej aplikacji, pobierz certyfikat SSL od jednego z zaufanych dostawców i poprawnie go zainstaluj.

Do przesyłania plików zawierających PHI należy również używać bezpiecznego protokołu SSH lub FTPS zamiast zwykłego FTP.

Uścisk dłoni SSL; źródło: the SSL store

Email nie jest bezpiecznym sposobem przesyłania PHI.

Popularne usługi, takie jak Gmail, nie zapewniają niezbędnej ochrony. Jeśli wysyłasz wiadomości e-mail zawierające informacje PHI poza serwer objęty ochroną firewalla, powinieneś je zaszyfrować. Istnieje wiele usług i rozszerzeń do przeglądarek, które mogą to zrobić za Ciebie. Alternatywnie można skorzystać z usługi poczty elektronicznej zgodnej z HIPAA, takiej jak Paubox.

Należy również wdrożyć zasady ograniczające informacje, które można udostępniać za pośrednictwem poczty elektronicznej.

4. Szyfrowanie/deszyfrowanie

Szyfrowanie jest najlepszym sposobem zapewnienia integralności PHI. Nawet gdyby hakerom udało się wykraść dane, bez kluczy deszyfrujących wyglądałyby one jak bełkot.

Nieszyfrowane laptopy i inne urządzenia przenośne są częstym źródłem naruszeń HIPAA. Aby być po bezpiecznej stronie, należy zaszyfrować dyski twarde wszystkich urządzeń, które zawierają informacje PHI. Można to zrobić za pomocą bezpłatnych narzędzi szyfrujących, takich jak BitLocker dla systemu Windows lub FileVault dla systemu Mac OS.

5. Utylizacja PHI

Powinieneś trwale zniszczyć PHI, gdy nie jest już potrzebne. Tak długo, jak kopia pozostaje w jednej z kopii zapasowych, dane nie są uważane za „usunięte”.

W 2010 r. Affinity Health Plan zwrócił swoje kserokopiarki firmie leasingowej. Nie wymazał jednak ich dysków twardych. W wyniku naruszenia ujawniono dane osobowe ponad 344 000 pacjentów.

Affinity musiała zapłacić 1,2 miliona dolarów za ten incydent.

PHI może ukrywać się w wielu nieoczekiwanych miejscach: kserokopiarkach, skanerach, sprzęcie biomedycznym (np. MRI lub ultrasonografy), urządzeniach przenośnych (np.laptopy), stare dyskietki, dyski flash USB, płyty DVD/CD, karty pamięci, pamięć flash w płytach głównych i kartach sieciowych, pamięć ROM/RAM itp.

Oprócz wymazania danych, należy również odpowiednio zniszczyć nośniki zawierające PHI przed ich wyrzuceniem lub oddaniem. W zależności od sytuacji można je wymazać magnetycznie (np. za pomocą degaussera), nadpisać dane za pomocą oprogramowania takiego jak DBAN lub zniszczyć dysk fizycznie (np. rozbijając go młotkiem).

W dyskach pamięci opartych na pamięci flash (np. pamięciach USB) dane są rozłożone na całym nośniku, aby zapobiec ich zużyciu. Z tego powodu trudno jest całkowicie wymazać poufne informacje za pomocą zwykłego oprogramowania do niszczenia danych. Można jednak użyć narzędzi producenta, takich jak Samsung Magician Software, aby pozbyć się dysków flash (lub po prostu użyć młotka).

6. Tworzenie kopii zapasowych danych i ich przechowywanie

Kopie zapasowe są niezbędne do zachowania integralności danych. Uszkodzenie bazy danych lub awaria serwera mogą z łatwością uszkodzić Twoje PHI. Podobnie jest w przypadku pożaru w centrum danych lub trzęsienia ziemi.

Dlatego ważne jest posiadanie wielu kopii danych PHI przechowywanych w kilku różnych miejscach.

Plan tworzenia kopii zapasowych danych PHI powinien określać prawdopodobieństwo narażenia danych na szwank. Wszystkie informacje o wysokim i średnim ryzyku powinny być codziennie backupowane i przechowywane w bezpiecznym miejscu. Należy również podpisać umowę BAA z dostawcami kopii zapasowych.

Kopia zapasowa jest bezużyteczna, jeśli nie można jej przywrócić.

W sierpniu 2016 r. firma Martin Medical Practice Concepts padła ofiarą ataku ransomware. Firma zapłaciła hakerom za odszyfrowanie PHI. Jednak z powodu awarii kopii zapasowej lokalne szpitale straciły informacje o 5 000 pacjentów.

Testuj swój system regularnie, aby zapobiec awariom odzyskiwania danych. Należy również rejestrować przestoje systemu i wszelkie niepowodzenia w tworzeniu kopii zapasowych informacji PHI.

Pamiętajmy również, że same kopie zapasowe powinny być zgodne ze standardami bezpieczeństwa HIPAA.

7. Kontrole audytowe

Brak kontroli audytowych może prowadzić do wyższych grzywien.

Należy monitorować, co jest robione z informacjami PHI przechowywanymi w systemie. Należy rejestrować każdy przypadek zalogowania się i wylogowania użytkownika z systemu. Należy wiedzieć kto, kiedy i gdzie uzyskał dostęp do danych wrażliwych, aktualizował je, modyfikował lub usuwał.

Monitorowanie można przeprowadzić za pomocą oprogramowania, sprzętu lub środków proceduralnych. Prostym rozwiązaniem byłoby wykorzystanie tabeli w bazie danych lub pliku dziennika do rejestrowania wszystkich interakcji z informacjami o pacjencie.

Tabela taka powinna składać się z pięciu kolumn:

  • user_id. Unikalny identyfikator użytkownika, który wszedł w interakcję z PHI;
  • entity_name. Podmiot, z którym użytkownik wszedł w interakcję (Podmiot jest reprezentacją pewnej koncepcji świata rzeczywistego w Twojej bazie danych, np. rekord zdrowotny);
  • record_id. Identyfikator encji;
  • action_type. Charakter interakcji (utworzenie, odczyt, aktualizacja lub usunięcie);
  • action_time. Dokładny czas interakcji.

W tym przykładzie lekarz (user_id 1) utworzył rekord pacjenta, radiolog go przejrzał, a później ten sam lekarz zmienił rekord.

Będziesz musiał okresowo kontrolować dzienniki aktywności, aby odkryć, czy niektórzy użytkownicy nadużywają swoich uprawnień w celu uzyskania dostępu do PHI.

8. Automatyczne wylogowanie

System z PHI powinien automatycznie kończyć każdą sesję po ustalonym okresie bezczynności. Aby kontynuować, użytkownik musiałby ponownie wprowadzić swoje hasło lub autoryzować się w inny sposób.

Chroniłoby to PHI, jeśli ktoś zgubi swoje urządzenie będąc zalogowanym do Twojej aplikacji.

Dokładny okres bezczynności powodujący wylogowanie powinien zależeć od specyfiki Twojego systemu.

W przypadku bezpiecznej stacji roboczej w wysoce chronionym środowisku, możesz ustawić timer na 10-15 minut. W przypadku rozwiązań webowych okres ten nie powinien przekraczać 10 minut. Natomiast dla aplikacji mobilnej można ustawić timeout na 2-3 minuty.

Różne języki programowania w różny sposób implementują automatyczne wylogowywanie.

Źródło: MailChimp

9. Dodatkowe zabezpieczenia aplikacji mobilnych

Urządzenia mobilne stwarzają wiele dodatkowych zagrożeń. Smartfon można łatwo ukraść lub zgubić w miejscu o dużym natężeniu ruchu, narażając na szwank poufne informacje.

Aby temu zapobiec, można użyć:

  • Blokada ekranu (Android/iOS);
  • Szyfrowanie całego urządzenia (Android/iOS);
  • Zdalne usuwanie danych (Android/iOs).

Nie możesz wymusić tych funkcji na użytkownikach, ale możesz zachęcić ludzi do korzystania z nich. Możesz włączyć instrukcje do procesu wdrażania lub wysyłać wiadomości e-mail z opisem, jak je włączyć.

Porada: Możesz przechowywać PHI w bezpiecznym pojemniku oddzielnie od danych osobowych. W ten sposób można zdalnie wymazać informacje zdrowotne bez wpływu na pozostałe dane.

Wielu lekarzy używa osobistych smartfonów do przesyłania informacji zdrowotnych. Można zneutralizować to zagrożenie za pomocą bezpiecznych platform do przesyłania wiadomości.

Aplikacje takie przechowują wrażliwe dane w bezpiecznej bazie danych. Aby uzyskać dostęp do PHI, użytkownicy muszą pobrać komunikator i zalogować się na swoje konta.

Innym rozwiązaniem są szyfrowane, chronione hasłem portale zdrowotne, na których pacjenci mogą czytać wiadomości od swoich lekarzy. Portale takie wysyłają powiadomienia bez zawartych w nich informacji PHI (np. „Drogi Użytkowniku, otrzymałeś nową wiadomość od „).

Pamiętaj, że powiadomienia push nie są domyślnie zabezpieczone. Mogą pojawić się na ekranie, nawet jeśli jest on zablokowany. Upewnij się więc, że nie wysyłasz żadnych informacji PHI za pośrednictwem powiadomień push. To samo dotyczy SMS-ów i wszelkich wiadomości automatycznych.

Źródło: Bridge Patient Portal

Inną rzeczą do rozważenia jest to, że FDA może sklasyfikować niektóre aplikacje mHealth jako urządzenia medyczne (oprogramowanie, które wpływa na proces podejmowania decyzji przez pracowników służby zdrowia).

Pamiętaj więc, aby przed rozpoczęciem rozwoju sprawdzić, czy Twoja aplikacja musi być zgodna z innymi przepisami dotyczącymi opieki zdrowotnej. Możesz sprawdzić ten test z Federalnej Komisji Handlu, aby uzyskać szybką odpowiedź.

Podsumowanie

Teraz masz minimalną listę cech oprogramowania zgodnego z HIPAA.

Same nie zagwarantują jego bezpieczeństwa. Nie ochronią Cię przed phishingiem lub inżynierią społeczną.

Ale posiadanie tych funkcji powinno przekonać audytora, że zrobiłeś wystarczająco dużo, aby chronić dane swoich klientów.

Aby audyty były mniej bolesne, dokumentuj wszystkie swoje wysiłki w zakresie zgodności z HIPAA. Dla każdej wersji swojej aplikacji przedstaw pisemne specyfikacje, plany testowania jej bezpieczeństwa i ich wyniki. Nie zapomnij też sprawdzić, czy musisz przestrzegać innych przepisów przed rozpoczęciem prac rozwojowych.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.