Od końca 2020 roku Ministerstwo Zdrowia rozesłało w ramach programu Domowej Opieki Medycznej 230 tys. pulsoksymetrów do chorych na COVID-19. Wyniki przesyłało potem nieco ponad 30 tys. osób, czyli, jak przyznał minister zdrowia Adam Niedzielski, zaledwie 10–15% odbiorców. Sprzęt trafił do domów, ale większość pomiarów nigdy nie dotarła do lekarzy. Pięć lat później, według badania Centrum e-Zdrowia, telemonitoring prowadzi 10,7% szpitali, a zdalną opiekę kardiologiczną – tylko 2,3% wszystkich placówek. Lukę między pomiarem w domu a lekarzem ma zamknąć integracja urządzeń medycznych.
Obejmuje ona całą drogę, jaką pokonuje odczyt od momentu, gdy urządzenie go zapisze, do chwili, gdy lekarz zobaczy go przy właściwym pacjencie. W aplikacjach ta droga zaczyna się zwykle od ciśnieniomierza z Bluetoothem, który pacjent zakłada w domu, a kończy w systemie, w którym pracuje przychodnia. Między tymi punktami jest kilka etapów, a na każdym coś może pójść nie tak. Poniżej śledzimy jeden pomiar od początku do końca, a potem opisujemy prace powtarzane przy każdym kolejnym urządzeniu, przepisy obowiązujące w Polsce i w UE oraz przygotowanie projektu przed pierwszą wyceną. Budżet i ryzyko rosną wraz z liczbą obsługiwanych typów urządzeń, a liczba pacjentów czy sprzedanych sztuk ma tu znacznie mniejsze znaczenie. Oprogramowanie dla branży medycznej z integracją urządzeń przez Bluetooth tworzymy od ponad dziesięciu lat dla przychodni, firm diagnostycznych i producentów rozwiązań medycznych, więc piszemy o tym z doświadczenia wyniesionego z wdrożeń.
Integracja urządzeń medycznych – definicja i dwie ścieżki
Pod tym hasłem kryją się dwa zadania, które poza nazwą niewiele łączy: jedno rozgrywa się w szpitalu, gdzie kardiomonitor albo respirator przekazuje dane do systemu szpitalnego przez oprogramowanie pośredniczące, drugie w aplikacji, która łączy się z urządzeniem należącym do pacjenta. Zamawiający często dostają ofertę na pierwsze, choć potrzebują drugiego.
Integracja urządzeń medycznych w trzech krokach
Integracja urządzeń medycznych to praca programistyczna, dzięki której pomiary z urządzenia trafiają do oprogramowania, które je przechowuje, pokazuje albo na ich podstawie działa, bez przepisywania liczb przez człowieka. Składają się na nią trzy elementy: połączenie z urządzeniem, przełożenie formatu danych producenta na własny oraz przypisanie każdego odczytu do dokumentacji właściwego pacjenta. Bliskie pojęcie zna polskie prawo: rozporządzenie, które w 2022 roku wprowadziło do koszyka świadczeń nadzór telemetryczny nad pacjentami z rozrusznikami, opisuje go jako „zdalną analizę danych technicznych i klinicznych, gromadzonych przez wyroby medyczne” przy użyciu systemów teleinformatycznych.
Jeśli zawiedzie którykolwiek z trzech elementów, wracamy do ręcznego wpisywania. Ciśnieniomierz, który daje się sparować, ale zwraca dane, których nie da się rozkodować, jest tak samo bezużyteczny jak taki, który nie łączy się wcale, a bezbłędnie odczytany wynik przypisany do niewłaściwej osoby szkodzi bardziej, niż gdyby go w ogóle nie było.
Integracja urządzeń medycznych a interoperacyjność
W materiałach producentów oba słowa padają zamiennie, ale przy pisaniu umowy różnica zaczyna mieć znaczenie. Integracja łączy punkt z punktem: ten model, ta wersja oprogramowania układowego (firmware'u), ten system. Interoperacyjność jest cechą systemu, który przyjmie dane z każdego urządzenia zgodnego z opublikowanym standardem. W Unii za deklaracją interoperacyjności idą zresztą konkretne obowiązki, które nakłada rozporządzenie o europejskiej przestrzeni danych dotyczących zdrowia (EHDS). Wyrób medyczny, który obiecuje współpracę z systemami elektronicznej dokumentacji medycznej, musi spełnić zasadnicze wymagania rozporządzenia, a aplikacja wellness, która deklaruje to samo, od 2029 roku potrzebuje oznakowania potwierdzającego zgodność i wpisu do unijnej bazy.
Obu pojęciom towarzyszy jeszcze trzecie – łączność, która oznacza tylko tyle, że urządzenie potrafi coś wysłać. Sama łączność bez integracji to ciśnieniomierz, który nadaje w próżnię.
W projektach aplikacji medycznych płaci się w praktyce za integrację, a liczy na interoperacyjność. Ciśnieniomierz zgodny ze standardowym profilem Bluetooth Blood Pressure odczyta każda aplikacja, która ten profil obsługuje. Urządzenie z zamkniętym formatem producenta wymaga kodu pisanego pod konkretną firmę, a ten kod przestaje działać w dniu, w którym producent coś zmieni.
Dwie ścieżki: aparatura szpitalna i aplikacja pacjenta
Integracja urządzeń medycznych wygląda zupełnie inaczej w szpitalu i w domu pacjenta, a od miejsca, w którym stoi urządzenie, zależy nawet źródło finansowania projektu.
| Aparatura szpitalna | Aplikacja pacjenta | |
|---|---|---|
| Typowe urządzenia | Kardiomonitory, respiratory, pompy infuzyjne | Domowe ciśnieniomierze, wagi, pulsoksymetry, glukometry |
| Sposób przesyłania danych | Łącza przewodowe, sieć szpitalna, bramki producentów | Bluetooth Low Energy do telefonu pacjenta |
| Kto odpowiada za połączenie | Dział IT szpitala i dostawca oprogramowania pośredniczącego | Twoja aplikacja |
| Dokąd trafiają dane | System szpitalny (HIS) lub kliniczny (CIS) | Twój backend, a potem ewentualnie system placówki |
| Najczęstsze problemy | Mapowanie urządzeń, zasady sieci szpitalnej, zamówienia publiczne | Praca w tle, parowanie, przypisanie pomiaru do pacjenta |
| Kto płaci | Szpital | Właściciel produktu |
W szpitalach integracja urządzeń medycznych dostała w ostatnich latach spory zastrzyk pieniędzy, bo inwestycja D1.1.2 z KPO finansowała wprost „systemy zbierania danych z urządzeń medycznych i ich integrację z systemem szpitalnym”, choć samej aparatury już nie. Wojewódzki Szpital Zespolony w Elblągu za niemal 15 mln zł, z czego 12 mln zł pochodziło z KPO, wdrożył system kliniczny, który automatycznie pobiera dane z kardiomonitorów, respiratorów, pomp infuzyjnych i aparatów do znieczulenia na oddziałach intensywnej terapii i blokach operacyjnych.
Coraz więcej dzieje się jednak w prawej kolumnie tabeli. Od maja 2023 roku NFZ płaci za nadzór telemetryczny nad pacjentami z wszczepionymi rozrusznikami i kardiowerterami, podczas gdy wcześniej zdalnie monitorowano około 1% z blisko 500 tys. takich chorych. W pilotażu Narodowego Instytutu Kardiologii pacjenci z niewydolnością serca codziennie ważyli się i mierzyli ciśnienie w domu. Waga i ciśnieniomierz sparowane ze smartfonem same wysyłały pomiary na platformę telemedyczną, a odczyt spoza ustalonych granic uruchamiał telefon od zespołu monitorującego i powiadomienie do poradni POZ. Potencjalnych użytkowników nie brakuje: tylko w 2024 roku 2,07 mln dorosłych zrealizowało receptę na paski do glukometru. Wszystkie te programy opierają się na sprzęcie, który stoi u pacjenta w domu, więc ciężar łączności przechodzi z działu IT szpitala na aplikację.
Integracja urządzeń medycznych na przykładzie pomiaru ciśnienia
Pojedynczy odczyt przekracza więcej granic, niż zakłada większość właścicieli produktów, a integracja urządzeń medycznych to suma tego, co dzieje się na każdej z nich. Tak wygląda cała droga pomiaru z domowego ciśnieniomierza, od którego zwykle zaczyna się produkt do zdalnego monitorowania pacjentów:
- Pacjent mierzy ciśnienie, a urządzenie zapisuje wynik we własnej pamięci.
- Ciśnieniomierz rozgłasza swoją obecność przez Bluetooth Low Energy, a aplikacja go wykrywa i nawiązuje połączenie.
- Aplikacja odczytuje odpowiednią charakterystykę i dostaje tablicę bajtów.
- Bajty zamieniają się w ciśnienie skurczowe i rozkurczowe, tętno, znacznik czasu oraz jednostkę.
- Odczyt jest szyfrowany, oznaczany identyfikatorem pacjenta i trafia do kolejki wysyłki.
- Backend sprawdza poprawność danych, zapisuje je i przekazuje do aplikacji dla lekarzy albo do systemu placówki.
Przy krokach trzecim i czwartym pomagają standardy. Na piątym produkty najczęściej zawodzą, i to tak, że długo nikt tego nie zauważa.
Parowanie i odczyt danych przez Bluetooth Low Energy
Urządzenia BLE udostępniają dane w postaci usług, z których każda zawiera charakterystyki o numerycznych identyfikatorach. Bluetooth SIG publikuje przydzielone numery dla typowych pomiarów medycznych, dlatego ciśnieniomierz zgodny z usługą Blood Pressure Service ma znaną charakterystykę, która zwraca ciśnienie skurczowe, rozkurczowe i średnie w ustalonym układzie. Wystarczy ją odczytać i rozkodować bajt flag określający jednostkę (mmHg albo kPa), żeby dostać dane, z którymi da się pracować.
Sporo urządzeń standard pomija. Producenci stosują własne usługi z nieudokumentowanym formatem danych – czasem dlatego, że sprzęt powstał przed profilem, a czasem po to, żeby klient nie wychodził poza ich aplikację. Dostęp do takich danych wymaga albo pakietu SDK producenta, udostępnianego zwykle po podpisaniu NDA, albo odtworzenia formatu z przechwyconej transmisji. Druga droga jest powolna i zawodna, a bywa też zakazana przez licencję, którą się zaakceptowało.
iOS i Android obsługują BLE przez własne interfejsy, które różnią się na tyle, że nawet wspólny kod wymaga osobnej obsługi każdej platformy. Aplikacja wieloplatformowa w React Native ma wspólny interfejs i logikę biznesową dla obu systemów, a cienka warstwa natywna zostaje tam, gdzie wymaga tego stos Bluetooth. W tej warstwie integracja urządzeń medycznych pochłania najwięcej pracy przy każdym nowym modelu.
Praca w tle – najsłabsze ogniwo
Jeśli przed każdym pomiarem trzeba otworzyć aplikację, część chorych tego nie zrobi, a w danych klinicznych pojawią się luki. Najtrudniejsze zadanie, jakie stawia przed zespołem integracja urządzeń medycznych w zdalnym monitorowaniu, to utrzymanie przepływu danych bez angażowania pacjenta, a poradniki na ten temat niemal je pomijają.
iOS utrzymuje połączenie Bluetooth w tle tylko pod określonymi warunkami. Aplikacja musi zadeklarować odpowiedni tryb pracy w tle, a Core Bluetooth wybudzi ją, gdy znane urządzenie przekaże dane – o ile poprawnie obsłużono zachowywanie i przywracanie stanu. Android ma własne ograniczenia: tryb Doze, zasady usług pierwszoplanowych zaostrzane niemal w każdej wersji systemu i agresywne zamykanie procesów przez nakładki producentów telefonów, które z dokumentacją Androida mają niewiele wspólnego.
Dla produktu oznacza to kilka rzeczy:
- Pomiary będą przychodzić z opóźnieniem. Backend musi przyjmować odczyty w dowolnej kolejności, zamiast zakładać, że przychodzą chronologicznie.
- Urządzenia gromadzą zaległości. Ciśnieniomierz z pamięcią oddaje przy następnym połączeniu wszystko, co zebrał, więc aplikacja musi porównywać je z danymi na serwerze i usuwać duplikaty. Sprawa się komplikuje, gdy z jednego konta pacjenta korzystają dwa telefony.
- Zużycie baterii to ryzyko dla całego produktu. Zbyt częste skanowanie wyczerpuje telefon, a wtedy pacjent po prostu odinstalowuje aplikację.
- Emulator niczego tu nie udowodni. Testy prowadzi się na trzyletnim Androidzie z nakładką producenta oszczędzającą baterię, bo taki telefon ma w ręku prawdziwy pacjent.
Przerwy w przepływie danych trzeba przyjąć za pewnik i zaprojektować uzgadnianie danych od pierwszego dnia, bo produkt do zdalnego monitorowania jest wart dokładnie tyle, ile pomiarów dociera na serwer.
Przekazanie pomiarów dalej, czyli do systemu placówki
Aplikacji dla lekarzy, którą dostarczasz sam, wystarczy własna baza danych. Kiedy jednak lekarz chce widzieć te liczby w programie, w którym prowadzi dokumentację, zadanie zmienia się w integrację z systemem gabinetowym albo szpitalnym, a na tym etapie polskie realia wyglądają inaczej, niż sugerują zagraniczne poradniki. Platforma P1 wymienia elektroniczną dokumentację medyczną w standardzie HL7 CDA w polskiej implementacji krajowej i profilach IHE XDS.b, a HL7 FHIR służy tam wyłącznie do raportowania zdarzeń medycznych. Kanału, którym domowy pomiar ciśnienia mógłby trafić do platformy albo Internetowego Konta Pacjenta, na liście udostępnionych interfejsów nie ma.
Pomiary trafiają więc do systemu konkretnej placówki, a dalsze decyzje należą do lekarza. Rozporządzenie w sprawie dokumentacji medycznej pozwala włączyć do dokumentacji materiały udostępnione przez pacjenta albo odnotować z nich informacje istotne dla leczenia, ale nie wymaga importowania każdego odczytu. Zwykle kończy się to zestawieniem trendów i przekroczeń zamiast tysięcy pojedynczych wyników w historii choroby.
Technicznie przesłanie pomiaru do systemu gabinetowego to tydzień pracy, o ile producent tego systemu udostępnia API. Na samą zgodę na zapis trzeba jednak czasem czekać miesiącami: dostęp zależy od dostawcy oprogramowania placówki, jego zasad i często od umowy handlowej, a takich spraw nie da się załatwić w jednym sprincie. Właśnie dlatego tę część rozpoznaje się na samym początku projektu, tak samo jak każdą inną integrację systemów IT. Za kilka lat może się to zmienić: EHDS daje pacjentowi prawo do samodzielnego dopisywania informacji do własnej dokumentacji elektronicznej, ale ten przepis zacznie działać dopiero w 2029 roku.
Praca przy każdym urządzeniu i ramy prawne
Drugi typ urządzenia kosztuje niemal tyle samo co pierwszy, co zaskakuje większość zamawiających, bo przy nim powtarza się prawie całą pracę integracyjną. Do tego dochodzą przepisy: integracja urządzeń medycznych wchodzi na teren regulowany wcześniej, niż zakłada wiele zespołów produktowych.
Prace powtarzane przy każdym typie urządzenia
Przy każdym nowym urządzeniu integracja urządzeń medycznych obejmuje te same kroki:
- Zdobycie egzemplarza i dokumentacji, a przy zamkniętym formacie także SDK razem z licencją, która się z nim wiąże.
- Wykrywanie, parowanie i ponowne łączenie z uwzględnieniem kaprysów danego modelu. Różnice dotyczą powiązania urządzeń (bondingu), wejścia w tryb parowania, które czasem wymaga przycisku, i reakcji na próbę połączenia z drugiego telefonu.
- Rozkodowanie danych z obsługą jednostek, precyzji i stref czasowych. Waga podająca masę w funtach to całkiem realne zgłoszenie do supportu.
- Przypisanie każdego pomiaru do właściwej osoby, co ma największe znaczenie w domach, w których z jednego ciśnieniomierza korzystają dwie osoby.
- Testy na fizycznym urządzeniu w kolejnych wersjach firmware'u. Trzymamy do tego prawdziwy sprzęt na biurkach, bo integracja, która przechodzi testy w symulatorze, a zawodzi na fizycznym urządzeniu, to w tej branży norma.
Warstwę transmisji i wysyłkę na serwer pisze się raz i wykorzystuje przy kolejnych urządzeniach, natomiast rozkodowanie danych, zachowanie przy parowaniu i cykl testów zaczynają się za każdym razem od zera. Z punktu widzenia przepisów urządzenia też nie są sobie równe: ciśnieniomierz i pulsoksymetr podlegają unijnemu rozporządzeniu MDR, a glukometr do samokontroli, jako wyrób do diagnostyki in vitro, rozporządzeniu IVDR.
Integracja urządzeń medycznych potrafi pochłonąć skrajnie różną ilość pracy, co dobrze widać na naszych projektach. Platforma Vheda Health, którą rozwijamy od 2014 roku, składa się z backendowego API i aplikacji webowej dla lekarzy, a łączy się z czterema kategoriami urządzeń: glukometrem, pulsoksymetrem, ciśnieniomierzem i termometrem.
Dla Vheda Health zbudowaliśmy też aplikację mobilną dla pacjentów na iOS i Androida, z ponad 40 funkcjami i ośmioma zintegrowanymi urządzeniami medycznymi, które przez BLE przesyłają pomiary wagi, tętna, ciśnienia i poziomu glukozy. Klient ten sam, a skala prac integracyjnych różni się o rząd wielkości, przede wszystkim przez liczbę urządzeń.
Bezpieczeństwo danych: RODO, ocena skutków i ustawa o KSC
Dane z urządzenia są danymi o zdrowiu od chwili, w której opuszczą ciśnieniomierz, więc przepisom o ochronie danych podlega cała integracja urządzeń medycznych, łącznie z telefonem pacjenta. Szyfrowanie zaczyna się na łączu BLE i kończy na serwerze. Pomiary potrzebują takiej samej ścieżki audytu jak wszystko, co wpisuje lekarz. Z jednym dodatkiem: zapis powinien zawierać identyfikator urządzenia, które wygenerowało wartość, i czas jej dotarcia na serwer. Pomiar, który pojawi się z sześciogodzinnym opóźnieniem, wygląda jak zdarzenie kliniczne, jeśli nikt nie odnotował zwłoki.
RODO zalicza dane o zdrowiu do szczególnych kategorii (art. 9), wymaga ochrony danych już na etapie projektowania (art. 25) i zabezpieczeń odpowiadających ryzyku, w tym szyfrowania i regularnego testowania (art. 32). Przy ciągłym strumieniu pomiarów najwięcej pracy daje jednak zasada minimalizacji, bo z góry trzeba ustalić zakres zapisywanych danych, ich szczegółowość i okres przechowywania. Do tego dochodzi ocena skutków dla ochrony danych, bo wykaz Prezesa UODO wśród operacji, które jej wymagają, wymienia wprost przetwarzanie danych z „opasek medycznych” przesyłanych przez smartfon.
Ryzyko nie jest teoretyczne. W 2026 roku z systemów MyDr wyciekły dane, które mogą dotyczyć 18,8 mln osób, a we wrześniu Prezes UODO zapowiedział szersze kontrole przetwarzania danych o zdrowiu do końca roku. Od kwietnia 2026 roku obowiązuje też znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa, która obejmuje większe podmioty lecznicze, a wśród podmiotów ważnych wymienia producentów wyrobów medycznych. Do kwietnia 2027 roku objęte nią podmioty muszą wdrożyć system zarządzania bezpieczeństwem informacji i procedurę zgłaszania incydentów w ciągu 24 i 72 godzin, a przy wyborze dostawców oprogramowania – brać pod uwagę jakość i podatności ich produktów. Wpływ tych obowiązków na budżet opisujemy w artykule Ile wynosi koszt oprogramowania medycznego w 2026 roku?.
Granica między aplikacją a wyrobem medycznym
Ciśnieniomierz z oznakowaniem CE trafia do pacjenta z dokumentacją producenta, ale ta obejmuje wyłącznie sprzęt, a aplikację ocenia się osobno. Sama integracja urządzeń medycznych nie czyni jeszcze z niej wyrobu – przesądza o tym to, co aplikacja robi z odebranymi danymi.
Unijne wytyczne MDCG 2019-11, zaktualizowane w czerwcu 2025 roku, rysują granicę dość wyraźnie. System telemedyczny, który wyłącznie przesyła i wyświetla dane bez ich interpretowania, wyrobem medycznym nie jest. Moduł generujący alarmy na podstawie analizy parametrów konkretnego pacjenta już nim jest, podobnie jak aplikacja do samokontroli ciśnienia, która steruje ciśnieniomierzem, zbiera pomiary i je interpretuje. Według reguły 11 rozporządzenia MDR oprogramowanie monitorujące procesy fizjologiczne trafia do klasy IIa, a wytyczne zaliczają do niej wprost odczyty parametrów życiowych „w tym monitorowanie w domu”. Klasa IIa oznacza z kolei ocenę zgodności w jednostce notyfikowanej. Aplikacja, która rozszerza domowy glukometr o analizę trendów, podlega analogicznej ocenie według reguł IVDR.
Dla zespołu produktowego wynikają z tego cztery rzeczy:
- Przeznaczenie wynika także z marketingu. MDR definiuje je na podstawie etykiety, instrukcji, a także materiałów promocyjnych i sprzedażowych (art. 2 pkt 12), więc strona produktu obiecująca „wczesne wykrywanie zagrożeń” może przesądzić o klasyfikacji aplikacji, która w rzeczywistości rysuje tylko wykres.
- Interfejs dla pacjenta musi być po polsku. Ustawa o wyrobach medycznych wymaga polskich etykiet, instrukcji i interfejsu w wyrobach dla osób bez wykształcenia medycznego, a za naruszenie grozi kara do 100 tys. zł.
- Rejestracja w EUDAMED jest obowiązkowa. Według komunikatu Prezesa URPL cztery moduły europejskiej bazy działają obowiązkowo od 28 maja 2026 roku, a wyroby wprowadzone wcześniej trzeba w niej zarejestrować do 27 listopada 2026 roku.
- Sprzęt konsumencki przerzuca odpowiedzialność na aplikację. Jeśli aplikacja medyczna korzysta z czujnika w zwykłym smartwatchu, wytyczne MDCG 2023-4 każą jej producentowi wykazać poprawność pomiaru w każdej obsługiwanej konfiguracji.
Komisja Europejska zaproponowała w grudniu 2025 roku uproszczenie MDR, po którym oprogramowanie trafiałoby domyślnie do klasy I, ale to wciąż projekt: Parlament ma o nim głosować orientacyjnie w grudniu 2026 roku, a Rada nie uzgodniła jeszcze stanowiska. Najrozsądniejsza rada brzmi nudno, ale pozwala zaoszczędzić sporo pieniędzy: opinię regulacyjną o przeznaczeniu aplikacji warto zdobyć, zanim powstanie funkcja, która przesądzi o klasyfikacji. Dobudowanie systemu zarządzania jakością do produktu, który jest już na rynku, kosztuje wielokrotnie więcej niż zrobienie tego we właściwej kolejności.
Integracja urządzeń medycznych – planowanie projektu
O budżecie decydują przede wszystkim trzy rzeczy: wybór urządzeń, sposób łączenia się z nimi i wykonawca prac. Jeśli rozstrzygniesz je w tej kolejności, wycena nie rozsypie się, gdy przyjdzie sprzęt.
Pytania do producenta urządzenia, zanim się zdecydujesz
Najwięcej ryzyka w takim projekcie leży po stronie producenta urządzenia, a jedna rozmowa przed wyborem sprzętu wydobywa na wierzch prawie wszystko. Zapytaj:
- Czy dane są dostępne przez standardowy profil Bluetooth, czy przez własną usługę producenta?
- Czy dokumentacja protokołu jest publiczna i czy można ją przeczytać przed podpisaniem czegokolwiek?
- Czy jest SDK, ile kosztuje i na co pozwala jego licencja?
- Jak często zmienia się firmware i czy starsze wersje protokołu są potem nadal obsługiwane?
- Czy można kupić egzemplarze testowe do laboratorium i jak wygląda ich wymiana?
- Czy urządzenie ma oznakowanie CE według MDR, jest zarejestrowane w EUDAMED i ma instrukcję po polsku?
Za producenta, który szybko odpowie na wszystkie sześć pytań, warto zapłacić więcej. Ten, który przy drugim pytaniu odsyła do inżyniera sprzedaży i umowy NDA, mówi ci sporo o najbliższych dwunastu miesiącach.
Odpowiedzi powinny trafić do analizy potrzeb, zanim ktokolwiek poda jakąkolwiek kwotę – więcej o tym etapie piszemy w poradniku Jak dobrze zaplanować budżet projektu IT?.
Trzy modele: własny kod, SDK i platforma do łączności z urządzeniami
Integracja urządzeń medycznych może opierać się na jednym z trzech modeli, a wybór zależy głównie od znaczenia danych z urządzeń dla twojej oferty.
| Własny kod | SDK zewnętrznego dostawcy | Platforma do łączności z urządzeniami | |
|---|---|---|---|
| Na czym polega | Własna obsługa BLE i formatów danych dla każdego urządzenia | SDK dostawcy obsługujący wiele modeli | Usługa w chmurze z urządzeniami, łącznością i API |
| Kiedy się sprawdza | Mało typów urządzeń, dane wyróżniają produkt | Wiele urządzeń, standardowe pomiary | Liczy się szybkość wejścia na rynek bardziej niż marża |
| Jak rozkłada się koszt | Praca zespołu na starcie | Licencja plus prace integracyjne | Opłata za urządzenie lub pacjenta przez cały czas działania produktu |
| Kontrola | Pełna | Częściowa | Ograniczona |
| Główne ryzyko | Każda zmiana firmware'u jest twoim problemem | Lista urządzeń dostawcy może nie pokrywać się z twoją | Uzależnienie od dostawcy i cennik rosnący razem z liczbą pacjentów |
Gotowe platformy rozwiązują realny problem, gdy obsługujesz piętnaście modeli, z których żaden nie wyróżnia twojego produktu, ale przy niskiej marży na pacjencie szybko robią się drogie. W Europie działa ich kilka: berlińskie Thryve zaczyna od 499 euro miesięcznie i przechowuje dane w Niemczech, Withings sprzedaje urządzenia z własną łącznością komórkową i rozlicza się za aktywne urządzenia, a przy amerykańskich platformach sprawdź miejsce przechowywania danych, bo dla RODO to nie jest szczegół. Większość tych produktów wyrosła ze świata urządzeń konsumenckich albo szpitalnych, dlatego listę obsługiwanych modeli porównaj z własną listą, zanim zaczniesz porównywać ceny.
Integracja urządzeń medycznych: budżet, czas i zespół
Integracja urządzeń medycznych ma szerokie widełki kosztów, bo decyduje o nich przede wszystkim urządzenie. Urządzenie ze standardowym profilem i publiczną dokumentacją to zadanie o przewidywalnym zakresie. Nieudokumentowany sprzęt z SDK dostępnym po podpisaniu NDA i producentem w innej strefie czasowej potrafi pochłonąć więcej czasu niż cała reszta aplikacji, z czego większość upływa z dala od edytora kodu.
Przed pierwszym sprintem zapewnij cztery kompetencje:
- Programistę mobilnego, który już kiedyś debugował połączenie BLE, bo projektowanie ekranów to zupełnie inna umiejętność.
- Backendowca, który zajmie się przyjmowaniem pomiarów, usuwaniem duplikatów i obsługą danych przychodzących w dowolnej kolejności.
- Testera, który ma pod ręką fizyczne urządzenia i przechodzi pełny cykl na prawdziwych telefonach.
- Osobę odpowiedzialną za klasyfikację regulacyjną, z którą konsultuje się plan rozwoju, zanim pojawią się w nim alerty albo wyliczane wskaźniki.
Przy systemach klasy medycznej nasze stawki wynoszą 150–390 zł netto za godzinę. MVP, czyli pierwszą działającą wersję z jednym urządzeniem o udokumentowanym protokole, przygotowujemy w dwa–cztery tygodnie, a kolejne etapy wyceniamy na podstawie tego, co pokazał działający produkt. Pierwszemu urządzeniu bardziej służy dedykowany zespół programistyczny rozliczany w modelu time and material niż stała cena, bo dopóki nikt nie miał sprzętu w rękach, nie da się uczciwie wycenić rozkodowania jego danych. Zacznij od jednego urządzenia dopracowanego do końca, a resztę wyceniaj na podstawie zdobytych przy nim doświadczeń – dopiero druga integracja pozwala realnie wycenić dziesiątą.
FAQ – integracja urządzeń medycznych
Te pytania pojawiają się w prawie każdej pierwszej rozmowie o integracji urządzeń. Odpowiedzi dotyczą aplikacji współpracującej z urządzeniami pacjenta; wdrożenia szpitalne rządzą się własnymi prawami.
Czym jest integracja urządzeń medycznych?
Integracja urządzeń medycznych to automatyczne przenoszenie pomiarów z urządzenia do oprogramowania: połączenie, przełożenie formatu danych producenta i przypisanie każdego odczytu do właściwego pacjenta. Ma węższy zakres niż interoperacyjność, która opisuje system przyjmujący dane z każdego urządzenia zgodnego ze standardem, i niż integracja z systemem gabinetowym, która dotyczy dokumentacji medycznej. Kończy się w chwili zapisania odczytu na koncie pacjenta. Alerty, interpretacja i wyliczane wskaźniki to już funkcje aplikacji i od nich zależy jej status jako wyrobu medycznego.
Ile trwa integracja jednego urządzenia z aplikacją?
O czasie decyduje urządzenie, dlatego uczciwą odpowiedzią jest lista czynników. Najwięcej zmieniają cztery:
- standardowy albo własny profil Bluetooth,
- dokumentacja protokołu: publiczna, dostępna po podpisaniu NDA albo żadna – to czynnik o największej rozpiętości,
- zachowanie urządzenia w tle na obu platformach,
- liczba wersji firmware'u, które są już w rękach pacjentów.
Pod te czynniki układa się plan prac. Najsłabiej udokumentowane urządzenie najlepiej rozpoznać jako pierwsze, póki jeszcze można z niego zrezygnować, a sprzęt, którego nikt z zespołu nie miał w rękach, trzymać z dala od zakresu potrzebnego na start.
Czy aplikacja połączona z ciśnieniomierzem musi mieć oznakowanie CE?
Oznakowanie CE ciśnieniomierza nie obejmuje aplikacji, którą ocenia się osobno na podstawie jej przeznaczenia. Jeśli aplikacja wyłącznie przesyła i wyświetla pomiary, co do zasady nie jest wyrobem medycznym. Gdy steruje urządzeniem, interpretuje wyniki albo wysyła alerty o przekroczeniu progów, staje się wyrobem, zwykle w klasie IIa, i potrzebuje własnej oceny zgodności. Producent z siedzibą w Polsce rejestruje się wtedy w EUDAMED i składa do Prezesa URPL wniosek o numer SRN, czyli pojedynczy numer rejestracyjny.
Czy aplikacja może pobierać dane z Apple Watcha, Garmina albo przez Health Connect?
Może, przez systemowe magazyny danych zdrowotnych zamiast osobnej integracji z każdym urządzeniem. Apple HealthKit i Health Connect na Androidzie pozwalają aplikacji odczytać tętno, kroki, sen i podobne dane po wyraźnej zgodzie użytkownika, co zdejmuje z zespołu pracę przy Bluetooth. Google Fit API jest przy tym wspierane tylko do końca 2026 roku, więc nowe projekty powinny od razu korzystać z Health Connect. Haczyk tkwi w wiarygodności: zegarek sportowy jest zwykle urządzeniem wellness bez statusu wyrobu medycznego, więc jego pomiary nie mają gwarancji klinicznej. Wiele produktów łączy oba źródła – dane z opasek służą motywowaniu pacjenta, a te z wyrobów medycznych są podstawą decyzji klinicznych.
Czy domowe pomiary pacjenta trafią do Internetowego Konta Pacjenta?
Na razie nie ma takiej drogi, bo P1 nie udostępnia interfejsu do przesyłania pomiarów z urządzeń pacjenta. W pandemii działała państwowa platforma Domowej Opieki Medycznej, na której pacjenci wpisywali wyniki z pulsoksymetrów, a później także pomiary ciśnienia – ręcznie, w aplikacji. Sytuację może zmienić EHDS, który od 2029 roku da pacjentom prawo do dopisywania informacji do własnej elektronicznej dokumentacji medycznej, choć szczegóły techniczne dopiero powstają.
Co się dzieje, gdy producent zaktualizuje oprogramowanie urządzenia?
Czasem nic, a czasem parser przestaje działać u każdego pacjenta z danym modelem. Producent nie ma obowiązku utrzymywać stabilnego formatu danych, a kanału, którym informacja o zmianie dotarłaby na czas do twojego zespołu, zwykle po prostu nie ma. Jeśli aplikacja jest wyrobem medycznym, wytyczne MDCG 2023-4 wymagają zresztą ustalenia z producentem sprzętu kanałów powiadamiania o zmianach i incydentach. Testy regresji na fizycznych urządzeniach planuje się więc przy każdej aktualizacji i traktuje jako stałą pozycję w kosztach utrzymania.
