The read-transcribe-verify method

The method itself is straightforward. Its power lies not in its complexity but in its consistency -- in the fact that you apply it to every single field, without exception, without shortcuts.

Step 1: Read. Look at the source document. Find the specific value you need to transcribe. Read it completely. Do not glance at it. Do not read only the first two digits of a four-digit lab value. Read the entire value, including its unit. If the source is handwritten, confirm that you can distinguish every character -- that the "7" is not a "1," that the "4" is not a "9," that the decimal point is where you think it is. If you cannot read a character with confidence, stop. Clarify with the person who wrote it before you proceed.

Step 2: Transcribe. Enter the value into the CRF field. Enter it directly -- from the source document to the CRF, not from memory. The source document should be visible to you while you are typing or writing. If you are working from a laboratory report, the report should be open next to your CRF. If you are working from a source document worksheet, the worksheet should be in front of you. Never read five values from the source, hold them in your head, then enter them from memory. That is not transcription. That is recall, and recall introduces error.

Step 3: Verify. Immediately after entering the value, look back at the source document and compare what you entered to what the source says. Not later. Not after you finish the form. Now. Compare the value digit by digit, character by character. Confirm the unit. Confirm the decimal point placement. Confirm the date format. Only when you are satisfied that the CRF entry matches the source exactly do you move to the next field.

Then repeat. Read the next value. Transcribe it. Verify it. Field by field, value by value, through the entire form.

High-risk data elements: where transcription errors concentrate

Not all CRF fields carry equal transcription risk. A yes/no checkbox is hard to get wrong. But a seven-digit lab value with a decimal point, or a date that differs from another date by a single digit, or a blood pressure that is two three-digit numbers separated by a slash -- these are the fields where errors cluster. Understanding which data elements carry elevated risk allows you to apply heightened vigilance where it matters most.

Multi-digit laboratory values. Laboratory results are among the most error-prone data elements in clinical trials, and the reason is purely structural: they are long strings of digits, often with decimal points, presented in dense tabular formats on lab reports. A serum creatinine of 1.24 mg/dL becomes 1.42. A white blood cell count of 11,200/mcL becomes 12,100. A hemoglobin of 10.2 g/dL becomes 102 when the decimal point is missed entirely. These are not random errors -- they follow predictable patterns. Digit transposition (swapping two adjacent digits) and decimal misplacement are the two most common failure modes. When verifying lab values, check each digit individually and confirm the decimal position explicitly.

Dates. Dates are deceptively complex because they combine three components (day, month, year) in a format that varies by convention. The most common date transcription errors are year errors (entering 2025 instead of 2026, or 1956 instead of 1965), month transpositions in numeric formats (03 for March becomes 30), and day-month reversals when converting between regional formats. The DD-MMM-YYYY convention used in most clinical trials mitigates some of these risks by using three-letter month abbreviations, but it does not eliminate year errors or day transpositions.

Medication doses. A dose of 2.5 mg transcribed as 25 mg -- or 250 mg entered as 25 mg -- can have direct clinical consequences if the transcription error affects safety reporting, dose modification decisions, or eligibility calculations. Medication dose errors are particularly dangerous because they can be clinically plausible: 25 mg of a drug that comes in 2.5, 5, 10, and 25 mg strengths will not trigger an edit check, even though the actual dose was 2.5 mg. The decimal point is the critical character.

Timing fields. Times of vital sign measurements, dosing times, and procedure times are vulnerable to 12-hour transpositions (entering 02:00 instead of 14:00), to digit swaps (14:30 becomes 13:40), and to am/pm confusion when converting from 12-hour source records to 24-hour CRF formats. A dosing time error of 12 hours can invalidate pharmacokinetic calculations for the entire visit.

Blood pressure. Blood pressure is two three-digit numbers recorded as a pair, and the visual similarity between the systolic and diastolic components invites transposition. A reading of 138/86 can become 183/86, 138/68, or even 86/138. Because blood pressure values often fall within physiologically plausible ranges even when transposed (183 mmHg systolic is high but not impossible), these errors may not trigger edit checks.

Common transcription challenges

Not every transcription task is a simple copy operation. Some require judgment, conversion, or clarification before a value can be entered. These are the moments where errors compound -- where a coordinator must not only transcribe accurately but also transform the data correctly. Four categories of transcription challenge appear across virtually every clinical trial.

Unit conversions. When the source document records a value in one unit and the CRF requires a different unit, you must convert before entry. Weight is the most common example: the clinic scale reads 165 pounds, but the CRF field requires kilograms. Temperature recorded in Fahrenheit that must be entered in Celsius. Height in inches that must be entered in centimeters. The conversion itself is arithmetic, but the opportunity for error is substantial. A wrong conversion factor, a misplaced decimal, or an arithmetic mistake produces a value that is precise but wrong -- and precision without accuracy is worse than a blank field, because it looks correct.

The rule is: perform the conversion, document it, and verify the result against an independent source (a conversion table, a validated calculator, or a second person). Do not perform unit conversions from memory. A coordinator who "knows" that a pound is about 2.2 kilograms and divides 165 by 2.2 in their head will occasionally arrive at the wrong number. Use a tool. Document which tool. And verify the result.

Narrative-to-coded data. Source documents often contain narrative descriptions that must be translated into coded or categorized CRF entries. The investigator writes "mild erythema at the injection site, approximately 2 cm in diameter, resolved spontaneously within 48 hours" in the progress note. The CRF requires you to select a severity grade from a dropdown (Grade 1, Grade 2, Grade 3), a measurement in a numeric field, and a duration in days. This is not transcription in the strict sense -- it is interpretation. And interpretation requires that you understand the coding scheme well enough to apply it correctly.

The safest approach is to code from the CRF completion guideline, not from general medical knowledge. The guideline will define what constitutes Grade 1 versus Grade 2 for each type of reaction. If the source narrative does not map cleanly to the available codes -- if the description falls between two categories, or if the guideline does not address the specific finding -- flag it for the investigator. Do not guess. A coding error is harder to detect than a transcription error, because the coded value looks valid even when it is wrong.

Ambiguous source entries. Sometimes the source document itself is the problem. A handwritten "7" that could be a "1." A vital sign recorded without a unit. A date missing the year. A laboratory result with an unclear decimal point. When the source is ambiguous, you have exactly one acceptable response: clarify before entry. Go back to the person who created the source record. Ask them what they wrote. Have them initial the clarification. Then -- and only then -- transcribe the clarified value.

What you must never do is interpret an ambiguous source entry on your own and enter your interpretation as fact. If a handwritten number could be either 7 or 1, you do not get to choose which one it "probably" is. You do not get to enter the value that "makes more clinical sense." You clarify. Per ICH E6(R3) Section 2.12.6, the data reported to the sponsor must be consistent with the source records. You cannot be consistent with a source you cannot read.

Calculated values. Some CRF fields require calculated values derived from source data: body mass index calculated from height and weight, creatinine clearance calculated from serum creatinine using the Cockcroft-Gault formula, body surface area calculated from height and weight. These calculations introduce two layers of error risk: transcription error in the input values and calculation error in the arithmetic. When a CRF requires a calculated value, verify both the inputs and the output. Enter the source values first, perform the calculation using a validated tool (not mental arithmetic), and verify the calculated result against an independent calculation before entering it.

CRF correction procedures: when errors must be fixed

Despite the best methodology, errors will sometimes reach the CRF. A monitor identifies a discrepancy during source data verification. An edit check flags an implausible value. Your own self-review catches a transposition you missed on the first pass. When a CRF entry must be corrected, the correction itself must follow specific regulatory requirements -- requirements that differ in their mechanics between paper and electronic systems but share a single inviolable principle: the original entry must never be obscured or deleted.

ICH E6(R3) Section 2.12.6 states it directly: "Changes or corrections in the reported data should be traceable, should be explained (if necessary) and should not obscure the original entry." This is not a preference. It is a regulatory requirement rooted in data integrity: anyone reviewing the record at any point in the future must be able to see what was originally entered, what it was changed to, when, by whom, and why. An audit trail is not optional. It is the record of how the data evolved.

Paper CRF corrections. On a paper CRF, the correction procedure has been standardized for decades and admits no variation:

1. Draw a single line through the incorrect entry. The original value must remain legible beneath the line. Do not use white-out, correction tape, or heavy crosshatching that obscures the original.
2. Write the correct value near the crossed-out entry -- above it, below it, or beside it, depending on available space.
3. Initial the correction with your own initials (the person making the correction, not the investigator's initials unless the investigator is making the correction).
4. Date the correction with the date you are making the change, not the date of the original entry.
5. Provide a reason for the correction when the reason is not self-evident. "Transcription error -- source document shows 138" is sufficient. If the change reflects new information rather than an error correction, the reason must explain the basis for the change.

Every element is essential. A correction without a date cannot be placed in the timeline of the trial. A correction without initials cannot be attributed to the person who made it. A correction that obscures the original value destroys the audit trail. And a correction without a reason -- when the reason is not obvious -- leaves reviewers wondering whether the change was legitimate.

Electronic CRF corrections. In an electronic system, the mechanics are different but the principle is identical. When you modify a previously saved value in an EDC system, the system automatically captures several elements of the audit trail: the original value, the new value, the identity of the person making the change (your login credentials), and the date and time of the change. What the system cannot capture automatically is the reason for the change. That is your responsibility. When you modify a saved value, the system will prompt you to enter a reason for the change. This is not a formality to be dismissed with "corrected" or "changed." It is the explanatory component of the audit trail.

A good reason for change is specific and traceable: "Corrected per source document -- hemoglobin was 10.2 g/dL, not 102 g/dL (decimal point omitted during initial entry)." A poor reason is vague: "Data correction." The difference matters during audits and inspections, when a regulatory reviewer will examine the audit trail to determine whether changes to the data were legitimate corrections or inappropriate modifications.

When transcription errors have consequences

The methods described in this lesson -- read-transcribe-verify, heightened vigilance on high-risk elements, proper handling of challenges, disciplined correction procedures -- exist because transcription errors have consequences that extend far beyond a data query. A misplaced decimal can make an ineligible participant appear eligible. A transposed digit can mask a safety signal. A wrong date can place an adverse event outside the treatment window when it actually occurred during treatment.

The following case study illustrates what happens when a single digit transposition slips through -- not because the coordinator was careless, but because the verification step was skipped on a field that turned out to matter enormously.

This case study illustrates a principle that bears emphasis: the read-transcribe-verify method is not bureaucratic overhead. It is participant protection. A three-second verification -- looking back at the source to confirm that 25 was entered as 25, not 52 -- would have prevented every downstream consequence: the incorrect eligibility determination, the enrollment of an ineligible participant, the two doses of an investigational product administered to someone whose kidney function could not safely handle it, the protocol deviation, the IRB report, and the remedial actions.

The cost of the verify step is seconds per field. The cost of skipping it, even once, can be measured in participant safety, regulatory findings, and professional consequences.

The read-transcribe-verify method

The method itself is straightforward. Its power lies not in its complexity but in its consistency -- in the fact that you apply it to every single field, without exception, without shortcuts.

Step 1: Read. Look at the source document. Find the specific value you need to transcribe. Read it completely. Do not glance at it. Do not read only the first two digits of a four-digit lab value. Read the entire value, including its unit. If the source is handwritten, confirm that you can distinguish every character -- that the "7" is not a "1," that the "4" is not a "9," that the decimal point is where you think it is. If you cannot read a character with confidence, stop. Clarify with the person who wrote it before you proceed.

Step 2: Transcribe. Enter the value into the CRF field. Enter it directly -- from the source document to the CRF, not from memory. The source document should be visible to you while you are typing or writing. If you are working from a laboratory report, the report should be open next to your CRF. If you are working from a source document worksheet, the worksheet should be in front of you. Never read five values from the source, hold them in your head, then enter them from memory. That is not transcription. That is recall, and recall introduces error.

Step 3: Verify. Immediately after entering the value, look back at the source document and compare what you entered to what the source says. Not later. Not after you finish the form. Now. Compare the value digit by digit, character by character. Confirm the unit. Confirm the decimal point placement. Confirm the date format. Only when you are satisfied that the CRF entry matches the source exactly do you move to the next field.

Then repeat. Read the next value. Transcribe it. Verify it. Field by field, value by value, through the entire form.

High-risk data elements: where transcription errors concentrate

Not all CRF fields carry equal transcription risk. A yes/no checkbox is hard to get wrong. But a seven-digit lab value with a decimal point, or a date that differs from another date by a single digit, or a blood pressure that is two three-digit numbers separated by a slash -- these are the fields where errors cluster. Understanding which data elements carry elevated risk allows you to apply heightened vigilance where it matters most.

Multi-digit laboratory values. Laboratory results are among the most error-prone data elements in clinical trials, and the reason is purely structural: they are long strings of digits, often with decimal points, presented in dense tabular formats on lab reports. A serum creatinine of 1.24 mg/dL becomes 1.42. A white blood cell count of 11,200/mcL becomes 12,100. A hemoglobin of 10.2 g/dL becomes 102 when the decimal point is missed entirely. These are not random errors -- they follow predictable patterns. Digit transposition (swapping two adjacent digits) and decimal misplacement are the two most common failure modes. When verifying lab values, check each digit individually and confirm the decimal position explicitly.

Dates. Dates are deceptively complex because they combine three components (day, month, year) in a format that varies by convention. The most common date transcription errors are year errors (entering 2025 instead of 2026, or 1956 instead of 1965), month transpositions in numeric formats (03 for March becomes 30), and day-month reversals when converting between regional formats. The DD-MMM-YYYY convention used in most clinical trials mitigates some of these risks by using three-letter month abbreviations, but it does not eliminate year errors or day transpositions.

Medication doses. A dose of 2.5 mg transcribed as 25 mg -- or 250 mg entered as 25 mg -- can have direct clinical consequences if the transcription error affects safety reporting, dose modification decisions, or eligibility calculations. Medication dose errors are particularly dangerous because they can be clinically plausible: 25 mg of a drug that comes in 2.5, 5, 10, and 25 mg strengths will not trigger an edit check, even though the actual dose was 2.5 mg. The decimal point is the critical character.

Timing fields. Times of vital sign measurements, dosing times, and procedure times are vulnerable to 12-hour transpositions (entering 02:00 instead of 14:00), to digit swaps (14:30 becomes 13:40), and to am/pm confusion when converting from 12-hour source records to 24-hour CRF formats. A dosing time error of 12 hours can invalidate pharmacokinetic calculations for the entire visit.

Blood pressure. Blood pressure is two three-digit numbers recorded as a pair, and the visual similarity between the systolic and diastolic components invites transposition. A reading of 138/86 can become 183/86, 138/68, or even 86/138. Because blood pressure values often fall within physiologically plausible ranges even when transposed (183 mmHg systolic is high but not impossible), these errors may not trigger edit checks.

Common transcription challenges

Not every transcription task is a simple copy operation. Some require judgment, conversion, or clarification before a value can be entered. These are the moments where errors compound -- where a coordinator must not only transcribe accurately but also transform the data correctly. Four categories of transcription challenge appear across virtually every clinical trial.

Unit conversions. When the source document records a value in one unit and the CRF requires a different unit, you must convert before entry. Weight is the most common example: the clinic scale reads 165 pounds, but the CRF field requires kilograms. Temperature recorded in Fahrenheit that must be entered in Celsius. Height in inches that must be entered in centimeters. The conversion itself is arithmetic, but the opportunity for error is substantial. A wrong conversion factor, a misplaced decimal, or an arithmetic mistake produces a value that is precise but wrong -- and precision without accuracy is worse than a blank field, because it looks correct.

The rule is: perform the conversion, document it, and verify the result against an independent source (a conversion table, a validated calculator, or a second person). Do not perform unit conversions from memory. A coordinator who "knows" that a pound is about 2.2 kilograms and divides 165 by 2.2 in their head will occasionally arrive at the wrong number. Use a tool. Document which tool. And verify the result.

Narrative-to-coded data. Source documents often contain narrative descriptions that must be translated into coded or categorized CRF entries. The investigator writes "mild erythema at the injection site, approximately 2 cm in diameter, resolved spontaneously within 48 hours" in the progress note. The CRF requires you to select a severity grade from a dropdown (Grade 1, Grade 2, Grade 3), a measurement in a numeric field, and a duration in days. This is not transcription in the strict sense -- it is interpretation. And interpretation requires that you understand the coding scheme well enough to apply it correctly.

The safest approach is to code from the CRF completion guideline, not from general medical knowledge. The guideline will define what constitutes Grade 1 versus Grade 2 for each type of reaction. If the source narrative does not map cleanly to the available codes -- if the description falls between two categories, or if the guideline does not address the specific finding -- flag it for the investigator. Do not guess. A coding error is harder to detect than a transcription error, because the coded value looks valid even when it is wrong.

Ambiguous source entries. Sometimes the source document itself is the problem. A handwritten "7" that could be a "1." A vital sign recorded without a unit. A date missing the year. A laboratory result with an unclear decimal point. When the source is ambiguous, you have exactly one acceptable response: clarify before entry. Go back to the person who created the source record. Ask them what they wrote. Have them initial the clarification. Then -- and only then -- transcribe the clarified value.

What you must never do is interpret an ambiguous source entry on your own and enter your interpretation as fact. If a handwritten number could be either 7 or 1, you do not get to choose which one it "probably" is. You do not get to enter the value that "makes more clinical sense." You clarify. Per ICH E6(R3) Section 2.12.6, the data reported to the sponsor must be consistent with the source records. You cannot be consistent with a source you cannot read.

Calculated values. Some CRF fields require calculated values derived from source data: body mass index calculated from height and weight, creatinine clearance calculated from serum creatinine using the Cockcroft-Gault formula, body surface area calculated from height and weight. These calculations introduce two layers of error risk: transcription error in the input values and calculation error in the arithmetic. When a CRF requires a calculated value, verify both the inputs and the output. Enter the source values first, perform the calculation using a validated tool (not mental arithmetic), and verify the calculated result against an independent calculation before entering it.

CRF correction procedures: when errors must be fixed

Despite the best methodology, errors will sometimes reach the CRF. A monitor identifies a discrepancy during source data verification. An edit check flags an implausible value. Your own self-review catches a transposition you missed on the first pass. When a CRF entry must be corrected, the correction itself must follow specific regulatory requirements -- requirements that differ in their mechanics between paper and electronic systems but share a single inviolable principle: the original entry must never be obscured or deleted.

ICH E6(R3) Section 2.12.6 states it directly: "Changes or corrections in the reported data should be traceable, should be explained (if necessary) and should not obscure the original entry." This is not a preference. It is a regulatory requirement rooted in data integrity: anyone reviewing the record at any point in the future must be able to see what was originally entered, what it was changed to, when, by whom, and why. An audit trail is not optional. It is the record of how the data evolved.

Paper CRF corrections. On a paper CRF, the correction procedure has been standardized for decades and admits no variation:

1. Draw a single line through the incorrect entry. The original value must remain legible beneath the line. Do not use white-out, correction tape, or heavy crosshatching that obscures the original.
2. Write the correct value near the crossed-out entry -- above it, below it, or beside it, depending on available space.
3. Initial the correction with your own initials (the person making the correction, not the investigator's initials unless the investigator is making the correction).
4. Date the correction with the date you are making the change, not the date of the original entry.
5. Provide a reason for the correction when the reason is not self-evident. "Transcription error -- source document shows 138" is sufficient. If the change reflects new information rather than an error correction, the reason must explain the basis for the change.

Every element is essential. A correction without a date cannot be placed in the timeline of the trial. A correction without initials cannot be attributed to the person who made it. A correction that obscures the original value destroys the audit trail. And a correction without a reason -- when the reason is not obvious -- leaves reviewers wondering whether the change was legitimate.

Electronic CRF corrections. In an electronic system, the mechanics are different but the principle is identical. When you modify a previously saved value in an EDC system, the system automatically captures several elements of the audit trail: the original value, the new value, the identity of the person making the change (your login credentials), and the date and time of the change. What the system cannot capture automatically is the reason for the change. That is your responsibility. When you modify a saved value, the system will prompt you to enter a reason for the change. This is not a formality to be dismissed with "corrected" or "changed." It is the explanatory component of the audit trail.

A good reason for change is specific and traceable: "Corrected per source document -- hemoglobin was 10.2 g/dL, not 102 g/dL (decimal point omitted during initial entry)." A poor reason is vague: "Data correction." The difference matters during audits and inspections, when a regulatory reviewer will examine the audit trail to determine whether changes to the data were legitimate corrections or inappropriate modifications.

When transcription errors have consequences

The methods described in this lesson -- read-transcribe-verify, heightened vigilance on high-risk elements, proper handling of challenges, disciplined correction procedures -- exist because transcription errors have consequences that extend far beyond a data query. A misplaced decimal can make an ineligible participant appear eligible. A transposed digit can mask a safety signal. A wrong date can place an adverse event outside the treatment window when it actually occurred during treatment.

The following case study illustrates what happens when a single digit transposition slips through -- not because the coordinator was careless, but because the verification step was skipped on a field that turned out to matter enormously.

This case study illustrates a principle that bears emphasis: the read-transcribe-verify method is not bureaucratic overhead. It is participant protection. A three-second verification -- looking back at the source to confirm that 25 was entered as 25, not 52 -- would have prevented every downstream consequence: the incorrect eligibility determination, the enrollment of an ineligible participant, the two doses of an investigational product administered to someone whose kidney function could not safely handle it, the protocol deviation, the IRB report, and the remedial actions.

The cost of the verify step is seconds per field. The cost of skipping it, even once, can be measured in participant safety, regulatory findings, and professional consequences.