One Button Uber POC

One button to order a ride to your drug trial appointment. It is designed to keep the rider anonymous to Uber.


This ‘One button’ function was an Uber proof of concept concept meant to explore the technology needed to allow the patient to request a ride to the clinician’s office.

The drug trial app knows the location of the clinician’s office as well as the time of a patient’s appointment. This allows the ‘one button’ ride request to program in destinations and to allow rides only when close in time to the appointment.

The issue with this type of ride is that various privacy laws and drug trial agreements require that Uber not know the identity of the rider. Uber developed a special health care API specifically designed for these anonymous rides. It turns out that Uber’s day-one code assumption was the rider had their own account (even if it was paid by the company). This API works around this assumption.

This project never advanced past the POC stage. It fully exercised the API, allowing rides to be ordered (in Uber’s sandbox) as well as providing location call-backs as the ride progressed.


By the time I was assigned to do this POC, the business folks had already established a relationship with Uber to be among the first to use their then alpha-API. I worked with the Uber people to set up these special accounts where there was a master account (our company) with sub-accounts for each drug trial (where the drug company was ultimately responsible for payment)

The POC is fully in Flutter. It dipped into our ‘site’ location info (the clinician’ office) as well as the patient’s schedule.

As part of my work on this and the innovation team I developed the concept of what I call ‘Flutter Anywhere’ it is a set of interface modules that allow the same exact base flutter widget, in this case the Uber POC to be imbedded in any technology as either an embedded visual ‘widget’ or a new page. These technologies include web, native iOS, native Android and of course Flutter.

The Uber Health API is purely an API with no UI level SDK. It is thus up to the app to find the rider’s current location (using Google Maps) and then using the API to order the ride. The API returned things like the current location of the selected vehicle as well as an object fully describing the car and driver. Once the driver used their driver app to indicate a pick-up, location info for the rides was periodically returned to the app via callback which can be plotted on Google Maps.

At the end of the POC phase we were able to prove in the technology and fully size the scope of end-to-end work, including what would be needed to globally set up this function throughout the company’s systems and for sites to administer these rides.

I did a presentation on this to the whole company once the POC was completed.

Other Work