--- title: "Duplikaty kart pacjenta: kto zatwierdza dopasowanie AI?" description: "Jak bezpiecznie oceniać duplikaty kart pacjenta: rola AI, dwa niezależne sygnały, imienne zatwierdzenie i możliwość cofnięcia powiązania." image: "https://ai4med.pl/img/laczenie-kart-pacjenta-ai.jpg" date: 2026-08-09 author: Jacek Wyderka category: Dane i bezpieczeństwo tags: duplikaty kart pacjenta, EDM, integralność danych, dopasowanie rekordów, human-in-the-loop url: "https://ai4med.pl/dane-i-bezpieczenstwo/laczenie-kart-pacjenta-ai" inLanguage: pl --- # Duplikaty kart pacjenta: kto zatwierdza dopasowanie AI? Błędne połączenie dwóch kart pacjenta może przypisać wyniki, rozpoznania albo historię wizyt niewłaściwej osobie. **AI może ustawić podobne rekordy w kolejce do oceny, ale nie powinna samodzielnie scalać dokumentacji.** Decyzję zatwierdza imiennie upoważniony pracownik na podstawie niezależnych sygnałów, a placówka zachowuje możliwość cofnięcia powiązania. Problem pojawia się zarówno wtedy, gdy jedna osoba ma różne dane kontaktowe w dwóch systemach, jak i wtedy, gdy dwie osoby mają podobne nazwisko lub wspólny telefon rodzinny. **Wynik podobieństwa nie jest dowodem tożsamości.** Artykuł pokazuje modelowy przypadek, kartę decyzji i pierwszy test bez rzeczywistych danych pacjentów. 23 lipca 2026 r. AWS opisał w HealthLake funkcję resource matching dla siedmiu typów zasobów FHIR (standardu wymiany danych medycznych). System tworzy powiązanie bez zmiany rekordów źródłowych. Funkcja jest jednak w zamkniętej wersji testowej, działa deterministycznie na identyfikatorach i **nie jest gotową polityką dla polskiej EDM**. ## Dlaczego wysoki wynik AI nie wystarcza do połączenia kart? Placówka potrzebuje trzech oddzielnych kroków: **wykrycia kandydata**, **rozstrzygnięcia tożsamości** i dopiero potem technicznego powiązania. Wynik „94% podobieństwa” mówi, jak konkretna wersja algorytmu uporządkowała parę. Nie mówi, czy dwa rekordy można bezpiecznie uznać za kartę tej samej osoby. Badanie Cao i współautorów łączy model uczący się reprezentacji danych z regułami deterministycznymi. Rozwiązanie wykorzystuje kilka sygnałów, a wiarygodny identyfikator może nadpisać wynik modelu. Badano je w amerykańskiej komercyjnej bazie, więc **nie wyznacza progu dla polskiej przychodni**. AWS dopasowuje zasoby po identyfikatorach o określonym zakresie, nie rozstrzyga konfliktu między nimi i pozostawia użytkownikowi decyzję o dalszym działaniu. Sam wysoki wynik nie powinien uruchamiac połączenia. Podobną granicę warto zachować przy [przypisywaniu skanu do znanej karty](/dane-i-bezpieczenstwo/papier-edm-indeksowanie-ai), choć tam decyzja dotyczy dokumentu, a nie tożsamości między rekordami. ## Przykład modelowy: dwie karty, jedna niepewna tożsamość > **Przykład modelowy** — rekordy A i B, wartość wyniku oraz przebieg decyzji są hipotetyczne. Pokazują błąd procesu dopasowania, a nie skuteczność konkretnego systemu ani realne zdarzenie. System wykrywa dwie karty utworzone w różnych kanałach rejestracji. Zgadza się podobna forma nazwiska, część daty urodzenia i telefon. Model umieszcza parę wysoko w kolejce. **Na pierwszy rzut oka wygląda to jak duplikat**, lecz telefon jest numerem rodzinnym, a pełna data urodzenia różni się jedną cyfrą. Upoważniony pracownik sprawdza źródło identyfikatorów, widzi brak drugiego niezależnego potwierdzenia i odrzuca powiązanie. **Obie karty pozostają aktywne**, a para dostaje status „rozstrzygnięta — różne osoby”, aby system nie wracał do niej bez nowych danych. Próg AI decyduje tu o wejściu do kolejki, nie o scaleniu. Zespół powinien, zapisać również powód decyzji. ## Które sygnały rozstrzygają, a które tylko podnoszą podejrzenie? Użyj tabeli jako karty rozmowy z dostawcą EDM i właścicielem jakości danych. **Podobieństwo kieruje do kontroli**, natomiast podstawę powiązania tworzą sygnały zweryfikowane w procedurze placówki. | Sygnał | Co naprawdę potwierdza | Działanie | Właściciel decyzji | | --- | --- | --- | --- | | Zgodny silny identyfikator w tym samym zakresie | oba rekordy wskazują ten sam identyfikator; nadal trzeba wykluczyć błąd wpisu | sprawdź źródło i drugi niezależny sygnał | upoważniony pracownik odpowiedzialny za dane podstawowe | | Drugi identyfikator zweryfikowany niezależnie | zgodność nie wynika tylko z kopiowania tej samej omyłki | dopuść parę do ręcznego zatwierdzenia | osoba wskazana w procedurze | | Podobne nazwisko, data urodzenia lub adres | rekordy są podobne demograficznie, nie że dotyczą tej samej osoby | umieść w kolejce albo oznacz do wyjaśnienia | pracownik oceniający kolejkę | | Wspólny telefon lub e-mail | dane kontaktowe się pokrywają; mogą należeć do rodziny lub opiekuna | traktuj jako sygnał pomocniczy | pracownik oceniający kolejkę | | Zgodne rozpoznanie, lek lub opis wizyty | podobieństwo kliniczne występujące u wielu osób | nie używaj jako dowodu tożsamości | uprawniony personel ocenia tylko skutki pomyłki | | Wynik podobieństwa modelu | pozycję pary według określonej wersji modelu | ustaw priorytet kontroli, bez automatycznego merge | właściciel procesu ustala próg kolejki | Zasada dwóch niezależnych sygnałów jest **propozycją bramki operacyjnej**, nie uniwersalnym przepisem. Placówka może wymagać mocniejszego potwierdzenia zależnie od jakości źródeł i skutków błędu. ## Kto zatwierdza powiązanie i kto może je cofnąć? Właścicielem decyzji nie powinien być „każdy z dostępem do EDM”. Placówka wskazuje rolę uprawnioną do poprawy danych podstawowych i znającą procedurę identyfikacji. **Manager zatwierdza reguły**, administrator konfiguruje uprawnienia, a IOD ocenia zakres danych i logów. Gdy pomyłka dotknęła treści klinicznej, właściwa osoba medyczna sprawdza skutki. Polskie rozporządzenie wymaga, aby system zapewniał integralność treści i metadanych oraz identyfikował osobę, czas i zakres zmiany. Karta decyzji zapisuje więc identyfikatory techniczne rekordów, ocenione sygnały, werdykt, zatwierdzającego, czas, uzasadnienie i identyfikator cofnięcia. **Nie trzeba kopiować pełnej zawartości kart do kolejki.** Standard HL7 FHIR pokazuje przydatny wzorzec: zasób Linkage może wskazać autora powiązania, jego aktywność oraz rekord źródłowy, alternatywny lub historyczny. To nie narzuca architektury, ale pokazuje, że **odwracalność i odpowiedzialnego autora można zaprojektować jako część danych**. ## Kiedy uruchomić kolejkę, a kiedy zatrzymać proces? **Tu się broni uruchomienie kolejki, gdy** placówka zna zakresy identyfikatorów, ma właściciela decyzji i potrafi odtworzyć oraz cofnąć powiązanie. Dostawca powinien wyjaśnić znaczenie wyniku i pozwolić całkowicie wyłączyć automatyczne scalanie. **Nie zaczynaj, gdy** wspólny telefon wystarcza do połączenia, wynik nie pokazuje użytych sygnałów, odrzucenie pary nie jest zapamiętywane albo cofnięcie usuwa ślad decyzji. Próg kolejki kalibruj na zatwierdzonym zbiorze testowym i zapisuj wraz z wersją modelu. Spadek liczby kart nie jest sam w sobie sukcesem. ## Pierwszy test: pięć par rekordów bez automatycznego scalania Przygotuj pięć całkowicie syntetycznych par: tę samą osobę z historycznym kontaktem, dwie osoby ze wspólnym telefonem, literówkę w nazwisku, różnicę w dacie urodzenia oraz parę podobną tylko przez częste nazwisko. **Testujecie procedurę**, nie statystyczną jakość modelu. Dla każdej pary zapisz wynik kolejki, sprawdzone sygnały, decyzję, uzasadnienie i próbę cofnięcia linku. Warunek przejścia: żadna para nie łączy się automatycznie, każda decyzja ma wskazaną osobę, a zespół potrafi ją odtworzyć. **Dopiero potem** warto rozszerzyć test i mierzyć osobno fałszywe alarmy oraz pominięte duplikaty. ## Źródła - [ISAP — tekst jednolity rozporządzenia w sprawie dokumentacji medycznej (Dz.U. 2024 poz. 798)](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20240000798) — polskie źródło urzędowe potwierdza wymagania integralności, identyfikacji osoby i zakresu zmiany; karta aktu wskazuje późniejsze nowelizacje. Sprawdzono: 2026-08-08. - [AWS HealthLake — wydanie resource matching z 23 lipca 2026 r.](https://docs.aws.amazon.com/healthlake/latest/devguide/releases.html) oraz [opis działania funkcji](https://docs.aws.amazon.com/healthlake/latest/devguide/resource-matching-how-it-works.html) — dokumentacja potwierdza status gated preview, dopasowanie po identyfikatorach i nieinwazyjne powiązania. Sprawdzono: 2026-08-08. - [HL7 FHIR R5 — Resource Linkage](https://fhir.hl7.org/fhir/linkage-definitions.html) — specyfikacja opisuje autora, stan aktywności i typy rekordów w powiązaniu; ma poziom Trial Use, więc jest wzorcem technicznym, nie polskim wymogiem. Sprawdzono: 2026-08-08. - [PubMed — Cao i in., Linking patient records at scale with a hybrid approach combining contrastive learning and deterministic rules](https://pubmed.ncbi.nlm.nih.gov/41777588/) — publikacja z 9.02.2026 r. pokazuje hybrydowe dopasowanie wielu sygnałów na dużej bazie komercyjnej; nie wyznacza progu dla polskiej placówki. Sprawdzono: 2026-08-08. - Okładka: [Jakub Zerdzicki na Pexels](https://www.pexels.com/photo/ring-binders-with-documents-on-desk-17018372/)