INTRODUKTION TIL. Version af dette dokument: Senest opdateret: REDCap version: Peter Bjødstrup Jensen (Datamanager i OPEN)

Transkript

1 INTRODUKTION TIL Version af dette dokument: V.1.0 Senest opdateret: REDCap version: Skrevet af: Peter Bjødstrup Jensen (Datamanager i OPEN)

2 1 INDHOLDSFORTEGNELSE 1 Indholdsfortegnelse Introduktion Om REDCap Guide til at bruge denne manual Nomenklatur Overblik over redcap Brugeroprettelse Login Velkomstside Projektoversigt Navigation overblik project Home Project Setup Other functionality Project Revision History Opbygning af REDCap instrumenter Online designer REDCap Shared Library Opbygning af instrumenter Det særlige felt record id Redigering af felter field labels og variabelnavne God skik for navngivning af variable Opretning af nye felter Gennemgang af felttyper Introduktion til REDCap Side 2 af 52 REDCap vejl. 1, version 1, OPEN

3 4.3.1 Preview Textbox Notesbox Calculated Fields Drop-down, radiobutton og checkbox God skik for kodning af værdier Begin new section feltet File upload feltet Descriptive text feltet Slider felt Matrix felt Identifiers og Required Fields Felt Layout Redigering, kopiering, flytning og sletning af felter Forgreningslogik Fremgangsmåde i opbygningen af instrumenter Longitudinale studier og events Aktiver projekt som longitudinalt Opsætning af begivenheder / Events Tilknyt instrumenter til events DAta indtastning og projektoverblik Oprettelse af en ny projektdeltager Forskel for longitudinale studier Indtastning Gemning af indtastning Fejlmeddelelser og notifikationer Uudfyldte required fields Introduktion til REDCap Side 3 af 52 REDCap vejl. 1, version 1, OPEN

4 5.3.2 Forsøg på at indtaste ikke valideret værdiformat Forsøg på at indtaste uden for valideringsranges Ændringer i opstrøms felter der påvirker nedstrøms felter Fejl i forgreningslogik Fejl i Calculated fields Overblik over indtastninsstatus Ikke-longitudinalt Longitudinalt Andre funktionaliteter i REDCap Surveys: Randomisering Calendar og Scheduling Data import Data Export Data Comments og Data Resolution Workflow Double Data Entry Data Quality Report builder Introduktion til REDCap Side 4 af 52 REDCap vejl. 1, version 1, OPEN

5 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 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 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 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 Survey Projektdeltager Projektpersonale Projektansvarlig 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) Et spørgeskema til udsendelse. I REDCap er et survey et instrument, der er aktiveret som survey En person f.eks. patient eller kontrolperson, der skal indsamles data om i forbindelse med et forskningsprojekt Den gruppe personer der er tilknyttet projektet til opbygning af projekt og indtastning af data. Overordnet ansvarlig for projektet. Vil være en af underskriverne af OPENs licensaftale Introduktion til REDCap Side 5 af 52 REDCap vejl. 1, version 1, OPEN

6 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 adresse og modtager en automatisk 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 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: Introduktion til REDCap Side 6 af 52 REDCap vejl. 1, version 1, OPEN

7 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 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 Introduktion til REDCap Side 7 af 52 REDCap vejl. 1, version 1, OPEN

8 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 Introduktion til REDCap Side 8 af 52 REDCap vejl. 1, version 1, OPEN

9 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 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 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 Introduktion til REDCap Side 9 af 52 REDCap vejl. 1, version 1, OPEN

10 Figur 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 Introduktion til REDCap Side 10 af 52 REDCap vejl. 1, version 1, OPEN

11 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 Introduktion til REDCap Side 11 af 52 REDCap vejl. 1, version 1, OPEN

12 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 Introduktion til REDCap Side 12 af 52 REDCap vejl. 1, version 1, OPEN

13 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 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. Introduktion til REDCap Side 13 af 52 REDCap vejl. 1, version 1, OPEN

14 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 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 ), 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 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 Introduktion til REDCap Side 14 af 52 REDCap vejl. 1, version 1, OPEN

15 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 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 Introduktion til REDCap Side 15 af 52 REDCap vejl. 1, version 1, OPEN

16 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 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. Introduktion til REDCap Side 16 af 52 REDCap vejl. 1, version 1, OPEN

17 Figur GENNEMGANG AF FELTTYPER I det følgende gennemgås de forskellige felttyper i REDCap 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) Introduktion til REDCap Side 17 af 52 REDCap vejl. 1, version 1, OPEN

18 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 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. Introduktion til REDCap Side 18 af 52 REDCap vejl. 1, version 1, OPEN

19 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 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. Introduktion til REDCap Side 19 af 52 REDCap vejl. 1, version 1, OPEN

20 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. validering tjekker at den indtastede værdi indeholder samt afsluttes med et punktum og suffix (mail@mail.dk). 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 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. Introduktion til REDCap Side 20 af 52 REDCap vejl. 1, version 1, OPEN

21 Figur 20 En oprettet notesboks fremstår, når den er oprettet i Online designeren som i Figur 21 Figur 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 Introduktion til REDCap Side 21 af 52 REDCap vejl. 1, version 1, OPEN

22 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. Alder på en given dato (Dato) fra DateOfBirth. Her antages datoer formateret efter dmy format. Antal dage imellem to datoer. round([vaegt]/(([ hojde]/100)^(2)),1) rounddown(datediff([dob],[dato],'y','dmy')) Datediff([dato1],[dato2], d, dmy ) Endeligt ses i Figur 23 hvordan feltet ser i online designeren, når det er oprettet Figur DROP-DOWN, RADIOBUTTON OG CHECKBOX Introduktion til REDCap Side 22 af 52 REDCap vejl. 1, version 1, OPEN

23 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 Introduktion til REDCap Side 23 af 52 REDCap vejl. 1, version 1, OPEN

24 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 99 ikke eller kan ikke tilvejebringes) 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. Introduktion til REDCap Side 24 af 52 REDCap vejl. 1, version 1, OPEN

25 Figur 26 Figur 27 og Figur 15 viser hvordan en New section ser ud i hhv. Online Designeren og i indtastningsøjeblikket / preview. Figur 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 Introduktion til REDCap Side 25 af 52 REDCap vejl. 1, version 1, OPEN

26 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 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 Introduktion til REDCap Side 26 af 52 REDCap vejl. 1, version 1, OPEN

27 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 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. Introduktion til REDCap Side 27 af 52 REDCap vejl. 1, version 1, OPEN

28 Figur 35 Figur 36 viser, hvordan slideren ser ud i online designeren Figur 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 Introduktion til REDCap Side 28 af 52 REDCap vejl. 1, version 1, OPEN

29 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. Introduktion til REDCap Side 29 af 52 REDCap vejl. 1, version 1, OPEN

30 Figur 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 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 Introduktion til REDCap Side 30 af 52 REDCap vejl. 1, version 1, OPEN

31 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 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 Introduktion til REDCap Side 31 af 52 REDCap vejl. 1, version 1, OPEN

32 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 Introduktion til REDCap Side 32 af 52 REDCap vejl. 1, version 1, OPEN

33 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å Introduktion til REDCap Side 33 af 52 REDCap vejl. 1, version 1, OPEN

34 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 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 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. Introduktion til REDCap Side 34 af 52 REDCap vejl. 1, version 1, OPEN

35 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 Introduktion til REDCap Side 35 af 52 REDCap vejl. 1, version 1, OPEN

36 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 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 TILKNYT INSTRUMENTER TIL EVENTS Introduktion til REDCap Side 36 af 52 REDCap vejl. 1, version 1, OPEN

37 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 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 Introduktion til REDCap Side 37 af 52 REDCap vejl. 1, version 1, OPEN

38 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. Introduktion til REDCap Side 38 af 52 REDCap vejl. 1, version 1, OPEN

39 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, Introduktion til REDCap Side 39 af 52 REDCap vejl. 1, version 1, OPEN

40 man ønsker at oprette. I eksemplet i Figur 53 oprettes en ny patient med Study ID Når der trykkes enter åbnes der direkte til dataindtastning i instrumentet Demographics for projectdeltageren (Figur 55). Figur 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). Introduktion til REDCap Side 40 af 52 REDCap vejl. 1, version 1, OPEN

41 Figur 54 Introduktion til REDCap Side 41 af 52 REDCap vejl. 1, version 1, OPEN

42 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 f.eks. blive genkendt ved alle de følgende indtastninger: , , , Introduktion til REDCap Side 42 af 52 REDCap vejl. 1, version 1, OPEN

43 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 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 FORSKEL FOR LONGITUDINALE STUDIER Introduktion til REDCap Side 43 af 52 REDCap vejl. 1, version 1, OPEN

44 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 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 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 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 FORSØG PÅ AT INDTASTE IKKE VALIDERET VÆRDIFORMAT Introduktion til REDCap Side 44 af 52 REDCap vejl. 1, version 1, OPEN

45 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 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 Æ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 Introduktion til REDCap Side 45 af 52 REDCap vejl. 1, version 1, OPEN

46 Figur 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 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. Introduktion til REDCap Side 46 af 52 REDCap vejl. 1, version 1, OPEN

47 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 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 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. Introduktion til REDCap Side 47 af 52 REDCap vejl. 1, version 1, OPEN

48 Figur 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 Introduktion til REDCap Side 48 af 52 REDCap vejl. 1, version 1, OPEN

49 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 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 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 Introduktion til REDCap Side 49 af 52 REDCap vejl. 1, version 1, OPEN