HIPAA i FDA w tworzeniu aplikacji dla ochrony zdrowia: które przepisy mają zastosowanie do twojej aplikacji

HIPAA reguluje prywatność danych pacjentów, a FDA określa, czy twoje oprogramowanie jest regulowanym wyrobem medycznym. Odpowiadają na różne pytania, a wiele aplikacji zdrowia cyfrowego musi spełniać oba zestawy wymagań, dlatego traktowanie tego jako wyboru „albo–albo” źle się kończy.

Najważniejsza różnica polega na tym, że HIPAA chroni prywatność i bezpieczeństwo danych pacjentów, a FDA decyduje o dopuszczeniu wyrobu. W zależności od tego, co robi aplikacja i jakie składa deklaracje, może podlegać jednemu z tych reżimów, obu albo żadnemu. Po lekturze tego artykułu będziesz wiedzieć, który z nich dotyczy twojej aplikacji, gdzie się pokrywają i co każdy z nich zmienia w procesie tworzenia.

Podsumowanie

Zgodność aplikacji zdrowia cyfrowego najlepiej potraktować jako wczesną decyzję architektoniczną. Od pierwszego dnia wpływa ona na model danych, kontrolę dostępu, język deklaracji i harmonogram wydania. Jeśli wybierzesz niewłaściwą oś albo pominiesz jedną z nich, koszty szybko dadzą o sobie znać — czy to w postaci zbyt rozbudowanej aplikacji wellness, czy narzędzia klinicznego bez zabezpieczeń, których oczekują regulatorzy. Jeśli rozstrzygniesz to odpowiednio wcześnie, koszt będzie stanowił ułamek tego, co późniejsze dostosowanie.

HIPAA i FDA odpowiadają na dwa różne pytania

HIPAA obejmuje to, kto może uzyskać dostęp do danych pacjenta, jak są one przesyłane i co się dzieje, jeśli dojdzie do ich wycieku. Z kolei FDA określa, czy twoje oprogramowanie kwalifikuje się jako regulowany wyrób medyczny i co musisz zrobić, zanim trafi na rynek. 

Żaden z tych reżimów nie odpowiada jednak na pytanie, na które odpowiada drugi. I to właśnie dlatego founderzy, którzy ujmują to jako „HIPAA czy FDA”, zwykle wpadają w impas. Ogólne poradniki o „zgodności aplikacji dla ochrony zdrowia”, które wrzucają oba tematy do jednego worka, też rzadko pomagają, bo odpowiadają na pytanie, którego nikt faktycznie nie zadał.

W obrębie tego samego produktu działają dwie odrębne osie:

• Oś prywatności dotyczy chronionych informacji zdrowotnych (PHI), niezależnie od tego, co robi z nimi twoja aplikacja. 

• Oś wyrobu dotyczy tego, jakie medyczne deklaracje składa twoja aplikacja, niezależnie od tego, jak starannie obchodzisz się z danymi. 

Aplikacja do medytacji i narzędzie diagnostyczne mogą przechowywać identyczną ilość PHI. Tylko jedno z nich kiedykolwiek będzie oceniane przez FDA.

Poniższa tabela pokazuje, gdzie zaczyna się każdy z tych reżimów, co go uruchamia i jakie są konsekwencje pomyłki:

Kiedy HIPAA ma zastosowanie do twojej aplikacji?

Twoja aplikacja podlega HIPAA od momentu, gdy zaczyna tworzyć, przechowywać lub przesyłać chronione informacje zdrowotne (PHI). Dotyczy to zarówno sytuacji, gdy tworzysz ją bezpośrednio dla podmiotu objętego przepisami, jak i wtedy, gdy działasz jako jego business associate. Wielkość zespołu ani etap projektu nie mają tu znaczenia. Obowiązek wynika z samych danych i to one od pierwszego dnia wyznaczają punkt wyjścia dla tworzenia aplikacji zgodnej z HIPAA.

PHI obejmuje więcej, niż możesz się spodziewać. Wystarczy imię i nazwisko powiązane z terminem wizyty, identyfikator urządzenia przypisany do wskaźnika zdrowotnego albo zgłoszenie do wsparcia, w którym wspomniano o objawie. Do zakwalifikowania tych danych nie jest potrzebna ani diagnoza, ani wynik badania laboratoryjnego.

Dotyczy to podmiotów takich jak świadczeniodawcy opieki zdrowotnej, plany zdrowotne i clearinghouses. Jeśli tworzysz rozwiązanie dla jednego z nich albo przetwarzasz dane w ich imieniu, jesteś business associate. Ten status wymaga podpisania Business Associate Agreement (BAA), zanim jakiekolwiek PHI zacznie być przekazywane — także przez zewnętrzne API i dostawców LLM, którzy mają kontakt z tymi danymi.

Z tego wynikają podstawowe obowiązki, które bezpośrednio odpowiadają regule bezpieczeństwa HIPAA jako bazowemu standardowi dla prywatności danych medycznych. Oznacza to szyfrowanie danych w spoczynku i w tranzycie, kontrolę dostępu opartą na rolach, logowanie audytowe oraz proces powiadamiania o naruszeniu który sprawdza się także pod presją. 

Te obowiązki mają realny wymiar finansowy. HHS podniósł maksymalną karę cywilną dla najpoważniejszej kategorii naruszeń do 2,19 mln USD za typ naruszenia rocznie, ze skutkiem od stycznia 2026 roku. Do tego dochodzi koszt samego naruszenia: incydenty w ochronie zdrowia kosztują średnio 7,42 mln USD, najwięcej spośród wszystkich branż śledzonych przez IBM.

W praktyce oznacza to, że model danych, strategia logowania i umowy z dostawcami muszą od początku uwzględniać PHI.

Kiedy do gry wkracza FDA?

Gdy twoje oprogramowanie zaczyna służyć celowi medycznemu, staje się FDA SaMD, czyli Software as a Medical Device. Decyduje o tym przeznaczenie i deklarowane zastosowania, a nie sprzęt. Licznik kroków i detektor arytmii mogą korzystać z identycznych sensorów; regulacje dotyczą aplikacji, która deklaruje wykrywanie schorzenia serca, a nie układu scalonego w jej wnętrzu.

Granica przebiega między ogólnym dbaniem o dobrostan a deklaracjami klinicznymi. Tracker fitness, który promuje zdrowy styl życia i nie zawiera deklaracji diagnostycznych ani terapeutycznych, zazwyczaj nie podlega regulacjom. Ten sam tracker staje się SaMD w chwili, gdy informujesz użytkowników, że potrafi wykryć konkretną chorobę.

W styczniu 2026 roku FDA zawęziła swój nadzór nad cyfrowymi produktami zdrowotnymi niskiego ryzyka. Urządzenia ubieralne z AI i trackery stylu życia mają teraz jaśniej wytyczoną drogę do pozostania w kategorii general wellness, niż przewidywały wytyczne z 2019 roku.

Klasyfikacja SaMD zależy od zamierzonego zastosowania i wskazań do użycia — to temat, którego ten artykuł nie omawia szczegółowo. Poziom ryzyka obejmuje klasy od I (niskie ryzyko) do III (wysokie ryzyko), a ścieżka wejścia na rynek — 510(k), De Novo lub PMA — wynika właśnie z tego. Podobnie jak w unijnym MDR, ramy klasyfikacji SaMD opierają się na podejściu uwzględniającym ryzyko, aby określić właściwą ścieżkę regulacyjną, mimo że produkty klasyfikuje się niezależnie w każdym systemie regulacyjnym. 

Narzędzie do wsparcia decyzji klinicznych dobrze pokazuje, jak szczegółowa bywa ta granica. Oprogramowanie, które podsumowuje dane pacjenta do przeglądu przez lekarza i umożliwia mu samodzielne podjęcie decyzji, często nie podlega regulacjom dotyczącym wyrobów medycznych zgodnie z wytycznymi FDA dotyczącymi CDS z 2026 roku. Zmienia się to, gdy oprogramowanie zaczyna rekomendować konkretną diagnozę lub leczenie, a lekarz nie ma realnej możliwości wcześniejszej weryfikacji.

Dokładne zrozumienie tej granicy ma kluczowe znaczenie przy określaniu czy twój cyfrowy produkt zdrowotny jest wyrobem medycznym. 

Jak klasyfikacja wygląda w praktyce: aparaty słuchowe Eargo klasy II FDA

Eargo pokazuje, gdzie ta granica przebiega w praktyce. Jego aparaty słuchowe to wyroby klasy II FDA, sprzedawane bezpośrednio konsumentom i promowane w kontekście codziennej troski o słuch. Taki wellnessowy sposób komunikacji nie przenosi ich poza kategorię wyrobów medycznych; to dopuszczenie nadal określa, jakie deklaracje produkt może składać i jak trafia na rynek. 

Stworzyliśmy kompanijną aplikację na iOS, aplikacje na Androida i aplikacje webowe, które łączą się z tymi urządzeniami w trzech generacjach sprzętu, tworzone we współpracy z audiologami Eargo i uwzględniające wyniki badań klinicznych w każdym wydaniu. Gdy oprogramowanie współdziała z takim dopuszczonym urządzeniem, kwestia samego urządzenia bezpośrednio kształtuje proces tworzenia: co aplikacja może deklarować, jak duży wkład kliniczny stoi za każdą zmianą i jaka dokumentacja jest z nią dostarczana.

HIPAA a FDA: jak naprawdę działa podwójna regulacja

Oprogramowanie podlegające nadzorowi FDA rzadko obywa się bez PHI. Te dwa reżimy regulacyjne zwykle nakładają się na siebie. Founderzy, którzy wyjaśnią już kwestię FDA, często zakładają, że HIPAA to osobny, opcjonalny temat. To założenie pomija połowę obrazu.

Pułapka aplikacji wellness dotyka więcej zespołów, niż powinna. Jedno stwierdzenie marketingowe — jedna linijka w opisie w app storze obiecująca wykrywanie lub diagnozowanie czegokolwiek — może z dnia na dzień zamienić ogólną aplikację wellness w SaMD. Taka zmiana od razu nakłada obowiązki wobec FDA. Zwykle oznacza też, że aplikacja już wcześniej przetwarzała dość PHI, by uruchomić wymogi HIPAA. Tyle że nikt jej pod to nie projektował, bo produkt zaczynał jako narzędzie wellness.

Znaczenie ma też moment, bo oba reżimy działają według różnych harmonogramów. Prace nad prywatnością zaczynają się w momencie, gdy pierwszy commit dotyka PHI — na długo przed tym, jak ustalisz, co produkt ma deklarować. Kwestia urządzenia rozstrzyga się później, gdy zdefiniujesz zamierzone zastosowanie, często bliżej premiery. Projektuj pod HIPAA od pierwszego dnia, niezależnie od tego, jak ostatecznie rozstrzygniesz kwestię FDA.

Jak ustalić, co cię dotyczy

W większości przypadków wszystko sprowadza się do dwóch pytań: czy gdziekolwiek w aplikacji pojawia się PHI i czy jakakolwiek jej część wysuwa deklarację kliniczną? 

Twoje odpowiedzi przypiszą cię do jednej z trzech kategorii pokazanych poniżej:

Przejdź przez te pytania dla swojej aplikacji i odpowiedz tak lub nie na każde z nich:

1. Czy twoja aplikacja tworzy, przechowuje lub przesyła jakiekolwiek dane, które identyfikują osobę i dotyczą jej zdrowia?

2. Czy udostępniasz te dane świadczeniodawcy, planowi zdrowotnemu lub clearinghouse’owi albo zbierasz je w ich imieniu?

3. Czy twoja aplikacja deklaruje, że diagnozuje, leczy, wylecza, zapobiega lub łagodzi konkretną chorobę albo stan?

4. Czy twoja aplikacja podejmuje decyzje terapeutyczne lub kliniczne bez wcześniejszego przeglądu i potwierdzenia przez klinicystę?

5. Czy korzystasz z zewnętrznego API lub modelu AI, który przetwarza dane zdrowotne opisane w pytaniach 1 lub 2?

Twój wynik:

• Tak dla 1 lub 2, nie dla 3 i 4: dotyczy cię tylko HIPAA. Zacznij już teraz od BAA i technicznych zabezpieczeń.

• Tak dla 1 lub 2 oraz tak dla 3 lub 4 (co obejmuje większość przypadków): dotyczą cię FDA i HIPAA. Uwzględnij oba od pierwszego dnia.

• Nie dla wszystkich: na ten moment nie dotyczy cię żaden z nich, ale wracaj do tej checklisty za każdym razem, gdy dodajesz funkcję lub deklarację marketingową.

Potwierdź swoje odpowiedzi w narzędziu FTC's Mobile Health Apps Interactive Tool zanim ostatecznie domkniesz architekturę. To bezpłatne narzędzie, które za jednym razem sprawdza zasady HIPAA, FDA i FTC.

A co z UE?

W Europie podział przebiega wzdłuż tych samych dwóch osi:

• Po stronie prywatności GDPR pełni rolę HIPAA. 

• Po stronie wyrobów medycznych unijne MDR pełni rolę FDA. 

Jeśli tworzysz produkt jednocześnie na rynek USA i UE, zarządzasz równocześnie czterema ramami regulacyjnymi, a opisana wyżej logika nakładania się obowiązuje niezależnie po każdej stronie.

Jest jedna rzecz, na której zespoły wykładają się częściej niż na czymkolwiek innym: klasa ryzyka w USA nie przekłada się na UE. Dopuszczenie FDA w klasie II nie pozwala przewidzieć, do jakiej klasy ten sam produkt zostanie zakwalifikowany zgodnie z unijnym MDR — i odwrotnie. Każda klasyfikacja jest odrębna.

Przenoszenie produktu między rynkiem amerykańskim a europejskim wymaga jasnego zrozumienia klasyfikacji SaMD oraz tego, jak wchodzi ona w interakcję z szerszymi standardami ram regulacyjnych. Podobnie międzynarodowe przetwarzanie danych pacjentów wymaga takiego ułożenia działań, by spełniały rygorystyczne standardy prywatności danych medycznych po obu stronach Atlantyku.

Jak każda oś wpływa na tworzenie produktu

Jeśli potraktujesz zgodność z przepisami jako decyzję architektoniczną, obie osie staną się założeniami projektowymi już na wczesnym etapie, na długo, zanim w przeciwnym razie ujawniłyby się jako przeszkody.

Tworzenie aplikacji zgodnej z HIPAA zaczyna się w warstwie danych. To oznacza sposób szyfrowania PHI, to, kto może je odpytywać, oraz to, jak od pierwszego commitu rejestrowany jest każdy dostęp.

FDA bezpośrednio kształtuje tworzenie oprogramowania dla wyrobów medycznych. To ona decyduje, jakie deklaracje może zawierać twój interfejs użytkownika i jak duży nadzór klinicysty musi występować między twoim oprogramowaniem a decyzją. Decyduje też, czy twój proces wydawniczy musi mieć wbudowaną wymaganą przez FDA dokumentację i mechanizmy kontrolne, zanim wypuścisz produkt.

Ustalenie przed pierwszym commitem, która oś ma zastosowanie, pozwala uniknąć tych kosztów.

Ustalenie, które przepisy dotyczą twojej aplikacji, to pierwsza decyzja. Zbudowanie architektury, która je spełni, to kolejna. Jeśli jesteś na tym etapie, porozmawiaj z zespołem healthcare Monterail o tym, jak podchodzimy do zgodności z HIPAA i FDA jako wbudowanego elementu procesu tworzenia.