eCOA/ePRO App Development for Clinical Trials: BYOD, 21 CFR Part 11, and Instrument Migration

Most teams arrive at eCOA app development expecting a survey app with compliance bolted on near the end. Forms, a scheduler, some encryption, a submit button, and a security review somewhere before launch. The screens really do look like that. That picture is where the budget goes wrong.

In two published phase 3 trials, roughly a fifth and a third of baseline diary entries were lost, while overall compliance for those same trials read 94% and 93%.

Everything trial-specific about this build follows from what the app produces: evidence in a regulatory submission. The instrument and the record set your constraints, and the interface takes what’s left. And the record an inspector examines lives on your server, not on the participant’s phone.

If you’re on the sponsor’s digital team, or at the vendor they hired, your first decision lands well before the platform comparison. And it barely looks like a decision: what kind of assessment you’re building.

What makes eCOA/ePRO app development different from building a survey app?

The output is evidence in a regulatory submission, so the instrument and the record set the constraints. The instrument’s license gates your screens before build starts. The inspectable record is the first durable store on your server, and everything the phone holds before that write is a draft. The scheduling engine encodes the protocol, so a misconfigured reporting window can destroy baseline data while headline compliance still reads fine. The CDISC ODM export shape is a design input, not a final step.

Key takeaways

• Treat the participant’s phone as a draft client. Everything an inspector cares about has to reach your server before it counts.
• Settle instrument licensing and measure-owner screen review before the protocol locks. Both sit ahead of build, and both become amendments afterwards.
• Derive diary windows from each participant’s actual visit date. Windows fixed at site setup were the top cause of missing baseline data in two phase 3 trials, which lost a fifth and a third of their entries while headline compliance read 94% and 93%.
• Design the CDISC ODM export before the schema, because treating EDC integration as a connector problem turns it into data-model rework late.
• Plan for a provisioned tail on every BYOD study. Its size drives both budget and eligibility criteria.

Table of Contents

1. eCOA vs ePRO vs eDiary: why the label changes your build
2. Your ePRO app is evidence in an FDA submission, device or not
3. Every BYOD clinical trial is a hybrid, so budget for provisioned devices from day one
4. Instrument migration: what you can change on screen without breaking measurement equivalence
5. EQ-5D and PROMIS put instrument licensing on your critical path
6. Your eCOA audit trail and e-signatures have to survive a 21 CFR Part 11 inspection
7. eCOA architecture: the scheduling engine is your protocol in code
8. EDC integration: plan the CDISC ODM export before you design the schema
9. Decentralized clinical trials add modules to eCOA, and the estimate doesn’t scale linearly
10. The eCOA/ePRO app development checklist: what to settle before the protocol locks
11. Why Topflight Apps for eCOA/ePRO development

eCOA vs ePRO vs eDiary: why the label changes your build

These terms get swapped around freely, and the people selling platforms do most of the swapping. Sorting out eCOA vs ePRO takes one sentence, and it changes who has to log in to your app.

FDA splits assessments by who reports, a frame reconfirmed in PFDD Guidance 3 in October 2025:

• patient-reported outcomes (PRO), from the patient
• clinician-reported outcomes, from the clinician
• observer-reported outcomes, from a caregiver
• performance outcomes, from a task the patient does

Move any of those onto a screen and you get an ePRO, eClinRO, eObsRO, or ePerfO. Every one is electronic clinical outcome assessment work, which is what the eCOA umbrella covers. An eDiary app is a delivery pattern rather than a fifth category, and it can carry any of the four.

FDA’s DHT examples include both questionnaires and task-based performance measures, and E6(R3) renamed source documents to source records, with ePRO and wearable data named inside the definition.

The categories are operational. Who reports decides whose credentials the record attributes the entry to, whose device it runs on, and who sits through training before the site opens. A clinician-scored assessment and a patient diary carry different attribution rules and different training burdens, and the label is what tells you which one you’re scoping.

Your ePRO app is evidence in an FDA submission, device or not

Every team commissioning one of these asks the clearance question first. Is this a medical device, and do we need clearance before the trial opens? For most eCOA builds the answer is no. The evidence obligations land anyway.

Trial data sits under FDA regulations, good clinical practice, and the consent. HIPAA applies alongside, carrying the same HIPAA compliant software development obligations it does anywhere else. None of it turns on the device question.

Fit-for-purpose runs on two tracks, and FDA keeps them apart on purpose

The FDA DHT guidance keeps the device-definition question out of scope entirely. It says so twice, and routes you to CDRH.

Investigational use is exempt from most device requirements under Part 812, marketing authorization included. No IDE is needed where the DHT is nonsignificant-risk, or where an already-authorized device runs inside its cleared indications. FDA calls a significant-risk DHT in a drug IND uncommon.

Verification and validation are owed whether or not the DHT meets the device definition.

The DHT guidance decides whether the technology is fit-for-purpose, and it explicitly excludes COA selection and modification, which sit with PFDD Guidance 3. Two tracks, two evidence bases. Your electronic patient reported outcomes software gets judged on the first, and the instrument you put inside it gets judged on the second. Clearing one says nothing about the other.

The design-controls carve-out expires the moment you commercialize

Enforcement discretion is what keeps the investigational path light. FDA doesn’t intend to enforce design controls on a DHT used only in clinical investigations, and it says the discretion stops applying once the DHT is intended for use outside one.

That’s a cliff, and it has a date on it that rarely makes the project plan. A team planning to sell the same app after the trial, or to license it to sponsors as a product, is on the commercial track already, whatever the current paperwork says. It forces a sequencing decision, and the sequence starts at month one.

Design controls and a quality system cost far less built in than retrofitted, which is the same lesson every health AI FDA clearance project learns.

Every BYOD clinical trial is a hybrid, so budget for provisioned devices from day one

Yes, participants can use their own phones. BYOD clinical trials come with conditions: a provisioned fallback so nobody is excluded for owning the wrong handset, faithful instrument migration, and a documented minimum device specification before the study opens. Inspectors open the server-side record either way, so the handset is never the thing under inspection.

Seven dimensions carry the choice between BYOD and provisioned devices. Comparability is the only one where the two come out level.

On offline capture, FDA wants storage and transmission frequency adequate to minimize missing data, and participant network capacity adequate to the volume. On a provisioned estate you verify all of it before the study opens. On BYOD you specify it and then hope.

Comparability stopped being the blocker for BYOD in 2023

The ISPOR task force settled the comparability question that year, and said so explicitly for mixed-mode bring your own device (BYOD) designs. Where sufficient comparability evidence already exists and faithful-migration practices are followed, further comparability testing is unnecessary. Two of the task force’s co-authors are serving FDA CDER reviewers in the Division of Clinical Outcome Assessment. That’s what the conclusion rests on.

One limit stays. BYOD is inappropriate for customized or highly specialized DHTs, and FDA’s example is disorder-specific actigraphy.

The number to settle early is the size of the provisioned tail

FDA’s digital health technology guidance says sponsor-provided devices should be available as an option so participants who don’t bring their own aren’t excluded, and that sponsor-provided telecommunication services should be available where access is limited. The hybrid pattern is the recommended posture, which leaves one open question: what fraction of your participants land on the provisioned side.

Answer it early. It feeds the budget and the eligibility criteria, and both lock before the first site opens.

The compliance gap in the table compares BYOD-only against hybrid, which makes it an argument for the fallback.

Instrument migration: what you can change on screen without breaking measurement equivalence

Teams used to budget for an equivalence study before they could build an ePRO app around a validated instrument. Since 2023 that study is usually unnecessary, and a lot of published guidance still says otherwise. What replaced it is smaller. Implement correctly, then document that you did.

Faithful migration is a defined list, and your designer will feel every item on it

The field says measurement comparability now. The test behind either word is whether respondents interpret and answer items the same way regardless of mode. Measurement equivalence is the term most people still use, and it points at the same thing.

The current authority on instrument migration (paper to screen) is the C-Path eCOA Consortium’s class 1 practice set, and it’s specific enough to hand straight to a designer.

What the screen shows:

• Items self-contained, one screen at a time
• Formatting preserved from the original
• Response order unchanged regardless of device orientation
• Response targets equal-sized and evenly spaced
• Layout space reserved for translation expansion

How it behaves:

• No default or preselected response
• No auto-advance when a response is selected
• Backward navigation available before submit
• Input validation on entry
• An explicit final save-and-submit screen

Read it as a design brief and it rules out most of what a modern form library hands you for free. Auto-advance is the one designers fight hardest for, and it’s explicitly out. Responsive reflow that reorders options on a narrow screen is out too, which is a real constraint once you’re supporting phones and tablets from one codebase.

Measure owners set their own rules per instrument. FACIT publishes its own migration specification, down to the font on the paper original and one item per screen on handhelds, and it disclaims liability for instructions a vendor has revised. The class 1 list is your floor, and the instrument you licensed may raise it. Add linguistic validation and translation management on top. That’s a five-step workflow, run per language and per country.

The deliverable is documentation, and only a modification turns it back into research

Whether you owe new evidence turns on one question: does existing evidence show the mode change left the instrument’s measurement properties alone? For common scale types the answer is already in the literature, and your job is to assemble it into a summary. That’s documentation. It turns back into research only where you’ve modified something, which is why modification is the word to watch in your own spec.

The reversal is recent. The earlier ISPOR reports, in 2009 and 2014, discouraged mixing modes within a study and warned that pooled scores raise measurement error and can cost you power to detect a treatment benefit. The 2023 task force relaxed that.

So the package you hand the sponsor is an evidence summary for the instrument, and a screen report proving your implementation met the class 1 practices. Two documents, produced by your own team, in place of a study you’d have commissioned.

EQ-5D and PROMIS put instrument licensing on your critical path

The instrument is someone else’s intellectual property, so instrument licensing governs your screen as much as your wording. Four names cover most trials: EQ-5D, PROMIS, SF-36, and EORTC.

The first three diverge on six counts. EQ-5D gates the format, PROMIS gates the system, SF-36 gates the scoring.

PROMIS is the one builders get wrong, and it’s a schedule problem

Free reads as unconditional. The free lane was drawn around a researcher printing a PDF, and a build sits on the other side of it, whatever the download page implied.

Permissions and screen review sit ahead of build, which is what turns licensing from paperwork into a schedule risk. Put both on the plan next to the protocol milestones, and give the measure owner’s review real calendar time rather than a placeholder.

Licensing compliance is itself a class 1 migration practice, and the measure owner may supply instrument-specific advice. Even EQ-5D’s downstream sublicensors restrict electronic builds.

Your eCOA audit trail and e-signatures have to survive a 21 CFR Part 11 inspection

Part 11 is where eCOA software development stops resembling ordinary product work. 21 CFR Part 11 compliance is a set of properties attached to one store, and finding that store changes the rest of the build.

Your first durable store is the record

FDA locates source data in the durable electronic data repository into which the device’s data and metadata are transmitted, and it says it doesn’t intend to inspect individual devices for source data verification. The definition is specific: a database protected from alteration and maintained to the end of the retention period.

So the first server-side store your app writes to is the thing an inspector opens. Everything the phone does before that write is a draft, which rules out a whole class of architecture where the device is the system of record and the server is a backup.

Your audit trail owes five fields and one edit-check behavior

Part 11 names them:

• date and time of entry or modification
• who made the change, with user ID and role
• the old value alongside the new one
• the reason, where applicable
• retention in a searchable, sortable format

Attribution has no equivalent in consumer app work. FDA runs a data originator model: the participant is the originator for manually entered ePRO and task-based measures. Where someone else enters on their behalf, that person becomes the originator, and the reason the participant didn’t enter it has to be documented. A device transmitting automatically is its own originator and needs a data element identifier.

That puts an originator field on every record in your schema, and a documented reason path for proxy entry in your UI.

One edit-check rule gets missed more than the rest. When an edit check prompts a correction, the audit trail should capture the original response, the fact that the check prompted it, and the change made.

The append-only and tamper-evident principles underneath that list are the same ones that govern building a companion app for a pharma partnership.

A finger-drawn signature counts as handwriting

A signature drawn with a finger or a stylus is a handwritten signature, and handwritten signatures carry different linkage requirements. Valid electronic signatures have to carry the signer’s printed name, the date and time, and the meaning of the signing.

No system is FDA-certified for Part 11, and FDA can inspect you directly

Risk-based validation has a named scope: system functionality, protocol-specific configurations, customizations, data transfers, and interfaces between systems. Depth scales with system type, and bespoke systems sit at the top. That’s the honest cost of a custom build, and it belongs in the estimate.

FDA doesn’t evaluate electronic systems in advance and doesn’t certify e-signature systems. Any vendor selling you Part 11 certification is selling something that doesn’t exist. FDA may also run focused inspections of IT service providers whether or not regulatory obligations were transferred to them. If you’re the build partner, that one means you.

In 2024, a vendor contracted by Applied Therapeutics deleted the electronic records and audit trails held in the study’s eCOA system, covering all 47 enrolled subjects, two days after FDA preannounced a site inspection. Those were the Part 11 records for the eCOAs measuring the trial’s primary and secondary efficacy endpoints. Applied Therapeutics got the warning letter.

eCOA architecture: the scheduling engine is your protocol in code

Of every component in an eCOA build, the scheduling engine carries the most consequence and the least visibility. It’s where ePRO app development goes wrong in ways your dashboard won’t show you.

A reporting window and a baseline visit can quietly cancel each other

Eli Lilly ran two phase 3 baricitinib trials, RA-BEAM with 1,305 participants and RA-BUILD with 684. The daily diary ran on a sponsor-provisioned handheld and accepted entries only inside a reporting window chosen at site setup. Where the baseline visit fell during or after that window, the first reminder didn’t fire until the next day’s window opened, and the Day 1 entry was gone. That was the single most common cause of missing baseline data, at 19.6% and 30.4% across the two trials. Headline compliance through week 12 sat at 94% and 93%. The dashboard looked fine.

The hardware was provisioned, so device fragmentation had nothing to do with it. The failure sits in the seam between protocol timing and diary configuration. The protocol set the visit date and the diary config set the window, and the collision between them belonged to neither document.

The requirements follow from that:

• diary windows derived from each participant’s actual visit date rather than fixed at site setup
• assessment schedules with defined behavior for early, late, and missed visits
• reminders and notifications firing against the derived schedule
• offline data capture that timestamps when the participant answered rather than when the server heard about it

Time zones have a primary-source answer. For trials spanning zones, the sponsor states the time zone corresponding to each timestamp, or states that times are recorded as GMT.

The transfer into the durable repository is a regulated design. Data and metadata move by a validated process, contemporaneously, and the transfer timestamp goes into the audit trail.

A trigger can come from location instead of a clock. On iFaint, a study we built with a research hospital, geofencing detected a participant near the hospital, then asked whether the visit was study-related and routed the answer into a survey.

Change control, training, and support are architecture problems

Mid-study change control is mandatory and it bites. Record the timing and nature of every device or platform update, and re-confirm fit-for-purpose afterwards. A measurement shift is a threat to the trial rather than a bug to log.

So your release process needs a study-aware gate. Shipping on the app store’s cadence stops being safe once a shift in what the instrument measures can cost the sponsor an endpoint.

Training is a product feature. In the same Lilly program, the device entered training mode automatically after setup so sites couldn’t skip it, and wouldn’t go active until training was confirmed complete. Support belongs in the same category: site burden is a sponsor obligation, and technical assistance means round-the-clock coverage in staffed languages.

EDC integration: plan the CDISC ODM export before you design the schema

This is where rework comes from. ePRO platform development that treats EDC integration as a connector problem finds out late that it was a data model problem, and by then the tables are built around the wrong target.

The exchange format and the submission format are different jobs

ODM carries clinical data along with its metadata, reference data, and audit information, which is the exact payload an eCOA record has to preserve. That’s also why it constrains your data model. If your schema stores responses without the metadata that describes them, the export becomes a transformation project, and transformation is where meaning goes missing.

Submission is a separate problem. It runs on tabulation standards, in the formats named in FDA’s Data Standards Catalog, and ODM isn’t one of them.

ODM v2.0 breaks backward compatibility with earlier versions, so a vendor claiming CDISC ODM support without naming a version has told you very little. Dataset-JSON sits inside the v2.0 framework and is under FDA evaluation, with the required submission format unchanged. Build the export as a mapping layer you can swap, because the version underneath it will move.

Rave and Veeva are the two surfaces you’ll meet

Medidata Rave Web Services is RESTful over HTTPS and runs in both directions, exchanging CDISC ODM and CSV. Clinical data comes out. Study design metadata goes both ways, down to individual fields and codelists. It also returns protocol deviations and comments.

Veeva CDMS exposes its own API, and practitioners build tooling against both. Behind either one sits a pipeline you should design against: the sponsor’s data team extracts, then maps to SDTM and validates with Pinnacle 21.

Rave returns audit trail history too, and that’s the item worth designing around. The fields you specified for Part 11 have a consumer outside your own system. Design them as something another system reads, because one will.

Decentralized clinical trials add modules to eCOA, and the estimate doesn’t scale linearly

Sponsors describe the whole thing as one project. Decentralized clinical trial app development usually means eCOA plus:

• eConsent
• televisit
• sensor or wearable capture

Each module arrives with its own evidence obligations. FDA has a guidance covering decentralized clinical trials (DCT) as a whole, “Conducting Clinical Trials With Decentralized Elements,” final September 2024.

If they arrive with a platform already chosen, it’s usually one of Signant Health, Clario, Castor, YPrime, ObvioHealth, or Curebase. Your build then has to coexist with it.

eConsent is its own build, sitting under 21 CFR Part 50 with two FDA guidances behind it and a separate signature path, plus whatever your IRB wants to see.

Sensor endpoints follow the same fit-for-purpose logic as the app itself. A DHT replicating an established measurement may need no new endpoint justification, though it still needs verification and validation. A novel endpoint has to be justified against how a participant feels, functions, or survives.

We’ve pulled participant heart-rate data from Apple HealthKit and Google Fit into a trial app, and fed smart flowmeter and smart pillbox streams into a dashboard for trial managers. Standard wearable app development, with a submission at the end of it.

The ground is moving underneath all of it. ICH adopted E6(R3) Annex 2 in June 2026, covering decentralized and pragmatic designs and real-world data, and it takes effect in January 2027. FDA issued its final ICH GCP E6(R3) guidance in September 2025 without setting a US compliance date. Build for a rulebook that’s still being written.

The eCOA/ePRO app development checklist: what to settle before the protocol locks

Everything below is cheap while the protocol is open. After it locks, each line becomes an amendment.

Before the protocol locks:

• Instrument licenses secured per format, digital included
• Measure owner screen review submitted
• Minimum device specification documented, with a process for adding models mid-study
• Data process map showing where data flows and where it’s stored

Before the first participant enrolls:

• Letter of non-repudiation filed
• Authorized data originator list maintained and inspection-ready
• Time zone declared per timestamp, or GMT declared
• Alternative entry path defined for when the system is unavailable
• Data lock procedure agreed with the sponsor’s data management team
• Training materials complete, because they go into the submission

The contract items carry unusual evidential weight, because Applied Therapeutics committed them to FDA as corrective actions after losing its eCOA data.

In the contract:

• Vendors given no ability to delete files
• Sponsor holding its own backup, including for third-party systems
• Paper source retained at site, with a copy at the sponsor
• Data and linkable metadata guaranteed through the full retention period
• Closeout procedure covering access revocation

Screen review and the instrument licenses behind it are what move a date. They’re also what teams find out about last, well after the rest of the healthcare app development plan looks settled.

Why Topflight Apps for eCOA/ePRO development

We’ve worked inside the codebase of Medable, a leading decentralized trial platform, customizing and extending it so its pharma and academic-hospital customers could run study-specific configurations. That’s a different job from greenfield work. We were shipping into a platform other teams depended on, for customers running studies we couldn’t disrupt.

We shipped two builds on top of it. Event-triggered assessment on a study with a research hospital, and a trial-manager dashboard fed by participant data alongside IoT device streams for a Fortune 100 pharma sponsor. Trials launched for Merck and Stanford.

A two-week pilot, a two-month dashboard, a three-month app that shipped to both stores. All three ran on live studies.

We’re the build partner, working alongside the sponsor or CRO who owns the study. Instrument licensing, comparability evidence, and validation authority sit with them and with the measure owners, and we build to those rather than around them.

Clinical trial app development with us usually starts on the piece the sponsor is least sure about, most often the scheduling engine or the export.