245. Walidacja danych podczas wprowadzania

Walidacja danych podczas wprowadzania jest jednym z najskuteczniejszych sposobów ograniczania błędów w bazie badawczej. Jej istotą nie jest mechaniczne blokowanie każdej nietypowej wartości, lecz sprawdzanie, czy wpis odpowiada wcześniej ustalonym definicjom zmiennych, zakresom pomiaru, regułom badania i relacjom między zmiennymi. Dobrze zaprojektowana walidacja działa w miejscu, w którym błąd powstaje: przy wpisywaniu danych do formularza elektronicznego, arkusza lub systemu EDC. Dzięki temu osoba wprowadzająca dane może od razu sprawdzić źródłowy dokument i poprawić zapis, zamiast pozostawiać problem do późniejszego etapu czyszczenia.

W tej lekcji kursu metodologii badań i statystyki na statystyk.edu.pl przeanalizujemy, czym jest walidacja, jakie reguły warto stosować, kiedy komunikat powinien blokować zapis, a kiedy jedynie sygnalizować potrzebę weryfikacji. Temat stanowi bezpośrednie rozwinięcie wcześniejszych lekcji o projektowaniu bazy, nazwach zmiennych, formacie danych oraz etykietach zmiennych i wartości.

Czym jest walidacja danych?

Walidacja danych to systematyczne sprawdzanie, czy wprowadzona wartość spełnia określone warunki logiczne, techniczne, merytoryczne lub proceduralne. Warunki te powinny wynikać z protokołu badania, formularza źródłowego, charakterystyki używanego narzędzia pomiarowego oraz planu analizy. W badaniach klinicznych reguły walidacyjne są często określane z języka angielskiego jako edit checks, query rules albo kontrole rozbieżności. Mogą być uruchamiane natychmiast po wpisaniu wartości, przy zapisie formularza albo w ramach późniejszej kontroli zbiorczej (Harris et al., 2009; Krishnankutty et al., 2012).

Walidacja nie jest tym samym co dowód prawdziwości informacji. System może stwierdzić, że wiek 42 lata mieści się w dopuszczalnym zakresie, ale nie może na tej podstawie zagwarantować, że osoba badana rzeczywiście ma 42 lata. Walidacja kontroluje przede wszystkim zgodność zapisu z regułą. Ocena zgodności ze źródłem wymaga dodatkowo weryfikacji dokumentacji, ponownego kontaktu z uczestnikiem, kontroli formularza źródłowego albo innej procedury jakościowej.

Walidacja, weryfikacja i kontrola jakości

• Walidacja odpowiada na pytanie: czy wartość spełnia zdefiniowane warunki?
• Weryfikacja odpowiada na pytanie: czy wartość zgadza się ze źródłem?
• Kontrola jakości obejmuje szerszy proces, w którym analizuje się kompletność, dokładność, spójność, aktualność i przydatność danych.

Rozróżnienie jest ważne, ponieważ dobrze działająca walidacja nie eliminuje wszystkich błędów. Nie wykryje na przykład sytuacji, w której pielęgniarka omyłkowo odczytała ciśnienie tętnicze z niewłaściwego wiersza dokumentacji, jeśli wpisana wartość jest technicznie możliwa i mieści się w zdefiniowanym zakresie.

Dlaczego walidację należy wykonywać już podczas wprowadzania?

Błąd wykryty natychmiast jest zwykle łatwiejszy do wyjaśnienia niż błąd wykryty po kilku tygodniach. Osoba wprowadzająca dane ma wtedy dostęp do formularza papierowego, dokumentacji medycznej lub odpowiedzi uczestnika. W późniejszym etapie może nie pamiętać sytuacji pomiarowej, a źródło może być niedostępne. Wczesna kontrola ogranicza także przenoszenie błędu do kopii roboczych, eksportów, tabel i skryptów analitycznych.

Elektroniczne systemy gromadzenia danych mogą wykorzystywać metadane opisujące typ zmiennej, zakres dopuszczalnych wartości, sposób kodowania odpowiedzi i reguły wyświetlania kolejnych pytań. Takie podejście zwiększa powtarzalność procesu i pozwala budować formularze, które reagują na wcześniejsze odpowiedzi użytkownika (Harris et al., 2009). Nie oznacza to jednak, że oprogramowanie samo zaprojektuje poprawne reguły. Reguły muszą być merytorycznie uzasadnione i przetestowane.

Podstawowe rodzaje reguł walidacyjnych

1. Kontrola typu i formatu

Najprostsza reguła sprawdza, czy wpis ma właściwy typ. Zmienna age_years powinna być liczbą, visit_date datą, a sex_code jedną z wcześniej określonych kategorii. Kontrola formatu może wymagać użycia określonej liczby znaków, separatorów albo układu daty.

Przykład: numer identyfikacyjny uczestnika może mieć postać ABC-0245. Wpis abc245 może być niezgodny z formatem, nawet jeśli osoba wprowadzająca dane rozumie, o którego uczestnika chodzi. Standaryzacja zapisu ułatwia późniejsze łączenie tabel i wykrywanie duplikatów.

2. Kontrola kompletności

Reguła kompletności sprawdza, czy wymagane pole zostało wypełnione. Nie każde puste pole oznacza jednak błąd. Brak informacji może być uzasadniony, na przykład gdy pytanie nie dotyczy danej osoby albo badanie nie zostało wykonane. Dlatego lepiej rozróżniać:

• brak odpowiedzi wymagający uzupełnienia;
• „nie dotyczy”;
• „nie wiadomo”;
• „odmowa odpowiedzi”;
• „badania nie wykonano”.

Wpisywanie kodu 999 jako uniwersalnej wartości brakującej jest ryzykowne. Program może potraktować go jako prawdziwą liczbę, co zaburzy średnią, odchylenie standardowe lub model regresji. Kody braków powinny być jednoznacznie opisane i odpowiednio zdefiniowane w programie analitycznym.

3. Kontrola zakresu

Kontrola zakresu sprawdza, czy wartość znajduje się między dolną a górną granicą. Granice mogą być:

• techniczne – wynikające z możliwości urządzenia lub skali;
• teoretyczne – wynikające z definicji zmiennej;
• kliniczne – opisujące wartości typowe lub możliwe w określonej populacji;
• kwalifikacyjne – wynikające z kryteriów włączenia do badania.

Warto odróżniać zakres niemożliwy od zakresu rzadkiego. Ciśnienie skurczowe równe 480 mmHg jest prawdopodobnie błędem wpisu lub jednostki. Natomiast wartość 190 mmHg jest nietypowa, ale może być prawdziwa. Pierwsza sytuacja może uzasadniać blokadę zapisu, druga raczej komunikat ostrzegawczy i konieczność sprawdzenia źródła.

4. Kontrola wartości dopuszczalnych

W przypadku zmiennych kategorycznych należy ograniczyć wpis do zdefiniowanego słownika. Jeżeli zmienna smoking_status ma kategorie „nigdy”, „obecnie” i „w przeszłości”, nie należy pozostawiać swobodnego pola tekstowego, w którym mogą pojawić się warianty „nie palę”, „niepalenie”, „były palacz” lub literówki.

Najbezpieczniejszy jest wybór z listy, przy czym baza powinna przechowywać kod, a użytkownik powinien widzieć zrozumiałą etykietę. Przykładowo kod 1 może oznaczać „nigdy”, 2 – „obecnie”, a 3 – „w przeszłości”. Takie kodowanie musi być opisane w słowniku danych.

5. Kontrola zależności między zmiennymi

Niektóre błędy ujawniają się dopiero po porównaniu kilku pól. Można zapisać regułę w postaci:

jeżeli pregnancy_status = „tak”, to sex_code musi należeć do kategorii zgodnej z protokołem oraz gestational_age_weeks nie może być puste

W badaniu dotyczącym hospitalizacji można wymagać, aby data wypisu nie była wcześniejsza niż data przyjęcia:

discharge_date ≥ admission_date

W tym zapisie discharge_date oznacza datę wypisu, admission_date datę przyjęcia, a symbol ≥ oznacza „większe lub równe”. Równość jest dopuszczalna, jeśli przyjęcie i wypis mogą nastąpić tego samego dnia.

6. Kontrola unikalności i duplikatów

Identyfikator uczestnika powinien być unikalny, jeżeli każdy wiersz bazy odpowiada jednej osobie. Jeżeli baza ma strukturę pomiarów powtarzanych, unikalny może być dopiero klucz złożony, na przykład participant_id + visit_number. Wpisanie dwa razy uczestnika P014 dla wizyty 2 może oznaczać duplikat, ale może też wskazywać na błąd w strukturze danych. Walidacja powinna być zgodna z jednostką obserwacji ustaloną w projekcie.

Reguły twarde i miękkie

Reguła twarda blokuje zapis albo przejście do kolejnego ekranu. Powinna być stosowana wtedy, gdy wpis jest niemożliwy lub narusza podstawową integralność bazy. Przykładem jest data spoza zakresu systemu, nieistniejąca kategoria albo brak identyfikatora koniecznego do powiązania rekordu.

Reguła miękka wyświetla ostrzeżenie, ale pozwala kontynuować pracę. Jest właściwa wtedy, gdy wartość jest nietypowa, lecz możliwa. Komunikat może brzmieć: „Wartość 190 mmHg jest wysoka. Sprawdź jednostkę i dokument źródłowy. Jeśli wartość jest prawidłowa, zatwierdź i wpisz uzasadnienie”. Takie rozwiązanie ogranicza ryzyko, że system będzie wymuszał poprawianie prawdziwych obserwacji.

Komunikat powinien być konkretny, neutralny i pomocny. Informacja „błąd danych” jest niewystarczająca. Lepszy komunikat wskazuje pole, warunek i możliwe działanie. W badaniach klinicznych należy również zachować historię zmian, datę korekty, osobę dokonującą zmiany oraz powód modyfikacji, zwłaszcza gdy system podlega formalnym procedurom jakościowym.

Przykład 1: badanie pacjentów z nadciśnieniem

Załóżmy, że w badaniu obserwacyjnym rejestrujemy wiek, płeć, ciśnienie skurczowe, ciśnienie rozkurczowe, datę pomiaru i informację o przyjęciu leku przeciwnadciśnieniowego.

Zmienna	Przykładowa reguła	Reakcja systemu
age_years	liczba całkowita od 18 do 100	blokada wartości spoza zakresu
sbp_mmhg	liczba od 60 do 300; ostrzeżenie dla wartości <90 lub >180	blokada dla wartości niemożliwych, ostrzeżenie dla nietypowych
dbp_mmhg	liczba od 30 do 200	blokada wartości spoza zakresu
antihypertensive	tak/nie/brak danych	lista wyboru
measurement_date	data nie późniejsza niż data wizyty	ostrzeżenie lub blokada zależnie od protokołu

Można także dodać regułę relacyjną: sbp_mmhg > dbp_mmhg. Jeżeli ciśnienie skurczowe wynosi 110, a rozkurczowe 125, należy sprawdzić wpis. Nie wolno jednak bezrefleksyjnie zamieniać wartości miejscami. Automatyczna korekta mogłaby stworzyć dane, których nikt nie potwierdził w źródle.

Przykład 2: badanie psychologiczne z pomiarem powtarzanym

W badaniu skuteczności programu redukcji stresu uczestnicy wypełniają skalę w punkcie wyjściowym i po ośmiu tygodniach. Baza ma zawierać participant_id, visit, wynik skali oraz informację, czy ankietę wypełniono samodzielnie.

Walidacja powinna sprawdzić, czy wynik skali mieści się w zakresie wynikającym z liczby pozycji i sposobu punktowania. Jeśli suma może wynosić od 0 do 40, wynik 47 powinien zostać zablokowany. Inaczej należy traktować brak wyniku: może oznaczać nieukończenie ankiety, a nie błąd liczbowy.

Druga reguła może wymagać, aby dla każdego uczestnika występował najwyżej jeden rekord dla wizyty wyjściowej i jeden dla wizyty po ośmiu tygodniach. Jeżeli pojawi się trzeci rekord, system powinien wskazać potencjalny duplikat, ale nie musi go automatycznie usuwać. Najpierw należy ustalić, czy doszło do powtórnego wypełnienia kwestionariusza, korekty rekordu, czy błędu identyfikatora.

Jak projektować reguły walidacyjne?

1. Zacznij od definicji zmiennych. Dla każdej zmiennej określ nazwę, typ, jednostkę, zakres, kody braków i dopuszczalne wartości.
2. Powiąż regułę z celem badania. Najważniejsze kontrole powinny dotyczyć zmiennych kluczowych dla kryteriów włączenia, głównych wyników i planowanych analiz.
3. Zdecyduj, czy reguła ma blokować zapis. Nie każda nietypowa obserwacja jest błędem.
4. Napisz komunikat dla użytkownika. Powinien wyjaśniać, co sprawdzić i jakie są następne kroki.
5. Przetestuj reguły na danych fikcyjnych. Sprawdź wartości prawidłowe, graniczne, brakujące, skrajne i celowo błędne.
6. Przeprowadź test użytkownika. Osoba znająca badanie powinna ocenić, czy reguły są zgodne z praktyką.
7. Monitoruj częstość uruchomień reguł. Zbyt wiele ostrzeżeń może świadczyć o błędnej regule albo niejasnym formularzu.

Warto prowadzić dokument zwany planem walidacji danych. Dla każdej reguły można zapisać identyfikator, warunek, zmienne objęte kontrolą, typ reakcji, treść komunikatu, uzasadnienie, właściciela merytorycznego, datę testu i status wdrożenia. Taka dokumentacja ułatwia audyt, szkolenie zespołu i późniejsze wyjaśnianie decyzji.

Najczęstsze błędy

• Zbyt szerokie pola tekstowe. Swobodny tekst zwiększa liczbę literówek, wariantów zapisu i trudności z kodowaniem.
• Traktowanie każdej wartości nietypowej jako błędnej. Wartości skrajne mogą być prawdziwe i klinicznie ważne.
• Brak rozróżnienia między brakiem danych a kategorią „nie dotyczy”. Takie połączenie utrudnia ocenę kompletności i analizę braków.
• Automatyczna zmiana danych bez śladu. System nie powinien sam poprawiać wartości, których nie potwierdzono w źródle.
• Reguły sprzeczne z protokołem. Przykładowo ograniczenie wieku do 18–65 lat jest niewłaściwe, jeśli badanie dopuszcza osoby do 70 lat.
• Brak testów wartości granicznych. Należy sprawdzić między innymi minimum, maksimum, wartości tuż poza zakresem oraz brak danych.
• Nadmierna liczba ostrzeżeń. Użytkownicy mogą zacząć zatwierdzać komunikaty bez ich czytania.
• Brak śladu audytowego. W bazie powinno być wiadomo, kto, kiedy i dlaczego zmienił wpis.
• Walidacja wyłącznie pojedynczych pól. Wiele ważnych błędów dotyczy relacji między datami, wizytami i zmiennymi.
• Mylenie walidacji z weryfikacją źródłową. Poprawny format nie oznacza jeszcze poprawności merytorycznej.

Przykład praktyczny: analiza przypadku

Zespół prowadzi badanie pacjentów przyjmowanych na oddział ratunkowy. W formularzu wpisuje się czas wystąpienia objawów, czas przyjęcia, czas wykonania badania laboratoryjnego i wartość stężenia troponiny. Po kilku dniach zauważono, że w bazie występują ujemne czasy oraz nietypowo wysokie wyniki laboratoryjne.

Pierwsza wersja walidacji zawierała jedynie kontrolę typu liczbowego. System akceptował więc wartości -35 i 9999. Po analizie protokołu wprowadzono następujące reguły:

• czas od wystąpienia objawów do przyjęcia nie może być ujemny;
• czas badania laboratoryjnego nie może być wcześniejszy niż czas pobrania materiału;
• troponina musi być dodatnia lub równa zero, a wartości powyżej ustalonego zakresu pomiarowego wymagają sprawdzenia jednostki;
• dla wyniku przekraczającego zakres urządzenia należy użyć osobnej kategorii, a nie wpisywać umownie wartości 9999;
• każdy wpis spoza zakresu klinicznego wymaga potwierdzenia w dokumentacji, lecz nie jest automatycznie usuwany.

Po wdrożeniu reguł liczba błędów wynikających z pomyłek jednostek i kolejności dat zmniejszyła się. Jednocześnie zespół odkrył, że część ostrzeżeń dotyczyła prawdziwych, ciężkich przypadków. To pokazuje, dlaczego walidacja powinna odróżniać błąd niemożliwy od obserwacji rzadkiej. Jej celem jest poprawa jakości danych, a nie sztuczne wygładzenie rozkładu wyników.

Walidacja a późniejsze czyszczenie danych

Walidacja podczas wprowadzania ogranicza liczbę problemów, ale nie zastępuje kontroli zbioru po zakończeniu rekrutacji. Nadal należy sprawdzić między innymi rozkłady zmiennych, duplikaty, brakujące dane, niespójności między tabelami i zgodność z dokumentacją źródłową. W badaniach wieloośrodkowych warto porównać częstość braków i ostrzeżeń między ośrodkami, ponieważ różnice mogą wskazywać na odmienne praktyki pracy albo problemy szkoleniowe.

Wyniki kontroli jakości powinny być dokumentowane. Należy zachować informację o liczbie rekordów objętych kontrolą, liczbie wykrytych rozbieżności, sposobie ich rozstrzygnięcia oraz o tym, czy korekta wpłynęła na populację analizowaną. Takie podejście jest zgodne z szerszą zasadą przejrzystego raportowania zarządzania danymi i kontroli ich jakości (World Health Organization, 2017; EQUATOR Network, 2024).

Co warto zapamiętać?

• Walidacja sprawdza zgodność wpisu z ustaloną regułą, ale nie gwarantuje prawdziwości obserwacji.
• Najlepszym momentem wykrycia błędu jest chwila wprowadzania danych, gdy dostępne jest źródło informacji.
• Podstawowe reguły obejmują typ, format, kompletność, zakres, wartości dopuszczalne, unikalność oraz zależności między zmiennymi.
• Wartości niemożliwe można blokować, lecz wartości tylko nietypowe powinny zwykle uruchamiać ostrzeżenie.
• Reguły muszą wynikać z protokołu i definicji zmiennych, a nie wyłącznie z intuicji osoby programującej formularz.
• Każdą regułę należy przetestować na danych prawidłowych, granicznych, brakujących i celowo błędnych.
• Automatyczna walidacja nie zastępuje weryfikacji danych ze źródłem ani końcowego czyszczenia bazy.
• Dobrze przygotowany plan walidacji zwiększa odtwarzalność, ułatwia szkolenie i wspiera późniejsze raportowanie badania.

W praktyce dojrzała baza danych nie jest tylko tabelą przechowującą wpisy. Jest systemem, który jasno określa, jakie wartości są dopuszczalne, jak reagować na niezgodności i kiedy potrzebna jest decyzja badacza. Im wcześniej te zasady zostaną zaprojektowane i przetestowane, tym mniejsze ryzyko, że późniejsza analiza statystyczna będzie oparta na błędnych, nieporównywalnych lub niewłaściwie zakodowanych danych.

Źródła i dalsza lektura

1. Harris, P. A., Taylor, R., Thielke, R., Payne, J., Gonzalez, N., & Conde, J. G. (2009). Research electronic data capture (REDCap)—A metadata-driven methodology and workflow process for providing translational research informatics support. Journal of Biomedical Informatics, 42(2), 377–381. DOI: 10.1016/j.jbi.2008.08.010.
2. Krishnankutty, B., Bellad, A., & Mavoori, A. (2012). Data management in clinical research: An overview. Indian Journal of Pharmacology, 44(2), 168–172. DOI: 10.4103/0253-7613.93842.
3. Mullooly, J. P. (1990). The effects of data entry error: An analysis of partial verification. Computers and Biomedical Research, 23(3), 259–267. DOI: 10.1016/0010-4809(90)90020-D.
4. Kush, R. D., Helton, E., Rockhold, F. W., Hardison, C. D., & Zuckerman, B. D. (2018). Evaluation of data entry errors and data changes to an electronic data capture clinical trial database. Clinical Trials, 10(1), 22–31. DOI: 10.1177/1740774512467742.
5. Cohen, A. M., Hersh, W. R., Peterson, K., & Yen, P.-Y. (2020). A rule-based data quality assessment system for electronic health record data. Journal of the American Medical Informatics Association, 27(2), 262–270. DOI: 10.1093/jamia/ocz182.
6. World Health Organization (2017). Data quality review: A toolkit for facility data quality assessment. Module 3: Data verification and system assessment. World Health Organization. Źródło.
7. EQUATOR Network (2024). Reporting guidelines for health research. EQUATOR Network. Źródło.

Jeżeli potrzebujesz indywidualnego wsparcia w doborze metod, przygotowaniu bazy lub opracowaniu wyników badań, sprawdź analiza statystyczna.