eCRF Electronic Signature Requirements Under Part 11

An eCRF electronic signature under 21 CFR Part 11 is not just a signature on a completed form. It sits on top of a data model FDA built around the eCRF itself, one where every field is associated with a named "data originator" before the investigator's signature ever gets applied. Part 11 will not tell you that. Read the regulation end to end and the words "eCRF," "case history," "investigator" and "data element" appear nowhere in it.

That model comes from a specific FDA guidance document: the September 2013 Electronic Source Data in Clinical Investigations, a guidance for industry issued jointly by CDER, CBER and CDRH. It is still live authority. FDA's October 2024 final guidance Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers cites it in six footnotes, lists it in its references, and adopts its definitions of "data originator" and "data element identifier" verbatim by reference. This post works through what the 2013 guidance says about eCRFs, where the investigator's Part 11 signature requirement comes from, what the 2024 guidance adds, and what an EDC system's audit trail has to capture to support it.

What FDA Actually Means by "eCRF"

The 2013 guidance's own glossary defines the term precisely: "Electronic Case Report Form (eCRF): An auditable electronic record of information that generally is reported to the sponsor on each trial subject, according to a clinical investigation protocol. The eCRF enables clinical investigation data to be systematically captured, reviewed, managed, stored, analyzed, and reported." Earlier in the same document, FDA states plainly: "FDA regulations define an electronic record as any combination of text, graphics, data, audio, pictorial, or other information represented in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system. An eCRF is an example of an electronic record."

That last sentence is the whole reason Part 11 is in scope at all. An eCRF isn't a special category exempt from Part 11's electronic record and signature controls; it's a named example of the thing Part 11 regulates.

The Data Originator Concept: Five Ways Data Gets Into an eCRF

Before FDA gets to the signature requirement, the guidance devotes its longest section to where eCRF data comes from, because that determines what the audit trail has to capture. Section III.A, "Data Capture," is 46 percent of the guidance body, more than three times the next-largest section. It states that "a data element in an eCRF represents the smallest unit of observation captured for a subject in a clinical investigation," and that "each data element is associated with an authorized data originator," which the glossary describes as "a person, a computer system, a device, or an instrument that is authorized to enter, change, or transmit data elements into the eCRF."

The guidance walks through five distinct capture paths, and each one assigns the "source" designation differently:

• Direct entry. A coordinator enters a subject's blood pressure directly into the eCRF at the visit. Here "the eCRF is the source," and the person entering it is the originator. If a paper transcription step is used first, "the paper documentation should be retained and made available for FDA inspection."
• Automatic transmission from a device or instrument. A blood pressure monitor or glucometer transmits a reading straight to the eCRF, and "the eCRF is the source," with the device as originator. The guidance's worked example is an ECG machine: "if an ECG machine automatically transmits to the eCRF, a data element identifier should be generated that identifies the ECG machine as the originator." Read the next sentence too, because it is the common real-world topology: "If a process is used by which the device or instrument transmits data automatically to, for example, an electronic health record system or to a service provider's database, then the EHR or the service provider's database is the source." Device to vendor cloud to EDC does not make the eCRF the source.
• Transcription from a paper or electronic source. A coordinator copies a value from a lab printout or a nurse's note into the eCRF. Here "the authorized person transcribing the data from the source documents is regarded as the data originator," and the underlying paper or electronic document, not the eCRF, is the source that must be retained and made available for FDA review.
• Direct transmission from an electronic health record. Because an EHR "can use intervening processes (e.g., algorithms for the selection of the appropriate data elements)," the guidance treats the EHR itself as the source, distinct from a device transmitting a raw reading. The data does not fall out of scope: "the pertinent data for the subjects in the clinical study should be made available for review during an FDA inspection."
• Patient-reported outcome (PRO) instruments. When a subject enters data directly into a PRO tool that transmits to the eCRF, "the subject is the data originator and the eCRF is the source." Same carve-out as the device path: "If a process is used by which the subject uses the instrument to transmit data to a technology service provider database, the service provider database is the source."

This matters for an EDC platform's audit trail design because "source" and "originator" aren't interchangeable labels; they determine what has to be retrievable during an inspection. If data is transcribed, the paper or electronic source document has to be retained separately and produced on request. If data is captured directly in the eCRF, the eCRF is the source, but that is not the end of what can be asked for: "when pertinent supportive information is available, FDA could request other documents during an inspection to corroborate a direct entry of source data elements into the eCRF." The guidance's example is a diagnosis entered at an initial visit, where "a record may be requested for evidence of testing or the use of medications to corroborate a diagnosis."

Data Element Identifiers: What Has to Travel With Every Field

The guidance says a data element identifier "should be attached to each data element as it is entered or transmitted by the originator into the eCRF," and that it should contain "originators of the data element," "date and time the data element was entered into the eCRF (the audit trail begins at the time the data are transmitted to the eCRF)," and "clinical investigation subjects to which the data element belongs." The glossary adds the one requirement in this set that is trivially checkable in a demo: "Once set by the computerized system, this value should not be alterable in any way." FDA's 2024 guidance quotes that definition back verbatim, so it is current, not a 2013 artifact.

The identifier is not itself the audit trail. It is what makes the audit trail legible, and the guidance says so: "These data element identifiers will allow sponsors, FDA, and other authorized parties to examine the audit trail of the eCRF data... and this audit trail should be readily available in a human readable form."

The modification rule is stated as a "must," footnoted to the general Part 11 audit trail provision: "Modified and/or corrected data elements must have data element identifiers that reflect the date, time, originator and reason for the change, and must not obscure previous entries." It is worth separating what the cited provision actually contains. 21 CFR 11.10(e) requires "use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records," and that "record changes shall not obscure previously recorded information." What the provision names as recorded is the date and time; it reaches operator entries and actions, and forbids obscuring. Who made the change and why both come from FDA reading that provision, not from its words, and FDA treats the two differently. FDA's 2024 guidance keeps that split explicit: audit trail components "must include" the date and time, "the individual making the change," and "the old value and the new value," while "the audit trail should include the reason for the change if applicable."

On who may make a correction, the guidance recommends rather than restricts: "only a clinical investigator(s) or delegated clinical study staff should perform modifications or corrections to eCRF data," and "a field should be provided allowing originators to describe the reason for the change." During investigator review it is looser still, and this surprises people: "either the clinical investigator(s) or an originator can enter the revised data element." That is the same original-value-preservation pattern we cover in more general terms in our guide to Part 11 audit trail requirements, applied here to a specific record type with its own named data-integrity vocabulary.

The Signature Requirement: A Guidance "Should" Resting on a Binding Predicate Rule

This is the part that actually pulls Part 11 into an eCRF workflow. The guidance states: "To comply with the requirement to maintain accurate case histories clinical investigator(s) should review and electronically sign the completed eCRF for each subject before the data are archived or submitted to FDA. Use of electronic signatures must comply with part 11 (21 CFR part 11)."

Two things worth separating in that sentence. "Should review and electronically sign" is guidance language; FDA's own boilerplate at the front of the document says "the use of the word should in Agency guidances means that something is suggested or recommended, but not required." The binding piece is the thing the recommendation is there to satisfy: "the requirement to maintain accurate case histories," which the guidance footnotes to "21 CFR 312.62(b) and 812.140(a)(3)." Those are predicate rules, not guidance. 312.62(b) covers drug and biologic trials and says plainly: "An investigator is required to prepare and maintain adequate and accurate case histories that record all observations and other data pertinent to the investigation on each individual administered the investigational drug or employed as a control in the investigation. Case histories include the case report forms and supporting data..."

Cite the device rule too, or half the audience gets the wrong instrument. The 2013 guidance is a CDER, CBER and CDRH document, and an investigator working under an IDE has no 312.62(b) duty at all. The parallel requirement is 21 CFR 812.140(a)(3), which obliges a participating investigator to maintain "records of each subject's case history and exposure to the device," and then uses nearly the same sentence: "Case histories include the case report forms and supporting data..." FDA's 2024 guidance pairs the two rule sets the same way.

The Part 11 link is not an inference. The guidance states it in the same breath as the recommendation: "use of electronic signatures must comply with part 11." The review step being non-binding does not make the signature non-binding once you choose to execute it electronically.

The guidance also addresses masking. Not every field needs investigator review before signature: "Under certain circumstances, the clinical investigator(s) can be masked to specific data in the eCRF," giving a blinded urine osmolality result as an example, and recommends listing any data exempt from review in a data management plan.

What the Signature Itself Has to Show

Once Part 11 is in scope, the eCRF signature has to meet the record-side signature provisions in Part 11's Subpart B. 21 CFR 11.50 requires that signed electronic records show, in any human-readable form including displays and printouts, "the printed name of the signer," "the date and time when the signature was executed," and "the meaning (such as review, approval, responsibility, or authorship) associated with the signature." For an eCRF, that manifestation has to make clear the signature is the investigator's review-and-attestation act, not just a save action or a completion checkbox.

21 CFR 11.70 adds the linking requirement: "Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means." Be precise about what that provision is. It is an anti-transfer rule, so a signature cannot be lifted off one record and reattached to another. It prescribes no particular technical method, and it says nothing about record versions. FDA's 2024 guidance is explicit on the method point: "part 11 regulations do not specify a particular method to create a valid electronic signature."

What answers the post-signature question is the audit trail, and FDA said so directly in 2024: "Any changes made to the record, including those subsequent to the electronic signature, must be reflected in the audit trail," footnoted to 21 CFR 11.10(e) and 11.30. An edit after signing does not quietly inherit the earlier attestation, because the change itself has to be on the record.

There is a second half of Part 11 the eCRF discussion usually skips. The guidance's footnote on the review-and-sign sentence points to it: "See the ICH E6 guidance; see also 21 CFR part 11, subpart C." Subpart C is the signature side. 11.100(a) requires each electronic signature to be "unique to one individual" and that it "shall not be reused by, or reassigned to, anyone else." 11.200(a)(1) requires non-biometric signatures to "employ at least two distinct identification components such as an identification code and password." 11.200(a)(1)(i) is the detail worth knowing before you write a requirement into an RFP: within "a single, continuous period of controlled system access," the first signing uses all components, and "subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual."

Changes After Signing: A New Signature, Not a Patch

The guidance's instruction is short: "If changes are made to the eCRF after the clinical investigator(s) has already signed, the changes should be reviewed and electronically signed by the clinical investigator(s)." That is a recommendation. The binding demand is the one above: 11.10(e) requires the change to land in a secure, computer-generated, time-stamped audit trail that records the date and time of the operator's action and does not obscure the previous entry, regardless of who made it. A reason-for-change field is a guidance recommendation sitting on top of that, not part of the binding set. An EDC system that takes a post-signature edit with no audit trail entry and no route back for investigator review is not following the model FDA laid out, whether the change comes from the investigator's own review, a query resolution, or a delegated staff member's correction.

The EHR Boundary: What FDA Says It Will Not Assess

The 2013 guidance draws a line that matters for anyone evaluating an EDC vendor against a source EHR integration: "The determination of whether a computer system used in a clinical investigation is suitable for its intended purpose might not be under the control of the clinical investigator(s) or sponsor (e.g., EHRs). The performance standards for these computer systems may be regulated by other authorities and under the control of, for example, healthcare providers or institutions. FDA does not intend to assess the compliance of EHRs with part 11."

Read that as what it says. It is a statement about what FDA will assess, not a declaration that EHR-sourced data escapes scrutiny. On the data the guidance says the opposite: where the EHR is the source, "the pertinent data for the subjects in the clinical study should be made available for review during an FDA inspection." The practical effect is that your Part 11 evidence burden lands on the eCRF and the signature on it, while the upstream EHR's own validation is somebody else's obligation. We cover the parallel boundary question for a different data flow, monitor access to source records, in our guide to remote monitoring and electronic records.

An EDC Vendor Checklist Specific to eCRF Signature Requirements

A general Part 11 vendor checklist covers audit trails, unique credentials, and signature meaning at a platform level. For an EDC system specifically, ask:

• Does every data element carry a data element identifier showing its originator, entry date/time, and subject, and is that identifier non-alterable once the system sets it, as FDA's definition says it should be?
• Can the system distinguish, for each field, whether the eCRF itself is the source (direct entry, device transmission straight to the eCRF) or whether something upstream is the source (transcription, EHR feed, device or PRO data routed through a vendor database), and does it flag which fields require a retained source document?
• Does the investigator's electronic signature on the completed eCRF display printed name, date/time, and signature meaning per 21 CFR 11.50, and is it linked to its record so it cannot be excised, copied, or transferred, per 21 CFR 11.70?
• Does a post-signature edit land in the audit trail? FDA's 2024 guidance says changes made after the electronic signature "must be reflected in the audit trail," and footnotes that to 21 CFR 11.10(e) and 11.30, so the audit trail entry is the part the regulation carries. Separately, does the system route the changed subject record back for a fresh investigator review and signature? The 2013 guidance states that step as a "should," a guidance recommendation rather than a regulatory requirement.
• Are data elements exempt from investigator review (blinded fields) listed in the data management plan as the guidance recommends, and, going a step further than the guidance asks, enforced in the system configuration rather than only on paper?
• Can the system hold and surface the sponsor's list of authorized data originators, including devices and instruments, at each clinical site? The guidance assigns that list to the sponsor, not the vendor, so the question is whether the platform can carry it, not whether it will author it.

None of these are answerable from a vendor's marketing page. They come out of the EDC vendor's own validation and design documentation, the kind of evidence a qualification assessment is built to surface before a study goes live, which we cover in general terms in our guide to clinical trial vendor qualification and in our e-signature vendor evaluation checklist.

Where This Leaves the Signature Layer

Klyverity doesn't run your EDC, build your eCRF forms, or decide what counts as a significant deviation for query resolution. That belongs to the EDC platform and your data management plan. What Klyverity secures is the signature act itself, once a subject's eCRF is ready for investigator sign-off. Two-component authentication at the point of signing. A signature manifestation showing who signed, when, and what the signature meant. A record link that ties the signature to the data it covers, with the change history visible, so a later edit can't quietly ride on an earlier attestation.

We cover the broader clinical trial signature landscape, site coordinator, sponsor, and CRO responsibilities, in our guide to electronic signatures in clinical trials. If you're evaluating how that signature layer fits alongside an EDC system you already run, talk to us.

FAQ

What is an eCRF under FDA's own definition?

FDA's 2013 guidance defines it as "an auditable electronic record of information that generally is reported to the sponsor on each trial subject, according to a clinical investigation protocol," and separately confirms "an eCRF is an example of an electronic record" under FDA's Part 11 definition, which is why Part 11 applies to it.

Is FDA's investigator sign-off recommendation for eCRFs mandatory or just a guidance recommendation?

The specific step "clinical investigator(s) should review and electronically sign the completed eCRF" is phrased as a recommendation in FDA guidance, using "should." But it exists to satisfy binding predicate rules, which the guidance footnotes as "21 CFR 312.62(b) and 812.140(a)(3)": drug and biologic investigators must "prepare and maintain adequate and accurate case histories," device investigators must keep "records of each subject's case history," and both rules state that case histories "include the case report forms and supporting data..." Once a signature happens electronically to satisfy that requirement, the guidance says "use of electronic signatures must comply with part 11."

What is a "data originator" and why does it matter for eCRF audit trails?

A data originator is the person, computer system, device, or instrument authorized to enter, change, or transmit a specific data element into the eCRF. FDA's guidance says a data element identifier recording the originator, entry date and time, and the subject it belongs to "should be attached to each data element," so that sponsors, FDA, and other authorized parties can examine the audit trail of the eCRF data.

What happens if an eCRF is changed after the investigator has already signed it?

FDA's 2013 guidance states the change "should be reviewed and electronically signed by the clinical investigator(s)" again. On the record side, FDA's October 2024 guidance is firmer: "Any changes made to the record, including those subsequent to the electronic signature, must be reflected in the audit trail." A signature that covered the earlier data does not quietly extend to a later edit, because the edit itself has to be visible in the audit trail.

Does Part 11 apply to the electronic health record feeding data into an eCRF?

FDA's 2013 guidance states "FDA does not intend to assess the compliance of EHRs with part 11," because EHR performance standards may be regulated by other authorities and controlled by healthcare providers or institutions. That is a statement about what FDA will assess, not a blanket exemption for the data: where the EHR is the source, the guidance says the pertinent study data "should be made available for review during an FDA inspection." Your Part 11 evidence burden sits on the eCRF and the signature on it.