eCOA and ePRO Platform Development: Why a Patient Diary Entry Gets Thrown Out of Your Analysis | Digital Heroes

Why a patient diary is the most fragile data in the trial

The primary endpoint is a patient-reported symptom score collected daily for twelve weeks. At the analysis meeting someone asks how many entries were completed inside their window. The answer is worse than expected, and worse still, a subset of entries carries timestamps clustered in the hour before a site visit. Paper diaries have a documented history of exactly this behaviour, patients completing a week of entries in the clinic car park, and the entire reason for moving to electronic collection was to make that impossible. If your build allows a back-dated entry, you have rebuilt paper with a battery in it.

eCOA is deceptively simple to demo and unforgiving in the field. The screens are a questionnaire. The system underneath has to guarantee that an entry happened when it says it happened, on a device the subject actually had, in a language the instrument owner approved, rendered exactly as the instrument was validated, with a trail that supports a label claim. Every one of those guarantees is where projects go wrong.

Problem 1: the instrument is licensed, and the screen version needs approval

Most validated outcome instruments are copyrighted and licensed by their owners. EQ-5D is licensed through the EuroQol Group, and many others are administered by their developers or by licensing organisations that also control translations. You do not get to redraw a scale because it looks better on a phone. Migration from paper to screen is governed work, the ISPOR ePRO good research practices guidance on migration is the reference most sponsors follow, and screenshot-level review by the instrument owner is a normal gate. Faithful migration means the same items, same order, same response options, same recall period, no helpful additions.

This is precisely where Signant Health earns its fees. It has migrated large parts of the common instrument catalogue already, and buying that library is often cheaper than recreating it. Medidata Patient Cloud is a sensible default when your EDC is Rave, because the reconciliation problem largely disappears. YPrime does careful configuration work. Castor is a good fit for academic and decentralised studies where instrument licensing is lighter. ObvioHealth is closer to a virtual trial service than a platform you own, which is right for some sponsors and wrong if ownership is the point. The consistent gap is not capability, it is the operating model: every study is a configuration engagement with a fee and a lead time, and a sponsor running the same six instruments across twenty studies pays repeatedly for a library it will never own.

What a custom build does: it makes the instrument a versioned, reusable object with its licence terms, approved translations, rendering rules and scoring algorithm attached. Study twelve reuses the approved rendering from study three, and the licence audit is a report rather than a search of everyone's email.

Problem 2: the timestamp is the endpoint, so the clock has to be defensible

An entry is only worth what its time evidence is worth. Device clocks can be changed by the person holding the device. Time zones shift when a subject travels. Daylight saving transitions create an hour that happens twice. Offline entries sync later and someone has to decide which time counts.

The build has to capture device local time, device time zone offset, an uptime-based monotonic reading that does not move when a user changes the clock, and the server time at sync, then store all of them. Window compliance is evaluated against a rule you define per instrument, not against whatever the phone said. Late entries are permitted or refused per protocol, and when refused, the system records the attempt rather than silently discarding it, because a refused attempt is real evidence about the subject. This part is dull, it is where the defensibility lives, and it is the first thing a shallow build gets wrong.

Problem 3: bring-your-own-device solves one problem and creates six

Provisioned devices cost money and logistics: procurement, mobile data plans, enrolment in device management, shipping to sites and to subjects, charging instructions, replacement for the ones that get lost, and a return and wipe process at study end. Bring-your-own-device removes the fleet and introduces fragmentation. Now you support an operating system range that includes phones several versions behind, screen sizes that affect instrument rendering, aggressive battery optimisation that silently kills your reminder notifications, and app store review cycles that stand between you and an urgent fix.

The honest position is that most studies need both. Build for BYOD as the default with a provisioned fallback for subjects who cannot or will not install, and treat rendering as a validated concern: define the supported screen size range and test instrument layout at each boundary, because an item that wraps differently on a small screen is a migration change, not a cosmetic one. Plan for forced update, because you will need to push a fix to a subject who has not opened the app store in a year, and plan for the review cycle in your release calendar rather than discovering it during an incident.

Problem 4: compliance is an operations problem your software either supports or ignores

A site sees a compliance dashboard once a week and calls the subjects who are drifting. That call is the intervention that saves the endpoint, and it only happens if the dashboard reaches the right person early enough to matter. Most platforms report compliance after the fact, at study level, which is interesting to nobody. Build it the other way round: per subject, per instrument, showing who is at risk this week and why, ordered so a coordinator can work the list in fifteen minutes. Escalation rules, reminders in the subject's language at a time they chose, and an honest view for the sponsor that separates a site with a training problem from a subject with a life event.

Artificial intelligence has one legitimate job here and one hard prohibition. The legitimate job is risk flagging: predicting which subjects are likely to lapse from early entry patterns so outreach is targeted, and detecting response patterns that suggest an instrument is being completed without being read, for example identical responses across items designed to diverge. The prohibition is absolute. No model may alter, impute or smooth a patient-reported value. The entry is the evidence. Imputation is a statistical decision made in the analysis plan by a statistician, not a feature in a data collection app.

Problem 5: the data has to reconcile with everything else

eCOA data is often source data with no paper backup, which is why the FDA guidance on electronic source data in clinical investigations matters to the design. It has to land in the study database with subject and visit identity that matches the EDC, scoring computed to the instrument owner's algorithm rather than a local interpretation, and a reconciliation report that surfaces the subjects who exist in one system and not the other. Add wearable or sensor endpoints and volume changes the architecture: continuous data belongs in its own store, joined on the subject and visit spine, not stuffed into the questionnaire tables.

What this costs and how long it takes

A first release with instrument rendering, scheduled windows, offline capture with defensible timestamps, reminders, site compliance views, audit trail and the validation package runs $95,000 to $200,000 and ships in 14 to 20 weeks, based on Digital Heroes delivery experience. A full platform adding device fleet management, BYOD distribution, translated instrument versions, wearable ingestion, proxy and caregiver reporting, scoring library and EDC reconciliation runs $280,000 to $650,000 phased over 9 to 15 months.

What drives price up in eCOA specifically: the number of languages, since each translated instrument version needs its own approval and rendering test, and nine languages is not nine times one language but it is not one either. Instrument licensing negotiation and migration review, which is calendar time you cannot compress. Provisioned device logistics, if you want the platform to manage the fleet rather than a vendor. Wearable and sensor integrations, one project per device family. Paediatric and proxy versions, because a caregiver-completed instrument is a different instrument with different rules. And accessibility work for older populations, which is real design effort and should not be skipped in a trial whose subjects are over 70. What keeps it down: starting with the instruments you use in every study and one language pair, then widening.

Build versus buy, and when buying is obviously right

Buy if you are running a single pivotal trial where a licensed instrument carries the primary endpoint. The migration library, the instrument relationships and the regulatory familiarity that Signant Health or Medidata bring are worth more than ownership on that timeline, and a failed migration approval is a schedule risk you should not take on for one study. Buy also if your only requirement is periodic questionnaires in one language for a short study, because the economics never turn over.

Build when two or more of these hold. You reuse the same instrument set across many studies and per-study configuration has become a visible budget line. You have a digital endpoint programme where sensors, app behaviour and questionnaires are one product rather than three vendors. You need the platform in a therapy area where subject experience materially affects retention and you want to iterate on it rather than file a change request. You run decentralised studies where the app is the site. Or you are building a data asset across studies and cannot have it fragmented across three vendors' exports. The tipping point is when patient experience becomes part of your scientific strategy rather than a collection mechanism.

How to choose a developer for eCOA and ePRO

Ask them how they establish that an entry happened when it claims to have happened. A partner who has built this talks about monotonic clocks, time zone capture, sync-time reconciliation and refused-attempt logging. A partner who says the phone provides the timestamp has not thought about a subject who changes the date.

Ask what they will do when an instrument owner rejects the screen layout. The right answer includes a rendering system where item presentation is configuration rather than code, so a revision is a change to a definition and a re-test, not a release cycle.

Ask how notifications survive aggressive battery optimisation on the devices your subjects actually own, and ask what their forced-update path looks like. Then confirm in writing before kickoff that you own the repository, the app store accounts, the infrastructure and the validation package. The app store account matters more than people expect, because a study app published under a vendor's account is a dependency you cannot unwind mid-study. At Digital Heroes all of it belongs to the client from the first commit.