EHR to EDC: how a graded adverse event gets from the clinical note to the trial database

EHR to EDC is the path an adverse event observation takes from the electronic health record to the electronic data capture system. The clinician documents it in the EHR; it becomes a case report form entry in the EDC. Labs and vital signs can travel that path field by field, but an adverse event's term, grade, dates, seriousness and attribution are judgments read from a narrative note, so its EDC entry holds up only when the evidence for each judgment travels with it.

For a contract research organization, this path sets the cost to deliver. A sponsor benchmarks bids on what a clean, locked database costs, and every adverse event entry without its support can come back as a query.

What does EHR to EDC mean in clinical trials?

The EHR belongs to the hospital. In a clinical trial, the EDC system belongs to the study and collects data in electronic case report forms (eCRFs) built to the protocol.

One stated goal of FDA's July 2018 guidance, Use of Electronic Health Record Data in Clinical Investigations, is to "promote the interoperability of EHR and EDC systems." Its section IV describes three levels of connection:

Level	How data moves	Where an adverse event fits
Noninteroperable	Staff transcribe data elements from the EHR into the eCRF by hand	A person reads the note, decides and keys the result
Interoperable	Demographics, vital signs, laboratory data and medications populate eCRF fields electronically	The lab value moves; grade, attribution and dates still need a reader
Fully integrated	Investigators enter research data directly in the EHR	The entry point moves; the judgment stays the same

For an EHR to EDC integration, the guidance asks that data exchange use existing open data standards where possible. Two in common use are HL7 FHIR, for exchanging health record data, and CDISC's CDASH standard, which names the fields a case report form collects.

FDA encourages exchange of structured data, such as demographics, vital signs and laboratory data, so it is entered once and used many times without manual re-entry. For unstructured data, sponsors "should consider the reliability and quality of unstructured EHR data." Adverse events live in the unstructured part.

Why can't an adverse event move from EHR to EDC field by field?

A lab result is one value in one field. An adverse event is a set of decisions: which CTCAE term describes it, which grade its criterion supports, when it started and stopped, whether it is serious, and how it relates to each drug in the regimen. The answers sit in prose: progress notes, nursing notes, a phone call documented days later.

Two published studies show how much the reading itself varies:

• Two observers reviewed the same records of patients on immune checkpoint inhibitors. They showed limited or poor agreement on whether most immune-related adverse events had occurred and on their grade, and their onset dates differed by 5 to 188 days. Agreement on treatment dates was near complete, so the authors attribute the gap largely to interpretation (Hsiehchen et al., JAMA Network Open, 2019).
• A recurring adverse event's attribution changes between visits for the same patient in 31 to 36% of cases (Hillman et al., Journal of Clinical Oncology, 2010; see adverse event attribution and the drug label).

An interface carries whatever the reader decided, so agreement has to be reached at the note.

How does an adverse event get filed, step by step?

1. Documentation. The clinician's EHR note is source.
2. Term. Someone reads the note, recognizes the event and selects the term in the CTCAE version the protocol names. NCI publishes CTCAE v5.0 (2017, MedDRA 20.1) and v6.0 (2025, MedDRA 28.0) (NCI CTEP). v5.0 has 837 terms and v6.0 has 850.
3. Grade. The grade is assigned against that term's criterion text.
4. Seriousness. Seriousness follows the outcome-based definition in 21 CFR 312.32(a): death, a life-threatening adverse event, inpatient hospitalization and the other listed outcomes. It is assessed separately from grade, so a Grade 3 event can be non-serious and a Grade 2 event can be serious.
5. Attribution. The investigator assesses the relationship to each suspect drug. For a serious adverse event, 21 CFR 312.64(b) requires an immediate report to the sponsor that includes "an assessment of whether there is a reasonable possibility that the drug caused the event."
6. Entry. A coordinator keys the result into the eCRF adverse event log.
7. Review. A monitor compares the eCRF with source and raises a query wherever the two do not reconcile or the entry lacks support.
8. Sign-off. The investigator reviews and electronically signs the completed eCRF, which the 2018 guidance (section V.C) asks for before data are archived or submitted to FDA. A change after signing should be reviewed and approved by the investigator. Under section V.C.2, a corrected entry carries the date, time, data originator and reason, and should "not obscure previous entries."
9. Reconciliation. Before database lock, serious adverse events in the clinical database are reconciled against the sponsor's safety database, a step covered in SAE reconciliation between the safety and clinical databases.

Where does rework on an adverse event entry happen?

Three places, in the order they arrive:

• Re-entry. Reading the note, grading and keying the result.
• The query round trip. A query is a request for the reasoning behind an entry. Each one crosses from monitor to site and back, and an entry that carries its support gives the monitor less to ask about.
• Reconciliation at lock. Discrepancies left open during conduct are resolved under deadline, about events that may be months old.

The ICH E6(R3) guideline, adopted January 6, 2025, asks that "unnecessary transcription steps between the source record and the data acquisition tool" be avoided (section 2.12.2). It also asks that data reported to the sponsor be "consistent with the source records or the discrepancies explained" (2.12.6).

What should travel with the grade into the EDC?

Each study builds its own eCRF. Most adverse event logs collect the fields that CDISC's CDASH implementation guide (CDASHIG v2.1) names for the AE domain:

AE log field	CDASH variable	Support that should travel with it
Adverse event term	AETERM	The sentence in the note that describes the event
MedDRA code	Coded from AETERM, not collected	The CTCAE term, which is itself a MedDRA LLT
Start date	AESTDAT	The dated passage, with any relative date resolved against the note's date
End date or ongoing	AEENDAT, AEONGO	The passage recording resolution, or its absence
CTCAE grade	AETOXGR	The criterion text the grade meets
Serious	AESER	The outcome that makes it serious, assessed separately from grade
Causality	AEREL	The working for each suspect drug
Action taken with study treatment	AEACN	The investigator's decision about the regimen
Outcome	AEOUT	The passage that records it

A worked example: one adverse event, note to AE log

A synthetic patient on a CTCAE v6.0 protocol receives investigational drug A (last dose 12 February) and carboplatin (last dose 19 February). A progress note dated Thursday 5 March reads: "Dry cough and breathlessness on exertion since Tuesday. Has stopped shopping and cooking; washing and dressing independently. Oxygen saturation normal on room air; no oxygen given. CT: new ground-glass opacities. Impression: pneumonitis. Admitted for IV steroids and observation."

The term is Pneumonitis. Its v6.0 Grade 2 criterion reads: "Symptomatic; medical intervention indicated; limiting instrumental ADL or mild/moderate impact on age-appropriate normal daily activity (pediatric)." Grade 3 reads: "Severe symptoms; oxygen indicated; limiting self-care ADL or severe impact on age-appropriate normal daily activity (pediatric)." In CTCAE, a semicolon means "or", so any one Grade 3 condition is enough. CTCAE lists shopping and preparing meals as instrumental ADL, and bathing and dressing as self-care ADL.

AE log field	Value	Supporting text
AETERM	Pneumonitis	"Impression: pneumonitis"; "new ground-glass opacities"
MedDRA LLT	10035742	The CTCAE v6.0 term Pneumonitis
AESTDAT	03-MAR-2026	"since Tuesday", read against the 5 March note date
AEONGO	Yes	No resolution recorded
AETOXGR	2	Symptoms; IV steroids started; shopping and cooking stopped; no oxygen; washing and dressing intact
AESER	Yes	Inpatient hospitalization, an outcome under 21 CFR 312.32(a)
AEREL	One assessment per drug	Onset 19 days after the last dose of drug A and 12 days after carboplatin; alternative causes the record does or does not exclude
AEACN	The investigator's decision	Not in the note; supplied by the coordinator
AEOUT	Not recovered/not resolved	No resolution recorded at this note

The start date is where two readers' onset dates diverge. "Since Tuesday" means 3 March only when it is read against the note's own date; read against the admission or a later note, it files a different date. The note also separates the two judgments the AE log keeps apart: the criterion supports Grade 2, and the admission makes the event serious.

How Burna AI files a graded adverse event into Medidata Rave

Burna AI reads the note, imported from Epic or Oracle Health through SMART on FHIR, and grades every adverse event against the protocol's CTCAE version, v5.0 or v6.0, on one engine. Each event is scored for attribution against every drug in the regimen using WHO-UMC and Kramer. Every grade traces to the line in the medical record that produced it.

A grade becomes a record when a qualified investigator signs it with a 21 CFR Part 11 electronic signature. The signature records what was accepted, what was overridden and the citations. AI suggests, clinicians decide. Human-in-the-loop, always.

Filing into the EDC is a separate step the coordinator confirms:

1. The graded event is mapped onto the study's Rave AE log form. The grading supplies the term, MedDRA code, dates, ongoing status, grade, seriousness, a causality category and the outcome where the note states it. Action taken with study drug comes from the coordinator. A required field with no value stops the filing before anything is entered.
2. The coordinator reviews a preview of every field, marked by whether it came from the grading or from them, and signs the exact content previewed. Content changed after signing is refused.
3. The filing runs in a browser session the coordinator can watch and take control of.
4. After submission, the form is read back and compared with what was signed. A filing counts as complete when the read-back matches, never on the EDC's acknowledgement alone.
5. A retry after a timeout finds the earlier filing instead of creating a second entry, and a correction is filed as an amendment that references the original.

EDC filing is enabled for Medidata Rave, switched on for each organization. Graded output also writes back to the medical record: through Oracle Health's FHIR interface, and through Epic's where a site has approved write access. Medical record integration in both directions is listed in Burna AI's public capability record.

How do you keep adverse event grading consistent across sites?

Cross-site consistency starts from a modest baseline: two reviewers identifying CTCAE adverse events in the same 100 notes agreed at kappa 0.59 to 0.68 (Fairchild et al., 2020). When each AE log entry names its CTCAE version and its cited sentence, a grade difference between sites can be checked against the version first and the evidence second. During a v5.0 to v6.0 transition, two sites can each grade correctly against different criteria; running both CTCAE versions in one trial covers that case.

Questions to ask any EHR-to-EDC tool

1. Which fields arrive in the EDC with the grade, and does the source sentence travel with them?
2. How is a filing confirmed: by the EDC's acknowledgement, or by reading the form back?
3. How is a correction after sign-off filed: as an amendment that references the original entry, with the date, time, originator and reason recorded, or as an overwrite?
4. Which EDCs and EHRs can it file into today, and which are planned?

EHR to EDC: frequently asked questions

What is the difference between an EHR and an EDC?

The EHR is the hospital's record of care, written by clinicians for treating the patient. The EDC is the study's system, collecting eCRF data built to the protocol for the sponsor's analysis. FDA's 2018 guidance treats the connection between them as a matter of interoperability.

Is EHR to EDC the same as eSource?

They overlap. FDA's Electronic Source Data in Clinical Investigations guidance (2013) defines electronic source data as "data initially recorded in electronic format," and it describes direct transmission of data elements from the EHR to the eCRF as one way data reach an eCRF. eSource names where the data were first recorded; EHR to EDC names the path they take to the study.

Does 21 CFR Part 11 apply to an EHR-to-EDC integration?

To the EDC side, yes. FDA's 2018 guidance states that it "does not intend to assess EHR systems for compliance with 21 CFR part 11," but that Part 11 "applies to the sponsor's EDC system that extracts the EHR data."

Can Burna AI file into Veeva Vault EDC?

Burna AI files adverse events directly into Medidata Rave. For any other EDC, including Veeva Vault EDC, the graded record exports for entry. More in how Burna AI differs from an EDC vendor.

Pricing the adverse event workstream on a multi-site oncology bid? Book a 15-minute conversation.