099. Zmienne pochodne – jak dokumentować ich sposób obliczania?

PrzezRedaktor

W poprzednich lekcjach omawialiśmy między innymi zmienne złożone, indeksy, transformacje i role zmiennych w modelu. Kolejny krok dotyczy nie samego tworzenia zmiennej pochodnej, lecz udokumentowania sposobu jej utworzenia. To rozróżnienie ma zasadnicze znaczenie: zmienna może być poprawnie obliczona w programie statystycznym, a mimo to niedostatecznie opisana w dokumentacji badania. Wtedy inni badacze nie wiedzą dokładnie, z jakich danych powstała, jakie reguły zastosowano i czy można odtworzyć wynik.

W tej lekcji pokażemy, jak dokumentować zmienne pochodne w sposób akademicki, praktyczny i możliwie odporny na nieporozumienia. Zasady te są przydatne zarówno przy analizie danych medycznych i psychologicznych, jak i w badaniach społecznych, pielęgniarskich czy epidemiologicznych. Dobrze opisana zmienna pochodna jest elementem ścieżki pochodzenia danych: można prześledzić jej drogę od pomiaru pierwotnego do wartości wykorzystanej w tabeli, wykresie lub modelu.

1. Czym jest zmienna pochodna?

Zmienna pochodna to zmienna utworzona na podstawie jednej lub większej liczby innych zmiennych, zwykle za pomocą określonego wzoru, reguły klasyfikacji, algorytmu albo procedury agregacji. Nie jest zatem bezpośrednim wynikiem pojedynczego pytania, pomiaru laboratoryjnego czy obserwacji, lecz rezultatem przekształcenia danych.

Przykładami są:

  • wskaźnik masy ciała obliczany z masy i wzrostu;
  • łączny wynik kwestionariusza wyznaczany na podstawie odpowiedzi na poszczególne pozycje;
  • zmienna „hipertensja: tak/nie” utworzona na podstawie ciśnienia tętniczego, diagnozy lub przyjmowania leków;
  • czas przeżycia wyznaczony z daty początku obserwacji i daty zdarzenia lub cenzorowania;
  • średnia liczba godzin snu obliczana z kilku pomiarów;
  • kategoria ryzyka utworzona na podstawie kilku czynników klinicznych.

Samo stwierdzenie, że „utworzono zmienną BMI” albo „obliczono wynik depresji”, jest niewystarczające. Trzeba jeszcze określić, z jakich zmiennych, według jakiego wzoru, w jakich jednostkach, z jakim traktowaniem braków danych oraz według jakich progów lub reguł interpretacyjnych.

2. Dlaczego dokumentacja zmiennych pochodnych jest ważna?

Dokumentacja spełnia kilka funkcji. Po pierwsze, umożliwia reprodukowalność, czyli ponowne uzyskanie tych samych wartości przy użyciu tych samych danych i reguł. Po drugie, ułatwia kontrolę jakości: badacz może sprawdzić, czy wzór zastosowano prawidłowo, czy jednostki są zgodne i czy nie pomylono kodów. Po trzecie, zwiększa interpretowalność wyników. Czytelnik powinien wiedzieć, co rzeczywiście oznacza zmienna wprowadzona do modelu.

Wytyczne STROBE wymagają jasnego definiowania wyników, ekspozycji, predyktorów, potencjalnych czynników zakłócających i modyfikatorów efektu, a także opisania źródeł danych oraz sposobu pomiaru każdej zmiennej (von Elm et al., 2007). W przypadku zmiennej pochodnej oznacza to konieczność opisania nie tylko jej nazwy, ale również procesu konstrukcji. W części objaśniającej STROBE podkreślono, że sposób pomiaru i klasyfikacji zmiennych wpływa na możliwość oceny wiarygodności badania oraz ryzyka błędu systematycznego (Vandenbroucke et al., 2007). ([journals.plos.org](https://journals.plos.org/plosmedicine/article?id=10.1371%2Fjournal.pmed.0040296&utm_source=openai))

Podobne podejście przyjmują standardy APA JARS. Zalecają one jasne definiowanie zmiennych, wskazanie sposobu ich pomiaru oraz przedstawienie decyzji analitycznych, które mogą wpływać na wynik (Appelbaum et al., 2018). ([pubmed.ncbi.nlm.nih.gov](https://pubmed.ncbi.nlm.nih.gov/29345484/?utm_source=openai))

3. Minimalny opis zmiennej pochodnej

Każda zmienna pochodna powinna mieć własny wpis w słowniku danych, planie analizy albo dokumentacji kodu. Minimalny opis powinien obejmować następujące elementy:

  1. Nazwa techniczna – jednoznaczna nazwa używana w zbiorze danych, na przykład bmi_baseline.
  2. Nazwa opisowa – zrozumiała etykieta, na przykład „BMI w punkcie wyjściowym”.
  3. Rola w badaniu – wynik, ekspozycja, kowariata, mediator, moderator, czynnik zakłócający lub zmienna opisowa.
  4. Źródła danych – nazwy zmiennych pierwotnych, formularzy, pomiarów, wizyt lub baz.
  5. Jednostki – na przykład kg/m2, punkty, dni, miligramy na decylitr.
  6. Wzór lub algorytm – zapis matematyczny albo pełna lista reguł.
  7. Reguły dotyczące braków danych – kiedy wynik pozostaje brakiem, a kiedy jest obliczany mimo niekompletnych danych.
  8. Reguły wartości granicznych – na przykład sposób postępowania z wynikiem równym progowi.
  9. Zakres i typ zmiennej – ciągła, dyskretna, nominalna, porządkowa, binarna; dodatkowo minimalny i maksymalny zakres dopuszczalnych wartości.
  10. Wersja i data utworzenia – szczególnie gdy algorytm był modyfikowany.

W dokumentacji zbiorów danych NIH zaleca się uwzględnianie słowników danych, algorytmów dla obliczanych elementów, opisów rekodowania i informacji o pochodzeniu danych. Dokumentacja powinna być wystarczająco jasna, aby ze zbioru mógł skorzystać badacz, który nie uczestniczył w jego tworzeniu (NHLBI, 2026). ([nhlbi.nih.gov](https://www.nhlbi.nih.gov/grants-and-training/policies-and-guidelines/guidelines-for-preparing-clinical-study-data-sets-for-submission-to-the-nhlbi-data-repository?utm_source=openai))

4. Jak zapisywać wzór?

Jeśli zmienna powstaje według wzoru, należy podać go w sposób czytelny oraz objaśnić każde oznaczenie. Najlepiej użyć zarówno zapisu matematycznego, jak i zdania opisowego.

Przykład: wskaźnik masy ciała

Wskaźnik masy ciała można zapisać następująco:

BMI = m / h2

  • BMI – wskaźnik masy ciała, wyrażony w kg/m2;
  • m – masa ciała w kilogramach;
  • h – wzrost w metrach.

Opis metodologiczny powinien doprecyzować, kiedy wykonano pomiar, czy wzrost przeliczono z centymetrów na metry, jak zaokrąglano wynik i co robiono z wartościami nierealistycznymi. Jeżeli w bazie wzrost zapisano jako 172 cm, to przed zastosowaniem wzoru należy użyć wartości 1,72 m. Zastosowanie liczby 172 bez konwersji jednostek dałoby wynik pozbawiony sensu praktycznego.

Dobry wpis w słowniku danych może wyglądać tak: „BMI w punkcie wyjściowym obliczono jako masę ciała w kilogramach podzieloną przez kwadrat wzrostu w metrach. Do obliczenia wymagano obu wartości. Wynik zaokrąglono do dwóch miejsc po przecinku. Pomiarów spoza zdefiniowanego zakresu kontroli jakości nie używano bez uprzedniej weryfikacji w dokumentacji źródłowej.”

5. Dokumentowanie reguł klasyfikacji

Wiele zmiennych pochodnych nie jest wynikiem prostego działania matematycznego, lecz klasyfikacji. Wtedy trzeba podać wszystkie przedziały, progi i warunki brzegowe.

Przykład medyczny: kontrola ciśnienia tętniczego

Załóżmy, że badacz tworzy zmienną binarną htn_control, oznaczającą kontrolowane nadciśnienie. Samo określenie „kontrolowane nadciśnienie” może być niejednoznaczne. Należy ustalić między innymi:

  • czy wykorzystywane jest ciśnienie skurczowe, rozkurczowe czy oba pomiary;
  • czy bierze się pod uwagę średnią z kilku pomiarów;
  • czy próg jest włączający, na przykład „poniżej 140” czy „poniżej lub równo 140”;
  • czy przyjmowanie leków wpływa na definicję;
  • jak traktuje się brak któregoś pomiaru;
  • czy reguła obowiązuje dla wszystkich uczestników, czy zmienia się zależnie od wieku lub choroby współistniejącej.

Przykładowy algorytm może brzmieć: „Zmienna htn_control przyjmuje wartość 1, jeżeli średnia z dwóch prawidłowo wykonanych pomiarów ciśnienia skurczowego jest mniejsza niż 140 mm Hg i jednocześnie średnia z dwóch pomiarów ciśnienia rozkurczowego jest mniejsza niż 90 mm Hg. Przyjęcie wartości 0 oznacza niespełnienie co najmniej jednego warunku. Jeżeli brakuje któregokolwiek z wymaganych pomiarów, wynik koduje się jako brak danych.”

Taki zapis jest znacznie lepszy niż zdanie „pacjentów podzielono na osoby z kontrolowanym i niekontrolowanym ciśnieniem”. Dokumentuje bowiem jednostkę analizy, liczbę pomiarów, sposób agregacji, progi oraz brak danych.

6. Braki danych w zmiennych pochodnych

Braki danych są jednym z najważniejszych elementów dokumentacji. Zmienna pochodna może być nieobserwowana dlatego, że brakuje wszystkich danych wejściowych, albo dlatego, że badacz przyjął zasadę wymagającą kompletności.

Przykładowo, wynik skali składającej się z dziesięciu pozycji można obliczać tylko wtedy, gdy uczestnik udzielił odpowiedzi na wszystkie pytania. Można też dopuścić brak jednej pozycji i zastąpić ją średnią z pozostałych odpowiedzi. Obie strategie mogą być uzasadnione, ale prowadzą do innej zmiennej. Dlatego dokumentacja powinna wskazywać:

  • minimalną liczbę dostępnych pozycji;
  • metodę uzupełniania brakującej pozycji, jeśli ją stosowano;
  • moment, w którym zastosowano imputację;
  • czy reguła dotyczyła wszystkich uczestników;
  • czy utworzono dodatkową zmienną informującą o kompletności danych.

Nie należy ukrywać faktu, że wartość pochodzi z imputacji albo częściowej odpowiedzi. Uzupełniona wartość nie jest tym samym co wartość bezpośrednio zmierzona. W zależności od celu badania należy także rozważyć, czy brak danych nie jest związany z cechami uczestnika lub stanem zdrowia.

7. Zmienne pochodne a role w modelu

Ta sama zmienna pochodna może pełnić różną rolę w różnych analizach. Wynik BMI może być zmienną objaśniającą w modelu ryzyka cukrzycy, zmienną kontrolną w badaniu zależności między aktywnością fizyczną a jakością życia albo elementem kryterium kwalifikacji do badania.

Dokumentacja powinna więc rozdzielać dwie kwestie:

  1. jak zmienna została obliczona;
  2. dlaczego wykorzystano ją w określonej analizie.

Zmiana roli nie powinna prowadzić do zmiany definicji bez wyraźnego uzasadnienia. Jeżeli w jednym modelu BMI analizuje się jako zmienną ciągłą, a w innym jako kategorię, należy opisać oba sposoby użycia. Trzeba także zaznaczyć, czy kategoryzacja była zaplanowana przed analizą, czy została wykonana po obejrzeniu rozkładu danych. Ta informacja jest istotna dla oceny ryzyka selektywnego raportowania i nadmiernego dopasowania modelu.

8. Dokumentacja kodu i wersjonowanie

Opis słowny jest konieczny, lecz w wielu projektach niewystarczający. Warto przechowywać również kod obliczeniowy, na przykład w R, Pythonie, Stacie lub SAS. Kod powinien być czytelny, komentowany i połączony z wersją danych, na której został uruchomiony.

Praktyczny system może obejmować:

  • nazwany plik z kodem tworzącym zmienne pochodne;
  • plik słownika danych;
  • opis mapowania nazw zmiennych pierwotnych na zmienne pochodne;
  • log zmian, w którym zapisuje się datę, autora i powód modyfikacji;
  • testy kontroli jakości, na przykład sprawdzenie zakresu wartości i liczby braków;
  • informację o wersji oprogramowania i pakietów, jeśli wynik może zależeć od implementacji.

Nie oznacza to, że każdy projekt musi mieć rozbudowaną infrastrukturę informatyczną. Nawet prosty arkusz kalkulacyjny może zawierać kolumny: nazwa, definicja, źródła, wzór, jednostka, braki danych, zakres, data aktualizacji, autor. Ważne, aby dokumentacja była aktualna i przechowywana razem z materiałami badania, a nie wyłącznie w pamięci członków zespołu.

9. Przykład praktyczny: wynik obciążenia objawami depresyjnymi

Załóżmy, że w badaniu pielęgniarek użyto kwestionariusza składającego się z dziewięciu pozycji. Każda pozycja ma wartości od 0 do 3. Tworzona jest zmienna phq9_total.

Dokumentacja powinna zawierać co najmniej:

  • nazwy dziewięciu pozycji wejściowych;
  • zakres odpowiedzi dla każdej pozycji;
  • informację, czy pozycje wymagają rekodowania;
  • regułę obliczania sumy;
  • minimalną liczbę odpowiedzi potrzebnych do wyznaczenia wyniku;
  • zakres teoretyczny wyniku;
  • zasady interpretacji kategorii, jeśli są używane;
  • źródło i wersję zastosowanego narzędzia.

Przykładowy wzór:

PHQ9_total = x1 + x2 + … + x9

Symbole x1–x9 oznaczają odpowiedzi na poszczególne pozycje. Jeżeli każda pozycja ma zakres od 0 do 3, teoretyczny zakres sumy wynosi od 0 do 27. Jeżeli dopuszczono jedną brakującą odpowiedź, trzeba jasno określić, czy brak zastępuje się średnią, czy wynik pozostaje nieobliczony. Należy też rozróżnić wynik liczbowy od kategorii nasilenia objawów. Kategoria jest kolejną zmienną pochodną i wymaga własnej dokumentacji.

10. Najczęstsze błędy

  • Opis zbyt ogólny. Zdanie „utworzono wskaźnik ryzyka” nie mówi, jakie zmienne i progi zastosowano.
  • Brak jednostek. Wzór może być formalnie poprawny, ale wynik będzie błędny, jeżeli masa, wzrost lub dawka są zapisane w innych jednostkach.
  • Pomijanie wartości granicznych. Nie wiadomo, do której kategorii należy wartość dokładnie równa progowi.
  • Nieokreślone braki danych. Czy jedna brakująca pozycja unieważnia cały wynik? Czy zastosowano imputację?
  • Mieszanie definicji i interpretacji. Reguła obliczania wyniku nie jest tym samym co jego kliniczna lub społeczna interpretacja.
  • Brak wersjonowania. Po zmianie algorytmu nie można ustalić, która wersja została użyta w publikacji.
  • Ciche rekodowanie. Zamiana kodu 99 na brak danych albo odwrócenie skali powinny być jawnie opisane.
  • Tworzenie zmiennej po obejrzeniu wyniku bez zaznaczenia tego faktu. Taka decyzja może zwiększać ryzyko optymizmu wyników i powinna być odróżniona od analizy zaplanowanej.
  • Nadmierna kategoryzacja. Zamiana zmiennej ciągłej na kilka kategorii może prowadzić do utraty informacji. Jeżeli jest konieczna, należy uzasadnić progi i wskazać ich źródło.

11. Jak wygląda dobry wpis w słowniku danych?

Element Przykład
Nazwa bmi_baseline
Etykieta Wskaźnik masy ciała w punkcie wyjściowym
Źródła weight_kg, height_cm
Wzór weight_kg / (height_cm / 100)^2
Jednostka kg/m2
Typ Zmienna ciągła
Braki Brak wyniku, gdy brakuje masy lub wzrostu
Zaokrąglenie Dwa miejsca po przecinku do celów prezentacyjnych
Kontrola jakości Sprawdzenie wartości skrajnych i zgodności jednostek
Wersja Algorytm 1.1, aktualizacja 2026-09-07

Taki wpis nie zastępuje pełnego protokołu ani kodu, ale pozwala szybko zrozumieć znaczenie zmiennej i odtworzyć podstawowy sposób jej wyliczenia. W większych projektach warto korzystać ze standaryzowanych elementów danych i słowników, takich jak repozytoria NIH Common Data Elements, które porządkują definicje, dopuszczalne wartości i formaty danych (NIH, 2026). ([cde.nlm.nih.gov](https://cde.nlm.nih.gov/?utm_source=openai))

12. Związek z raportowaniem modeli predykcyjnych

W badaniach prognostycznych dokumentacja zmiennych pochodnych ma dodatkowe znaczenie. Wynik predykcyjny może być tworzony z wielu pomiarów, a niejasność dotycząca kodowania lub braków danych utrudnia niezależną ocenę modelu. Wytyczne TRIPOD podkreślają potrzebę przejrzystego raportowania predyktorów, ich pomiaru, przekształceń i sposobu wykorzystania w modelu (Collins et al., 2015). ([pubmed.ncbi.nlm.nih.gov](https://pubmed.ncbi.nlm.nih.gov/?sort=date&term=25560714&utm_source=openai))

Jeżeli na przykład model ryzyka wykorzystuje „wiek”, trzeba określić, czy chodzi o wiek w pełnych latach, wiek w dniu włączenia, wiek w dniu zabiegu czy wiek zakodowany kategoriami. Jeżeli wykorzystuje „pogorszenie stanu”, trzeba podać, jak je zdefiniowano, w jakim oknie czasowym i na podstawie jakich pomiarów.

13. Co warto zapamiętać?

  1. Zmienna pochodna powstaje z innych danych według wzoru, algorytmu lub reguły klasyfikacji.
  2. Jej nazwa i etykieta nie wystarczają do pełnej dokumentacji.
  3. Trzeba wskazać źródła danych, jednostki, wzór, progi, reguły braków i sposób zaokrąglania.
  4. Każda kategoria utworzona z wyniku liczbowego jest odrębną zmienną pochodną i wymaga własnego opisu.
  5. Dokumentacja powinna rozróżniać definicję zmiennej od jej roli w konkretnym modelu.
  6. Warto przechowywać zarówno opis słowny, jak i kod obliczeniowy oraz historię zmian.
  7. Brak informacji o sposobie obliczania może uniemożliwić replikację, utrudnić ocenę błędu i osłabić wiarygodność wniosków.

W praktyce dobrym testem jakości dokumentacji jest pytanie: czy osoba spoza zespołu, mając dostęp do danych pierwotnych i opisu, mogłaby utworzyć dokładnie tę samą zmienną? Jeżeli odpowiedź brzmi „nie”, opis wymaga uzupełnienia. Na tym poziomie metodologia badań łączy się bezpośrednio z zarządzaniem danymi, przejrzystością analizy i odpowiedzialnym raportowaniem wyników omawianym w publicznym szkoleniu na statystyk.edu.pl.

\n

Źródła i dalsza lektura

\n

  1. von Elm, E., Altman, D. G., Egger, M., Pocock, S. J., Gøtzsche, P. C., & Vandenbroucke, J. P., for the STROBE Initiative (2007). The Strengthening the Reporting of Observational Studies in Epidemiology (STROBE) Statement: Guidelines for Reporting Observational Studies. PLoS Medicine, 4(10), e296. DOI: 10.1371/journal.pmed.0040296.
  2. Vandenbroucke, J. P., von Elm, E., Altman, D. G., Gøtzsche, P. C., Mulrow, C. D., Pocock, S. J., Poole, C., Schlesselman, J. J., & Egger, M. (2007). Strengthening the Reporting of Observational Studies in Epidemiology (STROBE): Explanation and Elaboration. PLoS Medicine, 4(10), e297. DOI: 10.1371/journal.pmed.0040297.
  3. Appelbaum, M., Cooper, H., Kline, R. B., Mayo-Wilson, E., Nezu, A. M., & Rao, S. M. (2018). Journal Article Reporting Standards for Quantitative Research in Psychology: The APA Publications and Communications Board Task Force Report. American Psychologist, 73(1), 3–25. DOI: 10.1037/amp0000191.
  4. Collins, G. S., Reitsma, J. B., Altman, D. G., & Moons, K. G. M. (2015). Transparent Reporting of a Multivariable Prediction Model for Individual Prognosis or Diagnosis (TRIPOD): The TRIPOD Statement. Annals of Internal Medicine, 162(1), 55–63. DOI: 10.7326/M14-0697.
  5. National Heart, Lung, and Blood Institute (2026). Instructions for Preparing Clinical Research Study Datasets for Submission to the NHLBI Data Repository. National Institutes of Health. Źródło.
  6. National Institutes of Health (2026). Common Data Elements (CDEs) Program. National Institutes of Health. Źródło.

\n

Podobne wpisy

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *