TrialGuide, a keep-on-your-drug-trial app


TrialGuide is a companion app for patient’s on drug trials. It allows you to answer questions specific to your daily progress in the trial (e.g. “Did you take that red pill at 3PM today?” “How do you feel 6 hours later?”). It reminds you of scheduled appointments and allows you to explore the how-to’s and the why’s of the trial. It provides a communications hub between you and the ‘site’ (the clinician’s office).

The app also supports having both a care-giver and the patient answer separate questions at separate times.

There are Android and iOS implementations of the app. Both versions are available in the stores or ‘pre-loaded’ onto single use phones given out by the site that boot only up to TrialGuide. Since drug trials are often international is scope, the app is sometimes used in remote rural areas of the world.

There is a large back-end system that allows drug trials to be set up and administered as well as a web interface for each clinician’s site.


I was hired by mProve, a 30 person startup at the time, to be a full-stack developer; Back end, iOS and Android apps. mProve was eventually acquired by what is now SignantHealth.

When I started the app was very buggy. For instance, patients are given ‘activation codes’… if something ‘went wrong’ during activation, or even after, these codes would end up invalidated, requiring the patient to get a new one from the site. I methodically analyzed all error states and fixed all holes in the process.

I became the company expert on the ‘single use, pre-loaded phones’. These were phones that were locked down by security policies from the back end. E.g. no phone calls allowed. There was also a ‘kiosk’ mode that allowed for the single app to run.

These single use phones in very poor coverage areas (WiFi or Broadband) posed particular problems. I found that the user flow for these devices wasn’t really studied well. What happened was that users would turn on the phone, take the survey and turn it right off… Makes sense right? Well in poor coverage the survey wouldn’t get out before the phone was turned off. I developed a boot-up background survey transmission system that would get the survey out with just a peep of network

I also uncovered ‘tricks’ that the site personnel devised (and apparently passed on from one another) where if a patient missed a time window for a survey, the site knew how to temporarily adjust the patient’s schedule allowing them to take it. This often resulted in allowing the patient to take same time based survey twice, which got the investigator into a twist as they usually answered these questions differently. There was subtle breadcrumbs in the app log and site log that I pieced together to find these and explain the situation to the investigator.

I had a load of fun doing this and was known as ‘We had no clue what was going on, I’m sure Marty can fix it’ guy.

Other Work