A clinical trial app is a regulated record that happens to have a screen.

Consent is a document with required parts

An eConsent app is not a sign-up flow with a tick box at the end. 21 CFR 50.25 sets out eight basic elements that must be provided to each subject, and an IRB approved the exact wording you are showing. Your screens present that wording. They do not paraphrase it, trim it to fit a phone, or move the inconvenient paragraph behind a link nobody opens.

Two of the eight get shortened most often. The confidentiality statement has to describe the extent to which confidentiality will be maintained and note that the Food and Drug Administration may inspect the records. The voluntariness statement has to say that refusing involves no penalty or loss of benefits, and that the subject may discontinue at any time on the same terms. Both survive being made prettier. Neither survives being made shorter.

Documentation is a separate rule from content. Under 21 CFR 50.27, consent is documented by a written form approved by the IRB, signed and dated by the subject or the subject's legally authorized representative at the time of consent, and a copy is given to the person signing. On a phone, giving that copy is a real feature and not a footnote: the signed version, exactly as signed, delivered somewhere the participant keeps it. Mailing a blank template is not the same thing.

Comprehension is the part no regulation writes for you. Short sections with a question after each one, a glossary that opens in place, and a record of time spent on the risks page all help. None of them replaces a required element.

21 CFR 50.25, elements of informed consent

Every entry is a record somebody will read back

If your app holds records that exist because FDA requires them, 21 CFR Part 11 is describing your database, not a vendor's. Section 11.10 asks for validation of the system, the ability to generate accurate and complete copies in both human readable and electronic form, protection of records for the whole retention period, and limiting system access to authorized individuals. None of that is bought. It is designed in or it is absent.

The line that changes the data model is the audit trail. Part 11 asks for secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions that create, modify or delete electronic records, and it adds that record changes shall not obscure previously recorded information. That rules out updating a row in place. Every edit writes a new row, the previous value stays readable, and the trail is kept at least as long as the record it belongs to.

Signatures have a shape too. A signed electronic record has to carry the printed name of the signer, the date and time the signature was executed, and the meaning associated with it, such as review, approval, responsibility or authorship. Those three have to appear in any human readable version, on screen and in print. A saved image of a finger squiggle carries none of them.

For a small team the consequence is that time is not a display concern. Store the instant the entry was made and the instant it refers to, and never let one overwrite the other. That is cheap to get right in week one and expensive after the first participant enrolls.

21 CFR 11.10, controls for closed systems

Recruitment is a screening funnel, not a sign-up form

A patient recruitment app has one job: turn interest into people who are genuinely eligible, without collecting health information you have no approval to hold. The two goals pull against each other. Every extra prescreening question raises the quality of the referral and increases what you are storing about people who will never enroll.

The workable shape is a short prescreen that asks only what rules people out, then a handover to the site. Age band rather than date of birth. Yes or no on the two or three criteria that disqualify most applicants. Distance band rather than a street address. The detailed history belongs to the site visit, under the protocol, after consent. A prescreen that collects less is also a prescreen more people finish.

The study records themselves are already public and machine readable. ClinicalTrials.gov serves a JSON API that returns study records without an API key, including status, eligibility criteria text, minimum age, sex, healthy volunteer flag and each site with its city and country. A listing screen does not need a hand-kept spreadsheet of trials. What the API does not hold is anything about a person, and that is the half you have to design.

If your prescreen ends in a conversation with a coordinator rather than a form submission, you have quietly moved into telehealth app development, with the scheduling, identity and recording questions that come with it.

What keeps data arriving after week two

Electronic diaries lose people in a predictable order. The first week is good, the second slips, and by the third the entries are being filled in from memory on the morning of a visit. The backdating is the real failure, not the missed day. The record now says something that is not true, and the audit trail will show exactly when it was typed.

Design for that instead of scolding people for it. A window that closes is more honest than a date field that accepts anything. Mark a late entry as late rather than refusing it, because a flagged late entry is data and a refused one is nothing. Keep the daily ask under a minute. If you are also recording doses taken, you are building part of a medication tracking app, and the same rule about two separate timestamps applies.

Reminders are the piece teams assume rather than check, so here is what we found. Newly sets notifications up on a hosted push service: the message goes from a server to a device that is online and has granted permission, and a send takes a title, a body and a recipient, with no send time and no repeat rule. It does not schedule a repeating local reminder on the handset, so we cannot tell you whether one survives a restart, and we will not pretend otherwise. You own the code that comes out, so on-device scheduling is work you can add and test on a real phone.

Either way the timing question is worth thinking about before the plumbing. The general mechanics of reminding participants on schedule are a subject of their own, and the protocol should decide the schedule long before the code does.