Krótka odpowiedź: oprogramowanie, które przetwarza dane o stanie zdrowia, podlega jednocześnie czterem rodzinom przepisów. Ochrona danych określa, co można robić z osobistymi danymi o stanie zdrowia: RODO (art. 9) w UE, HIPAA i zbiór przepisów stanowych w USA. Przepisy dotyczące systemów opieki zdrowotnej określają, jak dane muszą być przesyłane i udostępniane: Europejska Przestrzeń Danych o Zdrowiu (EHDS) w UE, TEFCA, USCDI i przepisy dotyczące blokowania informacji w USA. Bezpieczeństwo produktów ma zastosowanie, gdy oprogramowanie ma charakter medyczny: Rozporządzenie o Wyrobach Medycznych (MDR) i Rozporządzenie o Wyrobach Medycznych do Diagnostyki In Vitro (IVDR) w UE, przepisy FDA w USA, a normy IEC 62304 i ISO 13485 jako podstawowe standardy inżynieryjne i jakościowe. Bezpieczeństwo określa podstawowy poziom, który wszyscy muszą spełnić: ISO 27001 i 27799, NIS2 dla sektorów krytycznych, Zasada Bezpieczeństwa HIPAA. Tożsamość (eIDAS i Europejski Portfel Tożsamości Cyfrowej, NHS login, krajowe dowody tożsamości) przenika wszystkie cztery obszary.
Mapa
Mapa przepisów dotyczących danych medycznych grupuje zasady dotyczące oprogramowania przetwarzającego dane medyczne na rodziny: ochrona danych (art. 9 RODO, HIPAA, prawa stanowe USA), przepisy dotyczące systemów opieki zdrowotnej (EHDS, Cures Act, TEFCA), bezpieczeństwo produktów (MDR, IVDR, FDA), standardy inżynieryjne i jakościowe (IEC 62304, ISO 13485), bezpieczeństwo (ISO 27001, ISO 27799, NIS2, HIPAA Security Rule) oraz tożsamość (eIDAS 2).
| Rodzina | Przepis | Dotyczy | Czego wymaga |
|---|---|---|---|
| Ochrona danych | RODO, art. 9 i art. 35 | Każdego, kto przetwarza dane o stanie zdrowia mieszkańców UE | Podstawa prawna z art. 9 ust. 2, ocena skutków dla ochrony danych (DPIA), inspektor ochrony danych (DPO) w przypadku przetwarzania na dużą skalę, prawa, powiadomienie o naruszeniu w ciągu 72 godzin |
| Ochrona danych | HIPAA (Zasady dotyczące prywatności, bezpieczeństwa, naruszeń) | Podmioty objęte HIPAA i ich partnerzy biznesowi w USA | Dozwolone zastosowania, zabezpieczenia, powiadomienie o naruszeniu; nie obejmuje większości aplikacji konsumenckich |
| Ochrona danych | Przepisy stanowe USA (CCPA/CPRA, Washington My Health My Data…) | Firmy przetwarzające dane mieszkańców | Zgoda na dane o stanie zdrowia konsumentów, prawa do usunięcia, ograniczenia sprzedaży |
| System opieki zdrowotnej | EHDS, Rozporządzenie (UE) 2025/327 | Systemy EHR, aplikacje wellness twierdzące, że są interoperacyjne, posiadacze danych, organy dostępu do danych o zdrowiu | Dostęp pacjenta i przenoszenie danych w europejskim formacie wymiany, obowiązkowe MyHealth@EU, zezwolenia na wykorzystanie wtórne |
| System opieki zdrowotnej | 21st Century Cures Act, przepisy ONC HTI, TEFCA | Certyfikowane technologie medyczne w USA, świadczeniodawcy, sieci | API FHIR, dane USCDI, brak blokowania informacji, wymiana ogólnokrajowa |
| Bezpieczeństwo produktów | MDR 2017/745, IVDR 2017/746 | Oprogramowanie o przeznaczeniu medycznym dla pacjentów w UE | Klasyfikacja, ocena zgodności, ocena kliniczna, nadzór po wprowadzeniu do obrotu, oznakowanie CE |
| Bezpieczeństwo produktów | FDA (21 CFR 820/QMSR, 510(k), De Novo, PMA) | Oprogramowanie jako wyrób medyczny dla USA | Ścieżka przedrynkowa według klasy, system jakości, dokumentacja cyberbezpieczeństwa |
| Inżynieria | IEC 62304, IEC 82304-1, ISO 14971 | Zespoły tworzące oprogramowanie wyrobów medycznych | Cykl życia oprogramowania według klasy bezpieczeństwa, zarządzanie ryzykiem |
| Jakość | ISO 13485 | Producenci wyrobów | System zarządzania jakością obejmujący projektowanie, produkcję, reklamacje |
| Bezpieczeństwo | ISO/IEC 27001, ISO 27799, ISO 27701 | Dowolna organizacja; wytyczne specyficzne dla ochrony zdrowia | System zarządzania bezpieczeństwem informacji, kontrolki dotyczące ochrony zdrowia, rozszerzenie dotyczące prywatności |
| Bezpieczeństwo | NIS2, Dyrektywa 2022/2555 | Świadczeniodawcy, producenci wyrobów, dostawcy usług chmurowych i cyfrowych powyżej progów wielkości | Środki zaradcze, zgłaszanie incydentów w ciągu 24/72 godzin, odpowiedzialność zarządu |
| Bezpieczeństwo | Zasada Bezpieczeństwa HIPAA | Podmioty objęte HIPAA i partnerzy biznesowi w USA | Zabezpieczenia administracyjne, fizyczne i techniczne; analiza ryzyka |
| Tożsamość | eIDAS 2 i Europejski Portfel Tożsamości Cyfrowej | Usługi weryfikujące tożsamość obywateli UE | Akceptacja portfela do silnej identyfikacji od 2026–2027 |
Kto podlega jakim przepisom
Które przepisy dotyczące danych medycznych mają zastosowanie, zależy od tego, co robi oprogramowanie. Aplikacja konsumencka bez wskazań medycznych podlega art. 9 RODO, ocenie skutków dla ochrony danych (DPIA) i praktykom bezpieczeństwa; dodanie interpretacji czyni ją wyrobem medycznym zgodnie z MDR; platforma FHIR jest procesorem danych w rozumieniu RODO, a czasem podlega NIS2; szpital podlega wszystkim tym przepisom, a także NIS2 jako podmiot kluczowy.
- Aplikacja zdrowotna dla konsumentów bez wskazań medycznych (dziennik objawów, zapis wyników badań laboratoryjnych): RODO, art. 9 z wyraźną zgodą, DPIA, praktyka bezpieczeństwa na poziomie ISO 27001, a także etykieta aplikacji wellness EHDS, jeśli twierdzi, że łączy się z systemami EHR. Nie jest to wyrób medyczny, o ile jego zamierzone zastosowanie pozostaje niemedyczne. W USA: przepisy FTC i stanowe prawa dotyczące prywatności w zakresie zdrowia, a nie HIPAA.
- Ta sama aplikacja z funkcją interpretacji („Twój wynik sugeruje…”): wyrób medyczny zgodnie z MDR, reguła 11, zazwyczaj klasa IIa, z podstawami IEC 62304 i ISO 13485. Zobacz Czy aplikacja zdrowotna jest wyrobem medycznym? i Klasy SaMD.
- Dostawca platformy lub integracji FHIR: RODO jako podmiot przetwarzający (umowy z art. 28 RODO), ISO 27001, być może NIS2 jako dostawca infrastruktury cyfrowej lub usług ICT, obowiązki EHDS, gdy jest częścią systemu EHR, HIPAA jako partner biznesowy w USA.
- Szpital: wszystko powyższe jako administrator i operator, a także NIS2 jako podmiot kluczowy, krajowe przepisy dotyczące dokumentacji medycznej i terminy EHDS dotyczące połączenia z krajową infrastrukturą.
- Platforma badawcza: RODO, art. 9 ust. 2 lit. j) i art. 89, rozdział EHDS dotyczący wykorzystania wtórnego (zezwolenia od organu dostępu do danych o zdrowiu, bezpieczne środowiska przetwarzania) oraz standardy anonimizacji. Zobacz Wtórne wykorzystanie danych o zdrowiu.
W jakiej kolejności
Do zgodności z przepisami dotyczącymi danych medycznych najlepiej podejść w ustalonej kolejności: najpierw określić zamierzone przeznaczenie, ponieważ decyduje ono o tym, czy oprogramowanie jest wyrobem medycznym; następnie ochrona danych (podstawa prawna, DPIA, umowy powierzenia przetwarzania danych); następnie podstawowy poziom bezpieczeństwa zgodny z ISO 27001; następnie wymogi interoperacyjności, takie jak FHIR i EHDS lub USCDI; następnie ścieżka dotycząca wyrobu medycznego, jeśli dotyczy; na końcu kwestie transgraniczne.
- Określ zamierzone zastosowanie na piśmie. To decyduje, czy jesteś wyrobem medycznym, a wszystko inne wynika z tego.
- Najpierw ochrona danych: podstawa prawna, DPIA, umowy z podmiotem przetwarzającym, DPO. Są one potrzebne przed pierwszym rzeczywistym użytkownikiem, w każdym scenariuszu. Zobacz RODO, art. 9 w zakresie danych o zdrowiu i DPIA dla aplikacji zdrowotnej.
- Podstawowy poziom bezpieczeństwa: ISMS zgodny z ISO 27001, dopasowany do kontrolek dotyczących ochrony zdrowia z 27799; to również odpowiada na większość wymagań NIS2 i Zasady Bezpieczeństwa HIPAA. Zobacz ISO 27001 vs ISO 27799 i NIS2 dla szpitali i dostawców.
- Mandaty dotyczące interoperacyjności: FHIR i format wymiany obowiązujący na Twoim rynku (EHDS, USCDI/US Core), aby produkt nie został wykluczony z krajowej infrastruktury. Zobacz Wyjaśnienie USCDI i Wyjaśnienie TEFCA.
- Ścieżka dotycząca wyrobów, jeśli dotyczy: klasyfikacja, system jakości, cykl życia, ścieżka zgłoszenia do jednostki notyfikowanej lub FDA. Zaplanuj rok.
- Transgraniczność: różnice między HIPAA a RODO przy obsłudze obu rynków (HIPAA vs RODO), mechanizmy transferu, lokalizacja hostingu.
Gdzie Anpheros się plasuje
Anpheros Daily to osobisty rejestr zdrowia o deklarowanym niemedycznym przeznaczeniu: przechowuje, wyświetla i udostępnia dane, a nie interpretuje ani nie udziela zaleceń. Anpheros Platform to backend FHIR R4 oferowany klinikom i deweloperom jako podmiot przetwarzający zgodnie z art. 28 RODO, z kontrolą zgody przez pacjenta i dziennikami dostępu. Strony dotyczące przepisów w tym klastrze opisują zasady ich stosowania do każdego produktu tego typu; strona przejrzystości opisuje, jak Anpheros je stosuje do siebie.
Ta strona wyjaśnia przepisy dla zespołów produktowych i inżynieryjnych. Nie stanowi porady prawnej; teksty podane w sekcji Źródła są wiążące, a decyzje dotyczące Twojego przypadku podejmuje inspektor ochrony danych, jednostka notyfikowana lub doradca prawny. Ostatnia weryfikacja: październik 2026.
Powiązane strony
- Czy aplikacja zdrowotna jest wyrobem medycznym? UE MDR Reguła 11
- Twoje dane medyczne w UE: RODO, EHDS i Twoje prawa
- RODO, art. 9 w zakresie danych o zdrowiu
- DPIA dla aplikacji zdrowotnej
- HIPAA vs RODO
- NIS2 dla szpitali i dostawców technologii medycznych
- Standardy interoperacyjności w opiece zdrowotnej: mapa
- RODO dla deweloperów (strona deweloperska)
- Krajowe elektroniczne rejestry medyczne w Europie i USA
- MyHealth@EU i transgraniczne podsumowanie pacjenta
- Akt UE w sprawie sztucznej inteligencji i AI w ochronie zdrowia
- Wtórne wykorzystanie danych o zdrowiu
- Bezpieczeństwo i tożsamość w aplikacjach zdrowotnych
Źródła
- Rozporządzenie (UE) 2016/679 (RODO), EUR-Lex
- Rozporządzenie (UE) 2025/327 (Europejska Przestrzeń Danych o Zdrowiu), EUR-Lex
- Rozporządzenie (UE) 2017/745 (MDR), EUR-Lex
- Rozporządzenie (UE) 2017/746 (IVDR), EUR-Lex
- Dyrektywa (UE) 2022/2555 (NIS2), EUR-Lex
- HHS: HIPAA dla profesjonalistów
- ASTP/ONC: Trusted Exchange Framework and Common Agreement
- ISO/IEC 27001:2022
Najczęstsze pytania
Czy RODO dotyczy firmy z USA posiadającej użytkowników z UE?
Tak, zgodnie z art. 3 ust. 2, gdy tylko oferuje usługi osobom w UE lub monitoruje ich zachowanie, niezależnie od lokalizacji serwerów. Wymaga to wówczas przedstawiciela w UE, podstawy prawnej zgodnie z art. 9 oraz mechanizmu legalnego transferu.
Czy HIPAA jest bardziej rygorystyczne niż RODO?
Żadne z nich nie jest ściśle bardziej rygorystyczne. HIPAA ma węższy zakres (dotyczy tylko podmiotów objętych i partnerów biznesowych) i jest bardziej szczegółowe w kwestii zabezpieczeń; RODO jest szersze (dotyczy każdego, kto przetwarza dane mieszkańców UE), opiera się na prawach i wymaga podstawy prawnej dla każdego użycia. Produkt działający na obu rynkach musi spełniać oba.
Czy EHDS zastępuje RODO w zakresie danych o zdrowiu?
Nie. EHDS opiera się na RODO i dodaje obowiązki dla systemów EHR, dostępu pacjentów, wymiany transgranicznej i wykorzystania wtórnego. RODO pozostaje podstawą każdej operacji przetwarzania.
Od czego zacząć, jeśli nie mam zespołu ds. zgodności?
Napisz zamierzone zastosowanie, przeprowadź DPIA z wykorzystaniem szablonu, przyjmij podstawowy poziom bezpieczeństwa zgodny z ISO 27001 i używaj FHIR z profilami obowiązującymi na Twoim rynku. Te cztery kroki obejmują większość tego, o co zapyta pierwsza kontrola lub pierwszy klient szpitalny.
Wypróbuj za darmo w sandboksie
Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.
Za darmo · 30 syntetycznych pacjentów · bez karty
Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.
O Anpheros →