Inden der anmodes om at opløfte en REDCap database til produktion, er der en række ting, som bør tjekkes af den ansvarlige designer/RPM (Research Project Manager).  Dette dokument beskriver en række områder som anbefales gennemført eller overvejet. Man kan naturligvis udelade de funktionaliteter, der ikke anvendes i pågældende projekt.

Det indskærpes, at det er den ansvarlige projektejer/RPM der har ansvaret for at databasens funktionalitet er testet igennem inden opløft til produktion. Datamanager vil inden opløft foretage en kort gennemgang af databasen, men vil ikke udføre systematiske tests af alle felter og funktionaliteter.

I det omfang der stilles krav herom, er det er brugerens eget ansvar at kunne dokumentere at databasen er blevet grundigt testet inden opløft til produktion. Det vil oftest være tilfældet for GCP monitorerede lægemiddelforsøg. Det kan ske ved hjælp af screen dumps af indtastninger og dashboards, og ved hjælp af en nedskrevet protokol for testningen, hvor der angives hvad der er gjort for at teste de forskellige elementer. Det anbefales desuden af projektejer gemmer et eksporteret datasæt af alle testindividerne som dokumentation for at der er tastet testpatienter. Dette skal gøres inden projektet opløftes til produktion, da dette sletter alle indtastede data.

• Er den korrekte felttype valgt for variable?
• Er der for tekstbokse anvendt validering og ranges hvor det er relevant for at reducere risikoen for invalide data?
• Felternes ’field note’ kan ofte med fordel anvendes til at uddybe eller specificere feltets label. Det kunne være angivelse af det forventede format, enheder eller lignende. Angiv evt. et eksempel.
• Er personfølsomme variable markeret ”identifier”?
• Er de variable, som bør være markeret som ”required”, også blevet markeret som sådan?
• Er der valgt en god navnestandard på mine variable, gerne med et præfix ud fra instrument navn, således at man ved hvilket instrument en variable hører til?
• Er der fastlagt værdier for standard svar – eks. ”999 Ukendt svar” og ”666 Ønsker ikke at svare” og er der tjekket for, at disse numeriske værdier ikke kan karambolere med valide værdier for numerisk variable?
• Er der konsistent kodning af radiobutton felter med ja/nej svarmuligheder? Ofte kodes ”ja” med 1 og ”nej” med 0.
• Er enhed angivet i ”Field Label”, hvor det måtte være naturligt/nødvendigt, således at der aldrig kan drages tvivl om, hvilken enhed variablen er afgivet i?

• Er der indtastet testdata i alle instrumenter?
• Virker Branching Logic efter hensigten? Såfremt man har kompliceret logik, opsæt da en matrice med alle mulige kombinationer, således at man kan tjekke alle muligheder af og få sikkerhed for, at de virker efter hensigten.
• Er der den forventede værdi i variable, der er defineret som beregnede?
• Er der variable defineret som Radio Buttons, hvor der forekommer ”overlap” eller ”gap”, således at der vil være bias i data eller svar ikke kan afgives?

• Er alle events defineret og med korrekt day offset?
• Er alle instrumenter knyttet korrekt til én eller flere events?
• Der må ikke forekomme instrumenter som ikke er knyttet til mindst én event.
• Hvis der gøres brug af arms, er de så korrekt defineret og med tilhørende events?

• Er alle brugere, som skal indgå i projektet oprettet?
• Har alle brugere være logget ind og gjort sig bekendt med REDCap og projektets opbygning og har de indtastet data?
• Har alle brugere de korrekte/nødvendige rettigheder til at udføre deres opgave?

• Har DDE1 og DDE2 begge være logget på og foretaget data indtastning?
• Har reviewer været i Data Comparison Tool og gjort sig bekendt med dette?

• Har brugerne været inde i Data Quality Modulet og anvendt dette til at teste kvaliteten af data?
• Er der kørsel af standard regler, som giver anledning til bekymring/fejlrettelse?
• Vær specielt opmærksom på regel F skjulte felter, som indeholder data. Typisk en fejl i Branching Logic.
• Hvis brugeren selv har oprettet regler, er de så testet?

• Er alle personfølsomme variable markeret som ”Identifier”, som hermed nemt kan udelades i data eksporten?
• Brugeren bør gøre sig bekendt med udseendet af data eksporten. Dette gælder særligt for longitudinale projekter eller projekter der anvender repeating forms eller events, idet datarepræsentationen i disse tilfælde vil være lang i stedet for bred.

• Brugeren opfordres til at teste udfaldet af denne, alt efter om blokstørrelse er kendt eller ej, og om der er tale om blindet eller ikke-blindet.
• Hvis der gøres brug af strata, er de da korrekte? Og bliver fordelingen som forventet?

• Design skemaet så enkelt og overskueligt som muligt.
• Bryd lange spørgeskemaer op i sider via ”Begin Section”.
• Lav det så intuitivt som muligt.
• Lav ensartet opbygning af spørgsmål, således at der er tale om et ”roligt billede”.
• Overvej fordele/ulemper ved at kunne gemme og genoptage besvarelse af spørgeskema.
• Sørg for at teste skemaerne igennem – gerne med mange forskellige brugere.
• Ved automatisk udsendelse tjekkes og testes kriterie grundet igennem.
• Det er ligeledes vigtigt at tydeliggøre, hvorvidt spørgeskemaet skal indtastes af én omgang eller om der gives mulighed for at gemme og vende tilbage på et senere tidspunkt.
• Er der tænkt over felter til markering af dropout fra studiet pga. død eller frafald, således at sådanne markeringer kan indgå i automatiseret survey logik og derved undgå afsendelse af surveys til personer der ikke længere bør modtage surveys?