Tworzenie oprogramowania medycznego: czego naprawdę wymagają regulacje, interoperacyjność i budżet w 2026 roku?

CTO startupu telemedycznego zatwierdza plan na dwa kwartały: aplikacja pacjenta, portal lekarza, wideokonsultacje, a jako główna nowość — asystent AI, który na podstawie objawów podpowiada, czy umówić wizytę u lekarza rodzinnego, czy jechać na SOR. Partner technologiczny wycenia projekt na siedem miesięcy. Po czterech miesiącach konsultant regulacyjny czyta opis produktu na stronie i mówi jedno zdanie: „Ten triaż to wyrób medyczny klasy IIa”. Harmonogram, budżet i architektura zmieniają się tego samego popołudnia.

To jest cecha definiująca tworzenie oprogramowania medycznego. Sam kod rzadko jest trudniejszy niż w fintechu czy e-commerce. Różnica polega na tym, że jedno zdanie w opisie produktu może zmienić status prawny całego systemu, dane należą do najbardziej chronionej kategorii we wszystkich przepisach o ochronie danych, a oprogramowanie musi rozmawiać z systemami klinicznymi w standardach, z którymi większość programistów nigdy nie pracowała.

Poniżej pokazujemy, co to oznacza w praktyce w 2026 roku: jakie są rodzaje oprogramowania medycznego, kiedy oprogramowanie staje się wyrobem medycznym, jakie normy wyznaczają proces, czego wymagają RODO, EHDS, AI Act i polska platforma P1, dlaczego interoperacyjność jest najtrudniejszą częścią techniczną i ile kosztuje projekt regulowany w porównaniu z nieregulowanym. Artykuł nie jest poradą prawną ani regulacyjną.

Czym tworzenie oprogramowania medycznego różni się od innych projektów IT?

Trzy rzeczy wyróżniają ochronę zdrowia i każda ma bezpośredni koszt.

Status prawny produktu zależy od jego przewidzianego zastosowania. Ten sam algorytm może być funkcją wellness albo wyrobem medycznym — zależnie od tego, co producent deklaruje. Ta decyzja wyznacza proces wytwarzania, dokumentację, ścieżkę dopuszczenia do obrotu i odpowiedzialność, gdy coś pójdzie źle. Trzeba ją podjąć przed architekturą, a nie po premierze.

Dane należą do szczególnej kategorii. Dane o zdrowiu chroni art. 9 RODO, który zakazuje ich przetwarzania, chyba że zachodzi jedna z wymienionych podstaw prawnych. Naruszenia są też najdroższe ze wszystkich sektorów: raport IBM Cost of a Data Breach 2025 wskazał średni koszt naruszenia w ochronie zdrowia na poziomie 7,42 mln USD, a średni czas jego wykrycia i opanowania — 279 dni, o pięć tygodni dłużej niż średnia dla wszystkich branż. Ochrona zdrowia jest na szczycie tego rankingu od czternastu lat.

Oprogramowanie musi wpasować się w istniejący ekosystem kliniczny. Szpitale korzystają z systemów HIS, laboratoryjnych, radiologicznych, aptecznych i z krajowej platformy e-zdrowia. Nowy system, który nie wymienia z nimi danych, rzadko zostaje przyjęty, niezależnie od jakości interfejsu. Integracje często pochłaniają większą część budżetu niż nowe funkcje.

Nic z tego nie czyni projektów medycznych niemożliwymi ani nawet szczególnie wolnymi. Czyni je bezlitosnymi wobec decyzji podjętych za późno. Organizacje, którym się udaje, w pierwszych tygodniach rozstrzygają trzy kwestie: przewidziane zastosowanie każdego modułu, ścieżkę regulacyjną i cele integracji. Szerszy kontekst biznesowy — telemedycyna, wybór HIS, ROI z cyfryzacji — opisaliśmy w artykule o transformacji cyfrowej w ochronie zdrowia w Polsce. Tutaj skupiamy się na budowie oprogramowania.

Jakie rodzaje oprogramowania medycznego powstają dziś najczęściej?

„Oprogramowanie medyczne” to bardzo różne produkty. Ich profile regulacyjne i techniczne różnią się na tyle, że warto nazwać kategorię, zanim cokolwiek się wyceni.

Kategoria	Przykłady	Zwykle wyrób medyczny?	Główne wyzwanie techniczne
EDM, HIS i systemy szpitalne	Elektroniczna dokumentacja medyczna, systemy oddziałowe	Zwykle nie, chyba że moduły liczą dawki lub wspierają diagnozę	Integracje, migracja danych, wydajność, rejestr dostępu
Platformy telemedyczne	Wideokonsultacje, e-wizyty, grafiki, e-recepty	Zwykle nie (komunikacja), triaż może nim być	Dostępność, jakość wideo, weryfikacja tożsamości
Aplikacje i portale pacjenta	Rejestracja wizyt, wyniki badań, przypomnienia o lekach	Zwykle nie, chyba że interpretują wyniki	Dostępność cyfrowa, bezpieczeństwo, integracja z placówką
Zdalne monitorowanie pacjenta	Dane z glukometrów, ciśnieniomierzy, urządzeń noszonych	Często tak, jeśli generuje alerty kliniczne	Łączność z urządzeniami, jakość danych, logika alarmów
Wspomaganie decyzji klinicznych	Skale ryzyka, triaż, sugestie diagnostyczne	Często tak	Walidacja kliniczna, wyjaśnialność, zarządzanie ryzykiem
Oprogramowanie będące wyrobem medycznym (SaMD)	Analiza obrazów, algorytmy diagnostyczne, planowanie terapii	Tak, z definicji	Pełny regulowany cykl życia, ocena kliniczna
Integracje i middleware	Silniki integracyjne, bramki FHIR, łączniki do P1	Zwykle nie	Standardy (HL7 v2, CDA, FHIR, DICOM), mapowanie, niezawodność
Analityka i zdrowie populacyjne	Dashboardy, rejestry, platformy danych badawczych	Zwykle nie	Pseudonimizacja, zarządzanie danymi, wtórne wykorzystanie

Większość prawdziwych produktów to kombinacje. Platforma telemedyczna może składać się z modułów niebędących wyrobem (grafiki, wideo, płatności) i jednego modułu będącego wyrobem (triaż). Traktowanie całej platformy jako wyrobu mnoży koszty, a traktowanie całości jako zwykłego oprogramowania tworzy ryzyko prawne. Praktyczne rozwiązanie — rozdzielenie modułów architektonicznie i przez przewidziane zastosowanie — omawiamy niżej.

Kiedy oprogramowanie staje się wyrobem medycznym?

W Unii Europejskiej rozstrzyga o tym rozporządzenie (UE) 2017/745 w sprawie wyrobów medycznych (MDR). Oprogramowanie jest wyrobem medycznym, gdy producent przeznacza je do celu medycznego wobec konkretnych pacjentów — m.in. diagnozowania, zapobiegania, monitorowania, prognozowania, leczenia lub łagodzenia choroby. Kluczowe słowo to przeznaczenie: liczy się cel zadeklarowany w etykiecie, instrukcji używania i materiałach marketingowych, a nie to, co kod technicznie potrafi.

Podstawową wytyczną jest MDCG 2019-11, której pierwsza rewizja ukazała się w czerwcu 2025 roku. Prowadzi przez kwalifikację (czy to w ogóle wyrób?) i klasyfikację (jaka klasa ryzyka?). Rewizja 1 doprecyzowała przewidziane zastosowanie, oprogramowanie modułowe i regułę 11 oraz dodała tabele łączące znaczenie informacji dostarczanej przez oprogramowanie z powagą sytuacji zdrowotnej.

Klasyfikacja wynika z reguły 11 MDR, napisanej specjalnie dla oprogramowania:

• Oprogramowanie dostarczające informacji wykorzystywanych do podejmowania decyzji diagnostycznych lub terapeutycznych to domyślnie klasa IIa.
• Klasa IIb, jeśli takie decyzje mogą spowodować poważne pogorszenie stanu zdrowia lub interwencję chirurgiczną.
• Klasa III, jeśli mogą spowodować śmierć lub nieodwracalne pogorszenie stanu zdrowia.
• Oprogramowanie monitorujące procesy fizjologiczne to klasa IIa, a IIb, gdy monitoruje parametry życiowe, których zmiany mogą oznaczać bezpośrednie zagrożenie.
• Pozostałe oprogramowanie to klasa I.

W praktyce reguła 11 umieszcza większość oprogramowania wspomagającego decyzje w klasie IIa lub wyższej, co oznacza udział jednostki notyfikowanej w ocenie systemu zarządzania jakością i dokumentacji technicznej. Oprogramowanie klasy I producent certyfikuje sam, ale nadal potrzebuje systemu jakości, dokumentacji technicznej i nadzoru po wprowadzeniu do obrotu.

Wynikają z tego dwie praktyczne konsekwencje. Po pierwsze, tekst marketingowy jest dokumentem regulacyjnym. „Pomaga zdecydować, czy iść do lekarza” i „diagnozuje objawy” mogą umieścić tę samą funkcję w różnych kategoriach. Po drugie, okres przejściowy MDR nadal trwa dla starszych wyrobów: rozporządzenie (UE) 2023/607 przedłużyło go do 31 grudnia 2027 roku dla klasy III i implantowalnych wyrobów klasy IIb oraz do 31 grudnia 2028 roku dla pozostałych klas — ale tylko dla wyrobów dotychczasowych bez istotnych zmian. Nowe oprogramowanie od razu podlega MDR.

Jeśli planujesz sprzedaż w USA, obowiązują przepisy FDA dotyczące funkcji oprogramowania będących wyrobem (ścieżki 510(k), De Novo, PMA) z wyłączeniami dla części funkcji wspomagania decyzji klinicznych i wellness. Warto wcześnie ujednolicić deklarację przeznaczenia — rozbieżne deklaracje oznaczają dwa produkty do utrzymania.

Jakie normy wyznaczają proces: IEC 62304, ISO 13485, ISO 14971 i IEC 82304-1?

Rozporządzenia mówią, co trzeba wykazać, a normy zharmonizowane — jak producenci zwykle to robią. Dla oprogramowania rdzeń tworzą cztery normy.

IEC 62304 — cykl życia oprogramowania. Definiuje procesy wytwarzania i utrzymania oprogramowania wyrobów medycznych: planowanie, wymagania, architekturę, projekt szczegółowy, implementację, integrację, testy systemowe, wydanie, utrzymanie, zarządzanie konfiguracją, rozwiązywanie problemów i zarządzanie ryzykiem elementów oprogramowania. Jej centralnym pojęciem jest klasa bezpieczeństwa oprogramowania:

• klasa A — obrażenia lub uszczerbek na zdrowiu nie są możliwe;
• klasa B — możliwe są obrażenia niepoważne;
• klasa C — możliwa jest śmierć lub poważne obrażenia.

Klasa wyznacza głębokość dokumentacji. Klasa A wymaga wymagań, testów systemowych i zapisów wydania. Klasa C dodatkowo projektu szczegółowego do poziomu jednostek oprogramowania, weryfikacji jednostkowej i ściślejszej identyfikowalności. Obowiązuje wydanie 1.1 (zmiana 1 z czerwca 2015 roku), które przepisało regułę klasyfikacji i dodało klauzulę o oprogramowaniu dotychczasowym. Drugie wydanie jest w przygotowaniu — jego projekt zastępuje klasy A/B/C dwoma poziomami rygoru procesu i obejmuje oprogramowanie zdrowotne szerzej.

ISO 13485 — system zarządzania jakością. Norma systemu jakości dla producentów wyrobów medycznych: nadzór nad dokumentacją, sterowanie projektowaniem, zarządzanie dostawcami, działania korygujące i zapobiegawcze, szkolenia. Dla firmy programistycznej to organizacyjna rama wokół IEC 62304.

ISO 14971 — zarządzanie ryzykiem. Identyfikacja zagrożeń, szacowanie i kontrola ryzyk oraz ich monitorowanie po wydaniu. Zarządzanie ryzykiem oprogramowania według IEC 62304 włącza się w ten proces.

IEC 82304-1 — bezpieczeństwo produktów oprogramowania zdrowotnego. Obejmuje samodzielne oprogramowanie zdrowotne jako produkt, łącznie z wymaganiami dla dokumentów towarzyszących i działań po wprowadzeniu do obrotu, a w zakresie procesu wytwarzania odwołuje się do IEC 62304. Ma znaczenie dla oprogramowania zdrowotnego, które nie jest wyrobem, ale potrzebuje uznanego poziomu bezpieczeństwa.

W niemal każdym projekcie pojawiają się jeszcze dwie normy: IEC 62366-1 dotycząca inżynierii użyteczności (błędy użytkowania to jedno z głównych źródeł zagrożeń) i IEC 81001-5-1 dotycząca działań bezpieczeństwa w cyklu życia oprogramowania zdrowotnego.

Nic z tego nie wyklucza pracy zwinnej. IEC 62304 nie narzuca modelu cyklu życia, a raport techniczny AAMI TIR45 opisuje, jak stosować w jej ramach praktyki agile. Wymaga natomiast identyfikowalności każdego wymagania, środka kontroli ryzyka, testu i wydania. Zespoły, które automatyzują identyfikowalność w narzędziach, zachowują tempo. Zespoły, które robią to ręcznie w arkuszach przed każdym wydaniem — tracą je. Modele wytwarzania w środowiskach regulowanych porównaliśmy w artykule o modelach wytwarzania oprogramowania.

Czego od oprogramowania wymagają RODO, EHDS i polskie przepisy o e-zdrowiu?

Przepisy o ochronie danych i wymianie informacji dotyczą niemal każdego oprogramowania medycznego — niezależnie od tego, czy jest wyrobem.

RODO. Dane o zdrowiu to kategoria szczególna z art. 9. Oprogramowanie musi wspierać ważną podstawę prawną przetwarzania, minimalizację danych, kontrolę dostępu, rejestr zdarzeń, zasady retencji i prawa osób, których dane dotyczą. Przetwarzanie danych o zdrowiu na dużą skalę zwykle wymaga oceny skutków dla ochrony danych (art. 35), a przekazywanie poza UE — prawnego mechanizmu transferu.

Europejska Przestrzeń Danych dotyczących Zdrowia (EHDS). Rozporządzenie (UE) 2025/327 weszło w życie 26 marca 2025 roku i zmienia sytuację dostawców systemów EDM:

• 26 marca 2027 roku — ogólne stosowanie rozporządzenia;
• 26 marca 2029 roku — karty pacjenta i e-recepty oraz ich realizacja muszą być wymieniane między wszystkimi państwami członkowskimi przez infrastrukturę MyHealth@EU;
• 26 marca 2031 roku — dołączają obrazy medyczne, wyniki badań laboratoryjnych i wypisy szpitalne.

Systemy EDM będą musiały spełniać zharmonizowane wymagania interoperacyjności i rejestrowania zdarzeń, a pacjenci zyskają prawo do elektronicznego dostępu do danych i ich udostępniania. Jeśli budujesz komponent EDM z pięcioletnim horyzontem, wymagania EHDS należą do architektury już teraz.

Polska platforma P1. Od 8 stycznia 2020 roku obowiązkowe są e-recepty, od 8 stycznia 2021 roku e-skierowania, a od 1 lipca 2021 roku wszystkie podmioty lecznicze — publiczne i prywatne, także indywidualne praktyki — muszą raportować zdarzenia medyczne i udostępniać elektroniczną dokumentację medyczną przez platformę P1 prowadzoną przez Centrum e-Zdrowia. Każde oprogramowanie dla polskich placówek musi się z nią integrować.

Cyberbezpieczeństwo. Wiele podmiotów leczniczych to podmioty kluczowe lub ważne w rozumieniu dyrektywy NIS2, wdrożonej w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa obowiązującą od kwietnia 2026 roku. Przekłada się to na wymagania bezpieczeństwa wobec dostawców zapisywane w umowach.

HIPAA (USA). Dla produktów na rynek amerykański obowiązują Privacy Rule, Security Rule i zasady zgłaszania naruszeń. Dostawca oprogramowania przetwarzający dane w imieniu placówki podpisuje umowę business associate. W styczniu 2025 roku HHS opublikował projekt zmian Security Rule, który uczyniłby obowiązkowymi m.in. szyfrowanie danych w spoczynku i w tranzycie oraz uwierzytelnianie wieloskładnikowe. W połowie 2026 roku nadal był to projekt.

Jak AI Act wpływa na oprogramowanie medyczne wykorzystujące sztuczną inteligencję?

AI w ochronie zdrowia podlega jednocześnie MDR i AI Act (rozporządzenie (UE) 2024/1689). System AI, który jest wyrobem medycznym lub jego elementem bezpieczeństwa wymagającym oceny jednostki notyfikowanej, jest systemem wysokiego ryzyka w rozumieniu art. 6 ust. 1 AI Act.

Harmonogram zmienił się w 2026 roku. Pakiet Digital Omnibus dotyczący AI, opublikowany w Dzienniku Urzędowym 24 lipca 2026 roku i obowiązujący od 27 lipca 2026 roku, odroczył obowiązki dla systemów wysokiego ryzyka. Dla AI wbudowanej w produkty objęte unijnym prawodawstwem harmonizacyjnym z załącznika I — w tym wyroby medyczne — termin przesunięto na 2 sierpnia 2028 roku. Samodzielne systemy wysokiego ryzyka z załącznika III przesunięto na 2 grudnia 2027 roku. Głównym powodem było opóźnienie norm zharmonizowanych potrzebnych do wykazania zgodności.

Odroczenie nie oznacza, że temat można odłożyć. Obowiązki dla systemów wysokiego ryzyka obejmują system zarządzania ryzykiem, zarządzanie danymi treningowymi, walidacyjnymi i testowymi, dokumentację techniczną, rejestrowanie zdarzeń, przejrzystość wobec użytkowników, nadzór człowieka oraz wymagania dokładności, odporności i cyberbezpieczeństwa. Dla wyrobu medycznego ocenia się je razem z oceną zgodności według MDR, a znaczna część dowodów pokrywa się z pracą według IEC 62304 i ISO 14971. Produkt wprowadzony w 2027 roku będzie na rynku, gdy obowiązki zaczną obowiązywać — decyzje o zarządzaniu danymi i rejestrowaniu zdarzeń zapadają więc teraz.

Praktyczne konsekwencje dla procesu wytwarzania:

• Wersjonuj dane tak starannie jak kod. Zbiory treningowe i walidacyjne, ich pochodzenie i znane ograniczenia stają się częścią dokumentacji technicznej.
• Zaprojektuj nadzór człowieka w interfejsie. Lekarz musi móc zrozumieć, zmienić i zgłosić wynik systemu.
• Zaplanuj zarządzanie zmianą. Ponownie wytrenowany model może być istotną zmianą wyrobu medycznego. Z góry określ, które zmiany mieszczą się w uzgodnionym planie, a które wymagają nowej oceny.

Dlaczego interoperacyjność jest najtrudniejszą częścią techniczną?

W większości branż integracja oznacza REST API i uzgodnione schematy JSON. W ochronie zdrowia oznacza pracę ze standardami, które rozwijały się przez trzy dekady i współistnieją w tym samym szpitalu.

HL7 v2 — komunikaty z końca lat 80. — wciąż obsługuje dużą część przyjęć, zleceń i wyników wewnątrz szpitali. HL7 CDA porządkuje dokumenty kliniczne — polska elektroniczna dokumentacja medyczna opiera się na Polskiej Implementacji Krajowej HL7 CDA. DICOM obsługuje obrazowanie medyczne. HL7 FHIR to nowoczesny standard API oparty na zasobach, do którego coraz częściej odwołują się regulatorzy.

W przypadku FHIR wybór wersji ma znaczenie:

• R4 (2019) to pierwsze wydanie z treścią normatywną i wersja, do której odwołują się przepisy amerykańskie wydane na podstawie 21st Century Cures Act. To bezpieczny wybór dla nowych API.
• R5 opublikowano 26 marca 2023 roku jako wydanie próbne; nie dodało nowej treści normatywnej.
• R6 przeszło pierwsze głosowanie normatywne w styczniu 2026 roku, a kolejne rozpoczęło się w lipcu 2026 roku. Publikacja finalna spodziewana jest w 2026 lub 2027 roku.

Większość zespołów wybiera dziś R4 z warstwą abstrakcji ułatwiającą późniejszą migrację. Ważniejszy od wersji jest przewodnik implementacyjny: profile krajowe i regionalne określają, które pola są obowiązkowe, jakie słowniki obowiązują i jak działają identyfikatory. Dwa systemy „zgodne z FHIR”, używające różnych profili, nadal wymagają mapowania.

Drugim ukrytym kosztem są słowniki: SNOMED CT, LOINC, ICD-10 (i ICD-11), ATC dla leków. Mapowanie lokalnych kodów na słowniki standardowe to szczegółowa praca kliniczna, której programiści nie wykonają sami.

Trzecim są testy z prawdziwymi systemami. Platformy krajowe i dostawcy systemów szpitalnych udostępniają środowiska testowe z własną dostępnością, danymi i procedurami certyfikacji. Plan, w którym testy integracyjne zajmują dwa tygodnie na końcu projektu, prawie zawsze okazuje się błędny — integracja biegnie przez cały projekt. Ogólne podejście do integracji systemów przez API sprawdza się i tutaj, z dodatkową warstwą semantyki danych klinicznych.

Jak zabezpieczyć oprogramowanie medyczne, nie spowalniając dostaw?

Dane o kosztach naruszeń wyjaśniają, dlaczego bezpieczeństwo w ochronie zdrowia jest tematem dla zarządu. W praktyce kształtują je trzy grupy wymagań.

Oczekiwania regulatorów wobec wyrobów. W USA sekcja 524B ustawy FD&C wymaga od producentów „cyber devices” przedstawienia informacji o cyberbezpieczeństwie we wnioskach przed wprowadzeniem do obrotu — w tym wykazu komponentów oprogramowania (SBOM) obejmującego komponenty komercyjne, open source i gotowe oraz planu monitorowania i usuwania podatności po wprowadzeniu do obrotu. Finalne wytyczne FDA dotyczące cyberbezpieczeństwa wyrobów zaktualizowano 27 czerwca 2025 roku. W UE ogólne wymagania bezpieczeństwa i działania MDR obejmują bezpieczeństwo IT, a IEC 81001-5-1 opisuje związane z nim działania w cyklu życia.

Wymagania placówek. Szpitale wysyłają dziś kwestionariusze bezpieczeństwa obejmujące wyniki testów penetracyjnych, zarządzanie podatnościami, szyfrowanie, zarządzanie tożsamością, rejestrowanie zdarzeń i reagowanie na incydenty. Przekonujące odpowiedzi są częścią procesu sprzedaży.

Wzorce architektoniczne, które działają:

• Szyfrowanie wszędzie, z kluczami zarządzanymi oddzielnie od danych.
• Silna tożsamość pacjentów (krajowa identyfikacja elektroniczna, gdzie jest dostępna) i personelu (MFA, dostęp oparty na rolach, procedury awaryjnego dostępu z audytem).
• Niezmienny rejestr dostępu — kto, do którego rekordu i dlaczego sięgnął. W wielu krajach wymagany prawem i pierwsza rzecz sprawdzana po incydencie.
• Minimalizacja i separacja danych, na przykład przechowywanie identyfikatorów oddzielnie od danych klinicznych i pseudonimizacja w analityce.
• SBOM i zarządzanie zależnościami zintegrowane z pipeline’em, a nie składane przed audytem.

Bezpieczeństwo zautomatyzowane w pipeline’ie nie spowalnia zespołów. Bezpieczeństwo realizowane jako ręczna bramka przed każdym wydaniem — spowalnia. Opisaliśmy to w przewodniku DevSecOps 2026.

Jak wygląda proces wytwarzania w regulowanym projekcie medycznym?

Poniższe etapy opisują projekt oprogramowania będącego wyrobem medycznym. Oprogramowanie zdrowotne niebędące wyrobem przechodzi lżejszą wersję tej samej sekwencji.

1. Przewidziane zastosowanie i kwalifikacja. Deklaracja przeznaczenia, ustalenie statusu każdego modułu i klasyfikacja według reguły 11 (oraz przepisów FDA, jeśli dotyczy).
2. System jakości i plany. Wdrożenie lub rozszerzenie systemu ISO 13485, plan rozwoju oprogramowania według IEC 62304, plan zarządzania ryzykiem według ISO 14971 i plan inżynierii użyteczności według IEC 62366-1.
3. Wymagania i analiza ryzyka. Potrzeby użytkowników, wymagania systemowe i programowe, analiza zagrożeń i środki kontroli ryzyka — wszystko wzajemnie identyfikowalne. Opisanie najpierw procesów klinicznych, na przykład w notacji BPMN, znacznie poprawia kompletność wymagań.
4. Architektura i separacja. Elementy oprogramowania, ich klasy bezpieczeństwa i interfejsy. Oddzielenie modułów będących wyrobem od pozostałych oraz rejestr SOUP (oprogramowania o nieznanym pochodzeniu, czyli bibliotek zewnętrznych) z ich znanymi anomaliami.
5. Iteracyjny rozwój i weryfikacja. Sprinty z testami jednostkowymi, integracyjnymi i systemowymi proporcjonalnymi do klasy bezpieczeństwa oraz identyfikowalnością aktualizowaną w narzędziach.
6. Walidacja i użyteczność. Sumatywne testy użyteczności z reprezentatywnymi użytkownikami, ocena kliniczna (dla wyrobów) i walidacja działania algorytmów na niezależnych danych.
7. Ocena zgodności i wydanie. Dokumentacja techniczna, przegląd przez jednostkę notyfikowaną dla klasy IIa i wyższych, oznakowanie CE, rejestracja w EUDAMED; w USA odpowiedni wniosek do FDA.
8. Nadzór po wprowadzeniu do obrotu. Obsługa reklamacji, zgłaszanie incydentów, monitorowanie podatności, okresowe raporty bezpieczeństwa i sterowanie zmianą przy każdym wydaniu.

Etap, który najczęściej zaskakuje zespoły programistyczne, to ostatni. Wyrób medyczny nigdy nie jest „skończony”: każde wydanie to kontrolowana zmiana z oceną wpływu. Planowanie zespołu tak, jakby projekt kończył się na oznakowaniu CE, nie zostawia miejsca na obowiązki, które właśnie wtedy się zaczynają.

Ile kosztuje i jak długo trwa stworzenie oprogramowania medycznego?

Koszty zależą bardziej od zakresu niż od branży, więc zamiast widełek pokazujemy, jak regulacje zmieniają ten sam projekt. Przykładem jest platforma telemedyczna ze wstępu: aplikacja pacjenta, portal lekarza, wideokonsultacje i integracja z platformą P1.

Wariant 1 — oprogramowanie niebędące wyrobem, 7 miesięcy. Stawki to środki przedziałów z naszego benchmarku stawek body leasingu na 2026 rok; stawka analityka biznesowego i kierownika projektu (190 zł/h) to nasze założenie. Przyjmujemy 160 godzin miesięcznie na etat.

Rola	Etat	Stawka (zł/h)	Koszt w 7 miesięcy
Senior backend developer	2	220	492 800 zł
Mid backend developer	1	155	173 600 zł
Senior frontend / mobile developer	1	205	229 600 zł
Inżynier automatyzacji testów	1	165	184 800 zł
Senior DevOps engineer	0,5	240	134 400 zł
Senior security engineer	0,25	255	71 400 zł
Analityk biznesowy / kierownik projektu	1	190	212 800 zł
Razem	6,75		1 499 400 zł

Wariant 2 — ta sama platforma z modułem triażu klasy IIa, 10 miesięcy. Na podstawie doświadczenia projektowego dodajemy testera weryfikacji (1 etat, 120 zł/h), specjalistę ds. regulacji i jakości (0,5 etatu, 220 zł/h — nasze założenie) oraz trzy miesiące na sterowanie projektowaniem, weryfikację, walidację użyteczności i dokumentację techniczną. Wynik: 2 510 000 zł — o 67% więcej niż w wariancie 1.

Wynikają z tego trzy obserwacje. Po pierwsze, dodatkowy koszt to głównie proces, a nie funkcje: weryfikacja, zarządzanie ryzykiem, dokumentacja i czas. Po drugie, szacunek nie obejmuje opłat jednostki notyfikowanej, oceny klinicznej, zewnętrznego doradztwa regulacyjnego ani kosztów prawnych, które mocno zależą od produktu i klasy. Po trzecie, różnica wyraźnie maleje, jeśli regulacji podlega tylko moduł triażu, a reszta platformy jest zaprojektowana jako oprogramowanie niebędące wyrobem — dlatego architektura modułowa to najskuteczniejsza dźwignia kosztowa.

W budżetach projektów medycznych najczęściej brakuje trzech pozycji, niezależnie od klasy wyrobu. Pierwsza to czas ekspertów klinicznych — lekarzy, pielęgniarek, farmaceutów, którzy opisują procesy, zatwierdzają mapowanie słowników i uczestniczą w testach użyteczności. Ich godziny są drogie i trudne do zaplanowania, a bez nich wymagania pozostają zgadywaniem. Druga to dane testowe: realistyczne, ale zanonimizowane lub syntetyczne zbiory danych pacjentów, bez których nie da się rzetelnie przetestować integracji ani algorytmów. Ich przygotowanie bywa osobnym małym projektem. Trzecia to środowiska i certyfikacja integracji — dostęp do środowisk testowych platform krajowych i dostawców systemów szpitalnych, ich harmonogramy i procedury odbiorowe. Z naszego doświadczenia dopisanie tych trzech pozycji do planu na etapie wyceny to najtańszy sposób, żeby uniknąć opóźnień, których żaden zespół programistów nie nadrobi.

Z harmonogramem jest podobnie. MVP tej wielkości bez statusu wyrobu to zwykle 6–9 miesięcy. Wyrób klasy IIa dodaje ocenę zgodności, której długość zależy od dostępności jednostki notyfikowanej i jakości dokumentacji. Ogólną logikę budżetowania pierwszych wersji produktu opisuje nasz przewodnik po kosztach MVP. Przy umowach o stałej cenie w projektach regulowanych warto najpierw przeczytać, kto naprawdę płaci za przeniesienie ryzyka — niepewność regulacyjna to dokładnie ten rodzaj ryzyka, który dostawcy doliczają do ceny.

Jak wybrać partnera do tworzenia oprogramowania medycznego?

Partner do oprogramowania medycznego potrzebuje więcej niż programistów, którzy „robili kiedyś aplikację zdrowotną”. Poniższa lista kontrolna oddziela dostawców zdolnych poprowadzić projekt regulowany od tych, którzy będą się uczyć na Twoim budżecie.

Kryterium	O co zapytać	Sygnał ostrzegawczy	Dobra odpowiedź
Wiedza regulacyjna	Jak sklasyfikowalibyście ten moduł według reguły 11?	„Regulacje to Wasza sprawa”	Pytanie o przewidziane zastosowanie przed wyceną
Dojrzałość procesu	Jak realizujecie IEC 62304 w sprintach?	Dokumentacja pisana na końcu	Identyfikowalność w narzędziach od pierwszego sprintu
System jakości	Czy pracujecie w naszym systemie ISO 13485, czy macie własny?	Brak doświadczenia ze sterowaniem projektowaniem	Jasny podział odpowiedzialności za system jakości w umowie
Interoperacyjność	Z jakimi profilami FHIR i platformami krajowymi się integrowaliście?	„Robimy REST API”	Konkretne standardy, profile i środowiska testowe, w tym P1
Bezpieczeństwo	Jak tworzycie SBOM i obsługujecie podatności po wydaniu?	Testy bezpieczeństwa tylko przed startem	SBOM i skanowanie w CI/CD, plan monitorowania po wydaniu
Ochrona danych	Gdzie przetwarzane są dane i kto ma do nich dostęp?	Ogólnikowe odpowiedzi	Opisane przepływy danych, hosting w UE, rejestr dostępu
Ciągłość zespołu	Co się stanie, gdy kluczowy programista odejdzie?	Brak polityki zastępstw	Gwarancja zastępstwa, transfer wiedzy, dokumentacja
Utrzymanie po wydaniu	Kto utrzymuje wyrób po oznakowaniu CE?	Projekt kończy się na wydaniu	Model utrzymania i sterowania zmianą uzgodniony z góry

Najbardziej wymowne jest pierwsze pytanie. Partner, który przed wyceną pyta, co będą deklarować Twoje materiały marketingowe, rozumie branżę. Partner, który wycenia na podstawie listy funkcji — nie rozumie, a różnica wyjdzie na jaw po czterech miesiącach, jak we wstępie.

Znaczenie ma też model współpracy. Wiele organizacji medycznych zatrzymuje u siebie właściciela produktu, wiedzę kliniczną i system jakości, a moce programistyczne rozszerza o zewnętrznych specjalistów. Ten model i potrzebne kompetencje opisaliśmy w artykule o doborze zespołu IT do projektu e-zdrowia, a zastosowania branżowe — w haśle słownika o body leasingu w sektorze opieki zdrowotnej.

Jak ograniczyć ryzyko regulacyjne bez spowalniania rozwoju produktu?

Regulacje podnoszą koszt błędów, a nie koszt dobrej inżynierii. Organizacje, które regularnie wydają regulowane oprogramowanie medyczne, łączy pięć nawyków.

Najpierw, na piśmie, ustal przewidziane zastosowanie każdego modułu. Od tego zależy każda późniejsza decyzja — klasyfikacja, architektura, głębokość testów, marketing. Wracaj do tego przy każdej zmianie planu produktu.

Projektuj z myślą o separacji. MDCG 2019-11 uznaje oprogramowanie modułowe: moduł będący wyrobem można oddzielić od pozostałych, jeśli interfejsy i odpowiedzialności są jasno określone. Regulowany silnik triażu za wyraźnym interfejsem pozwala modułom rejestracji, wideo i płatności rozwijać się w normalnym tempie.

Automatyzuj identyfikowalność i dowody. Łącz wymagania, ryzyka, zmiany w kodzie, testy i wydania w narzędziach, których zespół już używa. Dowody generowane przez pipeline są zawsze aktualne. Dowody składane przed audytem — nigdy.

Traktuj integrację jako ciągły strumień prac. Zaczynaj integrację z FHIR, CDA i platformą P1 w pierwszych sprintach, testuj wcześnie na prawdziwych środowiskach i budżetuj mapowanie słowników z udziałem klinicystów.

Zaplanuj życie po wydaniu. Nadzór po wprowadzeniu do obrotu, zarządzanie podatnościami, sterowanie zmianą modeli AI i aktualizacje wynikające z EHDS czy zmian platformy krajowej to praca ciągła. Obsadź ją jak pracę ciągłą.

Najważniejsze wnioski:

1. Przewidziane zastosowanie decyduje o wszystkim. Jedno zdanie w tekście marketingowym może zmienić funkcję w wyrób medyczny klasy IIa.
2. Reguła 11 umieszcza większość oprogramowania wspomagającego decyzje w klasie IIa lub wyższej, co wymaga udziału jednostki notyfikowanej.
3. IEC 62304, ISO 13485 i ISO 14971 da się pogodzić z agile — pod warunkiem automatyzacji identyfikowalności.
4. Lata 2027–2031 przynoszą nowe obowiązki: EHDS od marca 2027 roku, przepisy AI Act dla medycznej AI wysokiego ryzyka od sierpnia 2028 roku, a na rynku USA prawdopodobnie ostrzejszą HIPAA Security Rule.
5. W naszym przykładzie regulacje podniosły koszt budowy o 67%, głównie przez weryfikację i dokumentację. Architektura modułowa to największa dźwignia, żeby ten koszt ograniczyć.

W ARDURA Consulting od ponad 10 lat budujemy oprogramowanie i zespoły IT dla klientów w Polsce, Europie, na Bliskim Wschodzie i w USA, w tym dostarczamy specjalistów IT dla sektora healthcare. W ramach usług software developmentu pomagamy placówkom medycznym i firmom healthtech tak układać produkty, żeby moduły regulowane pozostały regulowane, a cała reszta rozwijała się szybko.

Jeśli planujesz oprogramowanie medyczne i chcesz przed zatwierdzeniem budżetu skonsultować klasyfikację, architekturę lub skład zespołu, porozmawiaj z naszym zespołem.