DiGA – co to?
DiGA (Digitale Gesundheitsanwendung), czyli cyfrowa aplikacja zdrowotna, to kategoria oprogramowania medycznego z oznakowaniem CE, które może być bezpośrednio refundowane przez niemieckie publiczne kasy chorych (GKV). Program powstał na mocy ustawy DVG z grudnia 2019 roku i jest prowadzony przez Federalny Instytut ds. Leków i Wyrobów Medycznych (BfArM).
Aplikacja wpisana do katalogu DiGA może być przepisywana 73 milionom osób objętych ubezpieczeniem GKV. BfArM rozpatruje kompletny wniosek w ciągu trzech miesięcy. Przygotowanie samego produktu i jego zaplecza technicznego do tej weryfikacji zwykle zajmuje jednak znacznie więcej czasu.
Wiele firm healthcare poświęca miesiące na przygotowanie dowodów klinicznych wymaganych przez BfArM. Doświadczenia zespołów, które przeszły już ten proces, pokazują jednak, że równie dużym, a często większym, wyzwaniem są wymagania techniczne.
Pracując nad Selfapy, platformą terapii CBT działającą na rynku niemieckim, przeszliśmy przez ten proces w praktyce. Nasz zespół przeanalizował i wdrożył ponad 120 wymagań BSI, usunął podatności wykryte podczas testów penetracyjnych aplikacji na Androida i iOS oraz dostarczył trzy wersjonowane wydania zgodnie z harmonogramem procesu certyfikacyjnego.
W tym artykule pokazujemy, czego to doświadczenie nauczyło nas o tworzeniu oprogramowania przygotowanego do wymagań DiGA.
Wymagania techniczne DiGA – zestawienie
| Wymaganie | Co oznacza w praktyce | Obowiązkowe od |
|---|---|---|
| Oznakowanie CE (klasa I lub IIa) | Aplikacja musi być regulowana jako wyrób medyczny zgodnie z MDR | DVG 2019 |
| Certyfikacja BSI TR-03161 | Certyfikacja bezpieczeństwa produktu obejmująca m.in. testy penetracyjne | 1 lipca 2025 |
| ISO 27001 ISMS | Niezależnie audytowany system zarządzania bezpieczeństwem informacji | 1 kwietnia 2022 |
| Kryteria ochrony danych DiGAV | Ponad 150 weryfikowalnych wymagań podzielonych na 12 obszarów tematycznych | DVG 2019 |
| Integracja z ePA | Eksport danych do elektronicznej dokumentacji pacjenta w formacie zgodnym z FHIR | 1 stycznia 2024 |
BSI TR-03161: certyfikowany jest produkt, nie firma
Certyfikacja zgodna z BSI TR-03161 dotyczy konkretnego produktu. Oznacza to, że wydanie nowej wersji major aplikacji może wiązać się z koniecznością ponownego przejścia procesu certyfikacyjnego. Założenie, że po pierwszym wydaniu „compliance mamy już za sobą”, może więc szybko okazać się błędne.
Weryfikacja jest bardzo konkretna. Obejmuje analizę white-box prowadzoną przez laboratoria certyfikowane przez BSI, w tym ręczny przegląd kodu pod kątem koncepcji implementacyjnych BSI oraz zgodności z OWASP Top Ten.
W przypadku Selfapy oznaczało to pracę z ponad 120 wymaganiami dotyczącymi m.in. ochrony danych, protokołów szyfrowania i zapobiegania wyciekom informacji.
Podatności wykrywane podczas pentestów rzadko są egzotycznymi przypadkami. Częściej dotyczą niewłaściwego zarządzania sesją, logowania mogącego nieumyślnie ujawniać wrażliwe informacje czy implementacji szyfrowania niespełniającej wymaganego standardu. Wykrycie takich błędów dopiero podczas testów certyfikacyjnych jest znacznie bardziej kosztowne i czasochłonne niż uwzględnienie odpowiednich wymagań już na etapie projektowania i developmentu.
BSI TR-03161 jest obowiązkowe dla wszystkich nowych aplikacji DiGA od 1 lipca 2025 roku. Zespoły, które sprawnie przechodzą przez tę fazę, wiedzą wcześniej, na co zwracają uwagę audytorzy i mogą zapobiegać problemom zamiast usuwać je przed certyfikacją. To jeden z powodów, dla których tworzenie oprogramowania medycznego wymaga innego podejścia niż standardowy rozwój produktu cyfrowego.
Ochrona danych: DiGAV wykracza poza wymagania RODO
RODO stanowi punkt wyjścia, ale w przypadku DiGA nie jest jedynym źródłem wymagań.
DiGAV, rozporządzenie wdrażające niemiecką ustawę o cyfrowej opiece zdrowotnej, precyzyjnie określa pięć celów, w których aplikacja DiGA może przetwarzać dane użytkowników: realizację przeznaczenia aplikacji, wykazanie efektów terapeutycznych, generowanie zbioru danych AbEM, zapewnienie funkcjonowania technicznego oraz dalszy rozwój produktu. Ten ostatni cel wymaga osobnej, wyraźnej zgody użytkownika.
Przetwarzanie danych w celu wykraczającym poza ten katalog, nawet jeśli użytkownik wyraził na nie zgodę zgodnie z RODO, może zagrozić statusowi DiGA.
BfArM ocenia zgodność w zakresie ochrony danych na podstawie ponad 150 weryfikowalnych kryteriów podzielonych na 12 obszarów tematycznych. Istotne jest przy tym rozróżnienie między wymaganiami „udokumentowanymi”, czyli opisanymi w odpowiednich politykach i procedurach, a wymaganiami rzeczywiście „wdrożonymi” i funkcjonującymi w organizacji. Sama dokumentacja compliance nie wystarczy. Za zapisanymi procedurami muszą stać realne procesy operacyjne oraz możliwe do wykazania mechanizmy ich monitorowania i doskonalenia.
Certyfikat ISO 27001 ISMS jest wymagany niezależnie od BSI TR-03161, obowiązek ten obowiązuje od 1 kwietnia 2022 roku. Jeden certyfikat nie zastępuje drugiego. Oba stanowią element dokumentacji składanej do BfArM.
Integracja z ePA: nie jednorazowe wdrożenie, lecz stałe zobowiązanie
Od 1 stycznia 2024 roku wszystkie aplikacje DiGA muszą umożliwiać eksport danych do niemieckiego systemu elektronicznej dokumentacji pacjenta (ePA) za pośrednictwem interfejsów zdefiniowanych przez Gematik. Format eksportowanych danych musi być czytelny dla człowieka i zgodny z FHIR, z uwzględnieniem mapowania semantycznego określonego w § 355 SGB V.
Integracja nie kończy się jednak w momencie jej pierwszego wdrożenia. Gdy Gematik aktualizuje specyfikacje interfejsów, co zdarza się regularnie, zespół ma sześć miesięcy na dostosowanie aplikacji do nowych wymagań.
Jeżeli integracja z ePA została potraktowana jako element dodany dopiero pod koniec projektu, każda taka zmiana może przerodzić się w poważne wyzwanie inżynieryjne. Znacznie lepiej sprawdza się podejście, w którym interfejs Gematik od początku stanowi integralną część architektury danych i posiada jasno zdefiniowaną warstwę abstrakcji. Dzięki temu zmiany specyfikacji można obsługiwać bez konieczności przebudowywania kolejnych warstw systemu.
Taka decyzja architektoniczna powinna zostać podjęta odpowiednio wcześnie, ponieważ integracja wpływa jednocześnie na uwierzytelnianie, modele danych oraz logikę eksportu. Integracja systemów IT w środowisku regulowanym znacząco różni się od połączenia dwóch standardowych API, inne są zarówno potencjalne scenariusze awarii, jak i wymagania dotyczące dokumentacji.
Co podejście software jako wyrób medyczny zmienia w codziennej pracy?
Kiedy Alex Unger, Head of Engineering w Selfapy, pisał, że nasz developer „szybko zaadaptował się do naszego sposobu tworzenia oprogramowania jako wyrobu medycznego (SaMD)”, to zdanie kryło za sobą znacznie więcej niż samą umiejętność pisania kodu.
Oprogramowanie medyczne powstaje według innych założeń niż standardowy produkt cyfrowy. Jednym z kluczowych wymagań jest pełna identyfikowalność: każde wymaganie powinno być powiązane z odpowiednim testem, a każdy test — z udokumentowanym wynikiem. Formalny charakter ma również zarządzanie zmianami. Jeżeli zespół usuwa podatność bezpieczeństwa wykrytą podczas pentestu, poprawka musi przejść przez udokumentowany proces przeglądu i weryfikacji, zanim problem będzie można uznać za zamknięty.
Tempo developmentu nadal może być wysokie, ale proces od pierwszego dnia musi zapewniać audytowalność. Dokumentacja objęta kontrolą wersji, jasno zdefiniowane procesy code review oraz automatyzacja testów ze śledzeniem wyników tworzą środowisko, w którym znacznie łatwiej wykazać zgodność podczas audytu. Z tego samego powodu w projekcie Mentalyc zbudowaliśmy od podstaw środowisko CI/CD oraz automatyzację testów.
Najwięcej problemów z przygotowaniem produktu do DiGA pojawia się wtedy, gdy wymagania regulacyjne próbuje się nałożyć na istniejący kod i procesy, które od początku nie były projektowane z myślą o takim środowisku. Dostosowanie gotowego rozwiązania jest zazwyczaj trudniejsze niż uwzględnienie tych wymagań już na etapie projektowania.
3 decyzje, które mogą zadecydować o przebiegu procesu
Pierwsza dotyczy architektury danych. Ograniczenia DiGAV związane z celami przetwarzania danych powinny wpływać na model danych jeszcze przed rozpoczęciem jego implementacji. Decyzje dotyczące tego, jakie informacje są zbierane, gdzie są przechowywane i w jaki sposób mogą być wykorzystywane, znacznie łatwiej i taniej podjąć na początku projektu niż zmieniać je przed certyfikacją.
Druga dotyczy sposobu zaprojektowania warstwy ePA. Warto traktować ją jako stale utrzymywany interfejs posiadający własną warstwę abstrakcji. Specyfikacje Gematik będą się zmieniać, dlatego architektura powinna od początku uwzględniać możliwość ich aktualizacji.
Trzecia dotyczy samego procesu developmentu. Certyfikacja BSI TR-03161 oraz proces oceny BfArM obejmują nie tylko efekt końcowy, ale również sposób, w jaki oprogramowanie jest rozwijane. Identyfikowalność wymagań, zarządzanie zmianami oraz dokumentowanie testów nie są dodatkiem do procesu certyfikacyjneg lecz stanowią jego integralną część.
Jeżeli produkt jest już rozwijany, a DiGA dopiero pojawiła się jako potencjalny kierunek wejścia na rynek niemiecki, warto możliwie wcześnie przeprowadzić analizę luk. Zidentyfikowanie braków na tym etapie jest znacznie mniej kosztowne niż odkrycie ich podczas procesu certyfikacyjnego.
🚀 Budujesz produkt z obszaru digital health na rynek niemiecki i chcesz sprawdzić, czy jego architektura jest przygotowana na wymagania DiGA? Porozmawiajmy.
