Page History

"Yes/No" questions provide a definite answer. The absence of a response is ambiguous as it can mean "No," "None," or that the response is missing.

In situations where there is no other dependent or related field by which to gauge the completeness of the field in question, a "Yes/No" response ensures that the data are complete.

The database should contain an indication that a planned exam/assessment was not performed. The mechanism for this may be different from system to system or from paper to EDC.

A "Yes/No – assessment completed" question is preferred over a "Check if not done" box, unless the "Check if not done" field can be compared to a completed data field using a validation check to confirm that one or the other has data.

• In situations where there is no other dependent or related field to gauge the completeness of the field in question, a "Yes/No" response format should be used to eliminate ambiguity.
• When another related field is present, the "Yes/No" response is optional. For example, when a value for temperature is missing, a simple "Not Done" box may be checked. It is not necessary to respond "Done" when a temperature value is present.

This will provide a definitive indicator that a data field has missing data and has not been overlooked.

This will prevent unnecessary data queries to clarify whether an assessment has been performed.

The use of the "Yes/No" format helps to eliminate ambiguity about whether an assessment has been completed.

Data-cleaning prompts should be used to confirm that blank CRFs are intentionally blank.

Usually this will be a "Yes/No" question but it may be a "Check if blank" box, if a validation check can be used to confirm that either the "Check if blank" box is checked, or that there are data recorded in the CRF.

This will provide a definitive indicator that a CRF is blank on purpose and has not been overlooked.

This will prevent unnecessary data queries.

Collecting the same data more than once:

• Creates the opportunity for discrepancies between the entered values. For example, subject’s birthdate or age is collected on the Demographics page; it is not necessary to collect age on the Lab CRF at every visit.
• Requires extra reconciliation.
• May affect frequency counts and analysis results.

A "Check if ongoing" question is recommended to confirm ongoing against an end date.

This is a special-use case of "Yes/No," where the data entry field may be presented as a single possible response of "Yes" in conjunction with an End Date variable. If the box is checked, the operational variable may contain "Yes". If the box is not checked and the End Date is populated, the value of the variable may be set to "No".

For some EDC systems, it may be better to display the possible responses to the "Check if ongoing" question as radio buttons. Conditional logic can then be used to solicit the collection of the end date only if the answer to the "Ongoing" question is "N" (No).

7

Putting short instructions and prompts on the CRF increases the probability that they will be read and followed, and can reduce the number of queries and the overall data cleaning costs.

Having standard instructions supports all data collection using the same conventions for completing the fields.

Providing short instructions and prompts on the CRF and moving long instructions to a separate instruction booklet, facing page, or checklist will decrease the number of CRF pages, with the following benefits:

• Decreased CDM costs (e.g., decreased data entry costs)
• Allows CRF to be formatted so that the reader can easily identify the fields to be completed
• Format of the page is less cluttered, making it easier for individuals involved in data collection and monitoring to identify fields with missing responses

Collection of dates should use an unambiguous format, such as DD-MON-YYYY, where each part of the date is a unique format: "DD" is the day as a 2-digit numeric value; "MON" is the month as a 3-character letter abbreviation in English, or similar character abbreviation or representation in the local language; and "YYYY" is the year as a 4-digit numeric value.

For EDC, the user may be able to select a date from a calendar, and this would also meet the recommendation for an unambiguous date.

If the recommended approach is not adaptable to the local language, a similarly unambiguous format should be used.

The method for capturing date values should allow the collection of partial dates and should use a consistent method or convention for collecting the known date parts.

Using this data collection format (i.e., DD-MON-YYYY) will provide unambiguous dates. For example, the date "06/08/02" is ambiguous because it can be interpreted as June 8, 2002, or August 6, 2002.

If subject-completed CRF pages are translated into a local language, the CDASH recommended date format for collection may make translation of the documents easier.

To eliminate ambiguity, times should be collected with the use of a 24-hour clock, using the hh:mm:ss format for recording times.

Use only as many of the hh:mm:ss elements as are needed for a particular field. Individuals involved in data collection should be cautioned not to "zero-fill" time components if these are not known (for example 21:00:00 means "exactly 9 pm", but if how many seconds after 9 PM is unknown, seconds should not be recorded).

Subject-completed times may be recorded using a 12-hour clock and an "am" or "pm" designation. The time should then be transformed to a 24-hour clock in the database.

Manually calculated fields should not typically be recorded within the CRF when the raw data on which the calculation is based are recorded in the CRF.

An exception is when a treatment and/or study conduct decision should be made based on those calculations. In such cases it may be useful for the calculated field to be recorded within the CRF.

It may also be useful to provide the individuals involved in data collection a step-by-step worksheet to calculate this data.

Data items that can be calculated from other data captured within the CRF are more accurately reported if they are calculated programmatically using validated algorithms.

The noted exception may be in cases where it is important to show how an investigator determined a protocol-defined endpoint from collected raw data.

Questions with free-text responses should be limited.

Questions should be specific and clear rather than open-ended. Instead of free-text comment fields, a thorough review of the CRF by the protocol development team should be performed to maximize the use of predefined lists of responses.

The collection and processing of free text requires significant resources for data entry: It requires data management (DM) resources to review the text for safety information and for inconsistencies with other recorded data and is of limited use when analyzing and reporting data.

Another risk is data entry into free-text fields that should be recorded elsewhere.

The CRF is a tool to collect subject-level data. However, pre-population of some identifying (e.g., investigator name, protocol number) or timing information prevents errors and reduces data entry time.

Fields on the CRF or in the database that are known to be the same for all subjects may be pre-populated (e.g., measurements for which there is only 1 possible unit, such as Pulse Rate ="beats/min"). The units can be displayed on the CRF and populated in the database.

When a parameter such as location, position, or method is specified in a protocol and is part of the analysis, the CRF may include the common options for these parameters to ensure what actually happened can be reported and protocol deviations can be identified. If the parameter is pre-populated on the CRF and other options are not available, then data should not be recorded that was not collected per protocol specifications.

Taking measurements in multiple anatomical locations may affect the value of the measurement and/or the ability to analyze the data in a meaningful way (e.g., when data obtained from different locations may bias or skew the analysis). In this case, collecting the location may be necessary to ensure consistent readings. For example, temperature obtained from the ear, mouth, or skin may yield different results.

If there is no such rationale for collecting location, position, method, or any other value, it would be considered unnecessary data.

When information about spontaneously reported adverse events or medical history reported, recording responses verbatim ensures that no information is omitted.

Individuals involved in data collection are not expected to be coding experts and may not be familiar with the coding dictionaries used. Recording adverse events from a standardized list is the same as having them code these events.