This document provides guidance on designing case report forms (CRFs) for clinical trials. It emphasizes starting CRF development early and planning ahead with the desired data collection goals and database structure in mind. The right team should be involved in CRF development and review. Key recommendations include maintaining consistency throughout CRFs, using indicator questions, avoiding redundant data collection, and using worksheets instead of CRFs for non-clinical data. Thorough planning, reviews, and testing of CRFs can help ensure the high-quality collection of the intended clinical data.

1. Do’s and Don’ts
of CRF Design
Lori Tholkes Venable
& Jane Hamilton
14th Annual OCUG Conference, Oct 2009 – New Orleans

2. Introduction
• CRF development:
– First step in translating a protocol into data
– Ideally occurs concurrently with protocol
development
• Scope of p
p presentation:
– Targeted for paper-based CRF studies
• Although some information transferable to EDC
– Targeted to OC studies
• Although information transferable to other CDBMS
OCUG 2009 2

3. Topics
• Planning
• General Considerations
• Specifics
– Some “Do’s” and “Don’ts”
Do s Don ts
– With examples
– Workarounds / suggestions / alternatives
• Finalizing CRFs
• Summary
OCUG 2009 3

4. Planning (1)
• Start EARLY!!
– Enough time for drafts/reviews/changes/etc
– To “Get it Right the First Time”
• PLAN AHEAD!!
– With the END in mind!
– Plan ‘backwards’
backwards
• What is the desired end product?
• What is the best way to get there?
• Use draft protocol to design CRFs
– Standard CRF modules
– P j t and/or protocol-specific modules
Project- d/ t l ifi d l
OCUG 2009 4

5. Planning (2) – the Right Team
• CRF development / review / approval Team
– Clinical Data Manager
– OC: Global Librarian, Study Developer,
Procedure Developer
– Statistician
– Clinical Study Manager
– CRA
– …others … as needed/requested
• DE operator site staff, etc.
operator, staff etc
• All bring a unique and valuable perspective!
– Ask lots of questions
OCUG 2009 5

6. Planning (3) – the Right Data
• Collect precise data as required by
protocol
– Avoid collecting extraneous data
• that “just in case” data
just case
– If you COLLECT it:
• you have to CLEAN it
• You have to ANALYZE it
• You have to REPORT it
• Collect ONLY items needed in the
database
OCUG 2009 6

7. Planning (4) – the Right Design
• CRFs are only as good as their design
– If unclear to the site personnel will the data be
personnel,
accurate?
– If unclear to DE operators, will entry into the
database be accurate?
– If not reflective of the protocol, will everyone
know what to do with the resultant data?
• Must be easy to use
– For site personnel
– For Data Entry
– Etc.
OCUG 2009 7

8. Planning (5) – Thinking Ahead
• Address needs of those who will work with the
DATA
– Database developers
– Data Entry operators
– Procedure programmers
P d
– Data managers
– Statisticians
– Clinical personnel
– Etc.
• Consistency
– CRF design consistency across studies
– Review OC for existing objects/modules (reusability)
OCUG 2009 8

9. General Considerations (1)
• Consistency – throughout!
– Formats fonts, sizes, etc.
Formats, fonts sizes etc
• White space
– Too much? … Too little?
• Layouts
– Portrait vs landscape vs combination
• NCR
– Clarity of 2nd/3rd/4th NCR copies
y / / p
• Scanning
– If CRFs will be scanned
OCUG 2009 9

10. General Considerations (2)
• Page Numbering
– Either use or don t use – consistently throughout
don’t
• Use Section headings
– To differentiate OC DCMs
– DCM Description appears on DCFs
• Scrolling / log forms (AEs, Con Meds, etc)
Sc o g og o s ( s, Co eds,
– Visit designation?
– Visit/header date expected?
– Page numbering?
– Sub-Events?
OCUG 2009 10

11. General Considerations (3)
• Clear, specific Instructions
– Leave no doubt what is expected
– Specifically state “Check only ONE”
– Specifically state if/when certain fields should be
p y /
completed, e.g.:
• If ‘other’, then specify
• If ‘Yes’, then …………
Yes
• If ‘Female’, complete Childbearing status fields
• If ‘Smoker’/ ‘Drinker’, then ………
• Don’t split modules across pages
– Exception: multi-page forms, questionnaires, etc.
OCUG 2009 11

12. General Considerations (4)
• Use Indicator Questions, e.g.:
– Did patient experience any AEs? 1 Yes 2 No
– NOT: Adverse Events None …or… <nothing>
• Don’t want to make ASSUMPTIONS about the data!!
Don t
• Y/N vs. single checkbox, e.g.:
– Continuing? 1 Yes 2 No
– NOT: Continuing
• If this is checked, what is stored? (Yes?, Continuing?)
, ( , g )
• Avoid Graphics
– how can they be captured, analyzed, reported?
y p , y , p
OCUG 2009 12

13. General Considerations (5)
• Modules collected at multiple visits should
be modeled the same for each visit, e.g.:
– Vital Signs – same order each time
– PE – Body Systems same each time
y y
• Don’t collect fields that can be derived
– e.g., Age, BMI, Durations, Averages, etc
– Exception: if required for protocol criteria
• Don’t have a non-repeating question in the
midst of a Repeating QG
– Examples later
OCUG 2009 13

14. General Considerations (6)
• Avoid collecting redundant data
– If you collect it in 2 places you have to clean it
places,
– e.g., PE abnormalities on Med History (baseline)
or AE (post-baseline) – NOT on PE form
– Note: this usually seems to be Text fields –
much harder to compare / clean
• Wh t to do with every field, e.g.:
What t d ith fi ld
– Additional boxes next to a field – is this
supposed to be a separate field? … Alpha DVG?
– e.g.: Kit Number: __ __ __ Not dispensed
– Date of Exam: _ _ / _ _ _ / _ _ _ _ OR same as visit date
OCUG 2009 14

15. CRF Headers
• Maintain a STANDARD!
• Study/protocol title
– Match OC study name (minimize confusion for DE)
• Patient numbering schemes used in OC
– And Site / Investigator
• Visit number/name designation
– Match protocol verbiage
• Visit dates
– May only be needed for visit-specific forms
• Patient Initials? If so, what to do with in OC?
OCUG 2009 15

16. Date (and Time) Fields (1)
• Consistent format throughout study
– U S vs European vs Standard
U.S.
DON’T:
NOTE: Elsewhere throughout this CRF Book,
Dates are:
OCUG 2009 16

17. Date (and Time) Fields (2)
• Use separate lines or combs (or boxes)
– To display expected format
– Include example of date in expected format
DON T:
DON’T:
DO:
OCUG 2009 17

18. Date (and Time) Fields (3)
DO: (cont.)
NOTE: if using boxes, think about NCR copies
(lines/combs are probably b tt )
(li / b b bl better)
OCUG 2009 18

19. Numeric Fields (1)
• Use separate lines or combs
– To display expected digits & decimal places
DON’T:
OR:
OCUG 2009 19

20. Numeric Fields (2)
DO:
OR:
NOTE: don’t use boxes – they can look too much
y
like DVG checkboxes.
OCUG 2009 20

21. DVG (checkbox) Fields (1)
• DVG Checkboxes and Codes
– Codes: either Use or Don t Use – CONSISTENTLY!
Don’t
• Minimize confusion for DE (‘Enter by Seq #’)
– Location of checkboxes
• Consistent location throughout (right or left of response)
– Location of codes
• Next to checkbox not as a column heading
checkbox,
• Consistent location throughout (right or left of box)
– Consistent codes throughout
• E.g., 1=Yes, 2=No throughout – not some pages where
1=No and 2=Yes
OCUG 2009 21

22. DVG (checkbox) Fields (2) – DON’T
No codes
Codes Inconsistent location
of checkboxes
(some right, some
left f t t)
l ft of text)
Inconsistent
location of codes
OCUG 2009 22

23. DVG (checkbox) Fields (3) – DO
Consistent
use of Codes
Consistent location
of checkboxes
(left of text)
Consistent
location of codes
(lower right of box)
OCUG 2009 23

24. DVG (checkbox) Fields (4) – DON’T
Location of codes
(not i column
( in l
headings)
OCUG 2009 24

25. DVG (checkbox) Fields (5) – DO
Location of codes
(next to
checkbox)
OCUG 2009 25

26. DVG (checkbox) Fields (6) – DON’T
Location of codes
(next to boxes,
not in column
headings)
h di )
OCUG 2009 26

27. DVG (checkbox) Fields (7) – DO
Location of codes
(next to
checkbox)
OCUG 2009 27

28. Inconsistent Codes – DON’T
Elsewhere throughout this study:
1 = Yes
2 = No
OCUG 2009 28

29. Questionnaires (1)
• Things to think about:
– Will responses be stored as CHAR or NUM?
• If CHAR, full DVG text or abbreviated?
• If NUM, is entry clear to DE?
– Can questionnaire fit on one page, or will it span
multiple pages?
• What about page numbering?
– Is questionnaire completed by Patient or Inv.?
• Are instructions clear?
– Are there Derived scores to be calculated?
• Will they be derived in OC?
OCUG 2009 29

30. Questionnaires (2) - DON’T
Good: Instructions
to Patient
Bad: What does
DE enter?
(all NUM fields!)
OCUG 2009 30

31. Questionnaires (3) - DON’T
What does
DE enter?
t ?
t ese are all
these a e a
Numeric fields
OCUG 2009 31

32. “Check All that Apply” (1) – DON’T
• Avoid “Check All that Apply” options
– Forces ‘assumptions’ about the clinical data
assumptions
– Unnecessarily complex for database structuring
• Can be handled various ways, none of which are
y ,
ideal for:
– Database setup
– Data entry
– Data cleaning
– Data extract
OCUG 2009 32

33. “Check All that Apply” (3)
DON’T:
DO:
OCUG 2009 33

34. “Check All that Apply” (4) – DON’T
OCUG 2009 34

35. “Check All that Apply” (4) – DON’T
No instructions! Can more than
one be checked?
Can there be more
than 1 organism?
How will I build this database?
How will I clean this data?
How will I create Validation Procs?
How will I extract/report this data?
OCUG 2009 35

36. Instructions – DO
OCUG 2009 36

37. Instructions – Expected Units
DON’T:
??
DO:
No
question
OCUG 2009 37

38. Redundant Data – DON’T …
Here!
NOT here!
OCUG 2009 38

39. Redundant Data – Instead…
OCUG 2009 39

40. Redundant Data
On CRF Page 1:
On CRF Page 2:
Issues:
1.
1 What if these are different on the 2 pages?
2. Assigned study number:
• Page 1, length = 6;
• Page 2, length = 9
OCUG 2009 40

41. Non-repeating Q within RQG
NO!
OCUG 2009 41

42. Non-repeating Q within RQG
NO!
OCUG 2009 42

43. Non-repeating Q within RQG
NO!
OCUG 2009 43

44. Indicator Questions
No Indicator Q
If no AE Log received/entered:
• No record in database for that patient
• Forced to make “assumptions” about the data
(
(AE = safety data!)
y )
OCUG 2009 44

45. Indicator Questions
WITH Indicator Q
• A record in database for every patient
(query missing)
• No “assumptions” about the data
OCUG 2009 45

46. Indicator Questions
Need an Indicator Q
OCUG 2009 46

47. Indicator Questions
Yes!!
OCUG 2009 47

48. Indicator Questions
Not quite! Need to ‘force’
this into an Indicator Q
OCUG 2009 48

49. Indicator Questions
Much better!
OCUG 2009 49

50. Use Worksheets Instead (1)
• Use ‘Worksheets’ instead of ‘CRFs’ for:
– Items that might be ‘helpful’ but are ‘non
‘non-
clinical’ data/information;
– Examples:
p
• Individual Inclusion/Exclusion questions;
• Reminders/Checklists for visit-specific procedures
(exams, labs etc );
(exams labs, etc.);
• Prompts/Triggers to complete other forms (AEs, Con
Meds, etc.);
– Worksheets will remain with Patient’s source
data, but not entered into the clinical database
OCUG 2009 50

51. Use Worksheets Instead (2)
While this information serves a purpose
(prompting the investigator), it is not clinical data.
The clinical data is elsewhere (AE & CM forms).
These questions/prompts can be on a supplemental,
visit-specific worksheet or checklist.
OCUG 2009 51

52. Use Worksheets Instead
Again, this is simply a reminder to the investigator,
the clinical data is on the appropriate CRFs.
This can be on a non-CRF checklist/worksheet.
non CRF
OCUG 2009 52

53. Use Worksheets Instead
CRF – N !
No!
Worksheet – Yes!
… and here’s what your
CRF can be …
C
OCUG 2009 53

54. Use Worksheets Instead
This is the data you
REALLY care about –
for the CRF and the
database!
… or this …
OCUG 2009 54

55. Use Worksheets Instead
Again, this is
sufficient for the
CRF and the
database!
OCUG 2009 55

56. Finalizing CRFs (1)
• “Right Team” for review/input draft CRFs
– CRF review meeting(s)
– Repeat draft reviews until no further changes
• Suggest someone not familiar with the study
review / complete an entire set of CRFs
– Anticipate issues, questions, needed clarifications
p ,q ,
• Coordinate printing / shipping / etc
OCUG 2009 56

57. Finalizing CRFs (2)
• CRF Completion Manual
– Provides clear instruction to Site for accurate
completion of the study CRFs
– Includes clear expectations for Site personnel
p p
– Should be drafted concurrently with draft CRFs
– Address all potential issues
• Present CRFs & completion instructions at
Investigator’s meeting
– Include complete ‘example’ set of CRFs
OCUG 2009 57

58. Summary
• CRFs are NOT just for investigators … consider
everyone who will use the CRFs AND the data!
• Very clear instructions and training on CRF
completion
• Learn from past mistakes
• Standardization
• Consistency
OCUG 2009 58

59. Contact information
Lori Venable
Principal Consultant
BioPharm Systems, Inc.
734-332-
734-332-1718
lvenable@biopharm.com
Jane Hamilton
Senior Consultant
BioPharm S t
Bi Ph Systems, Inc.
I
810-750-
810-750-7337
jhamilton@biopharm.com
OCUG 2009 59

60. Biographies
Lori Venable
Lori is a Principal Consultant at BioPharm, Systems, Inc. She has been in the industry for over 21
y
years, representing a variety of pharma, contract, and device companies, both large and small.
, p g y p , , p , g
Lori has been actively involved in Oracle Clinical implementation since 1995, starting at Parke-
Davis as a member of the OC implementation team. Prior to joining BioPharm Systems in 2004,
she was at Baxter Healthcare’s Renal Division for 4 years, functioning as Sr. Project Manager
overseeing OC implementation and use.
g p
Lori has been an active OCUG member since its inception in Ann Arbor in 1996. She served as Co-
Chair of OCUG from 2003-2005 and currently serves on the Executive Committee. She’s been Co-
Chair of the Global Library focus group from 2002-2004 and 2007 to present, and actively
p
participates on numerous other focus g p Lori also co-facilitates the OCUG Website
p groups.
Committee; and served on the Planning Committee for the 2003 through 2009 annual conferences.
Lori’s primary OC and RDC responsibilities have included: training / coaching / troubleshooting;
Global Librarian; Study Developer; Validation/Derivation Procedure developer; writing SOPs and
g
guidelines; Application Administrator; and System Validation.
pp y
Jane Hamilton
Jane is a Senior Consultant at BioPharm Systems, Inc. where she works primarily on validation and
SOP creation. Jane has worked in the industry for 20 years. The majority of her experience is in
Data Management with Parke-Davis/Pfizer where she worked on the team that implemented/piloted
Oracle Clinical as well as the SOPs and standard processes to support it.
OCUG 2009 60