W danych demonstracyjnych szpitala w digna 22 kwietnia 2026 pielęgniarki w grupie szpitali podały 82 dawki nowego leku. Raport apteki za ten dzień pokazał zero. Nic nie zgłosiło błędu. Dawki zostały zarejestrowane, ale produktu nie było jeszcze w kartotece produktów apteki, więc każdy raport łączący dawki z produktami je pomijał. Integralność referencyjna w danych medycznych oznacza, że każdy rekord wskazujący na inny rekord, na przykład dawka na produkt, wynik badania laboratoryjnego na zlecenie albo pobyt na pacjenta, wskazuje na wiersz, który naprawdę istnieje.

Ten artykuł śledzi ten przypadek: jak powstała luka, jak kontrola integralności referencyjnej w digna ją wykryła i co zespół zrobił dalej. Potem poszerzamy perspektywę na relacje w danych szpitali i płatników, które zasługują na taką samą kontrolę.

Ogólną koncepcję rekordów osieroconych opisuje główny artykuł Czy Twoje dane wciąż odnajdują swoich rodziców? Zrozumienie integralności referencyjnej. Ten pozostaje w szpitalu.

Najważniejsze wnioski

• Osierocona dawka nie jest błędna, tylko niewidoczna: złączenie wewnętrzne (inner join) ją usuwa, więc raporty zaniżają liczby, nie zgłaszając żadnego błędu.

• W demo Danubia Kliniken 82 z 4326 podań leków 22 kwietnia odwoływało się do produktu, którego brakowało w kartotece produktów apteki.

• Reguła integralności referencyjnej w digna Data Validation to kilka pól i zero SQL, a zwraca błędne rekordy ze szpitalem, oddziałem i kodem produktu.

• Naprawa zwykle leży w danych głównych: dodaj produkt, uruchom ponownie inspekcję, a raport sam się poprawi.

• Kontrole działają we własnej bazie danych szpitala. Dane pacjentów nigdy nie opuszczają jego infrastruktury.

Spis treści

• Co wydarzyło się w Danubia Kliniken 22 kwietnia?

• Dlaczego technicznie nic nie zgłosiło błędu?

• Jak digna wykryła brakujący produkt?

• Co zespół robi dalej?

• Które relacje referencyjne mają znaczenie w danych szpitali i płatników?

• Dlaczego integralność referencyjna tak często się psuje w ochronie zdrowia?

• Gdzie działają kontrole i czy dane pacjentów opuszczają szpital?

• Jak zacząć?

Co wydarzyło się w Danubia Kliniken 22 kwietnia?

Nowy produkt, Coavira 2.5 mg z kodem produktu 3858646, dotarł na oddziały, zanim trafił do kartoteki produktów apteki. Pielęgniarki udokumentowały 22 kwietnia 2026 82 jego podania. Ponieważ w kartotece nie było pasującego wiersza, każdy raport łączący podania z produktami liczył zero dawek leku Coavira, podczas gdy rejestr podań leków pokazywał 82.

Danubia Kliniken to fikcyjna austriacka grupa szpitali, a wszystkie liczby w tym artykule pochodzą z danych demonstracyjnych digna. Zrzuty ekranu to prawdziwe ekrany digna.

Sekwencja jest zwyczajna. Produkt zostaje zamówiony, dostarczony i podany. Rekord główny, który go nazywa i wycenia, utrzymuje inny zespół, według innego harmonogramu. W demo tabela podań hospital_medication_administrations jest ładowana z systemów oddziałowych, a kartotekę produktów hospital_medications utrzymuje apteka. Przez dzień czy tydzień te dwie tabele się ze sobą nie zgadzają.

Kto to zauważa? Zwykle nie zespół danych. Oddziałowa porównuje raport zużycia z tym, co wie, że zostało podane, albo farmaceuta widzi spadek zapasów bez odpowiadającego mu zużycia. Do tego czasu błędne liczby krążą już od kilku dni.

Dlaczego technicznie nic nie zgłosiło błędu?

Nic nie zgłosiło błędu, bo żadne pojedyncze ładowanie nie było błędne. Podania się załadowały, kartoteka się załadowała, zapytanie raportu się wykonało. Błąd leży w relacji między dwiema tabelami, a złączenie wewnętrzne rozwiązuje uszkodzoną relację, po cichu usuwając wiersz zamiast zgłosić błąd.

Uproszczona wersja dziennego raportu zużycia wygląda tak:

SELECT m.product_code,
       m.medication_name,
       COUNT(*) AS doses
FROM   hospital_medication_administrations a
JOIN   hospital_medications m
       ON m.product_code = a.product_code
GROUP  BY m.product_code,

SELECT m.product_code,
       m.medication_name,
       COUNT(*) AS doses
FROM   hospital_medication_administrations a
JOIN   hospital_medications m
       ON m.product_code = a.product_code
GROUP  BY m.product_code,

SELECT m.product_code,
       m.medication_name,
       COUNT(*) AS doses
FROM   hospital_medication_administrations a
JOIN   hospital_medications m
       ON m.product_code = a.product_code
GROUP  BY m.product_code,

Coavira 2.5 mg w ogóle nie pojawia się w wyniku. Dashboard przefiltrowany na ten lek pokazuje 0. 82 wiersze nadal są w tabeli podań, ale żadne zapytanie przechodzące przez kartotekę nigdy ich nie zobaczy.

Ograniczenia bazy danych rzadko to wyłapują. Kliniczne systemy źródłowe mogą wymuszać własne klucze, ale w szpitalnej hurtowni danych ekstrakt z eMAR (elektronicznej karty podań leków) i kartoteka apteki zwykle pochodzą z różnych systemów, a zadeklarowane klucze obce często nie są przenoszone albo nie są wymuszane. Kontrola musi więc działać na danych w chwili, gdy trafiają do hurtowni. Ręczne znalezienie rekordów osieroconych to jedno zapytanie:

SELECT a.hospital,
       a.ward,
       a.product_code,
       COUNT(*) AS orphaned_doses
FROM   hospital_medication_administrations a
LEFT   JOIN hospital_medications m
       ON m.product_code = a.product_code
WHERE  m.product_code IS NULL
  AND  a.product_code IS NOT NULL
GROUP  BY a.hospital, a.ward,

SELECT a.hospital,
       a.ward,
       a.product_code,
       COUNT(*) AS orphaned_doses
FROM   hospital_medication_administrations a
LEFT   JOIN hospital_medications m
       ON m.product_code = a.product_code
WHERE  m.product_code IS NULL
  AND  a.product_code IS NOT NULL
GROUP  BY a.hospital, a.ward,

SELECT a.hospital,
       a.ward,
       a.product_code,
       COUNT(*) AS orphaned_doses
FROM   hospital_medication_administrations a
LEFT   JOIN hospital_medications m
       ON m.product_code = a.product_code
WHERE  m.product_code IS NULL
  AND  a.product_code IS NOT NULL
GROUP  BY a.hospital, a.ward,

Samo zapytanie jest proste. Trudność polega na tym, żeby uruchamiać je dla każdej relacji, przy każdym ładowaniu, i widzieć wynik, zanim raport zostanie wysłany. Siostrzany artykuł o tym, jak znaleźć rekordy osierocone w SQL i nie dopuścić do ich powstawania, omawia wzorce SQL szczegółowiej, w tym klucze złożone i obsługę wartości NULL.

Jak digna wykryła brakujący produkt?

Reguła integralności referencyjnej na źródle danych z podaniami sprawdzała przy każdej inspekcji każdy product_code względem kartoteki produktów apteki. 22 kwietnia 4244 z 4326 wierszy przeszło kontrolę, a 82 nie, więc status reguły na dashboardzie zmienił się na Failed, a błędne dawki były o jedno kliknięcie dalej.

Reguła

Reguła znajduje się w digna Data Validation, gdzie są trzy rodzaje reguł: Rule, Uniqueness i Referential Integrity. Konfiguracja tej reguły zajęła sześć kroków:

1. W Configuration wybierz źródło danych hospital_medication_administrations, otwórz zakładkę Data Validation i kliknij Add Rule. Otworzy się okno Add Data Validation Rule (dodaj regułę walidacji danych).

2. Wpisz Name (nazwa) i Description (opis): hc_product_in_master, „Każdy podany produkt istnieje w kartotece produktów apteki”.

3. Ustaw Type na Referential Integrity.

4. W sekcji Attributes wybierz product_code w tym źródle danych.

5. W sekcji must exist in (musi istnieć w) wybierz Data Source hospital_medications i jego Attributes product_code.

6. Ustaw Threshold Mode (tryb progu) na Absolute, Info threshold na 0, a Warn threshold na 1, tak aby już jedna osierocona dawka dawała status Uncertain, a dwie lub więcej powodowały niepowodzenie kontroli. Zapisz.

Reguła: product_code w podaniach musi istnieć w hospital_medications.product_code.

Bez pisania SQL. Od tej chwili reguła uruchamia się przy każdej inspekcji źródła danych, zaplanowanej lub na żądanie. Film Integralność referencyjna w digna: konfiguracja w niecałą minutę pokazuje tę samą konfigurację w czasie rzeczywistym, a artykuł o tym, jak skonfigurować kontrolę integralności referencyjnej, omawia każde pole, łącznie z kluczami złożonymi.

Wynik

Inspekcja za 22 kwietnia oceniła 4326 podań. 4244 znalazły swój produkt w kartotece, 82 nie. Przy Warn threshold równym 1 daje to status Failed na dashboardzie, obok pozostałych kontroli z tego dnia.

Dashboard 22 kwietnia: hc_product_in_master, 4244 z 4326 przeszło, status Failed.

Sama liczba wystarczy, żeby wiedzieć, że coś jest nie tak. Nie wystarczy, żeby wiedzieć, co z tym zrobić. Do tego potrzebujesz wierszy.

Błędne rekordy

digna zwraca same błędne rekordy: tę samą kontrolę z zanegowanym warunkiem, wykonaną wewnątrz bazy źródłowej. W widoku Invalid Records przefiltruj na Failed i wybierz kontrolę Full - hc_product_in_master. Każdy wiersz to dawka, która nie wskazuje na nic, ze szpitalem, oddziałem, działem, product_code 3858646 i medication_name Coavira 2.5 mg.

Invalid Records: każda błędna dawka ze szpitalem, oddziałem, działem i kodem produktu.

Ta lista odpowiada na pytania, które inaczej przez tydzień krążyłyby mailem: który produkt, które oddziały, ile dawek. Można ją wyeksportować dla tego, kto odpowiada za naprawę.

Co zespół robi dalej?

Zespół naprawia dane główne, nie dawki. Podania są poprawne: pielęgniarki podały Coavira 2.5 mg i to udokumentowały. Brakowało wiersza produktu, więc rozwiązaniem jest dodanie go do kartoteki produktów apteki, ponowne uruchomienie inspekcji i pozwolenie raportom uwzględnić dawki.

1. Przejrzyj błędne rekordy i potwierdź wzorzec. Ten sam kod produktu, 3858646, w każdym błędnym wierszu wskazuje na brakujący wpis w kartotece, a nie na literówkę w systemie oddziałowym.

2. Powiadom zespół, który jest właścicielem kartoteki produktów, w tym przypadku aptekę, i dołącz wyeksportowane rekordy.

3. Apteka dodaje Coavira 2.5 mg do hospital_medications.

4. Uruchom na żądanie ponowną inspekcję źródła danych z podaniami. Gdy każdy kod produktu zostanie rozwiązany, reguła znów przechodzi, a dawki pojawiają się w raportach.

5. Odśwież raport zużycia. 82 dawki się pojawiają, przypisane do właściwych szpitali i oddziałów.

Gdyby błędne rekordy pokazały dziesiątki różnych kodów na jednym oddziale, przyczyna byłaby inna, być może problem z mapowaniem w jednym interfejsie, i inny byłby też właściciel. Rekordy mówią Ci, z którym przypadkiem masz do czynienia. To główny powód, żeby patrzeć na wiersze, a nie na liczby.

Zespoły, które akceptują krótkie opóźnienie między pierwszym użyciem a wpisem do kartoteki, mogą podnieść progi lub przełączyć Threshold Mode na Relative. Dla danych o lekach Danubia trzyma je na ostrym poziomie.

Które relacje referencyjne mają znaczenie w danych szpitali i płatników?

Warto sprawdzać te relacje, od których zależą raporty i rozliczenia: dawki z produktami, pobyty z pacjentami, wyniki badań ze zleceniami i pobytami, obłożenie łóżek z oddziałami oraz roszczenia z ubezpieczycielami i polisami. Każda z nich, gdy jest uszkodzona, usuwa wiersze ze złączenia bez błędu i każda ma innego właściciela.

W danych szpitalnych ważne są dwa szczegóły. Po pierwsze, klucze złożone: kod oddziału często jest unikalny tylko w obrębie jednego szpitala, więc obłożenie łóżek należy sprawdzać na szpitalu i oddziale łącznie. W digna wybierasz kilka kolumn po obu stronach, w tej samej kolejności, a kontrola dotyczy ich kombinacji. Po drugie, wartości NULL: kontrole referencyjne pomijają klucze obce o wartości NULL, więc dawka w ogóle bez kodu produktu nie powoduje niepowodzenia. Jeśli każde podanie musi mieć kod produktu, dodaj osobną regułę typu Rule, product_code IS NOT NULL.

Integralność referencyjna to jedna warstwa walidacji danych klinicznych. Zakresy wartości, kontrole wiarygodności i reguły kodowania to kolejna; omawia je artykuł Walidacja danych medycznych: reguły kliniczne i regulacyjne na dużą skalę.

Dlaczego integralność referencyjna tak często się psuje w ochronie zdrowia?

Integralność referencyjna często się psuje w ochronie zdrowia, bo rekordy nadrzędne i podrzędne należą do różnych działów, leżą w różnych systemach i ładują się według różnych harmonogramów. Apteka utrzymuje produkty, izba przyjęć pacjentów, system laboratoryjny zlecenia, dział techniczny oddziały, a finanse ubezpieczycieli. Każdy z nich jest poprawny na własnych warunkach; złączenia między nimi nie są niczyim zadaniem.

• Dane główne mają wielu właścicieli. Produkt, oddział czy ubezpieczyciel jest tworzony przez dział, który się nim zajmuje, w ramach własnego procesu. Systemy, które się do niego odwołują, dowiadują się o nim później.

• Systemy ładują się według różnych harmonogramów. Dokumentacja oddziałowa może przychodzić kilka razy dziennie, a kartoteka jest odświeżana co noc albo po wniosku o zmianę. Każda luka między nimi tworzy rekordy osierocone, nawet jeśli obie strony w końcu są poprawne.

• Kody się zmieniają. Produkty są zastępowane, oddziały łączone lub przemianowywane, ubezpieczyciele zmieniają kody, katalogi badań laboratoryjnych są aktualizowane. Rekordy historyczne wciąż mają stare kody, a kartoteka, która przechowuje tylko bieżące kody, czyni je osieroconymi.

• Placówki się łączą. Gdy grupa szpitali włącza nowe placówki do wspólnego raportowania, listy kodów, które nigdy nie były projektowane do współpracy, spotykają się w tym samym złączeniu.

• Rekord nadrzędny jest w innej bazie. Kartoteka produktów może leżeć w systemie aptecznym, a podania w klinicznej hurtowni danych. Od Release 2026.01 digna sprawdza integralność referencyjną między różnymi połączeniami bazodanowymi w tym samym projekcie, bez replikowania którejkolwiek tabeli.

Nic z tego nie świadczy o źle zarządzanym szpitalu. To normalny stan szpitalnej hurtowni danych zasilanej z wielu systemów. Różnica polega na tym, czy znajdziesz lukę w dniu, w którym powstaje, czy w tygodniu, w którym ktoś się poskarży.

Gdzie działają kontrole i czy dane pacjentów opuszczają szpital?

Kontrole działają we własnej bazie danych szpitala, a dane pacjentów nigdy nie opuszczają jego infrastruktury. digna działa on-premises lub w chmurze prywatnej szpitala. Wysyła SQL do źródła, otrzymuje liczby i pobiera błędne wiersze tylko wtedy, gdy o nie poprosisz. Żadna tabela nie jest kopiowana na zewnątrz, a zespół digna nigdy nie widzi Twoich danych.

Dla danych klinicznych to warunek wstępny, a nie szczegół. Dane o lekach, badaniach laboratoryjnych i pobytach zostają tam, gdzie już nadzorują je Twoje zespoły bezpieczeństwa i ochrony danych.

Od Release 2026.06 reguły mogą też istnieć jako kod: Python SDK (pip install digna-sdk) zarządza projektami, inspekcjami i regułami z poziomu CI/CD, a reguły walidacji można eksportować ze środowiska testowego i importować do produkcyjnego.

Jak zacząć?

Wybierz jedną relację, której awaria zabolałaby najbardziej, zwykle dawki z produktami albo roszczenia z ubezpieczycielami, i dodaj dla niej regułę integralności referencyjnej. To kilka pól. Potem dodaj kolejną. Po kilku inspekcjach wiesz, którym złączeniom możesz ufać, a które po cichu gubią wiersze.

Jeśli chcesz zobaczyć działające kontrole Danubia Kliniken i porozmawiać o danych Twojego szpitala lub płatnika, umów demo z zespołem digna.

Najczęściej zadawane pytania

Czym jest integralność referencyjna w danych medycznych?

Oznacza, że każdy rekord odwołujący się do innego rekordu wskazuje na wiersz, który istnieje: dawka na produkt w kartotece apteki, wynik badania na jego zlecenie, pobyt na pacjenta. Gdy brakuje rekordu nadrzędnego, złączenia pomijają wiersz podrzędny, a raporty zaniżają liczby bez żadnego błędu.

Dlaczego dawki leków znikają z raportów szpitalnych?

Zwykle dlatego, że produktu brakuje w kartotece produktów apteki. Raporty łączą podania z produktami, a złączenie wewnętrzne po cichu usuwa dawki bez pasującego produktu. W demo Danubia Kliniken 82 dawki nowego produktu pokazywały się jako zero w każdym raporcie, który przechodził przez kartotekę.

Jak sprawdzić dane eMAR względem kartoteki produktów apteki?

Dodaj regułę Referential Integrity na źródle danych z podaniami w digna Data Validation: wybierz product_code jako atrybut, a następnie w must exist in wskaż kartotekę produktów i jej product_code. Każda inspekcja raportuje wiersze, które przeszły i nie przeszły kontroli, oraz wymienia każdą osieroconą dawkę.

Czy dane pacjentów opuszczają szpital, gdy digna wykonuje te kontrole?

Nie. digna działa on-premises lub w chmurze prywatnej szpitala, a każda kontrola jest wykonywana wewnątrz bazy źródłowej. digna wysyła SQL i otrzymuje liczby, a także błędne wiersze, gdy je otworzysz. Żadna tabela nie jest kopiowana na zewnątrz, a zespół digna nigdy nie widzi Twoich danych.

Które tabele w szpitalnej hurtowni danych wymagają kontroli integralności referencyjnej?

Zacznij od złączeń, na których opierają się raporty i rozliczenia: podania leków z kartoteką produktów, pobyty z pacjentami, wyniki badań ze zleceniami i pobytami, obłożenie łóżek z oddziałami według szpitala i kodu oddziału oraz roszczenia z ubezpieczycielami i polisami. Każde z nich ma innego właściciela do powiadomienia.