---
title: "Telemonitoring DOM a polisa OC: jakie logi pokażą odpowiedzialność?"
description: Jak przygotować logi, role i ścieżkę audytu przy telemonitoringu DOM, żeby rozmowa z brokerem i dostawcą nie skończyła się ogólnikiem.
image: "https://ai4med.pl/img/dom-polisa-oc.jpg"
date: 2026-07-06
author: Weronika Kasprzyk
category: Narzędzia i wdrożenia
tags: telemonitoring DOM, polisa OC, logi medyczne, odpowiedzialność, broker ubezpieczeniowy, audyt procesu
url: "https://ai4med.pl/narzedzia-i-wdrozenia/dom-polisa-oc"
inLanguage: pl
---

# Telemonitoring DOM a polisa OC: jakie logi pokażą odpowiedzialność?

## Czego dowiesz się z tego artykułu?

- Które logi z telemonitoringu DOM są najważniejsze przy rozmowie o polisie OC.
- Jak rozdzielić odpowiedzialność dostawcy, rejestracji i lekarza przy alercie.
- O co zapytać brokera, zanim pilotaż obejmie dane z urządzeń pacjenta.
- Jak przygotować kartę procesu bez realnych danych pacjenta.

Telemonitoring DOM wygląda na projekt medyczny, ale dla managera placówki bardzo szybko staje się też projektem dowodowym. Jeżeli z urządzenia pacjenta przychodzi pomiar, system oznacza alert, a człowiek ma zareagować, to przy sporze nie wystarczy zdanie: **system coś pokazał**. Trzeba wiedzieć, **kto zobaczył alert, kiedy go zatwierdził i co zrobiła placówka**.

W polskiej przychodni albo poradni specjalistycznej polisa OC nie powinna być rozmową po fakcie. Przy DOM trzeba ją włączyć przed pilotażem, bo pomiary z urządzeń, statusy alertów i komunikacja z pacjentem dotykają jednocześnie danych medycznych, decyzji człowieka i dostawcy technologii. **Najlepszy start to karta procesu**, a nie prezentacja funkcji.

Ja bym zaczęła od prostego pytania do zespołu: gdy pacjent albo rodzina zakwestionuje reakcję na alert, jakie logi pokażemy brokerowi, dostawcy i lekarzowi prowadzącemu? **To nie jest porada prawna ani likwidacja szkody**. To praktyczny ranking śladów, które warto mieć, zanim DOM wejdzie do codziennej pracy placówki.

## Najważniejsze

- **Nie pytaj tylko, czy OC obejmuje telemonitoring DOM.** Zapytaj, jaki proces, role, logi i wyłączenia ubezpieczyciel chce zobaczyć przy roszczeniu.
- **Najważniejszy log to nie sam pomiar.** Ważniejsze jest połączenie: źródło danych, czas alertu, odczyt przez człowieka, decyzja i komunikat do pacjenta.
- **Dostawca odpowiada za część techniczną, ale placówka za proces reakcji.** Ten podział musi być zapisany w umowie, procedurze i karcie pilotażu.
- **Lekarz lub uprawniony personel zatwierdza znaczenie kliniczne alertu.** AI albo system może porządkować dane, ale nie przejmuje odpowiedzialności medycznej.
- **Metryka sukcesu brzmi: pisemnie potwierdzony zakres ochrony oraz kompletna ścieżka audytu**, a nie liczba pacjentów podłączonych w pierwszym tygodniu.

## Szybka decyzja: czy proces jest gotowy?

**Zacznij od pilotażu**, jeśli potrafisz pokazać jeden proces DOM, jedną listę ról, zatwierdzone progi alertów i raport zdarzenia bez danych pacjenta. Broker nie musi znać każdego ekranu systemu, ale powinien zobaczyć **punkt odczytu, punkt decyzji człowieka i punkt kontaktu z pacjentem**.

**Zatrzymaj start**, jeśli dostawca nie pokazuje przykładowego raportu logów, zespół nie wie, kto reaguje na alert, albo lekarz ma tylko symbolicznie zatwierdzać wynik systemu. W takim układzie placówka nie wdraża telemonitoringu, tylko tworzy **nowe miejsce sporu o odpowiedzialność**.

## Ranking logów: co naprawdę pomaga przy OC

Przy rozmowie z brokerem nie chodzi o to, żeby pokazać jak najwięcej danych. Chodzi o to, żeby pokazać **właściwy ślad odpowiedzialności**. Dane z urządzenia są początkiem historii, ale roszczenie zwykle pyta o późniejsze kroki: kto wiedział, kto zareagował, kto zatwierdził i czy procedura była znana przed zdarzeniem.

| Priorytet i log | Co pokazuje przy OC | Kto potwierdza | Ryzyko braku |
| --- | --- | --- | --- |
| 1. Rejestr alertu: czas, parametr, próg, źródło urządzenia | co system faktycznie oznaczył jako wyjątek | dostawca systemu DOM | spór zaczyna się od niepewności, czy alert w ogóle powstał |
| 2. Potwierdzenie odczytu przez człowieka | oddziela automatyczne oznaczenie od reakcji personelu | lekarz, koordynator lub rejestracja według procedury | nie wiadomo, kto widział alert i kiedy |
| 3. Decyzja kliniczna albo organizacyjna | co człowiek zatwierdził po zobaczeniu alertu | lekarz lub uprawniony personel medyczny | system wygląda jak samodzielny decydent |
| 4. Komunikat do pacjenta lub opiekuna | treść i kanał kontaktu bez zgadywania | placówka, nie publiczny model AI | pacjent i placówka mają różne wersje zdarzenia |
| 5. Wersja reguły alertu i progu | czy próg był zatwierdzony przed pilotażem | manager procesu i dostawca | po zdarzeniu trudno obronić konfigurację |
| 6. Log dostępności systemu i awarii | czy problem był techniczny, czy organizacyjny | dostawca i administrator | odpowiedzialność placówki i dostawcy miesza się w jednym worku |
| 7. Eksport zdarzenia dla audytu | materiał dla brokera, IOD i zarządu | manager placówki | zespół odtwarza historię ręcznie z maili i telefonów |

Ten ranking jest celowo praktyczny. **Najwyżej są logi, które łączą alert z reakcją człowieka**, bo to one pokazują, czy DOM był narzędziem wspierającym proces, czy czarną skrzynką między pacjentem a gabinetem. Jeżeli chcesz najpierw uporządkować kliniczny podział ról, dobrym tłem jest tekst o [DOM i pomiarach pacjenta](/ai-w-pracy-lekarza/dom-pomiary-pacjenta).

## DOM to nie tylko pomiar, ale historia reakcji

CeZ opisuje DOM jako rozwiązanie do zdalnego monitorowania pomiarów pacjenta, w którym dane z urządzeń medycznych i typu smart mogą być zbierane, analizowane i udostępniane lekarzowi. Z perspektywy placówki to oznacza jedno: **pomiar przestaje być prywatną notatką pacjenta**, a staje się elementem procesu, który może wymagać reakcji.

W praktyce mamy trzy warstwy. Pierwsza to dane techniczne: urządzenie, parametr, czas, jakość transmisji. Druga to warstwa operacyjna: alert, zadanie, kontakt, eskalacja. Trzecia to warstwa kliniczna: interpretacja i decyzja człowieka z uprawnieniami. **Polisa OC i broker będą pytać właśnie o połączenie tych warstw**, bo szkoda rzadko wynika z samego faktu, że pomiar istnieje.

Nie wystarczy więc mieć dashboard. Trzeba mieć procedurę, która mówi, kiedy recepcja widzi tylko zadanie kontaktu, kiedy koordynator sprawdza kompletność danych, a kiedy lekarz zatwierdza znaczenie kliniczne alertu. **Human-in-the-loop musi być widoczny w logu**, nie tylko w deklaracji dostawcy. Szerzej ten mechanizm opisuje artykuł o [kontroli człowieka nad AI w placówce](/dane-i-bezpieczenstwo/kontrola-czlowieka-ai).

## O co zapytać brokera i dostawcę przed umową DOM

Rozmowa z brokerem powinna zacząć się od jednego procesu DOM, nie od ogólnego hasła telemedycyna. **Pokaż kartę procesu**, zakres danych, typ urządzeń, role oraz miejsce, w którym lekarz zatwierdza decyzję. Dopiero wtedy pytanie o OC ma sens, bo broker widzi, czy mówimy o świadczeniu zdrowotnym, organizacji kontaktu, awarii systemu, naruszeniu danych czy odpowiedzialności kontraktowej dostawcy.

Do brokera zapytałabym wprost:

- czy opisany proces mieści się w obecnym zakresie OC placówki, czy wymaga dodatkowego rozszerzenia albo osobnej ochrony;
- jakie logi i dokumenty ubezpieczyciel będzie chciał zobaczyć przy roszczeniu dotyczącym reakcji na alert DOM;
- czy polisa obejmuje szkody wynikające z błędu organizacyjnego placówki, awarii dostawcy, naruszenia danych albo opóźnionej reakcji;
- czy OWU zawiera wyłączenia dotyczące telemedycyny, outsourcingu IT, danych z urządzeń, kar umownych lub utraty rzeczy;
- kto powinien zgłaszać zdarzenie: lekarz, manager, IOD, dostawca czy wyznaczona osoba kontaktowa.

Do dostawcy pytania są inne. **Nie pytaj tylko o integrację i cenę**. Zapytaj, czy system zapisuje wersję reguł alertów, potwierdzenie odczytu, historię zmian, log awarii, eksport zdarzenia oraz role dostępu. Jeżeli dostawca mówi, że logi są, poproś o przykładowy raport bez danych pacjenta. **Raport testowy jest lepszy niż obietnica na slajdzie**.

Do IOD i managera procesu dodałabym trzy pytania kontrolne. Czy zakres danych jest minimalny dla celu pilotażu? Czy retencja logów jest znana i zgodna z procedurą placówki? Czy osoba zatwierdzająca alert ma realny czas i uprawnienie, żeby zatrzymać komunikat do pacjenta? **Bez tych odpowiedzi logi techniczne nie zamieniają się jeszcze w rozliczalność procesu**.

Jeśli placówka dopiero układa rozmowę o ubezpieczeniu przy AI, warto wrócić do szerszego tekstu o [polisie OC przy pilotażu AI](/narzedzia-i-wdrozenia/polisa-ai-szkody). Tutaj dokładamy wąski wariant: DOM, urządzenia, alerty i ślad reakcji.

## Przykład w poradni: alert i decyzja człowieka

> **Przykład modelowy** — scenariusz pokazuje sposób myślenia o audycie procesu. Nie zawiera realnych danych pacjenta, historii choroby ani opisu konkretnej szkody.

Prywatna poradnia specjalistyczna uruchamia pilotaż DOM dla małej grupy pacjentów z ustalonym planem kontroli parametrów. Urządzenie przesyła pomiar do systemu, system oznacza przekroczenie progu, a koordynator widzi zadanie do sprawdzenia. **To jeszcze nie jest decyzja kliniczna**. To jest informacja, którą trzeba przekazać zgodnie z procedurą.

Koordynator potwierdza odczyt alertu i sprawdza, czy dane są kompletne. Jeśli alert wymaga interpretacji, przekazuje sprawę lekarzowi. Lekarz ocenia znaczenie kliniczne i zatwierdza dalszy kontakt z pacjentem albo zmianę planu kontroli. **System porządkuje wyjątek, ale człowiek zatwierdza sens działania**.

Po miesiącu manager robi przegląd pięciu zdarzeń testowych bez danych pacjenta w materiałach warsztatowych. Sprawdza, czy dla każdego alertu da się odtworzyć źródło danych, czas oznaczenia, odczyt przez człowieka, decyzję i komunikat. Jeżeli w dwóch przypadkach brakuje potwierdzenia odczytu, to nie jest drobiazg administracyjny. **To luka dowodowa, którą trzeba zamknąć przed rozszerzeniem pilotażu**.

## Granica decyzji: kiedy i kiedy nie

To ma sens, gdy placówka ma jeden opisany proces DOM, zatwierdzone progi alertów, jasną rolę lekarza oraz raport logów, który broker i dostawca potrafią omówić na piśmie. Wtedy telemonitoring jest elementem zarządzanego procesu, a nie dodatkowym panelem z danymi pacjenta. **Największą wartością jest przewidywalność reakcji**, nie sama liczba zebranych pomiarów.

To nie ma sensu, gdy placówka chce zacząć od wielu urządzeń, wielu grup pacjentów i automatycznych komunikatów bez procedury odczytu, eskalacji oraz zatwierdzenia przez człowieka. W takim układzie logi pojawią się dopiero wtedy, gdy ktoś o nie zapyta po problemie. **A wtedy zwykle jest za późno na spokojne ustalenie odpowiedzialności**.

Najbardziej ostrożnie traktowałabym procesy, w których alert może sugerować pilność kontaktu, zmianę zachowania pacjenta albo decyzję kliniczną. Tu nie ma miejsca na skrót: dostawca dostarcza system i logi, manager odpowiada za proces, a lekarz zatwierdza znaczenie medyczne. **Żaden log nie zastąpi decyzji osoby uprawnionej**, ale dobry log pokaże, że decyzja rzeczywiście była po stronie człowieka.

## Pierwszy tydzień: karta procesu DOM dla placówki

Pierwszy krok jest prosty i mało efektowny: zrób jedną stronę procesu DOM przed rozmową z brokerem. **Na górze wpisz zakres pilotażu**, na przykład: jedna poradnia, jedna grupa pacjentów, dwa parametry, jeden kanał kontaktu i jedna osoba odpowiedzialna za przegląd alertów.

Niżej dopisz role. Lekarz zatwierdza znaczenie kliniczne. Koordynator albo rejestracja potwierdza odczyt i kontakt organizacyjny. Manager pilnuje metryki, umowy i odpowiedzi brokera. IOD sprawdza podstawę, zakres danych, retencję i logi. Dostawca potwierdza raport zdarzenia, awarie, wersję reguł i eksport audytowy. **Jeżeli którejś roli nie da się wpisać, pilotaż nie jest jeszcze gotowy**.

Przed startem potraktuj to jako checklist minimum:

- karta procesu DOM ma właściciela i jedną wersję zaakceptowaną przez lekarza oraz managera;
- dostawca pokazał przykładowy raport zdarzenia bez danych pacjenta;
- broker pisemnie wskazał, jakie logi i dokumenty będą potrzebne przy roszczeniu;
- IOD potwierdził zakres danych, retencję logów i zasady dostępu;
- zespół wie, kto odczytuje alert, kto zatwierdza decyzję i kto kontaktuje pacjenta.

Na koniec poproś brokera i dostawcę o pisemne potwierdzenie trzech rzeczy: zakres ochrony, wymagane logi oraz ścieżkę zgłoszenia zdarzenia. **Sugeruję nie rozszerzać DOM na kolejne grupy pacjentów**, dopóki placówka nie potrafi odtworzyć ścieżki alertu od urządzenia do decyzji człowieka. To spokojniejszy start, ale właśnie tak buduje się proces, który da się obronić przed pacjentem, wspólnikami i ubezpieczycielem.

## Źródła

- [Centrum e-Zdrowia — Ustawa o e-zdrowiu z podpisem prezydenta](https://www.cez.gov.pl/pl/page/o-nas/aktualnosci/ustawa-o-e-zdrowiu-z-podpisem-prezydenta), 12.06.2026. Oficjalne źródło dla świeżego kontekstu DOM: dane z urządzeń medycznych i typu smart mają być zbierane, analizowane i udostępniane lekarzowi; dostęp: 2026-07-06.
- [gov.pl — Domowa Opieka Medyczna](https://www.gov.pl/web/domowaopiekamedyczna), dostęp: 2026-07-06. Źródło rządowe opisujące DOM jako usługę zdalnego leczenia i monitorowania z użyciem platformy oraz urządzeń telemedycznych; wybrane jako tło definicyjne.
- [NTT DATA — Globalny Raport AI w Ubezpieczeniach 2026](https://pl.nttdata.com/landings/2026-global-ai-report-insurance), dostęp: 2026-07-06. Raport branżowy pokazuje znaczenie underwritingu, likwidacji szkód, scentralizowanego nadzoru i audytowalności w ubezpieczeniach; użyty jako kontekst rozmowy z brokerem.
- [UODO — Czy AI to zagrożenie dla danych?](https://uodo.gov.pl/pl/138/4422), 10.06.2026. Polskie źródło urzędowe o konieczności kontroli celu, zakresu i odpowiedzialności za dane przy AI, szczególnie przy danych medycznych; dostęp: 2026-07-06.
- [ELI — Rozporządzenie Ministra Finansów z 29 kwietnia 2019 r. w sprawie obowiązkowego OC podmiotu wykonującego działalność leczniczą](https://eli.gov.pl/api/acts/DU/2019/866/text.html), dostęp: 2026-07-06. Akt prawny wskazuje zakres obowiązkowego OC oraz wyłączenia, dlatego jest punktem odniesienia do rozmowy o rozszerzeniach i wyłączeniach ochrony.
- Zdjęcie okładkowe: [Tessy Agbonome na Pexels](https://www.pexels.com/photo/doctor-using-a-tablet-and-taking-notes-in-a-notebook-19957221/), ID 19957221; spokojna scena lekarza pracującego z tabletem i notatkami, dostęp: 2026-07-06.