Key Takeaways:

• FDA evaluates EDC systems during inspection, not before. It doesn’t certify or pre-approve trial systems, and its October 2024 guidance on electronic systems in clinical investigations, which replaced its 2007 computerized systems guidance, is now the main reference for applying Part 11 to clinical research.
• Validation and audit trails have to cover your actual study. FDA expects risk-based validation of protocol-specific configurations, integrations, and data transfers, plus audit trails that record who changed what, when, the old and new values, and the reason.
• Plan for amendments from day one. 76% of protocols now have at least one substantial amendment, and sites run on different protocol versions for an average of 215 days, so protocol versioning belongs in the data model.

If you’re an innovation director at a pharma company, a digital health VP at a CRO, or a research technology lead at an academic medical center, you already know the electronic data capture system shapes how a trial runs, from first patient in to database lock. It also shapes how an FDA inspection goes. Many healthcare software teams underestimate the distance between a patient engagement app and an EDC system that satisfies 21 CFR Part 11’s requirements for audit trails, electronic signatures, and validated data handling.

That distance matters more as trials move onto participants’ phones. Electronic patient-reported outcomes, eConsent, and wearable sensors all generate trial records, and FDA applies the same electronic records principles to the apps and devices that capture them.

This guide covers how to architect a clinical trial app and EDC system that holds up to inspection: when Part 11 applies, how to validate, how to build signatures and audit trails, how to handle patient-facing apps, offline sites, monitoring, and protocol amendments, and what FDA reviews when investigators arrive.

When Part 11 Applies

21 CFR Part 11 sets the criteria under which FDA considers electronic records and electronic signatures trustworthy, reliable, and generally equivalent to paper records and handwritten signatures. FDA published the final rule in March 1997, and it took effect that August.

In a clinical investigation, Part 11 covers records FDA needs to reconstruct the investigation that are kept electronically under predicate rules (the underlying recordkeeping requirements in FDA’s statutes and regulations, such as the IND and IDE record rules), along with records submitted to FDA in electronic form. It also applies at non-U.S. sites when the study runs under an IND or IDE.

FDA’s current thinking for clinical research is in its October 2024 guidance, Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers. It superseded FDA’s 2007 guidance on computerized systems in clinical investigations and builds on the 2003 Part 11 scope guidance, under which FDA applies a narrow and practical interpretation of the rule and exercises enforcement discretion over certain requirements, including validation and audit trails. That discretion doesn’t extend to the predicate rules themselves, and FDA still expects controls that keep records trustworthy.

A few boundaries help scope a build. FDA doesn’t intend to assess electronic health record systems for Part 11 compliance, and once EHR data enter the sponsor’s EDC system, FDA assesses compliance there. Part 11 doesn’t address email or text messages, though those channels still need security appropriate to what they carry. A patient app used purely for engagement generally sits outside Part 11, while the same app capturing endpoint data for an FDA-regulated trial is part of the trial’s record system.

How ICH E6(R3) Raises the Bar

Good Clinical Practice has also been rewritten. ICH adopted the principles and Annex 1 of E6(R3) on January 6, 2025, the EU put them into effect on July 23, 2025, and FDA published them as final guidance in September 2025 without setting a fixed U.S. compliance date.

For software teams, the biggest change is Annex 1’s new data governance section, which covers computerized systems across the full data life cycle: fitness for purpose, risk-proportionate validation, access controls, audit trails, and metadata. E6(R3) asks sponsors to concentrate effort on the data and processes most critical to participant safety and the reliability of results, which lines up with FDA’s risk-based approach to validation and monitoring. In practice, a sponsor should be able to show which data are critical, which systems touch them, and how each system’s controls are proportionate to that risk.

The Controls Part 11 Expects

Section 11.10 lists the controls for closed systems: validation, the ability to produce accurate and complete copies in human-readable and electronic form, protection of records throughout the retention period, access limited to authorized individuals, audit trails, operational and authority checks, device checks, training, written policies that hold signers accountable, and control over system documentation. FDA’s 2024 guidance turns several of these into concrete expectations for clinical systems.

Access control gets the most detail. FDA expects a record of everyone authorized to use a system, including when each user was added and any change to their permissions. Users work only under their own credentials. Systems should log users out after idle periods, limit login attempts, and record unauthorized attempts, and sites should tell sponsors when staff leave so access can be revoked. Part 11 doesn’t mandate a method, and FDA names multifactor authentication, strong credentials, and biometrics as options.

Data should be protected at rest and in transit, with encryption for confidentiality, and the system clock needs controls of its own. Only administrators should be able to change date and time settings, changes should be documented, and studies spanning time zones should record the time zone or use GMT.

Validation: Risk-Based and Specific to Your Study

FDA defines validation as establishing and documenting that a system’s specified requirements can be consistently fulfilled from design until decommissioning, including user acceptance testing. It recommends a risk-based approach, and the depth varies with the system: bespoke or customized software needs more than a configurable platform, which needs more than software used as-is. The risk assessment weighs the system’s intended use, the importance of the data it handles, and its potential to affect participants or the reliability of results.

The guidance also widens what teams have to plan for. Validation applies to your protocol-specific configuration, customizations, data transfers, and interfaces between systems, along with the vendor’s core functionality. And changes, including software upgrades and security patches, should be evaluated and validated throughout the system’s life depending on risk, without affecting the traceability or integrity of existing data.

Risk tiering keeps the effort where it belongs. An edit check that calculates a primary endpoint, a randomization or dosing function, or an integration that moves safety data deserves deep testing with documented expected and actual results. A configuration change to an optional demographic field needs a targeted check. A cosmetic change to a help screen may need little more than a documented impact assessment. Writing those tiers down before testing starts is what makes the approach defensible during an inspection.

A traditional computer system validation package still works as the backbone: user requirements, a validation plan, functional and design specifications, installation, operational, and performance qualification, a traceability matrix, and a summary report. Scale each deliverable to risk. FDA may request validation documentation during an inspection, including documents your IT service provider created, and you’re responsible for producing them.

Electronic Signatures That Hold Up

In a trial, electronic signatures replace handwritten ones on case report forms, investigator sign-offs, and other records FDA requires. Part 11 sets out what makes one valid:

• Signature manifestation. Each signed record shows the signer’s printed name, the date and time of signing, and the meaning of the signature, such as review, approval, or authorship.
• Record linking. Signatures are linked to their records so they can’t be excised, copied, or transferred to falsify another record, and any later change to a signed record appears in the audit trail.
• Signing components. Signatures that aren’t based on biometrics use at least two distinct components, such as a user ID and password. Within one continuous session, the first signing uses all components and later signings can use one.
• Identity verification. The organization verifies each person’s identity before issuing signature credentials. FDA’s guidance lists government-issued ID, security questions, and strong credentials with multifactor authentication or video observation as options.

Part 11 doesn’t require a particular technology. Username and password combinations, ID cards, biometrics, and digital signatures all work, and commercial e-signature services are acceptable when they meet Part 11. FDA treats a signature drawn with a finger or stylus as a handwritten signature, which matters for eConsent design, because that signature still has to be linked to its electronic record.

Before or when anyone first uses electronic signatures, the organization must submit a letter of non-repudiation certifying that its electronic signatures are the legally binding equivalent of handwritten ones. One letter can cover every electronic signature the organization uses, so there’s no need to file one per signer, and FDA accepts it electronically or by mail. FDA doesn’t certify signature systems or methods.

Building Audit Trails That Survive Inspection

An audit trail is a secure, computer-generated, time-stamped record that lets someone reconstruct how electronic records were created, modified, or deleted. Under section 11.10(e), record changes can’t obscure previously recorded information, and the trail has to be kept at least as long as the records it covers.

FDA’s 2024 guidance spells out the contents. Audit trails must capture all changes to a record, who made them, and when, and they should include the reason for each change. Each entry must include the date and time, the individual making the change (FDA suggests user ID and user role), and the old and new values. The trail should be protected from modification and from being disabled. Here’s what a single entry might look like for a corrected vital sign in a hypothetical study.

Field	Example value
Date and time	2026-03-14 15:42:07 UTC
User and role	jsmith, clinical research coordinator
Record	Subject 104-017, Visit 4, Vital Signs
Data element	Systolic blood pressure
Old value	18
New value	128
Reason	Transcription error, corrected against source
Protocol version	3.0

Not every keystroke needs logging. The audit trail should record deliberate actions such as saving or submitting, along with any edit to a completed field. When an edit check prompts a correction, the trail should show the original response, the fact that the check fired, and the change that followed. FDA recommends a searchable, sortable format, and where that’s impractical, static files such as PDFs that clearly correspond to the data elements they document.

Access logging is risk-based, and FDA gives one clear example: keep access records for any system or file containing unblinding information, so the integrity of the blind can be verified throughout the study. Review is risk-based too. FDA says periodic audit trail review may help sponsors ensure data quality and that the decision should rest on a risk assessment, and E6(R3)’s data governance expectations make a planned review focused on critical data the safer default.

In practice, the trail usually lives in a separate append-only table or log. Each entry links to its data record through a foreign key and stores the user ID and role, the old and new values, a trusted server timestamp, and a reason code or free-text justification. Permissions should stop anyone, database administrators included, from altering entries. Plan for the end of the study as well. When a system is decommissioned or a hosting contract ends, FDA expects sponsors to retain the metadata, audit trail information included, linked to each data element, so build that export into the vendor agreement from the start.

EDC Architecture: Custom Build, Platform, or Both

Sponsors can build an EDC system or configure a commercial platform such as Medidata Rave, Veeva Vault EDC, or Oracle Clinical One, and REDCap is common in academic research. A common pattern combines the two: a commercial or institutional EDC as the system of record, plus custom patient-facing apps connected by API.

A custom build gives full control over the data model, workflows, and integrations, which can suit rare disease studies, adaptive designs, or unusual data capture. The sponsor carries the entire validation burden, along with ongoing security patching and change control.

Factor	Custom build	Commercial platform	Hybrid: platform plus custom apps
Speed to first patient	Slowest	Fastest	Moderate
Validation scope	The entire system	Configuration, integrations, and data transfers	Platform configuration plus each custom app and its API
Flexibility	Full	Limited to the platform’s options	Full on the patient side, platform rules for the core record
Ongoing maintenance	Sponsor owns patching and change control	Vendor releases, with sponsor impact assessments	Split between the parties, defined in the agreements
Best fit	Novel designs and unusual data capture	Standard designs and teams with limited validation capacity	Trials with patient-facing apps, eConsent, or connected devices

Commercial platforms deploy faster and come with vendor validation documentation, though calling them pre-validated overstates what that documentation covers. FDA’s guidance says validation still has to cover your protocol-specific configuration, integrations, and data transfers, and the regulated entity stays responsible for Part 11 compliance whoever hosts the system. The vendor’s package shortens your validation work and leaves the study-specific part to you.

Whichever route you take, the relationship with an IT service provider needs structure. FDA recommends a written agreement, such as a master service agreement with a service level or quality agreement, covering the scope of services, each party’s responsibilities, and a plan that preserves your access to data for the full retention period. Evaluate providers on their validation processes, access controls, audit trail capability, backup and recovery, and ability to produce complete copies of records. FDA may inspect providers that have taken on regulatory obligations and can run focused inspections when it has concerns about data integrity.

Patient-Facing Trial Apps: ePRO, eConsent, and Wearables

Trials increasingly collect data outside the clinic. FDA’s guidance on decentralized elements, finalized in September 2024, covers telehealth visits, in-home visits, local health care providers, and remote consent. FDA calls the apps and sensors involved digital health technologies, and its 2024 Part 11 guidance applies the same principles to them as to any other trial system, with a few specifics worth designing in.

Know the data originator. Every data element should be tied to an authorized originator. When a participant enters data in an ePRO app, the participant is the originator. When a caregiver or staff member enters it for them, that person is, and the reason gets documented. When a wearable or glucose sensor transmits automatically, the device itself is the originator, identified by an automatically generated data element identifier. Sponsors keep a list of authorized originators for inspection.

Protect attribution. Apps that rely on user entry need access controls, such as PINs, biometrics, or multifactor authentication, so entries come from authorized people. Wearables are harder, so FDA expects investigators to tell participants that only they should wear the device and to document that conversation.

Transfer promptly and record it. Data should move to a durable repository through a validated process as soon as possible after capture, and the transfer date and time go into the audit trail. For inspection, FDA treats that repository as the location of the source data and doesn’t intend to inspect individual devices.

Build eConsent around the approved version. The FDA and OHRP guidance on electronic informed consent, issued in December 2016, still governs eConsent, and electronic consent systems in FDA-regulated trials fall under Part 11. If participants sign with a finger or stylus, bind that handwritten signature to the specific consent version the IRB approved.

Text and email reminders sit outside Part 11, but they still need security that fits the information they carry, which usually means keeping health details out of the message itself. Dogtown’s HIPAA-compliant app development work covers that layer, and our remote patient monitoring builds apply the same attribution and transfer discipline to device data.

Offline Data Sync for Sites With Unreliable Connectivity

Rural sites, mobile health units, home visits, and international sites with weak infrastructure all need to capture data offline and sync later. Without that ability, coordinators delay entry, transcribe from paper worksheets, or miss assessments, and each of those hurts data quality.

Offline sync needs local storage on the device, a queue for pending transactions, and conflict resolution. A typical design uses a native app or progressive web app with an encrypted local database such as SQLite or IndexedDB. While offline, entries write to the local store and get marked pending. When connectivity returns, the app uploads pending records in order, the server validates and writes each one and confirms receipt, and any conflict, such as the same field edited on two devices, gets flagged for a coordinator or data manager to resolve. Because FDA’s validation expectations extend to data transfers, the sync process itself needs validation, including failure cases like interrupted uploads and duplicate submissions.

Timestamps need the most care. Every offline action still generates a full audit record with its original capture time, so the true sequence of events can be reconstructed. FDA’s guidance for data captured on digital health technologies also puts the transfer time in the audit trail, and that practice suits any offline capture, so store both. Device clocks drift and users can change them, so compare device time with trusted server time at sync, flag discrepancies, and record the time zone or use GMT.

Site Monitoring and Source Data Verification

Monitoring no longer means checking every data point at every site. FDA’s 2013 guidance on risk-based monitoring and its April 2023 questions and answers recommend monitoring in proportion to risks to participants and data integrity. Source data verification can be part of that approach, with the risk assessment deciding how much of it to do and where, and centralized monitoring of EDC data can catch missing data and protocol deviations as they happen. E6(R3) takes the same risk-proportionate view.

That shapes what the EDC has to support. Monitors need targeted verification flags on critical data, a query workflow that tracks every question from opening to closure, remote access to the records they’re permitted to review, and dashboards that surface outliers, missed visits, and deviation patterns across sites. Each of those features generates records of its own, so they belong inside the validated system.

EHR integration can cut transcription errors, and FDA has offered guidance on using electronic health record data in clinical investigations since 2018. FDA doesn’t assess EHR systems for Part 11 compliance, but the interface that moves data into your EDC is a data transfer, so validate it and preserve the audit trail from the moment data arrive. Dogtown’s guide to EHR integration covers the technical patterns.

Protocol Amendments Without Breaking Existing Data

Amendments are the norm. In Tufts CSDD’s most recent benchmark of 950 protocols, 76% had at least one substantial amendment, up from 57% in the prior study, and amended protocols averaged 3.3 amendments. Phase II protocols had the highest prevalence, at nearly 90%. Most amendments couldn’t have been prevented either, since 77% were judged unavoidable, with regulatory requests and changes in study strategy as the top reasons. Each one is expensive, and an earlier Tufts study put the median direct cost of implementing a substantial amendment at $141,000 for a Phase II protocol and $535,000 for Phase III.

The finding that matters most for software is timing. Implementing an amendment took 260 days on average, from identifying the need to the last oversight approval, and sites operated on different protocol versions for a mean of 215 days, just over seven months. Changes to approved research can’t begin without IRB review and approval, except to eliminate apparent immediate hazards, so each site switches versions as its own approvals arrive. An EDC with a single global protocol switch can’t represent that.

Build versioning into the data model. Store each protocol version as its own configuration with its own eCRFs, edit checks, and visit schedule, and tag every record with the version in effect when it was collected. Track the effective version per site, tied to that site’s approval date, and gate each participant’s transition on re-consent where the amendment requires it. For protocols with a substantial amendment, Tufts found that sponsors reconsented about two-thirds of active participants. Never delete fields or visits that already hold data, and support side-by-side analysis across versions.

Some changes, like adding an optional assessment, are simple. Others, like redefining an endpoint, need explicit mapping so old and new data contribute correctly to the analysis datasets. Treat each amendment as a controlled change: validate what it touches, document the testing, and keep the record of how data integrity was maintained across versions.

What FDA Reviews During Inspection

Validation reports and system documentation generally stay in your files, available when FDA inspects, and aren’t part of a marketing application. During a sponsor inspection, FDA’s guidance says investigators generally focus on data management plans and procedures, the system life cycle from design to decommissioning, controls that keep records from being altered in value or meaning, access management, change control, contracts with IT service providers, and corrective and preventive actions.

For each study, document every electronic system that handles trial records, such as the EDC, clinical trial management system, interactive response technology, and electronic clinical outcome assessment tools, along with their requirements and a diagram showing how data flow from creation to final storage. FDA may ask for any records needed to reconstruct the study, including metadata and audit trails, as screenshots, printouts, or other human-readable copies. At investigator sites, inspectors look at training records, individual user accounts, and whether access was revoked when staff left.

What does go into a drug or biologic application is standardized study data. FDA requires CDISC standards, such as SDTM for tabulation and ADaM for analysis, for NDA, BLA, and ANDA studies that started after December 17, 2016, and for commercial IND studies that started after December 17, 2017, and it can refuse applications whose data don’t conform. Designing eCRFs with CDISC’s CDASH collection standard from the start makes the mapping to SDTM much easier at the end.

Problems found during inspection can lead to Form FDA 483 observations, and serious data integrity failures can call the reliability of the data into question. Security breaches confirmed to affect participant safety or privacy, or the validity of source data, should be reported to the IRB and FDA in a timely manner.

Real-World Example: Moffitt Cancer Center’s Smoking Cessation Trials

Moffitt Cancer Center, an NCI-designated Comprehensive Cancer Center, received two NCI R01 grants in 2019 to test smartphone-delivered smoking cessation interventions for two special populations, food pantry clients and people with HIV, and turned to Dogtown Media to build the apps. Each app delivers twelve weeks of structured, video-based treatment and twenty-six weeks of on-demand content. A weekly in-app survey assesses smoking status, motivation, self-efficacy, and stress, and backend logic uses the answers to choose which treatment videos each participant receives.

Both the iOS and Android apps integrate with a REDCap clinical database that stores all participant data, through an API that connects each app securely to the backend. They send personalized notifications that prompt participants to complete weekly surveys, and they deliver the intervention in English and Spanish. Both apps are deployed in the two ongoing randomized trials, and Moffitt’s team described them as fully automated, theory-based interventions brought to life.

The project shows the pattern most trial teams need: a patient-facing app that personalizes the intervention, connected to a research database the study team already uses. REDCap is widely used in academic research, and whether a given instance meets Part 11 depends on how the institution configures and validates it. When a trial app’s records support an FDA submission, the same architecture also carries the audit trail, access, signature, and validation controls described above, so those decisions belong in the first design review.

A Part 11 Readiness Checklist for Trial Apps

Before first patient in, confirm each of these is in place.

• Scope settled. You know which records fall under Part 11 and the predicate rules, app and device data included.
• Validation complete. The risk assessment, validation of protocol-specific configuration, integrations, and data transfers, and user acceptance testing are documented.
• Audit trails verified. Entries capture date and time, user ID and role, old and new values, and reasons, and no one can alter or disable them.
• Signatures ready. Manifestation and record linking are tested, identities are verified, and the letter of non-repudiation is on file.
• Access controlled. Every user has their own account, permission changes are logged, and departing staff lose access promptly.
• Clocks controlled. Time sources are trusted, time zones are recorded, and offline capture and transfer times are both kept.
• Originators defined. Participants, caregivers, staff, and devices are mapped as data originators.
• Versioning in place. Each record carries its protocol version, and each site’s effective version follows its approval date.
• Vendor agreements signed. Contracts define roles, oversight, and access to data for the full retention period.
• Documentation assembled. The system inventory, data flow diagram, SOPs, and training records are ready for inspection.

Why Partner With Dogtown Media

Dogtown Media builds clinical trial apps and apps for clinical research organizations, from patient-facing ePRO and intervention apps to integrations with the EDC systems sponsors already run. Our work with Moffitt Cancer Center on two NCI-funded randomized trials shows how a patient app and a research database fit together, and our compliance-first development process puts audit trails, access controls, and validation planning into the architecture from the first sprint.

If you’re planning a clinical trial app or EDC integration, request a free consultation to map your protocol’s requirements to an architecture that holds up to inspection.

Frequently Asked Questions

Does every clinical trial app need 21 CFR Part 11 compliance?

No. Part 11 applies to electronic records required under FDA’s predicate rules and to records submitted to FDA. An app that supports engagement without generating trial records sits outside it, while an app that captures efficacy or safety data for an FDA-regulated trial is part of the trial’s record system and needs Part 11 controls, including at non-U.S. sites under an IND or IDE. Behavioral studies that don’t involve an FDA-regulated product fall outside FDA’s clinical investigation rules, though institutional policies, the Common Rule, and often HIPAA still apply. When the answer isn’t clear, settle it with your regulatory team before you design the data model.

Does FDA certify or pre-approve EDC systems?

No. FDA doesn’t perform preliminary evaluations of EDC or other trial systems for Part 11 compliance, and it doesn’t certify electronic signature systems or methods. It evaluates systems during inspections, which is why validation records, SOPs, and audit trails have to be ready before first patient in. A vendor’s statement that its platform is Part 11 compliant is a starting point for your own assessment.

Can we build a clinical trial app with React Native or Flutter?

Yes. Part 11 doesn’t prescribe technology, so the framework doesn’t determine compliance. What matters is the architecture behind it: individual authenticated accounts, protected audit trails, encryption in transit and at rest, controlled timestamps, and validated transfer to the durable data repository. Cross-platform frameworks are a common way to reach iOS and Android from one codebase, and the validation effort covers the app and its integrations either way.

What should we do if we discover a data integrity issue during a trial?

Document it, assess its impact on participants and data, find the root cause, and put corrective and preventive actions in place, then update validation records if the system changes. FDA lists corrective actions for errors and noncompliance that could affect data integrity or participant protection among its sponsor inspection focus areas. If the issue is a security breach confirmed to affect participant safety or privacy, or the validity of source data, FDA’s guidance says to report it to the IRB and FDA in a timely manner. If data already submitted to FDA are affected, involve regulatory counsel on how to correct the record.

Do we need to re-validate the EDC system after a protocol amendment?

Not the whole system. Validate the changes the amendment introduces, based on risk. If it adds a field, confirm the field captures data correctly, appears in the audit trail, and exports to the analysis datasets. If it changes a visit schedule, confirm the new schedule applies to the right participants and sites while earlier records keep their original version. FDA expects system changes to be evaluated and validated throughout the system’s life without affecting the traceability or integrity of existing data, and every change documented

.