EDC Raw Data vs. SDTM Traceability: The "No Hardcoding" Rule & 21 CFR Part 11
Why you never fix dirty EDC clinical data in a SAS DATA step, and how data queries preserve ALCOA+ audit trails.
In clinical trials, raw Electronic Data Capture (EDC) data represents the legally binding clinical trial record electronically signed by the Principal Investigator. Under 21 CFR Part 11 and ICH E6(R2) ALCOA+ standards, statistical programmers are strictly prohibited from hardcoding clinical corrections (such as fixing obvious date typos, imputing values, or modifying verbatim adverse event terms) inside a SAS DATA step. All data anomalies must be resolved at the source through Clinical Data Management (CDM) electronic queries. The resulting SDTM datasets must maintain an unbroken, transparent 1-to-1 or 1-to-many lineage back to the raw eCRF audit trail.
Why Source Data Lineage & Audit Trails Matter in Regulatory Submissions #
When an EDC clinical dataset contains errors—such as an adverse event start date recorded as year 1926 or a visit date following patient discontinuation—the immediate instinct of an untrained programmer is to patch it with an in-memory IF-THEN statement. In regulated biostatistics under 21 CFR Part 11 and ICH E6(R2), this is a critical compliance violation. A statistical programmer cannot attest to clinical truth. Hardcoding fixes in SAS creates an unverified bifurcation between the hospital medical chart and the regulatory submission dataset, directly exposing the sponsor to critical regulatory inspection citations. Maintaining an unbroken, auditable lineage from raw EDC exports through SDTM mappings ensures every submitted data point is attributable, reproducible, and legally defensible.
Standard Syntax, Derivation & Framework Pattern #
/* ==============================================================
COMPLIANT WORKFLOW: Automated Data Quality Check (DQC) Macro
Never patch raw data with IF-THEN hardcoding in SDTM mapping.
Instead, flag discrepancies for formal CDM site queries.
============================================================== */
/* Step 1: Automated Rule Detection (Flagging Date Discrepancies) */
PROC SQL;
CREATE TABLE work.dqc_ae_future_dates AS
SELECT
raw.USUBJID,
raw.AESEQ,
raw.AETERM,
raw.AESTDTC AS RAW_AESTDTC,
dm.RFSTDTC AS STUDY_START_DTC,
'AE Start Date is prior to Year 2000 or after Visit Date' AS QUERY_REASON
FROM raw.edc_ae AS raw
INNER JOIN raw.edc_dm AS dm
ON raw.USUBJID = dm.USUBJID
WHERE INPUT(SUBSTR(raw.AESTDTC, 1, 4), 4.) < 2000
OR raw.AESTDTC > PUT(TODAY(), E8601DA.);
QUIT;
/* Step 2: Route Findings to Data Management (No In-Memory Fixes!) */
/* CDM issues EDC query -> Site PI reviews chart -> Site updates EDC.
When the next clean EDC batch exports, map directly to SDTM: */
DATA sdtm.ae;
SET raw.edc_ae;
DOMAIN = 'AE';
/* Valid Transformation: Mapping Raw CRF fields to CDISC Variables */
AETERM = STRIP(AETERM);
AESTDTC = STRIP(AESTDTC);
/* In define.xml, Origin is documented as: eCRF */
RUN;Core Rules #
- The 'No Hardcoding' Rule: Never write hardcoded conditional statements modifying patient clinical records in SAS (e.g. IF USUBJID='...' THEN AESTDTC='...').
- ALCOA+ Compliance: Clinical trial data must be Attributable, Legible, Contemporaneous, Original, and Accurate. Only the site investigator can authorize record changes.
- Inspection Risk: Inspectors compare submitted TLF outputs against hospital medical charts; undocumented in-memory code modifications trigger critical regulatory citations.
- Define-XML Metadata Lineage: Every variable in SDTM must declare its exact Origin (eCRF, Derived, Assigned, Predecessor). Secret in-memory overrides invalidate submission metadata.
- The CDM Loop: SAS programmers write automated Data Quality Checks (DQCs); Clinical Data Managers (CDMs) issue queries; site coordinators correct the EDC audit trail.
How 21 CFR Part 11, ICH E6(R2), and regulatory inspections mandate query resolution over in-memory code patches.
Frequently Asked Questions (FAQ) #
What is the 'No Hardcoding' rule in Clinical SAS programming?
The 'No Hardcoding' rule is an industry and regulatory mandate prohibiting programmers from altering clinical data points (such as dates, dosages, or adverse events) directly in SAS code. All corrections must be formally queried in the EDC system and amended by the investigative site to maintain 21 CFR Part 11 audit trails.
Why can't a SAS programmer fix an obvious typo like birth year 1926 instead of 1996?
Even for obvious typos, a programmer cannot independently assume clinical truth. Under GCP and 21 CFR Part 11, altering data without documented investigator sign-off creates an unverified electronic record. Inspectors will flag the discrepancy between the site chart and submission data as a major compliance failure.
What should a Clinical SAS programmer do when dirty EDC data is discovered?
The programmer writes an automated discrepancy check (Data Quality Check / DQC script) that outputs a query listing containing the USUBJID, visit, variable, and specific issue. This listing is delivered to Clinical Data Management (CDM), who issues a formal query in the EDC system for site resolution.
Where can I read the full technical walkthrough on EDC audits and SDTM traceability?
Read our in-depth companion article: The Cardinal Sin of Clinical SAS: Why You Never Fix Dirty EDC Data in a DATA Step.
Want complete video breakdowns, code files & exercises?
Explore comprehensive step-by-step masterclass training in our authoritative Clinical SAS Programming Course & CDISC Training.