INTRODUKTION TIL · 2019. 6. 17. · Introduktion til REDCap Side 5 af 52 REDCap vejl. 1, version 2, OPEN 14-06-2019 2 INTRODUKTION Dette dokument er tænkt som en introduktion til

INTRODUKTION TIL

Version af dette dokument: V.2.0

Senest opdateret: 14-06-2019

REDCap version: 8.10.7

Skrevet af: Anders K. Haakonsson (Datamanager i OPEN)

Introduktion til REDCap Side 2 af 52

REDCap vejl. 1, version 2, OPEN 14-06-2019

1 INDHOLDSFORTEGNELSE

1 Indholdsfortegnelse .................................................................................................................................................... 2

2 Introduktion ................................................................................................................................................................ 5

2.1 Om REDCap ....................................................................................................................................................... 5

2.2 Guide til at bruge denne manual ...................................................................................................................... 5

2.2.1 Nomenklatur ................................................................................................................................................. 5

3 Overblik over redcap .................................................................................................................................................. 6

3.1 Brugeroprettelse ............................................................................................................................................... 6

3.2 Login .................................................................................................................................................................. 6

3.3 Velkomstside ..................................................................................................................................................... 6

3.4 Projektoversigt .................................................................................................................................................. 7

3.5 Navigation overblik ........................................................................................................................................... 8

3.5.1 project Home ................................................................................................................................................ 9

3.5.2 Project Setup ................................................................................................................................................. 9

3.5.3 Other functionality ...................................................................................................................................... 10

3.5.4 Project Revision History .............................................................................................................................. 11

4 Opbygning af REDCap instrumenter ......................................................................................................................... 11

4.1 Online designer ............................................................................................................................................... 11

4.1.1 REDCap Shared Library ............................................................................................................................... 13

4.2 Opbygning af instrumenter ............................................................................................................................. 13

4.2.1 Det særlige felt record id ............................................................................................................................ 14

4.2.2 Redigering af felter – field labels og variabelnavne .................................................................................... 14

4.2.3 God skik for navngivning af variable ........................................................................................................... 15

4.2.4 Opretning af nye felter ............................................................................................................................... 16

4.3 Gennemgang af felttyper ................................................................................................................................ 17



4.3.1 Preview ....................................................................................................................................................... 17

4.3.2 Textbox ....................................................................................................................................................... 18

4.3.3 Notesbox ..................................................................................................................................................... 20

4.3.4 Calculated Fields ......................................................................................................................................... 21

4.3.5 Drop-down, radiobutton og checkbox ........................................................................................................ 22

4.3.6 God skik for kodning af værdier .................................................................................................................. 24

4.3.7 Begin new section feltet ............................................................................................................................. 24

4.3.8 File upload feltet ......................................................................................................................................... 25

4.3.9 Descriptive text feltet ................................................................................................................................. 26

4.3.10 Slider felt ................................................................................................................................................ 27

4.3.11 Matrix felt ............................................................................................................................................... 28

4.3.12 Identifiers og Required Fields ................................................................................................................. 30

4.3.13 Felt Layout .............................................................................................................................................. 30

4.3.14 Redigering, kopiering, flytning og sletning af felter ............................................................................... 31

4.4 Forgreningslogik .............................................................................................................................................. 31

4.5 Fremgangsmåde i opbygningen af instrumenter ............................................................................................ 34

4.6 Longitudinale studier og events ...................................................................................................................... 34

4.6.1 Aktiver projekt som longitudinalt ............................................................................................................... 34

4.6.2 Opsætning af begivenheder / Events.......................................................................................................... 34

4.6.3 Tilknyt instrumenter til events .................................................................................................................... 36

5 DAta indtastning og projektoverblik ......................................................................................................................... 39

5.1 Oprettelse af en ny projektdeltager ................................................................................................................ 39

5.1.1 Forskel for longitudinale studier ................................................................................................................. 40

5.2 Indtastning ...................................................................................................................................................... 42

5.2.1 Gemning af indtastning ............................................................................................................................... 43

5.3 Fejlmeddelelser og notifikationer ................................................................................................................... 44

5.3.1 Uudfyldte required fields ............................................................................................................................ 44



5.3.2 Forsøg på at indtaste ikke valideret værdiformat ....................................................................................... 44

5.3.3 Forsøg på at indtaste uden for valideringsranges ....................................................................................... 45

5.3.4 Ændringer i opstrøms felter der påvirker nedstrøms felter........................................................................ 45

5.3.5 Fejl i forgreningslogik .................................................................................................................................. 46

5.3.6 Fejl i Calculated fields ................................................................................................................................. 46

5.4 Overblik over indtastninsstatus ...................................................................................................................... 47

5.4.1 Ikke-longitudinalt ........................................................................................................................................ 47

5.4.2 Longitudinalt ............................................................................................................................................... 49

6 Andre funKtionaliteter i REDCap .............................................................................................................................. 51

6.1.1 Surveys: ....................................................................................................................................................... 51

6.1.2 Randomisering ............................................................................................................................................ 51

6.1.3 Calendar og Scheduling ............................................................................................................................... 51

6.1.4 Data import ................................................................................................................................................. 51

6.1.5 Data Export ................................................................................................................................................. 51

6.1.6 Data Comments og Data Resolution Workflow .......................................................................................... 51

6.1.7 Double Data Entry ....................................................................................................................................... 52

6.1.8 Data Quality ................................................................................................................................................ 52

6.1.9 Report builder ............................................................................................................................................. 52



2 INTRODUKTION

Dette dokument er tænkt som en introduktion til de kernefunktionaliteter i REDCap, der knytter sig til oprettelse af

instrumenter/skemaer samt til indtastning og overblik. Den dækker således ikke uddybende REDCaps mange moduler

og muligheder. Disse vil med tiden blive dokumenteret i særskilte dokumenter. Intentionen er, at forskeren der læser

dette dokument i forbindelse med opstarten af et REDCap projekt vil være i stand til at udføre en stor del af arbejdet

med opbygning af skemaer, events og test. Det er således ikke en erstatning for rådgivning fra OPENs datamanagere,

og det anbefales at tage kontakt til disse i tilfælde af problemer. Udover dokumentet her, anbefales det desuden at

udnytte de video tutorials, der er lavet af REDCap konsortiet. Disse er tilgængelige via OPENs REDCap platform, eller

direkte fra konsortiets hjemmeside http://www.project-redcap.org/

2.1 OM REDCAP

REDCap er et såkaldt Electronic Data Capture system (EDC) designet til at lette indsamling og håndtering af data i

forbindelse med forskellige former for kliniske studier. Systemet er udviklet på Vanderbilt Universitet, som udgav

første version i 2008. Der foregår løbende udvikling af systemet, og der er efterhånden et aktivt community af

brugere, der bidrager med ny funktionalitet i form af plugins til REDCap. REDCap distribueres og administreres under

en konsortiummodel som tillader konsortiemedlemmer at lave en lokal installation af systemet.

OPEN er medlem af REDCap konsortiet og har siden juni 2013 haft en aktiv REDCap installation. OPENs datamanagere

er ansvarlige for driften af REDCap platformen, som fysisk hostes af Region Syd IT.

2.2 GUIDE TIL AT BRUGE DENNE MANUAL

Det anbefales, at skimme dette dokument igennem inden man for alvor begynder at opbygge sit konkrete

forskningsprojekt. Eksperimentér med forskellige felttyper, forgreningslogik og opsætning af events. Sørg også for at

finde en god konvention for navngivning af variable og kodning af valgmuligheder tidligt i processen. Dette vil også

blive gennemgået i dette dokument, og der bliver anbefalet nogle retningslinjer.

I forbindelse med oprettelse af et REDCap projekt i OPEN, har man mulighed for at starte fra en skabelon, der har til

hensigt at give et overblik over mulighederne og opfordre til selv at udforske systemet samtidigt med, at man læser

dette dokument. Når man er klar til at kaste sig over sit eget projekt, er det blot et spørgsmål om at omdøbe eller

slette de instrumenter, man ikke skal bruge.

2.2.1 NOMENKLATUR

I dette dokument gøres der brug af en række begreber til beskrivelse af funktioner og elementer. Nogle af disse

fremgår af denne liste:

Instrument I REDCap bruges ordet instrument om et skema med forskellige felter til indsamling af data. Nogle vil kende dette som en Case Report Form (CRF)

Survey Et spørgeskema til udsendelse. I REDCap er et survey et instrument, der er aktiveret som survey Projektdeltager En person f.eks. patient eller kontrolperson, der skal indsamles data om i forbindelse med et

forskningsprojekt Projektpersonale Den gruppe personer der er tilknyttet projektet til opbygning af projekt og indtastning af data. Projektansvarlig Overordnet ansvarlig for projektet. Vil være en af underskriverne af OPENs licensaftale

http://www.project-redcap.org/



3 OVERBLIK OVER REDCAP

I dette kapitel gennemgås først de formelle ting omkring oprettelse og adgang til REDCap. Herefter gennemgås de

overordnede skærmbilleder og menuer.

3.1 BRUGEROPRETTELSE

Enhver bruger af REDCap identificeres ved hjælp af et unikt login navn, som anvendes ved login sammen med et

selvvalgt password. Login er strengt personligt og må aldrig deles med andre. Al logning i REDCap er baseret på

loginnavnet. Ved brugeroprettelse har brugeren selv mulighed for at ønske et loginnavn, som minimum skal være 3

bogstaver langt. Man kan på den måde vælge at genanvende sit login navn fra et andet system, såsom Cosmic.

Brugeren oprettes af datamanager med sit login, sit fulde navn og email adresse og modtager en automatisk email

med link til OPENs REDCap sider samt login og midlertidigt password. I forbindelse med første login skal brugeren selv

ændre dette til et personligt password

3.2 LOGIN

Login foregår på hjemmesiden https://open.rsyd.dk/redcap/ via skærmbilledet som ses i Figur 1.

Figur 1

Bemærk at REDCap registrerer mislykkede logins, og spærrer et login efter 3 fejlslagne loginforsøg. For at få genåbnet

en spærret konto skal en REDCap administrator kontaktes

3.3 VELKOMSTSIDE

Efter succesfuldt login præsenteres man for REDCaps velkomstside (Figur 2). Her beskrives systemet ganske kort, og

der linkes til nogle grundlæggende træningsmaterialer. Velkomstsiden giver adgang til 4 andre faner udover forsiden.

Training ressources linker til Vanderbilt Universitets video undervisningsressourcer, som det varmt kan anbefales at

tage et kig på. De kan også findes direkte via REDCap konsortiets hjemmeside: http://www.project-redcap.org/.

https://open.rsyd.dk/redcap/

http://www.project-redcap.org/



Fanen ’Help & FAQ’ linker til et REDCap dokument, som rummer svar på mange spørgsmål relateret til REDCaps

funktioner.’ Send-it’ fanen linker til en særlig REDCap funktionalitet, der muliggør sikker deling af dokumenter imellem

brugere af OPENs REDCap platform.

Figur 2

3.4 PROJEKTOVERSIGT

Fanen My Projects leder til projektoversigten for den enkelte bruger, hvor brugeren kan se alle de projekter, han har

fået tildelt rettigheder til at se (Figur 3). Ved første login vil der typisk kun være et enkelt tilgængeligt projekt, som på

forhånd er oprettet af en af OPENs datamanagere. Denne oprettelse vil normalt ske i samråd med den

projektansvarlige, således at projektet oprettes med den rette type, projektnavn, affiliation, rettigheder og

nødvendige værktøjer slået til.

Figur 3



Projektoversigten giver et kortfattet overblik over projektet eller projekterne ved hjælp af 5 status kolonner i højre

side. Records angiver, hvor mange records (typisk svarende til individer i et projekt) der er oprettet. Fields angiver, det

samlede antal felter til dataopsamling der oprettet i projektets skemaer/instrumenter. Instruments angiver, hvor

mange forskellige instrumenter der er oprettet. Type viser, om projektet er sat op som et klassisk projekt eller som et

longitudinalt studie (herom senere). Endeligt viser status kolonnen, om projektet er i udviklingsfase eller i

produktionsfase. Alle projekter vil starte i udviklingsfasen. Når man klikker på projektnavnet, kommer man ind på

forsiden af det pågældende projekts hjemmeside.

3.5 NAVIGATION OVERBLIK

REDCap har en relativt simpel vinduesopbygning og navigation. Skærmbilledet er overordnet opdelt i en venstre og en

højre side (Figur 4).

Venstre side af skærmen er opdelt i et antal separate sektioner. Øverst er der adgang til projektoversigten My

Projects, samt til Project Home og til Project Setup. Derefter følger nogle menupunkter, der relaterer sig til Data

Collection, og herunder igen en række menupunkter under overskriften Applications. Applications er forskellige

moduler og funktioner, som kan anvendes i forbindelse med REDCap. Præcist hvilke applikationer, der vises for en

given bruger for et givet projekt, afhænger af hvilke rettigheder den enkelte bruger har fået tildelt. Endeligt er der i

den nederste sektion adgang til REDCaps hjælpemateriale samt video tutorials. Menuerne i venstre side af

programmet er tilgængelige fra alle steder i REDCap.

Figur 4



Klikkes der på Project Home eller Project Setup øverst i venstre side åbnes i højre side et skærmbillede med 4 faner

Project Home, Project Setup, Other Functionality og Project Revision History.

3.5.1 PROJECT HOME

Project Home(Figur 4) giver øverst adgang til genveje til nogle REDCap funktionaliteter og et project dashboard

nederst, der giver et kortfattet overblik over projektets status i form af en brugeroversigt, en dataoversigt og en

kalenderoversigt.

3.5.2 PROJECT SETUP

Den anden fane Project Setup (Figur 5) giver adgang til en oversigt over en række indstillinger for projektet. Her kan

forskellige funktionaliteter og moduler aktiveres og overordnede ændringer af projektet foretages. Project Setup

siden er samtidigt tænkt som et overblik over den proces, der typisk skal gennemløbes i forbindelse med opbygning af

et REDCap projekt - fra udvikling til test og til sidst til produktion. Øverst tages stilling til meget overordnede

beslutninger om strukturen såsom, hvorvidt der er tale om et longitudinalt studie, og om der skal anvendes surveys.

Næste fase (som er den mest omfattende) er skemaopbygningsfasen, hvorefter andre moduler evt. kan aktiveres.

Længere nede er der testfasen og endeligt til sidst på project setup siden hvor projektet kan løftes i produktion. Ved

hver sektion kan man ’tjekke af’, når man mener, en given fase er overstået. Project setup siden er designet med det

typiske workflow for øje, men stiller ingen krav til om man følger denne proces. De enkelte funktioner på Project

Setup siden, vil blive gennemgået, når det bliver relevant, og ikke helt i den angivne rækkefølge



Figur 5

3.5.3 OTHER FUNCTIONALITY

Under Other Functionality fanen findes funktionaliteter relateret til kopiering, sletning og arkivering af projektet. Her

er det blandt andet muligt at slette alle de deltagerdata, der måtte være indtastet på projektet. Dette vil ikke blive

uddybet i dette dokument



3.5.4 PROJECT REVISION HISTORY

Under denne fane kan man se de forskellige versioner af projektets data dictionary fra projektet løftes i produktion og

fremadrettet. Data dictionary er den fil, der beskriver projektets opbygning med instrumenter og felter. Dette vil ikke

blive uddybet i dette dokument

4 OPBYGNING AF REDCAP INSTRUMENTER

I dette kapitel gennemgås opbygningen af projekter i REDCap. Dvs. en gennemgang af hvordan man opbygger

instrumenter til dataopsamling og strukturerer sit projekt. I et senere kapitel gennemgås indtastningen af data. Det

kan dog anbefales løbende at tage et kig på indtastningskapitlet, da opbygningen af er REDCap instrument typisk er en

iterativ proces, hvor man løbende prøver de ting af, der opbygges.

4.1 ONLINE DESIGNER

Et skema eller spørgeskema (survey) til opsamling af data kaldes i REDCap for et instrument. I venstre side under Data

Collection sektionen vises en oversigt over de instrumenter, der er oprettet på det aktuelle projekt (dog kun hvis

projektet ikke er opsat som longitudinalt). Alle nye projekter oprettes automatisk med ét start instrument, der hedder

My First Instrument, med mindre det er oprettet på baggrund af en skabelon, i hvilket fald der vil være flere

instrumenter. Den letteste måde at se nærmere på sine instrumenter og redigere i dem, er via REDCaps Online

Designer. Adgang til Online Designeren findes i Project Setup fanen under overskriften Design you data collection

instruments (Figur 6). REDCaps online designer vil for de fleste brugere være den primære metode til at opbygge data

instrumenter i REDCap. Instrumenter kan dog også opbygges direkte i et data dictionary, som herefter uploades på

projektet, men dette vil ikke blive gennemgået her. Der henvises til REDCap konsortiets undervisningsvideoer eller

datamanager for mere information om denne funktion.

Figur 6



Alternativt kan man klikke på det lille link Edit instruments i data collection menuen i venstre side (Figur 7).

Figur 7

Derved åbnes Online Designer oversigten sig i højre skærmbillede (Figur 8).

Figur 8

I denne oversigt vises alle de instrumenter, der er oprettet for dette projekt. Herfra er der flere muligheder. Ønsker

man at kigge nærmere på instrumentet og arbejde videre på det klikkes på instrumentnavnet. Ønsker man at oprette

et nyt instrument klikkes Create a new instument from scratch øverst. Navnet på instrumentet ændres ved at klikke

på rename og herefter skrive et nyt navn for instrumentet. Et instrument kan slettes ved at klikke på delete.

VIGTIGT: Slet aldrig det øverste instrument i listen. Det øverste instrument i et REDCap projekt er særligt, fordi det

første felt i dette instrument indeholder det record id der identificerer en patient/forsøgsenhed igennem hele

studiet (Mere herom om senere).

Det første instrument bør i stedet tilpasses det konkrete studie ved at bruge rename til at give det et passende navn, i

stedet for at oprette et nyt instrument nedenunder. I oversigten kan desuden ses hvor mange fields et instrument

indeholder (bemærk at My First Instrument allerede indeholder ét felt), og man kan downloade en pdf udgave af

instrumentet. Bemærk at pdf eksporten desværre ikke håndterer ikke-ascii karakterer som f.eks. æøå særlig godt.

Bemærk også øverst i dette skærmbillede et eksempel på REDCaps lette adgang til en kort (typisk 2-5 minutter)

demonstrationsvideo om det konkrete emne i dette skærmbillede(Figur 9)

Figur 9



I skærmbilledet herunder (Figur 10) har vi omdøbt det første instrument til Baseline og har oprettet to nye tomme

instrumenter kaldet 1.Kontrol og 2.Kontrol.

Figur 10

Bemærk at det er muligt at ændre rækkefølgen af instrumenter ved at trække i de blå pile, der kommer til syne, når

man holder musen over kolonnen til venstre for instrumentnavnet. Husk at det øverste instrument ikke skal flyttes.

4.1.1 REDCAP SHARED LIBRARY

Endeligt er der fra Online designer overblikket adgang til at downloade et nyt instrument direkte fra REDCap Shared

Library, som er en valideret ressource under REDCap konsortiet, der indeholder mange hundrede

standardinstrumenter, som ofte anvendes i klinisk forskning. REDCap Shared Library indeholder desuden typisk

oplysninger om den originale kilde eller publikation. Disse instrumenter er vist nok alle i engelsk version, men det kan i

mange tilfælde være hurtigere at oversætte et engelsk skema end at bygge sit eget fra bunden.

4.2 OPBYGNING AF INSTRUMENTER

Et instrument redigeres og opbygges ved at klikke på det pågældende instrument i oversigten (Figur 10). I eksemplet

her arbejder vi videre med Baseline instrumentet ovenfor i Figur 10. Når der klikkes på instrumentets navn åbner

skærmbilledet i Figur 11 sig.



Figur 11

Vi er stadig under fanen Online Designer, men kigger nu på et konkret skema. Også her er der en kort video

introduktion til mulighederne.

4.2.1 DET SÆRLIGE FELT RECORD ID

Baseline instrumentet indeholder på forhånd et enkelt felt kaldet Record ID, som er et særligt felt, som det også

fremgår af noten under feltet. I et givet projekt skal der altid være en variabel der unikt definerer forsøgsenheden.

Typisk vil en forsøgsenhed være et individ, men det kunne også eksempelvis være en graviditet eller noget helt andet.

Det første felt i det første instrument anvendes til at opsamle dette Record ID der anvendes til identifikationen.

Record ID feltet findes kun i det første instrument og REDCap vil automatisk associere alle data indtastet i andre

instrumenter til det samme Record ID. Da Record ID er fundamentalt for at binde alle data for det samme individ

sammen, skal det nødvendigvis være med i enhver eksport af data fra REDCap. Da det skal være muligt at lave en

eksport af data der ikke indeholder direkte personfølsomme data (se afsnittet om markering af felter med

personfølsomt indhold 4.3.12), må Record ID eksempelvist ikke være et CPR-Nummer. CPR-nummeret må gerne

indsamles i et separat felt (som kan markeres som følsomt). Record ID feltet er altid et tekstfelt.

4.2.2 REDIGERING AF FELTER – FIELD LABELS OG VARIABELNAVNE

I øverste venstre hjørne af feltet i Figur 11 er der en gul blyant, som giver adgang til at redigere det pågældende felt



Figur 12

Figur 12 viser det skærmbillede, der åbner sig til redigering af feltet. Med rødt er igen tydeligt angivet, at dette felt er

særligt, og vi har kun begrænsede muligheder for at redigere det. Redigeringsmulighederne begrænser sig til ændring

af Field Label i den venstre kasse samt Variable Name og Validation i højre side. Fra et teknisk synspunkt, er den

vigtigste oplysning for ethvert felt variabelnavnet, som er det navn, som datapunkter indtastet i dette felt bliver gemt

under i databasen. Variabelnavne skal være unikke, således at ingen felter på tværs af alle instrumenter i projektet må

dele variabelnavn. Se tekstboks om god variabelskik. Field Label feltet indeholder den beskrivende tekst, der

beskriver, hvad der skal indtastes i feltet. Det er ikke obligatorisk at dette felt indeholder en værdi, men det vil stort

set altid være hensigtsmæssigt at udfylde feltet med en præcis beskrivelse af feltets indhold. Der er ingen krav om, at

felt labels er unikke på tværs af projektet. I eksemplet er det muligt at ændre både label og variabelnavn til noget

passende for det konkrete projekt – f.eks. Patient ID eller CPR-nummer. Endeligt har man mulighed for at vælge en

validering af Record ID feltet (mere herom i næste afsnit). I de næste afsnit gennemgås den videre opbygning af

instrumenter i REDCap, når Record ID feltet er på plads.

4.2.3 GOD SKIK FOR NAVNGIVNING AF VARIABLE

En ordentligt procedure for navngivning af variable i et projekt er ikke uvæsentligt, og kan gøre mange ting lettere

undervejs og især i analysefasen af projektet. Brug noget tid INDEN opbygningen af projektet for alvor starter til at

finde et godt system. Følgende er gode retningslinjer, som er værd at overveje.

I REDCap må variabelnavne kun indeholde tal og bogstaver og underscores (ingen mellemrum), og der skelnes ikke

imellem store og små bogstaver (variable gemmes og vises som små bogstaver). Variabelnavnene vil i analysefasen af

projektet være den primære identifikation af data, så det er vigtigt, at variabelnavnet er sigende. Samtidigt bør det

ikke være for langt, da det gør det sværere at overskue og referere til bestemte variable i analysefasen og undervejs i

instrumentopbygningen i REDCap.

Undgå at bruge æøå i variabelnavne, da det kan forvirre nogle analyseværktøjer. Mange vælger at anvende engelske

variabelnavne som f.eks. visit_date i stedet for besoegs_dato, men det er naturligvis op til den enkelte. Forsøg dog at

være konsistent igennem projektet. Brug underscores til at bryde navnet, hvis det er nødvendigt.

De fleste projekter vil indeholde mere end et instrument, og det vil ofte være en ide at referere til det instrument et

felt hører til ved at anføre det forrest i variabelnavnet. Alle variable i baseline-instrumentet kunne f.eks. foranstilles



med ’bl_’, således at f.eks. besøgsdatofeltet får et variabelnavn, der hedder ’bl_visit_date’. På den måde har man også

mulighed for at bruge det samme variabelnavn i mere end et instrument blot med forskellig foranstillet værdi. Man

kan f.eks. have en besøgsdato både i Baseline og i 1.konsultation instrumenterne, som kan få navnene ”bl_visit_date”

og ”k1_visit_date”. Desuden giver en instrumentspecifik foranstilling visse fordele i forbindelse med større ændringer i

instrumenterne, når man anvender data dictionary tilgangen til oprettelse af instrumenter (gennemgås ikke her), da

det bliver lettere at lave søg og erstat på variabelnavne.

I nogle instrumenter, som f.eks. store standardinstrumenter eller spørgeskemaer kan det være svært at anvende

sigende variabelnavne til alle felter. Der kan det være bedre at anvende et fornuftigt nummereringssystem. Stadigvæk

med brug af en foranstillet angivelse af instrumentet. Ofte er der f.eks. nogle grupper af spørgsmål, der hver berører

et bestemt emne og har samme svarmuligheder. I sådan et tilfælde kunne en navngivningsmetode være: k1_q1a,

k1_q1b…k1_q2a… Her angiver k1 instrumentet, q er en forkortelse for question, 1a er første spørgsmål i første

gruppe, 1b er andet spørgsmål i første gruppe, 2a er første spørgsmål i anden gruppe osv. Når man opretter felter i

REDCap, så findes der en mulighed for, at lade REDCap selv finde på et variabelnavn baseret på den felt label man har

valgt, men det anbefales IKKE at anvende denne mulighed, da de autogenererede navne sjældent bliver særligt

sigende

4.2.4 OPRETNING AF NYE FELTER

Et nyt felt i et instrument oprettes ved at klikke på add field’ knappen et sted i oversigten over instrumentet (her

baseline instrumentet Figur 11). Hvis der allerede er mere end et felt i instrumentet, kan man klikke add field præcis

der, hvor man ønsker det nye felt oprettet i forhold til de eksisterende. Det åbner vinduet i Figur 13.

Figur 13

I ovenstående vindue afventer REDCap, at man vælger, hvilken felttype det nye felt skal oprettes som. Hvis man

allerede har oprettet andre felter, vil REDCap antage at det nye felt er magen til det seneste. Er dette ikke tilfældet

vælges en anden type. REDCaps felttyper fremgår af drop-down listen (Figur 14). Se evt. den lille video om felttyper,

der linkes til i dette vindue.



Figur 14

4.3 GENNEMGANG AF FELTTYPER

I det følgende gennemgås de forskellige felttyper i REDCap

4.3.1 PREVIEW

Figur 15 viser hvordan de forskellige felttyper tager sig ud, når de vises for brugeren i indtastningsøjeblikket. Denne

fremstilling af instrumentet fås ved at klikke på ’Preview instrument’ i toppen af Online Designeren, eller ved at

oprette en patient til indtastning (herom senere)



Figur 15

I det følgende gennemgås felttyperne i Figur 15 en af gangen. Der vises både hvordan det oprettede felt fremstår i

instrumentet, samt den dialogboks der skal udfyldes for at oprette feltet. Bemærk at den visuelle fremstilling der vises

i Figur 15, er den måde felterne fremstår på i Preview mode eller i indtastningsøjeblikket. Den er ikke helt identisk

med den måde de fremstår på i opbygningsfasen i online designeren, som gennemgås i de næste afsnit.

4.3.2 TEXTBOX

Textboxen (Figur 16) er en af de mest anvendte felttyper i REDCap, idet den både anvendes til tekst, numeriske

værdier og datoer.



Figur 16

Som for alle andre felttyper indeholder textbox setup dialogen et field label til angivelse af en forklarende tekst samt

et felt til variabelnavnet (se boks angående variabelnavngivning). De to Yes-No Radiobutton sektioner Required og

Identifier er gennemgående for alle felttyper, men diskuteres separat i afsnittet Identifiers og Required Fields. Det

samme er tilfældet for boksene Custom Alignment og Field Note, som diskuteres under afsnittet Felt Layout.

4.3.2.1 FELTVALIDERING

Feltet validation indeholder en række muligheder for at kontrollere, hvad der kan indtastes i et textboks felt. Der kan

vælges imellem følgende valideringsregler (Figur 17).

Figur 17

Øverst findes to forskellige CPR-nummer valideringer hhv med og uden bindestreg. Disse validerer at der indtastes en

dato imellem 00 og 31, en måned imellem 00 og 12 og et år imellem 00 og 99 efterfulgt af 4 cifre uden restriktioner.



Det er altså ikke umuligt at indtaste et ikke validt cpr-nummer, men ingen valide cpr-numre vil blive afvist. Der findes 3

forskellige Date valideringer svarende til forskellig rækkefølge af dag, måned og år i datoen. Dato med klokkeslæt kan

valideres med en af de 6 Datetime valideringsregler. Når der valideres med en date eller datetime regel, vil feltet

visuelt præsentere sig, som det kan ses i Figur 15 med en lille kalender og evt. også et ur, hvor man kan klikke sig til

dato og tidspunkt i stedet for at taste.

Email validering tjekker at den indtastede værdi indeholder et @ samt afsluttes med et punktum og suffix

([email protected]). Integer er til validering af heltal, altså værdier uden decimaler. Letters only godkender kun tekster

bestående af bogstaver. MRN er et amerikansk identitetsformat, som ikke bør anvendes. Endeligt findes 3 forskellige

number formater. Number kan indeholde enhver tekststreng der udelukkende indeholder tal og decimal punktum

(bemærk REDCap anvender punktum som decimal separator og ikke komma). Number (1 decimal place) og Number

(2 decimal places) godtager kun værdier, der afsluttes med 1 eller 2 decimaler efter punktum. Endeligt er der en

tidspunktsvalidering uden dato og et amerikansk telefonnummer.

Vælges en datovalidering eller numerisk validering får man også mulighed for at indtaste øvre og nedre

grænseværdier for værdien. Forsøger man at indtaste en værdi uden for det definerede område, bliver man mødt

med en advarsel herom, hvorefter man kan kontrollere, om der er tale om en fejl. Er der ikke tale om en fejl, kan man

godt tilsidesætte advarslen. Man kan altså godt vælge at bruge grænseværdier, som langt de fleste bør ligge indenfor

og stadig rumme de få, der falder udenfor.

Figur 18

Bemærk at et tekstfelt kan indeholde lige så meget tekst som en notesbox (flere tusind karakterer), men egner sig

visuelt ikke særlig godt til lange tekster. Notesboxen indeholder til gengæld ingen valideringsmuligheder. Når

tekstfeltet er oprettet (der trykkes save), fremstår det som det ses i Figur 19 herunder. Bemærk at afhængigt af den

valgte validering, kan den i visse tilfælde fremstå anderledes. Se f.eks. Figur 15 for et eksempel på et datovalideret

tekstfelt.

Figur 19

4.3.3 NOTESBOX

Notesboxen giver mulighed for visuelt at præsentere en større tekst i samme vindue. Figur 20 viser opsætningssiden

for en notebox. Der angives en Field Label samt et variabelnavn. Notesboksen tillader ingen form for validering af det

indtastede indhold.



Figur 20

En oprettet notesboks fremstår, når den er oprettet i Online designeren som i Figur 21

Figur 21

4.3.4 CALCULATED FIELDS

Et calculated field kan anvendes til automatisk at udregne og gemme en værdi baseret på en ligning. Denne ligning

kan referere til værdier i andre felter i det aktuelle instrument eller i andre instrumenter. Den udregnede værdi kan

bruges som et relevant datapunkt som f.eks. et BMI eller en datodifference, eller det kan være brugbart i forbindelse

med mere komplicerede forgreningslogikker. Når man i et calculated field ønsker at referere til værdien af en anden

variabel anvendes firkantede parenteser rundt om referencevariablen [variabelnavn]. Hvis den refererede variabel

befinder sig i et andet datainstrument, og hvis projektet er aktiveret som et longitudinalt studie (Afsnit 4.6) er det

også nødvendigt at referere til event navnet foran variabelnavnet [event_navn][variabel_navn].

Figur 22 herunder demonstrerer opsætningen af et calculated field. Udover field label og variabelnavn er der

mulighed for at skrive ligningen for den udregning der ønskes foretaget. I eksemplet er vist, hvordan et BMI kan



udregnes ud fra værdier i felterne med variabelnavne: bl_weight og bl_height (højde angives typisk i cm – derfor

ganges med 10000).

Figur 22

For yderligere detaljer om formatering af ligninger i calculated fields henvises til linket How do I format the equation,

som findes direkte i vinduet eller til Help & FAQ informationen i REDCap. I skemaet herunder angives et par eksempler

på hyppigt forekommende ønsker til calculated fields.

BMI fra vægt (kg) og højde (cm) – afrundet til 1 decimal. round([vaegt]/(([ hojde]/100)^(2)),1) Alder på en given dato (Dato) fra DateOfBirth. Her antages datoer formateret efter dmy format.

rounddown(datediff([dob],[dato],'y','dmy'))

Antal dage imellem to datoer. Datediff([dato1],[dato2],’d’,’dmy’)

Endeligt ses i Figur 23 hvordan feltet ser i online designeren, når det er oprettet

Figur 23

4.3.5 DROP-DOWN, RADIOBUTTON OG CHECKBOX



Felttyperne multiple choice drop-down, multiple choice radiobutton og Checkboxes er opsætningsmæssigt identiske.

I Figur 24 vises opsætningen for multiple choice radiobutton.

Figur 24

Som altid angives en field label samt et variabelnavn. Derudover findes nu et felt til angivelse af de

forhåndsdefinerede valgmuligheder (Choices) og deres kodede værdier. Syntaksen er således, at hver valgmulighed

foranstilles med den ønskede kode for dette valg efterfulgt af komma. Der kan indtastes flere tusinde valgmuligheder,

hvilket i givet fald kun vil egne sig til et drop-down felt. Vælger man ikke selv at kode sine valgmuligheder vil REDCap

autonummere dem fra 1 og op.

Den visuelle forskel på de tre felttyper illustreres i Figur 15. Derudover gælder, at det kun er checkboxen der muliggør

mere end et valg. Udover det visuelle er der en markant forskel på, hvordan data lagres i databasen og fremstår ved

eksport og i den senere analyse afhængigt af om man vælger drop-down eller radiobutton (som begge kun godtager

ét svar) i forhold til at vælge checkboxes. Kort fortalt kan data fra en drop-down eller radiobutton felt repræsenteres

som én enkelt variabel/kolonne i de eksporterede data, hvorimod en checkbox kræver en kolonne pr. svarmulighed.

Dette uddybes ikke her, men betyder at checkboxes aldrig bør anvendes i situationer, hvor der kun skal vælges én

værdi. Undtagelsen er felter designet, som en simpel ’kryds af boks’ hvor der således kun er et enkelt valg (at klikke

eller ikke at klikke). Her bør checkboxes anvendes frem for radiobuttons.

Resultatet af oprettelsen af checkboxen, som den ses i Online designeren, kan ses i Figur 25

Figur 25



4.3.6 GOD SKIK FOR KODNING AF VÆRDIER

Ligesom med variabelnavne er det fornuftigt at have en forhåndsdefineret procedure for kodning af valgmuligheder i

sine instrumenter, som går igen i alle felter og instrumenter. F.eks. er det normalt god skik at felter med ja/nej

svarmuligheder kodes med 0,Nej og 1,Ja. Ligeledes bør man ved angivelse af køn have en fast regel. For spørgsmål

med en lang række svarmuligheder, som ikke er standardsvar som ja/nej, vil en fortløbende nummerering fra 1 og

frem normalt være den bedste løsning. Ofte vil man imidlertid inkludere svarmuligheder af typen: ’ved ikke’, ’ønsker

ikke at oplyse’, ’ikke relevant’ og ’andet’. Det er i sig selv god skik at inkludere denne type svar, hvor det kunne være

relevant, men det kan desuden være fornuftigt at forbeholde bestemte kodede værdier til at repræsentere disse valg.

Det kunne f.eks. være at ’ved ikke’ altid kodes 99, og ’andet’ altid kodes 88, eller noget i den stil. Fordelen ved at

vælge meget høje værdier er, at de så ikke kommer i karambolage med de ’almindelige’ valg, hvis listen bliver lang.

Udover at det kan have fordele i analysefasen med faste værdier for denne type valg, så kan det også i REDCap være

rart. Det skyldes at alle referencer til afgivne svar (f.eks. i calculated fields eller i forgreningslogik) foregår via

værdierne for disse svar og ikke deres label.

Kodning af denne type standardsvar hænger normalt sammen med felttyper som f.eks. radiobuttons. Ønsker man i

stedet i et tekstfelt (f.eks. et tekstfelt til indtastning af laboratorieværdier) at angive, at værdien ikke findes (missing),

kan man vælge en værdi, der skal tastes. Man skal i så fald være opmærksom på ikke at vælge en værdi, der kunne

være en reel værdi. Man kan evt. vælge en negativ værdi. Løsningen er dog generelt ikke særlig elegant, især ikke hvis

feltet f.eks. er valideret som numerisk med to decimaler. Missing værdien skal i givet fald også angives med decimaler.

Derudover kan missing værdierne forstyrre, når man skal lave statistik på svarene. Et alternativ kan være at anvende

et checkbox eller radiobutton felt til først at angive om en værdi er til rådighed, og kun ved ja vise feltet, hvori

indtastningen skal laves. Ulempen er selvfølgelig at denne metode hurtigt kommer til at fylde meget.

Følgende tabel kan anvendes som inspiration for valg af standardkodninger

Svar label Svar Kode

Ja 1 Nej 0 Mand 1 Kvinde 2 Ikke Relevant 55 Andet 66 Ønsker ikke at oplyse 77 Ved ikke (kender/husker ikke svaret) 88 Missing (svaret/resultatet eksisterer ikke eller kan ikke tilvejebringes)

99

4.3.7 BEGIN NEW SECTION FELTET

Felttypen begin new section er særlig idet den kun indeholder en field label og intet variabelnavn. Det er således ikke

et felt til opsamling af data. Feltet anvendes til at lave en opsplitning med overskrifter af et langt instrument.



Figur 26

Figur 27 og Figur 15 viser hvordan en New section ser ud i hhv. Online Designeren og i indtastningsøjeblikket /

preview.

Figur 27

4.3.8 FILE UPLOAD FELTET

File upload feltet er i opsætning identisk med notebox feltet idet der kun angives en felt label og et variabel navn

(Figur 28). I online designeren fremstår feltet, som det ses i Figur 29 med et grønt link, der muliggør upload af en fil,

som knyttes til dette felt og dette RecordID via en ny dialogbox (Figur 30).

Figur 28



Figur 29

Figur 30

REDCap muliggør upload af enkeltfiler på op til 32 mb, men hvis du i dit projekt har brug for at uploade mange filer af

størrelser i omegnen af 5-32 mb (f.eks. store billedfiler), så skal dette snakkes igennem med den datamanager, der er

tilknyttet projektet.

4.3.9 DESCRIPTIVE TEXT FELTET

Descriptive text feltet indeholder både en field label og et variabelnavn, men er ikke tænkt til opsamling af data. Feltet

vil normalt bruges til at give information til indtasteren af et skema f.eks. i form af en besked, der vises, hvis der svares

noget bestemt til et andet spørgsmål. Det kunne f.eks. være en procedure, indtasteren skal mindes om, hvis der i et

andet felt er markeret en bivirkning. I stedet for en besked kan der også vises et billede, hvilket kræver, at der

uploades et billede i opsætningen af feltet og vælges inline image ( Figur 31)

Figur 31



Figur 32 herunder viser descriptive text feltet, som det ser ud i online designeren.

Figur 32

Det er muligt at anvende HTML formatering af den tekst, der vises i et descriptive text felt, således at beskeden kan

gøres mere iøjnefaldende. Dette kræver at man i opsætningen af feltet indkapsler hele, eller dele af, teksten i html

tags i field label feltet i forbindelse med opsætning af feltet. Figur 33 viser resultatet af en simpel HTML formatering,

der viser teksten med større skrift og opsat i en farvet tekstboks. Nedenfor viser Figur 34, hvordan HTML

formateringen i dette tilfælde er lavet i opsætningen af felt label. Dette vil ikke blive drøftet videre i dette dokument.

HTML formatering begrænser sig ikke til Descriptive text felter, men kan i princippet anvendes i alle field labels – f.eks.

begin new section.

Figur 33

Figur 34

4.3.10 SLIDER FELT

Et slider felt anvendes normalt, når man ønsker at muliggøre en vurdering på en kontinuer skala, en såkaldt visual

analog scale (VAS). Dette er hyppigst anvendeligt i forbindelse med spørgeskemaer, hvor en deltager bliver bedt om at

angive sin opfattelse af en ting på en skala, hvor venstre og højre sider svarer til to ekstreme udsagn. Figur 35 viser

opsætningen af et slider felt. Udover field label og variabelnavn tager man forneden stilling til eventuelle labels, der

skal vises langs med linjen, samt hvorvidt værdien fra 0 til 100 skal vises for indtasteren. Et sliderfelt er ikke den rigtige

felttype til felter af typen ’På en skala fra 1 til 10 angiv da …’. I det tilfælde bør man i stedet vælge et radiobutton felt

med 10 valgmuligheder.



Figur 35

Figur 36 viser, hvordan slideren ser ud i online designeren

Figur 36

4.3.11 MATRIX FELT

Selvom REDCap har mulighed for en lang række felttyper, er det begrænset, hvor kreativt man kan layoute felter på

skærmen. Hvert felt kan kun opsamle ét datapunkt og hvert felt fylder en hel linje i instrumentet. Den eneste

mulighed, REDCap tilbyder for at lave en mere kompakt struktur, er ved at bruge matrix felter. Dette kan gøres i det

enkelte instrument ved i stedet for Add Field at vælge Add Matrix of Fields (Figur 37).

Figur 37

Felt matricer kan anvendes, når man har flere felter efter hinanden af typerne Checkbox eller Radiobutton, hvor

svarmulighederne er ens for alle felterne. Udover at resultatet visuelt bliver mere kompakt, er det også en hurtigere

måde at oprette flere felter på. Nedenfor ses dialog skærmen for opsætning af en feltmatrice (Figur 38). Der er

mulighed for at oprette en overordnet header tekst for hele matricen øverst, og herefter kan man nedenfor oprette



field labels for alle de spørgsmål, man ønsker at inkludere i matricen. Hvert felt man opretter i en matrice

repræsenteres internt i REDCap præcist, som et felt oprettet på normal vis, og skal derfor knyttes til et unikt

variabelnavn til højre for field label. Nederst til venstre angives de valgmuligheder, der skal være på samme måde som

i drop-down, radiobutton og checkbox felter. Nederst i højre hjørne angives, om matricen skal vises med radiobuttons

med kun ét muligt svar pr. spørgsmål eller med checkboxes med multiple svarmuligheder. Endeligt skal matricen have

et unikt matrix group name, svarende til et variabelnavn for den samlede matrice.

Figur 38

Figur 39 herunder viser, hvordan en feltmatrice tager sig ud i online designeren.



Figur 39

4.3.12 IDENTIFIERS OG REQUIRED FIELDS

I alle de felttyper der anvendes til opsamling af data, kan man i forbindelse med oprettelse af feltet angive Yes/No til

Identifier og til Required Field.

Identifier skal markeres som Yes, hvis der er tale om et datafelt, der kan siges at være identificerende for det

pågældende individ (enten alene eller sammen med andre oplysninger). Det kunne f.eks. være cpr-nummer, adresse,

navn, telefonnummer, kommune osv. Det har ingen direkte konsekvens for det videre forløb af projektet, men det

muliggør anvendelse af REDCaps funktioner til at begrænse adgangen til netop disse variable. Dette kan eksempelvist

være i forbindelse med eksport af data at filtrere data for identifier felter. Som tidligere nævnt må Record ID feltet

ikke indeholde værdier som f.eks. CPR-nummer, da Record ID feltet ikke kan markeres som identifier da det er

fundamentalt for at sammenholde data.

Felter, der markeres som Required Fields, er felter, hvor der kræves et svar fra indtasteren. Det vil i praksis sige, at

REDCap returnerer en notifikation om, at der er required fields, der ikke er udfyldt, hvis man prøver at gemme en

indtastning af et instrument, hvor et sådant felt er efterladt tomt. Dette skal tænkes som en påmindelse, og

notifikationen kan overrules af indtasteren, hvis denne kan bekræfte, at der ikke er tale om en forglemmelse, men et

bevist valg. Det anbefales, at man kun sætter felter som required, hvis man på forhånd vurderer det som afgørende,

at der indtastes en værdi for dette felt og at denne værdi altid bør være til rådighed for indtasteren i

indtastningsøjeblikket.

4.3.13 FELT LAYOUT

De fleste felter indeholder mulighed for at angive en Custom alignment og en field note. Under Custom alignment kan

man ændre på den måde REDCap orienterer eksempelvis radioknapperne eller checkboxes i forhold til teksten. Dette

kan justeres efter smag og behag. Field note er en mulighed for at tilføje en lille note eller beskrivelse i forbindelse

med feltet, som man ikke vil have i felt label. Igen er det lidt smag og behag, men i nogle situationer kan det være



hensigtsmæssigt ikke at få for lange field labels med meget detaljerede instrukser og i stedet have en uddybende

kommentar som et field note. Bemærk også at oplysninger i field label eksporteres sammen med data i forbindelse

med eksport til statistik programmer, men det gør tekster i field notes ikke. Figur 40 herunder viser et eksempel med

et højdefelt, hvor detaljer omkring målingen fremgår af en field note.

Figur 40

4.3.14 REDIGERING, KOPIERING, FLYTNING OG SLETNING AF FELTER

I oversigten over det enkelte instruments felter i Online Designeren har hvert felt nogle genveje angivet i venstre

hjørne med adgang til forskellige funktioner for dette felt (se Figur 41)

Figur 41

Den gule blyant giver adgang til at redigere i opsætningen af det enkelte felt som gennemgået i et tidligere afsnit.

Herefter følger muligheden for at lave en kopi af et felt. Dette kan være en genvej i forhold til at lave et nyt felt ved

hjælp af Add Field. REDCap laver en kopi af feltet, som placeres under den eksisterende med samme udseende og

type.

VIGTIGT: Når man kopierer et eksisterende felt, vil REDCap automatisk ændre variabelnavnet i det nye felt til noget

unikt. Udgangspunktet for det nye navn er det gamle navn, men hertil tilføjes nogle vilkårlige karakterer, så feltet

bliver unikt. Disse autogenererede variabelnavne er normalt ikke hensigtsmæssige, og det anbefales derfor, at man

altid efter at have kopieret et felt retter variabelnavnet, så det bliver sigende for det nye felt.

Den grønne forgrenede pil giver adgang til opsætning af forgreningslogik på det pågældende felt. Dette gennemgås i

et separat afsnit

Den næste funktion giver mulighed for at trække feltet op eller ned i instrumentet, således at man ganske let kan

ændre på rækkefølgen af instrumentets felter. Man skal selvfølgeligt være opmærksom på, ikke at komme til at flytte

et calculated field op foran de felter der indgår i dets beregning og tilsvarende for felter med defineret

forgreningslogik.

Endeligt kan man på det røde kryds slette et oprettet felt

4.4 FORGRENINGSLOGIK

I mange instrumenter vil der være felter, som det kun i bestemte tilfælde er relevant at udfylde for en given

projektdeltager. Behovet for at udfylde et givet felt vil normalt være betinget af svaret på et tidligere spørgsmål. F.eks.

vil det kun være relevant for de personer der har markeret ’Kvinde’ i feltet køn, at udfylde spørgsmålet om tidligere



graviditeter. Ligeledes bør en notesbox med mulighed for at specificere en uddannelse kun åbne, hvis der er svaret

’andet’ i uddannelsesfeltet. Denne slags logikker samt mere komplekse variationer kan laves simpelt i REDCap med

Branching logic (forgreningslogik). Forgreningslogik defineres for et felt af gangen, nemlig det felt hvis visning vi

ønsker at betinge af værdier i andre felter. I det følgende eksempel ønsker vi at betinge visningen af feltet med

spørgsmålet tidligere svangeskaber med værdien af valget i feltet Køn og feltet Alder. Klikker vi på den grønne pil i

feltet Tidligere svangerskaber (Figur 42), åbner forgreningslogik menuen for feltet sig, som set i Figur 43.

Figur 42

Figur 43

Der er to tilgange til at definere forgreningslogikken, nemlig Drag-N-Drop Logic Builderen nederst og Advanced

branching logic syntax øverst. I de fleste tilfælde vil den nederste være tilstrækkelig og lettest at anvende. Drag-N-

Drop logic builderen fungerer ved, at man i venstre side finder variablene for de felter, som på en eller anden måde

skal betinge visningen. Hvordan de enkelte variable fremtræder i listen afhænger af deres type. Vi ser f.eks. at

variablen bl_age (som er variablen svarende til tekst feltet med label ’Alder’) kun står angivet én gang som bl_age =

(define criteria), imens variablen bl_sex for radiobuttonfeltet ’Køn’ står angivet to gange, svarende til de to forskellige



mulige svar. Vores betingelse er baseret på svaret ’Kvinde’ og på ’Alderen’, så disse to trækkes over i højre side (Figur

44).

Figur 44

Betingelsen bl_sex = Kvinde (2) kan ikke specificeres yderligere, men for alderen vælges en ’Større end lig med’

operator (>=) og værdien 15. Samtidig markeres ”All below are true”, for at kræve at begge betingelser skal være

opfyldt, for at feltet skal vises. Det er altså visningen af feltet, der betinges og ikke den manglende visning af feltet.

Når man bygger sin logik med Drag-N-Drop logic builderen, opdateres den avancerede branching logic i øverste fane

sig tilsvarende, så den i dette tilfælde ser ud som set i Figur 45.

Figur 45

Det er sjældent, at man behøver at bruge Advanced Branching Logic Syntax, og der henvises til linket i branching

vinduet for flere detaljer. Branching logic baserer sig normalt på felter inden for samme instrument, men der er ikke

noget i vejen for at inddrage variable fra andre instrumenter. I Drag-N-Drop builderen skal man da blot angive, hvilket

instrument man vil lede efter variable i. Det er endda muligt i longitudinale projekter at betinge forgrening på feltet

indtastet for det samme eller andre instrumenter i forbindelse med andre events.

TIP. Det er ikke ualmindeligt at mange felter efter hinanden alle skal have deres visning betinget af et bestemt svar i

et tidligere felt, og altså derfor af præcis den samme logik. I REDCap er der ikke muligt at lave forgreningslogik for

flere felter samtidig, så man er nødt til at opsætte logikken i hvert felt for sig. I disse tilfælde er det lettest at lave

logikken for det første felt med Drag-N-Drop logic builderen og så med musen markere den syntax dette generer

foroven i Advanced Branching Logic Syntax og kopiere dette (ctrl+c). Når man skal lave logikken for de næste felter

bruger man ikke Drag-N-Drop, men markerer Advanced Branching Logic Syntax og paster/kopierer syntaksen fra før

ind foroven (ctrl+v), hvorefter der gemmes. Alternativt kan sådanne gentagelser med fordel laves via datadictionary

opbygning af instrumenter, som dog ikke gennemgås i dette dokument

Bemærk: Forgreningslogikker opdateres ikke automatisk, hvis de felter logikkerne refererer til ændres. Dvs. hvis man

ændrer et variabelnavn eller ændrer et felt fra radiobutton til checkbox, og dette felt indgår i en forgreningslogik, så



ugyldiggør man den tidligere opbyggede forgreningslogik. Man skal manuelt ændre de forgreningslogikker, der måtte

være påvirket af en sådan ændring. REDCap gør ikke opmærksom på fejlen før instrumentet åbnes for at indtaste

data. Da vil der fremkomme en fejlmeddelse (se afsnit 5.3.5).

4.5 FREMGANGSMÅDE I OPBYGNINGEN AF INSTRUMENTER

Når man opbygger lange instrumenter i REDCap, kan det betale sig løbende at teste funktionen af disse instrumenter.

Dette er særligt vigtigt, hvis instrumentet gør meget brug af calculated fields og forgreningslogik. Hvis man opretter

100 felter og først derefter tester instrumentet, kan det være svært at identificere præcist, hvor en evt. fejl har sneget

sig ind i instrumentet, idet flere felter kan være påvirket af den samme fejl på komplicerede måder. Det anbefales

derfor, at man løbende tester sine instrumenter ved oprettelse af FIKTIVE INDIVIDER! Sørg derfor for at læse kapitlet

om indtastning af data (Kapitel 5), inden du for alvor begynder på at oprette felter til dit projekt.

4.6 LONGITUDINALE STUDIER OG EVENTS

Mange kliniske studier involverer at forsøgspersoner følges over tid og at data opsamles flere gange undervejs i dette

forløb. Ofte vil de dataopsamlinger, der sker undervejs i forsøget være meget ensartede eller identiske. For denne

type af studier kan det ofte betale sig, at aktivere projektet som et longitudinalt studie i REDCap. Dette gør det muligt

at anvende det samme skema til flere indsamlinger og muliggør brugen af flere smarte funktioner og moduler i

REDCap, som f.eks. scheduling modulet. I afsnittet her vises opsætningen af et longitudinalt studie. Under afsnittet

omkring indtastning af data ser vi på, hvilke muligheder dette giver i forhold til at få overblik over studiekohorten og

den enkelte patient.

4.6.1 AKTIVER PROJEKT SOM LONGITUDINALT

Som udgangspunkt er et nyoprettet REDCap projekt ikke opsat som et longitudinalt studie. Man er derfor nødt til i

project setup at aktivere dette. Det ses i Figur 46 herunder.

Figur 46

4.6.2 OPSÆTNING AF BEGIVENHEDER / EVENTS

Næste skridt er, at definere de begivenheder der skal gennemløbes i det pågældende projekt. Dette vil typisk være ret

oplagt ud fra protokollen. I et klassisk simpelt studie kunne der f.eks. være en baseline event, en række

konsultationsevents og endeligt en konkluderende event eller end-of-study event. Der vil altså ofte være tale om de

specifikke konfrontationer eller mærkedage, som gør sig gældende i det givne studie ifølge protokollen.



Opsætningen af begivenheder foregår også på project setup siden under afsnittet Define your events and designate

instruments for them (Figur 47). Bemærk at denne mulighed først bliver synlig, når projektet er blevet aktiveret som

longitudinalt.

Figur 47

Når man klikker på Define my events, åbner siden som ses i Figur 48.

Figur 48



Nederst på siden er der mulighed for at oprette de events, der skal anvendes i det pågældende projekt. REDCap har

allerede oprettet den første event, som kan redigeres ved at klikke på den gule blyant. Herefter tilføjes de næste

events ved at klikke på Add new event. Der findes 3 elementer, der kan angives for hver event. Days Offset giver

mulighed for at angive det forventede antal dage imellem den første event, som typisk angives med offset=0, til den

pågældende event. Forventer man at have månedlige besøg kan første besøgs event f.eks. have et offset på 30 dage

og det næste have 61 dage. Hvis protokollen ikke dikterer en særlig stram tidsplan imellem events, kan man vælge

blot at anvende Days Offset feltet til at angive en rækkefølge. Man kan altså blot angive 1,2,3,4 osv. for hver event.

Offset Range feltet kan anvendes til at angive de acceptable marginer, der må være på Days Offset værdien. Det

kunne f.eks. være +/- 7 dage. Et sted hvor dette har betydning er f.eks. i REDCap scheduling modul, som anvender

Days Offset og Offset Range til at lægge en besøgskalender for en given projektdeltager.

Event name feltet er til eventens navn. Yderst til højre vises det unikke autogenerede event navn som REDCap internt i

databasen associerer til denne event. Det er dette event navn, man skal bruge i calculated fields og branching logic,

hvis man skal referere til en variabel i et andet instrument [unique_event_name][variable_name]. Se afsnittet om

calculated fields. Figur 49 herunder viser opsætningen efter indtastning af 5 events i et simpelt studie.

Figur 49

4.6.2.1 PROJECT ARMS I REDCAP

Under Define my events siden i REDCap er der også mulighed for at sætte flere forskellige projektarme op. Det gør

det muligt at opsætte forskellige event scenarier, afhængigt af hvilken projektarm der er tale om. Man kan således

have en protokol, der kræver, at to forskellige grupper i studiepopulationen skal gennemgå en række events på lidt

forskellig vis. Vi vil ikke komme nærmere ind på ’Arms’ i dette dokument, men henviser til REDCaps dokumentation og

OPENs datamanager.

4.6.3 TILKNYT INSTRUMENTER TIL EVENTS



Det sidste skridt i opbygningen af et longitudinalt studie er, at tilknytte instrumenter til de events man har defineret.

Dette gøres på Define my events siden eller på project setup siden ved at klikke på fanen Designate instruments for

my events.

Figur 50

Derved kommer man til siden, som ses i Figur 51. Her har man mulighed for i en matrix at knytte instrumenterne (ses

som rækker) til events (ses som søjler). Denne matrice kaldes i REDCap for et Event Grid. Matricen redigeres ved at

klikke på begin editing og saves igen, når man er færdig. I eksemplet har vi tilknyttet 5 instrumenter til 5 events, men

et event grid kan opsættes vilkårligt kompliceret. Vi kan se, at der ved baseline eventen kun skal udfyldes baseline

skemaet hvorimod både 1. og 2. konsultation kræver udfyldelse af 2 forskellige skemaer. Man kan også bemærke, at

instrumentet Konsultation anvendes ved alle 3 konsultationsbegivenheder, hvorimod alle andre instrumenter kun

anvendes en enkelt gang. I projekter hvor man anvender flere arms, er det muligt at opsætte et separat event grid for

hver arm.

Figur 51

4.6.3.1 OM GENBRUG AF INSTRUMENTER

I eksemplet fra Figur 51 anvendes det samme instrument Konsultation ved 3 separate events, imens f.eks.

instrumenterne 1. Kontrol og 2. Kontrol kun anvendes en enkelt gang hver, til trods for at de to instrumenter godt

kunne forventes at have en del lighedspunkter. Når man skal tage stilling til, om et givet instrument kan anvendes ved

mere end 1 event, skal man kigge på, om det der skal indsamles ved de to events er identisk, eller næsten identisk.

Hvis det er identisk, vil det normalt være oplagt at genbruge skemaet til alle de relevante events. Hvis det er næsten



identisk, vil det normalt med intelligent brug af branching i instrumentet være muligt at designe det på en sådan

måde, at det kan genbruges. Man kan f.eks. indlede instrumentet med et spørgsmål, der specificerer, hvilket

besøgsnummer der er tale om, og bruge dette resultat til at vise eller gemme bestemte felter, som ikke er relevante

for alle events. Hvis det data, der skal indsamles på de forskellige events, bliver for forskelligt, kan det være en bedre

løsning at designe to separate instrumenter, der så må anvendes på hver sin event.



5 DATA INDTASTNING OG PROJEKTOVERBLIK

I dette kapitel demonstreres hvordan man indtaster data i et REDCap projekt, og hvordan man kigger på de data, man

har indtastet. Vi arbejder stadig i et projekt, som er i udviklingsmode, og som altså endnu ikke er løftet i produktion.

Dette er altså i første omgang tænkt som indtastning i forbindelse med udvikling og løbende test af de opbyggede

skemaer. I princippet er der dog ingen nævneværdig forskel i processen omkring inddatering, efter at projektet er

løftet i produktion. Blot har man i produktionsfasen ikke adgang til at se og redigere sine instrumenter i online

editoren.

Der er nogle forskelle på indtastningsproceduren og de tilgængelige visninger af data afhængigt af, om der er tale om

et ikke-longitudinalt projekt, eller et projekt der er aktiveret som longitudinalt (Se afsnittet: Longitudinale studier og

events). Herunder tages udgangspunkt i proceduren i forbindelse med et ikke-longitudinalt projekt. Herefter uddybes

de vigtigste forskelle i forbindelse med et longitudinalt projekt.

5.1 OPRETTELSE AF EN NY PROJEKTDELTAGER

Indtastning af data foregår via ’Data Collection’ afsnittet i REDCaps venstre fane. Her findes et menupunkt der hedder

Add / Edit Records (se Figur 52)

Figur 52

Klikker man herpå åbner Add / Edit records skærmbilledet sig i højre side (Figur 53). Den øverste sektion giver

mulighed for enten at kigge på data og fortsætte inddatering for en allerede oprettet projektdeltager, eller oprette en

ny projektdeltager. Nederst er der mulighed for at søge på tværs af kohorten på bestemte felter Bemærk at der også i

dette skærmbillede linkes til en videointroduktion til data entry, som er godt supplement til dette dokument. Som det

ses allerøverst i Figur 53, så er der angivet Demographics. Det skyldes, at det første instrument i dette projekt (som er

det instrument der indeholder recordID variablen for projektet) hedder Demographics. Det er typisk det første skema,

der skal udfyldes data for.

En allerede oprettet patient kan enten være complete eller incomplete på et givet instrument, afhængigt af om

instrumentet er helt eller delvist udfyldt og afhængigt af, hvordan skemaet blev gemt ved indtastningen (dette

uddybes om lidt). Ved at klikke på drop-down menuen for hhv. Incomplete eller Complete records kan man vælge den

eksisterende patient, man ønsker at kigge nærmere på eller fortsætte indtastningen for. Denne status går på det

aktuelle instrument som i Figur 53 er demographics, og altså ikke på den samlede indtastningsstatus på tværs af

instrumenter.

Ønsker man at oprette en ny projektdeltager, gøres dette ved at indtaste det recordID, man har valgt til at

repræsentere ham eller hende. I Figur 55 hedder denne linje Enter a new or existing Study ID, fordi der i dette projekt

er valgt Study ID som felt label i det øverste felt i Demographics instrumentet. Hvis man i dette felt har valgt at

anvende en valideringsregel (feks kun at tillade tal), så vil dette blive håndhævet, når man indtaster det nye recordID,



man ønsker at oprette. I eksemplet i Figur 53 oprettes en ny patient med Study ID ’123456’. Når der trykkes enter

åbnes der direkte til dataindtastning i instrumentet Demographics for projectdeltageren 123456 (Figur 55).

Figur 53

5.1.1 FORSKEL FOR LONGITUDINALE STUDIER

For et longitudinalt studie, hvor instrumenter kan genbruges flere gange, er det ikke så let at definere, hvornår en

indtastning er complete eller incomplete. For sådanne projekter vises i stedet for de to drop-down menuer

Incomplete Records og Complete Records en enkelt drop-down menu kaldet Existing Records. I øverste venstre

hjørne står der heller ikke et konkret instrument, men i stedet Add / Edit Records (Figur 54).



Figur 54



5.2 INDTASTNING

I Figur 55 vises Demographics instrumentet, efter der er indtastet data i de første felter. Indtastning i REDCap foregår

lettest med musen, men der kan anvendes tabulator til at springe til næste felt. Mellemrumstasten kan anvendes til at

markere f.eks. en radiobutton eller en checkbox.

Figur 55

Bemærk: Enter-tasten har en anden funktion, end man kender det fra andre systemer som f.eks. EpiData. Enter-tasten

skal i REDCap ikke anvendes til at afslutte indtastningen af et felt og springe til det næste felt. I stedet vil enter tasten

aktivere funktionaliteten Save Record svarende til at klikke på Save Record knappen med musen. Dette kan lede til lidt

forvirring.

Datofelter kan udfyldes enten med musen via kalender widget til højre for feltet, eller via genvejen ’Today’. Afhængigt

af hvilket datoformat man har valgt til validering af et datofelt (DMY eller YMD), er det ikke altid nødvendigt at taste

datoen eksakt efter formatet. For et datofelt der er valideret med DMY (day-month-year), vil datoen 15-05-2014 f.eks.

blive genkendt ved alle de følgende indtastninger: 15-05-2014, 15052014, 15.5.2014, 15.5.14



Bemærk at feltet Age i Figur 55 er angivet med rødt. Dette skyldes, at der her er tale om et calculated field, som altså

ikke er indtastet, men udregnet på baggrund af data i andre felter

5.2.1 GEMNING AF INDTASTNING

Når man har indtastet data i et instrument for en projektdeltager, er det naturligvis afgørende at gemme de

indtastede data. Dette gøres ved at klikke på Save Record i den sorte boks øverst i højre side eller i bunden af

instrumentet. Et instrument kan gemmes i 3 forskellige tilstande, som vælges af indtasteren i det nederste felt i

instrumentet. Dette felt hedder Complete? under headeren Form Status (Figur 56). Dette felt bliver altid automatisk

inkluderet i alle instrumenter, der bygges i REDCap og kan ikke redigeres eller ændres. Feltet er en drop-down med

følgende valgmuligheder: Incomplete, Unverified og Complete. Uanset hvilken status man vælger, gemmes de data

der er indtastet, når der trykkes save. Præcis hvordan man vælger at anvende de tre forskellige statustyper, kan

afgøres på det enkelte projekt, men typisk vil Incomplete anvendes, når skemaet slet ikke indeholder data, eller kun

indeholder begrænsede data. Hvis alle felter er udfyldt og man er tilfreds med indtastningen vælges typisk at gemme

som Complete. Unverified kan anvendes i tilfælde af, at en indtastning skal godkendes af en anden bruger (måske en

overordnet ansvarlig), inden den kan gemmes som Complete. Alternativt anvendes Incomplete ofte til andre formål,

som kan defineres for det enkelte projekt. Hvis man ikke aktivt vælger en status, når man gemmer, så gemmes

indtastningen som Incomplete. Indstilling af status for at gemme har ingen betydning for, hvorvidt man kan vende

tilbage til data og ændre i dem ved en senere lejlighed.

Figur 56

Når man trykker på knappen Save Record antages det, at man er færdig med indtastningen for denne gang, og man

springer ud til menuen for oprettelse af en ny projektdeltager. Ønsker man blot løbende, at gemme det man er i færd

med at indtaste, skal man anvende knappen Save and Continue. Dette gemmer de aktuelt udfyldte data, men holder

den aktuelle indtastning aktiv i vinduet. Dette kan være relevant ved indtastning af et meget langt instrument, hvor

der kunne være risiko for at miste meget arbejde, hvis computeren pludseligt går ned. Endeligt kan man vælge at

anvende Save and go to Next Form. Dette gemmer og afslutter indtastningen i det aktuelle instrument og springer

direkte til indtastning af data i det næste instrument i rækken for den pågældende projektdeltager.

BEMÆRK: En oprettet projektdeltager (se Figur 52) vil først blive aktivt oprettet i databasen i det øjeblik der første

gang bliver gemt noget indtastet data for denne deltager. Forlader man således indtastningen, inden man har gemt

noget, så skal denne deltager oprettes på ny, hvis man alligevel vil taste data ind for deltageren senere.

5.2.1.1 FORSKEL FOR LONGITUDINALE STUDIER



For longitudinale studier, hvor instrumenter genbruges på forskellige events, er resultatet af at anvende knapperne

Save Record og Save and continue to next form lidt anderledes. Når man trykker på Save Record returnerer man til

den pågældende forsøgsdeltageres event grid (uddybes senere). Når man klikker Save and continue to next form

springer man til det næste instrument, der er tilknyttet den aktuelle event

5.2.1.2 LÅSNING AF INSTRUMENT

Ønsker man at en gemt indtastning ikke uden videre kan redigeres, kan man nederst på instrumentet angive, at de

indtastede data skal låses. Det gøres ved at markere Lock this record for this form (Figur 56). Bemærk at dette kræver,

at den pågældende bruger har fået tildelt rettigheder til at låse instrumenter. Et låst instrument skal låses op, inden

der kan foretages ændringer. At låse op er en separat rettighed, som specifikt kan tildeles bestemte brugere.

5.2.1.3 SLETNING AF PROJEKTDELTAGER

Hvis en bruger er oprettet med de rette rettigheder, er det muligt nederst i instrumentet at vælge Delete Record

(Figur 56). Vælges dette slettes alle indtastede data for denne projektdeltager på tværs af alle instrumenter og

events.

5.3 FEJLMEDDELELSER OG NOTIFIKATIONER

Der findes en række notifikationer og fejlmeddelelser, der kan møde brugeren i indtastningsøjeblikket, som det kan

være rart at forstå. Nogle af de hyppigst forekommende forklares herunder.

5.3.1 UUDFYLDTE REQUIRED FIELDS

Figur 57 viser den notifikation der vises, når man forsøger at gemme et instrument med tomme felter, hvis disse felter

var defineret med must provide value. I eksemplet i Figur 57 er det et datofelt, der ikke er blevet udfyldt, men

notifikationen vil liste alle de required fields, der måtte være efterladt tomme. Man har nu tre valgmuligheder. Man

kan enten trykke Okay og returnere til det aktuelle skema for at udfylde de tomme felter, eller man kan ignorere

advarslen og enten forlade indtastningen og returnere til deltager-oprettelsessiden, eller ignorere advarslen og

springe til næste instrument for denne forsøgsdeltager. I begge de sidste tilfælde gemmes data, som de er. Bemærk at

dette ikke har nogen indflydelse på den status man vælger at gemme indtastningen i (Incomplete, Unverified eller

Complete)

Figur 57

5.3.2 FORSØG PÅ AT INDTASTE IKKE VALIDERET VÆRDIFORMAT



Hvis man i forbindelse med indtastning forsøger at indtaste en værdi i et felt der ikke svarer til det dataformat feltet er

valideret på, modtager man notifikationen, der ses i Figur 58. Notifikationen indeholder desværre ikke oplysning om,

hvad det rigtige format er, men det kunne f.eks. være, at man har forsøgt at indtaste et heltal i et felt der kræver et

komma (punktum) og en enkelt decimal. Bemærk at denne notifikation ikke kan ignoreres, værdien skal rettes, så den

passer til valideringen

Figur 58

5.3.3 FORSØG PÅ AT INDTASTE UDEN FOR VALIDERINGSRANGES

Hvis man i forbindelse med indtastning forsøger at indtaste en værdi i et felt, der ligger under eller over, de

valideringsranges der er specificeret for feltet, vises notifikationen, som ses i Figur 59. Denne notifikation er ikke

ultimativ og kan ignoreres, men har til hensigt at få indtasteren til at dobbelttjekke den indtastede værdi. Det kan

altså lade sig gøre at indtaste værdier udenfor valideringsranges.

Figur 59

5.3.4 ÆNDRINGER I OPSTRØMS FELTER DER PÅVIRKER NEDSTRØMS FELTER

I forbindelse med indtastning i skemaer der indeholder forgreningslogik, kan der opstå situationer, hvor en rettelse af

en værdi i et felt ugyldiggør data, der er indtastet i et senere felt. Har man f.eks. i første omgang angivet en deltager

som kvinde og derefter svaret på et betinget spørgsmål om antal graviditeter, så vil spørgsmålet om antal

svangerskaber være ugyldigt, hvis man senere finder ud at deltageren faktisk er mand. I sådanne tilfælde modtager

man en fejlmeddelelse, som set i Figur 60. Der gøres opmærksom på, at den ændring man er ved at foretage (ændre

kvinde til mand), vil betyde at værdien i feltet k1_svanger bliver slettet. I instrumenter med komplekse forgreninger

kan en ændring potentielt have konsekvenser for en lang række felter, og man vil da modtage en sådan fejlmeddelelse

fra hvert nedstrøms felt, der bliver påvirket, hvor man skal bekræfte, at data slettes i disse felter



Figur 60

5.3.5 FEJL I FORGRENINGSLOGIK

I forbindelse med opbygning forgreningslogik i instrumenter kan det, især ved anvendelse af Advanced branching

logic syntax, lade sig gøre at oprette forgreningslogik syntax der ikke er gyldig. Forgreningslogik værktøjet tjekker, at

der ikke anvendes ugyldige variable i syntaksen, men en række andre ting tjekkes ikke før instrumentet åbnes for

indtastning. Dertil kommer, at forgreningslogikken ikke automatisk opdateres, hvis man ændrer i de variable, der

indgår i logikken. Dvs. hvis man f.eks. sletter et felt, ændrer variabelnavnet eller ændrer det fra radiobutton til

checkbox, og dette felt indgår i en forgreningslogik, der allerede er lavet, så skal man manuelt ind og tilrette

forgreningslogikken. REDCap gør ikke opmærksom på dette.

Hvis man åbner et instrument for at indtaste data og dette instrument indeholder fejl i forgreningslogik, vil man se

fejlmeddelelsen i Figur 61, som i dette eksempel drejer sig om feltet med variabelnavn er_svanger. Gå tilbage i

instrumentet og find fejlen.

Figur 61

5.3.6 FEJL I CALCULATED FIELDS

På samme måde som ved forgreningslogik, kan det ske at man i forbindelse med rettelser i et skema, såsom sletning

eller omdøbning af variable eller ændring af felttyper, kommer til at ugyldiggøre allerede lavede calculated fields.

REDCap gør ikke opmærksom på dette, før instrumentet åbnes for indtastning.



Hvis man åbner et instrument for at indtaste data og dette instrument indeholder fejl i forgreningslogikken vil man se

fejlmeddelelsen i Figur 62, som i dette eksempel går på feltet med variabelnavn er_alder2.

Figur 62

5.4 OVERBLIK OVER INDTASTNINSSTATUS

Der findes forskellige måder at få et overblik over, hvad der er indtastet og gemt for den enkelte forsøgsdeltager, samt

for alle forsøgsdeltagere. Her adskiller mulighederne sig noget afhængigt af, om der er tale om et longitudinalt projekt

eller et ikke-longitudinalt projekt

5.4.1 IKKE-LONGITUDINALT

Ikke longitudinale projekter er typisk ikke så komplicerede at overskue, og indtastningsprocessen er ofte et spørgsmål

om simpelthen at udfylde instrumenterne i den rækkefølge, de er defineret på i online designerens

instrumentoversigt. For disse projekter er der i venstre søjle i Data Collection sektionen mulighed for at se

indtastningsstatus for den enkelte projektdeltager, efter at han er blevet valgt eller oprettet i Add / Edit Records. I

eksemplet i Figur 63 ser man, at for projektdeltager PT102 er instrumentet Demographics blevet gemt som Complete

(derfor grøn), men de øvrige instrumenter er fortsat kun gemte som Incomplete og derfor røde. Bemærk at dette ikke

nødvendigvis betyder, at der ingen data er indtastet i de øvrige instrumenter, men blot at den status de er gemt som

er Incomplete.



Figur 63

5.4.1.1 DASHBOARD – IKKE LONGITUDINALT

Ønsker man at se et overblik over indtastningsstatus for alle projektdeltagere samtidigt, kan man få det ved at klikke

på linket Record Status Dashboard, som er den øverste linje i Data Collection sektionen i venstre søjle (se Figur 63).

Dashboardet for et simpelt ikke-longitudinalt studie med 5 oprettede projektdeltagere og 6 instrumenter ses i Figur

64. Som det fremgår af figur legenden, så indikerer en grøn prik, at det pågældende instrument er gemt som

Complete, gul indikerer Unverified og rød indikerer Incomplete. Klikker man på en prik i Dashboardet åbner

indtastningssiden sig for den pågældende projektdeltager og instrument.

Figur 64



5.4.2 LONGITUDINALT

For longitudinale studier, hvor instrumenter genbruges på tværs af events på forskellig vis, er der behov for et bedre

overblik over status for den enkelte deltager.

5.4.2.1 EVENT GRID VISNING

Når man opretter eller vælger en eksisterende deltager i Add / Edit Records menuen i venstre søjle, åbner visningen

automatisk som Event grid i venstre side. En deltagers event grid er en matrix visning af deltagerens

indtastningsstatus på tværs af begivenheder og instrumenter, der svarer til den opsætning, der er lavet i Project Setup

-> Define Events -> Designate instruments for my events (Afsnit 4.6). Figur 65 viser et Event Grid for projektdeltager

PT202

Figur 65

5.4.2.2 DASHBOARD – LONGITUDINALT

Ligesom for ikke-longitudinale studier kan man også for longitudinale studier anvende Dashboardet til at skabe et

overblik over alle projektdeltagere samtidigt. Pga. muligheden for at hvert instrument skal udfyldes ved flere

lejligheder, er dashboardet imidlertid en smule mere kompliceret at læse.

Figur 66

Dashboardet indeholder alle de kombinationer af events og instrumenter, som er med i event grid visningen, men i et

format, hvor de står på en enkelt række. I eksemplet i Figur 66 indeholder kolonnenavnene med sort navnet på det



instrument, der er tale om, og med rødt fremgår navnet på den event, hvor instrumentet skal udfyldes. Sorteringen af

kolonnerne i denne visning er efter instrument først (i den rækkefølge de står i instrument overblikket i online

designeren) og dernæst efter den specificerede event rækkefølge fra opsætningen af events.



6 ANDRE FUNKTIONALITETER I REDCAP

De funktioner, der er blevet gennemgået i dette dokument, udgør kernefunktionaliteten i opbygning af instrumenter i

REDCap samt indtastning af data. Herudover indeholder REDCap en lang række andre moduler, som i første omgang

ikke bliver gennemgået. Nogle af disse beskrives kort herunder, men det anbefales at kigge på REDCaps online training

videos for mere oplysning om disse, samt selvfølgeligt drøfte mulighederne i forbindelse med et konkret projekt med

OPENs datamanagere.

6.1.1 SURVEYS:

Instrumenter opbygget I REDCap kan aktiveres som surveys, hvilket gør det muligt at udsende dem direkte til

projektdeltagere, så de selv kan udfylde dem. Data vil automatisk blive gemt i databasen på samme måde, som hvis de

blev tastet på normal vis. Surveys kan enten laves som public surveys, som kan sendes ud til en masse email adresser

eller postes som et link på en hjemmeside, eller det kan indgå som en del af dataindsamlingen for en kohorte således

at data er bundet til et ID for projektdeltageren.

6.1.2 RANDOMISERING

REDCap indeholder et randomiseringsmodul, som kan anvendes til at simplificere randomisering i kliniske studier. Det

fungerer ved, at man på forhånd generer en stratificeret allokationstabel, som kan tilknyttes et randomiseringsfelt i et

REDCap instrument. Når man klikker på denne knap i instrumentet returnerer REDCap et randomiseringsnummer eller

en randomiseringsgruppe afhængigt af behovet for blinding i forsøget

6.1.3 CALENDAR OG SCHEDULING

REDCap indeholder en kalenderfunktion, som alle de tilknyttede forskere kan anvende. I sin simpleste form er der tale

om en delt kalender, hvor man f.eks. kan oprette aftaler med forsøgsdeltagere eller andre vigtige begivenheden og få

overblik over kommende aftaler. Herudover findes der en scheduling funktion, som kan anvendes på longitudinale

studier til at lave en besøgsplan for en given projektdeltager baseret på de begivenheder, der er specificeret i studiet,

og det antal dage der er angivet imellem begivenhederne

6.1.4 DATA IMPORT

Det er muligt, at uploade data direkte ind i et REDCap instrument fra en kommasepareret fil (regnearksfil). Dette kan

være en relevant alternativ til at indtaste data, der allerede findes i digital form

6.1.5 DATA EXPORT

REDCap giver selvfølgeligt mulighed for at eksportere data på en række forskellige måder til en række forskellige

formater (Excel, SPSS, R, STATA)

6.1.6 DATA COMMENTS OG DATA RESOLUTION WORKFLOW



Det er ofte relevant at være i stand til at skrive kommentarer til indtastede datapunkter, eller til direkte at kunne

spørge andre forsøgsansvarlige om bestemte datapunkter. REDCap giver mulighed for at gøre dette på to forskellige

måder, enten via Data comments eller mere avanceret via Data Resolution Workflow funktionen

6.1.7 DOUBLE DATA ENTRY

REDCap giver mulighed for at lave double data entry af data i projekter, hvor data på papir skal indtastes i REDCap

med meget stor grad af præcision

6.1.8 DATA QUALITY

REDCap indeholder et modul, der gør det muligt at identificere datapunkter, der kan være behov for at kigge nærmere

på i forbindelse med en dataoprensningsproces, enten løbende eller ved afslutning af dataindsamling.

6.1.9 REPORT BUILDER

REDCap indeholder et modul, der kan lave rapporter baseret på udvalgte variable og logikker

Documents

INTRODUKTION TIL · 2019. 6. 17. · Introduktion til REDCap Side 5 af 52 REDCap vejl. 1, version 2, OPEN 14-06-2019 2 INTRODUKTION Dette dokument er tænkt som en introduktion til