← Tilbage til For ansatte

Korrekt navngivning og dokumentation af variable er afgørende for at sikre genkendelighed, kvalitet og effektiv vedligeholdelse af projekter. Hos Frontal Lobe anvendes en fast struktur, så alle databaser kan forstås og vedligeholdes af både udvikler og kunde – også efter længere tid.

1. Principper for variabelnavne

Alle variabler skal navngives efter en konsekvent struktur:

[prefix]_[variablebeskrivelse]_[postfix]

• Prefix: instrumentets navn eller forkortelse — fx dem_ for demografi, visit1_ for første visit, lab_ for laboratorieværdier. Formålet er at skabe entydige navne på tværs af instruments og undgå overlap.
• Variablebeskrivelse: en kort og præcis beskrivelse af, hvad feltet indeholder — fx age, sex, height, cholesterol. Undgå specialtegn, mellemrum og danske bogstaver (æ, ø, å). Navnet skal give mening uden at man behøver se feltets label.
• Postfix (valgfrit): angiver datatype eller feltkarakteristika — fx _yn (ja/nej), _dt (dato), _txt (tekst), _num (tal). Bruges kun hvor det øger forståeligheden og konsekvensen i instrumentet.

Eksempler:

• dem_age_num → Deltagerens alder (numerisk)
• dem_sex_yn → Deltagerens køn (Ja/Nej-felt)
• lab_creatinine_num → Kreatininværdi
• visit1_fasting_dt → Dato for fastende blodprøve ved Visit 1

2. Kodning af svarmuligheder

• Kodningen af svarmuligheder skal være logisk, konsekvent og analysevenlig på tværs af hele databasen.
• Generel standard for binære felter: 0 = Nej, 1 = Ja. (Ved behov kan 99 = Ukendt anvendes, men kun hvis feltet tillader “ikke relevant” svarmuligheder.)
• Ved multiple choice-felter (radio buttons eller dropdowns) skal koden følge en logisk orden, fx stigende sværhedsgrad, naturlig rækkefølge eller klinisk relevans.
• Ved checkbox-felter opretter REDCap automatisk en separat variabel for hver mulighed i formatet [variabelnavn]___[kode].
• Af den grund skal koder for checkboxes være korte og sigende, typisk tre bogstaver — fx dem_risk___smk (rygning), dem_risk___htn (hypertension), dem_risk___dm (diabetes).
• Det er bedre at bruge tekst-koder (fx “smk”, “htn”, “dm”) end tal (1, 2, 3) i checkbox-felter, da det gør datafilen mere læsbar og intuitiv i analysefasen.
• Alle kodningsvalg skal fremgå af dokumentationen for at sikre, at analysere kan forstå felternes struktur uden at åbne REDCap.

3. Dokumentation af opsætning

Dokumentationen foregår delvist automatisk via REDCap’s metadata og data dictionary, men suppleres altid af en samlet beskrivelse af de væsentligste designvalg og beslutninger under opsætningen. Opsætningsfilen bruges ikke til at notere alle små valg, men til at samle de større designbeslutninger såsom:

• Struktur (events, instruments, automatiseringer)
• Brug af branching logic, automatisk afsendelse, randomisering mv.
• Afvigelser fra kundens oprindelige ønske, hvis der er foretaget forbedringer
• Eventuelle tekniske begrænsninger eller workaround-løsninger

Dokumentationen opdateres løbende og gemmes i firmaets Dropbox samt i projektets Trello-kort, hvor fremdrift og åbne punkter også registreres. Derudover gemmes følgende typer dokumenter i projektmappen i Dropbox:

• Opsætningsplan (kort oversigt over de vigtigste beslutninger)
• Spørgsmål og afklaringslog (løbende note under udvikling)
• Mødereferater (fra kundemøder, interne koordinationsmøder mv.)
• Versioner af datadictionary (udtræk før og efter ændringer i strukturen)

Alle dokumenter skal ligge i den relevante projektmappe i Dropbox under fx:

/FrontalLobe/Projects/[ProjektNavn]/Documentation/

Ved projektets afslutning skal der foreligge en endelig version af dokumentationen, som svarer til databasen i Production-mode.

4. Krav til navngivning og dokumentation

• Alle variable skal have entydige navne – ingen må genbruges på tværs af instruments.
• Navne skal kunne læses uden forklaring (ingen interne forkortelser, som kun udvikleren forstår).
• Alle ændringer i struktur eller logik skal dokumenteres kort i opsætningsfilen og/eller i Trello.
• Kodning af svarmuligheder skal følge de fælles standarder (0/1 og korte tekstkoder til checkboxes).
• Ved større ændringer (>10 felter eller >2 instruments) skal ny data dictionary eksporteres og arkiveres.
• Test-records skal oprettes og navngives tydeligt (fx TEST01, TEST02) for at dokumentere funktionalitet.

5. Formål

Denne struktur sikrer, at:

• Alle projekter kan overdrages mellem medarbejdere uden tab af viden.
• Alle felter og logikker kan spores tilbage til deres oprindelse og formål.
• Kodningen er konsekvent, forståelig og klar til analyse uden ekstra oprydning.
• Kunden altid kan få en forståelig oversigt over databasens opbygning.
• Frontal Lobe’s databaser fremstår som velstrukturerede, veldokumenterede og let vedligeholdelige.