The Cardinal Sin of Clinical SAS: Why You Never Fix Dirty EDC Data in a DATA Step

The 1926 Birth Year Temptation #

Imagine you are running the initial SDTM mapping program for the Demographics (DM) domain on an oncology Phase III trial. As you inspect your frequency outputs, you spot Subject ABC-101-042 with a recorded birth year of 1926.

The inclusion criteria for the protocol restrict enrollment to adults aged 18 to 65. The patient enrolled in 2024. If they were truly born in 1926, they would be 98 years old—a blatant protocol violation. But you look at the screening date and other lab records; clearly, the clinical research coordinator at the hospital site struck the wrong key: the patient was almost certainly born in 1996 (age 28).

To a junior programmer under pressure to deliver mock tables before the Friday project review, the solution seems trivial:

The log is clean. The tables compile without errors. The summary statistics look pristine. But you have just committed what biostatistical leadership calls the Cardinal Sin of Clinical SAS Programming.

The Regulatory Trap: 21 CFR Part 11 & ALCOA+ #

To understand why hardcoding fixes in SAS is unacceptable, you must look outside programming syntax and examine the legal framework governing clinical trials: Title 21 CFR Part 11 and ICH E6(R2) Good Clinical Practice (GCP).

Clinical data must adhere to the ALCOA+ framework:

• Attributable: Every single observation, change, and deletion must be unambiguously linked to an authenticated individual with the legal authority to enter it. A statistical programmer sitting at a CRO or sponsor desk has no legal standing to modify a patient's medical history.
• Legible & Traceable: There must be an unbroken audit trail demonstrating the original value, who changed it, the exact timestamp of the change, and the documented clinical reason for the revision.
• Contemporaneous: Changes must be documented at the moment they occur at the investigative clinical site.
• Original: The data in the regulatory submission must trace back to the primary source document (hospital electronic health record or paper clinic chart).
• Accurate: Accuracy is verified through investigator sign-off, not programmer guesswork.

When you execute that IF-THEN override in SAS, you break ALCOA+ completely. The source Electronic Data Capture (EDC) system still holds 1926-04-12. The clinical site knows nothing about your change. The Principal Investigator never signed off on it. You have created an unverified phantom record that exists only in your SAS work session.

The Anatomy of an Inspection Finding #

How does this actually get caught? Regulators do not just read summary reports; inspectors examine clinical trial sites and sponsor headquarters during audits.

Inspectors pull a random sample of enrolled subjects from the submitted DM.xpt dataset. They pull the hospital medical records for Subject ABC-101-042. Then they pull the EDC electronic audit log from Medidata Rave or Veeva EDC.

The inspector compares them:

Inspectors ask the Lead Biostatistician: "Who authorized the alteration of this patient's date of birth in the submission dataset, and where is the documented audit trail?"

The answer is found buried in line 84 of an unvalidated SAS mapping script. That finding produces an immediate formal inspection citation citing failure to maintain adequate and accurate case histories (21 CFR 312.62) and failure to maintain secure, computer-generated, time-stamped audit trails (21 CFR 11.10(e)). In severe cases, it calls into question the integrity of the entire safety database.

The Compliant 4-Step Query Loop #

If you cannot fix dirty data in SAS, what is the professional responsibility of a clinical programmer when anomalies arise?

You execute the Compliant Data Quality Check (DQC) Query Loop:

1. Step 1: Write Automated DQC Validation Macros: Programmers build standardized discrepancy macros that screen raw EDC tables for biological impossibilities, chronological conflicts (e.g. AE start date prior to informed consent), and protocol violations.
2. Step 2: Generate Query Listings for CDM: The program outputs a formatted spreadsheet or discrepancy report containing the USUBJID, visit, form name, variable name, current raw value, and detailed discrepancy rationale.
3. Step 3: Clinical Data Management Issues Site Query: The CDM coordinator reviews the listing and issues a formal electronic query in the EDC system (e.g. Medidata Rave). The investigative site coordinator pulls the hospital paper chart, confirms the typographical error, enters the correct value (1996-04-12), and provides a documented reason for change ("Typographical error corrected per source medical records"). The Principal Investigator re-signs the eCRF.
4. Step 4: Clean Export Streams to SDTM: In the next raw EDC database extract, the corrected data streams into SAS naturally. The SDTM mapping script maps the cleaned field directly to BRTHDTC with zero manual intervention.

Production SAS DQC Macro Example #

Here is how senior biostatistical teams handle discrepancies cleanly and reproducibly:

Allowed Transformations vs. Prohibited Overrides #

Does this mean you can never transform data in a SAS DATA step? Of course not. The critical distinction is between standardized transformations (governed by CDISC Implementation Guides) and unauthorized clinical overrides.

Define-XML 2.0 Origin Implications #

Every dataset in a modern FDA submission package is accompanied by a machine-readable data definition file: Define-XML 2.0.

For every single variable in an SDTM domain, the sponsor must explicitly declare the Origin attribute:

• Origin="eCRF": Collected directly on the electronic Case Report Form by site staff.
• Origin="Derived": Calculated programmatically via a mathematical or algorithmic rule specified in the metadata.
• Origin="Assigned": Populated by static sponsor rules (e.g. STUDYID or DOMAIN).
• Origin="Predecessor": Directly copied from an existing variable in another domain (e.g. DM.RFSTDTC copied into ADSL.TRTSDTM).

When you submit SDTM DM.BRTHDTC, its declared Origin is eCRF. If an agency validator inspects the submitted SAS Transport (.xpt) file against the raw EDC transfer and discovers you altered the birth year via hardcode, your Define-XML metadata is legally fraudulent.

Summary: Protect the Audit Trail at All Costs #

Clinical SAS programming is not web development where you hotfix bugs directly in production code. You are participating in a legal, regulatory, and ethical chain of custody designed to protect human clinical trial participants and ensure drug efficacy.

Next time you see an obvious typo in an EDC dataset:

• Do not touch it in your DATA step.
• Write an automated discrepancy check.
• Deliver the query listing to Clinical Data Management.
• Let the investigator fix the source audit log.