Create Jira Ticket
This idea cannot be sent to Jira.
TrialPilot. Research, closer to everyday life.
A woman wakes up three years into Long COVID. Standing makes her heart race. A short walk costs her two days in bed. She has questions that deserve careful answers. Which treatments might help. What improves daily function. Why an improvement lasts for one person and disappears for another. The nearest study that might answer them is a four-hour drive away.
TrialPilot was built by a patient so that more of those questions become studies people can actually join.
Our founder has lived with Long COVID since 2021. His work includes public research advocacy, RECOVER-TLC working-group and protocol-design contributions, and service on the RECOVER Biospecimen Access Committee. His co-founders bring big tech engineering experience. We combine the urgency of living with illness with the discipline of building dependable software.
Patients told us they were eager to contribute observations and samples. Decentralized study teams told us they were stitching studies together from survey tools and REDCap. The ambition was there. Connecting the work remained difficult.
TrialPilot brings study design, enrollment, participation, and review into one place. Drug repurposing is a particular opportunity, testing existing medicines for conditions with too few answers.
Since Phase 1 we acted on what we heard. We narrowed AI to specific, reviewable jobs. We added NIH Common Data Elements so studies speak a shared language. We made it possible for teams to test the participant journey before anyone enrolls.
Published papers, patient and researcher interviews, and FDA guidance on decentralized trials and digital health technologies shape the design.
The platform is built and ready for more study partners. We need investigators and patient organizations to put it to work, with appropriate protocols, approvals, and support.
Research, closer to everyday life.
Solution Overview (MVP Demonstration)
User-Facing Application
Live demo, prototype, or working product
Working software, plus the attached 5-minute demo.
Website: https://www.trialpilot.app
Researcher preview: https://admin-staging.trialpilotresearch.com
Participant app (iOS TestFlight): https://testflight.apple.com/join/MJ3PEWyY
Android available on request
Access instructions (if needed)
Researcher preview login: Email judges@trialpilot.app, Password TopxHHS2026!
Results for the American People
Her clinician shares a study code or she sees a new study on social media. She reads the consent on her phone, signs, and enrolls from bed. No drive. No waiting room.
Our target users are people with invisible illnesses like Long COVID, ME/CFS, POTS, and Lyme who are too sick or too far away to reach a site. Most are women, who are disproportionately affected and often dismissed. Caregivers, clinicians, patient organizations, and investigators complete the circle.
A researcher sets the protocol and assessments, then publishes. Participants arrive by code, link, or public listing, and the study team confirms eligibility. Daily check-ins take minutes and save progress, so a crash midway loses nothing. A permitted caregiver can help.
Measures fit the illness. Post-exertional malaise is tracked by default. Where a protocol allows, the NASA Lean Test runs at home with guided steps. Wearables add context when someone has one and are never required.
Phase 1 reviewers asked about technology deserts. A smartphone or internet browser access is the only requirement. Check-ins are short and light on data, and studies can keep site visits or mailed kits for what technology cannot do.
Fewer people should be excluded because of where they live or how sick they are.
Data, Tech & Evidence Driven Approach
Longitudinal research needs observations that keep their meaning over time.
Shared definitions. NIH Common Data Element lookup and import bring in standard questions and complete forms, including NIH JSON exports. Source identifiers, versions, and response codes stay attached to each measure and travel with every export, so results can be compared across studies. Teams still review rights, mappings, scoring, and fit.
Consented sources. Participant reports, structured assessments, and supported wearable records from Apple Health and Google Health enter under study consent. Each protocol decides which measures apply and on what schedule.
Open evidence. PubMed retrieval puts published literature beside the design. Where enabled, authorized CURE ID case reports can inform drug-repurposing hypotheses. They do not establish efficacy.
Accountable records. Participant identity and study data live in separate stores. Researchers see de-identified views scoped to their own studies. Every change to clinical data is written to an append-only audit history with who, when, and what changed, built toward 21 CFR Part 11 expectations.
Bounded AI. AI agents review Study Builder designs and gather literature. An experimental, opt-in participant guide answers everyday study questions from published study sources and points people to the team when needed. Researchers retain scientific and clinical decisions. Reminders today are scheduled automation, not AI. Supervised analysis support is on our roadmap under defined permissions and human review.
Execution, Efficiency & Delivery:
The platform is built. Today a research team can use:
A study builder covering protocol, participants, assessments, interventions, eConsent, single IRB tracking, safety definitions and halting rules, and publishing
A study dashboard for enrollment, participation, reported concerns, and review
A way to test the full participant journey before launch
A participant app on iOS TestFlight, with Android on request
Configured studies judges can walk through end to end
The value lands on both sides. Coordinators stop reconciling spreadsheets, survey exports, and email. Investigators get structured, audit-ready data instead of cleanup. Participants spend their limited energy on the study, not on travel and paperwork.
We measure what matters to a study team. Time to enrollment. Retention. Participant effort and satisfaction. Missing observations. Coordinator time.
What we need is more partners. Investigators and patient organizations bring protocols, approvals, local services where needed, and participant support. We bring the software and the people who built it, ready to launch more supervised studies now.
Scalability, Reuse & Societal Impact:
Invisible illness is where we start, not where we stop. The same foundation supports research across chronic conditions where symptoms are episodic, hard to see in a clinic, and best observed at home.
Reuse is built in. Study structures can be saved and adapted, and NIH definitions travel with each measure, so the next team starts from work that came before rather than a blank page.
Deployment fits existing research. Studies can run fully remote or pair home participation with site visits for specialized equipment. Clinicians and patient organizations become the front door, reaching rural communities and trial deserts through people patients already trust.
FDA's 2026 real-time clinical trial initiative adds momentum toward continuous, digital evidence.
Partners supply suitable measures, approvals, local services, and connectivity. Participants have access to a smartphone or web browser. Investigators keep scientific and clinical control.
Our next steps include launching more supervised partner studies. Measure access, enrollment, retention, satisfaction, and the usefulness of AI assistance. Publish what we learn, including what did not work.
The long-term promise is broader participation and knowledge that keeps its value from one study to the next.
Congratulations, Jon. The point about people too sick or too far away to reach a study site really lands, and I like that the NIH Common Data Elements travel with every measure.
I work on a different piece: turning published Lyme and Long COVID papers into runnable simulators. Simulator 4 in my library covers a registry study of 4,183 people with persistent Lyme disease (Johnson et al., Healthcare). The authors report that common trial eligibility rules would exclude roughly 9 in 10 of them, against about 35% in other diseases. In the simulator, the biggest lever is how many people with diagnosed co-infections stay eligible: moving that one assumption takes the usable share from about 4% to 39% (chart attached, an illustrative stress test, not a confidence interval).
That fits your theme of who gets left out of studies. My entry is here if you’re curious: https://invisibleillness.crowdicity.com/post/896844
Wishing you every success.
Reply 1
Thanks for this — the “too sick or too far away” framing really landed. A four-hour drive to a study site, or a short walk costing two days in bed, is exactly the kind of barrier that quietly shapes who ends up in research.
Two things I'm curious about: with NIH Common Data Elements, where identifiers, versions, and response codes travel with every export, how do you handle condition-specific nuance for Lyme — persistent symptoms, co-infections, eligibility criteria — so a study built here doesn't silently reproduce the exclusion patterns we've seen elsewhere? And can your pre-launch journey test surface eligibility drop-off before anyone enrolls?
I also appreciated that you narrowed AI to specific, reviewable jobs and kept reminders as scheduled automation, not AI. How does a researcher actually see and override an AI review of a study design, and how will that audit trail hold up in your first supervised partner studies?
Reply 0
Oh btw, I was reading this again and something stuck with me. You mentioned single IRB tracking together with safety definitions and halting rules in the study builder, and I realized I don't fully understand how that part works in practice. When a halting rule is triggered, how is that communicated to participants and to the single IRB, and what does a participant actually see when a study pauses? I keep thinking about someone who joined because they are too sick or too far away to take part any other way, and how you keep that moment clear for them.
Reply 0
I keep thinking about the first study that actually runs on this, not the demo walkthrough. A participant changes phones, loses signal on a bus, or hands the device to a caregiver mid check in, and the study still has to work.
What I would want in the first 90 days is a failure log, not just a completion rate. How many check ins finish on the first try, how many need a support touch, and how many fall back to a phone call or paper? And if a preset failure threshold is hit, does new enrollment pause, or does the study keep adding people into the same breakage? A study tool that cannot show its breakage is asking a sponsor to trust the clean version only.
Reply 0