Breast cancer records, translated into guidance a patient can act on.
Yerbba reads a patient’s electronic health record and turns it into a plain-language report: her diagnosis, the treatment options that fit her case, and questions to bring to her care team. All she has to do is sign up and give consent.
- Years
- 2018–2021
- My role
- Co-founder · Design lead · Full-stack developer
- Team
- 4 leads + 6 team members while I was there
- Status
- Live. My co-founder still runs it.
What I covered
Overall role Co-founder Steps 1–5
Patients could read their records but couldn’t tell what they meant.
Medical records are written for clinicians. A newly diagnosed patient has to connect staging, biomarkers, treatment options, trials and side effects on her own, at the moment she is least ready to take it in.
Three of us met in the Master of Health Informatics program at the University of Michigan in 2016: a developer, a designer and a doctor. Patient apps at the time made people log their own data. We wanted the automation Mint brought to personal finance, applied to a patient’s own care.
We incorporated in 2018 and decided the input should be the health record itself.
Doctors had little time to explain, and search results didn’t fit her case.
We ran two rounds of interviews with patients and doctors, then a survey to test whether patients would pay for a personalized report.
5 breast cancer, 2 lung cancer and 1 blood cancer patient
All breast cancer patients. 1 patient and 2 doctors were follow-ups from round 1.
said yes to paying a $50 fee for a Yerbba Report.
“It would have been a tremendous asset when faced with all the new information one has to navigate through. Having a report specifically for me would have helped me understand what to expect and to know how my doctors were making the recommendations about my treatment.”
Asking a doctor
- Time-consuming and expensive
- Gaps around newer care methods; possible bias
- Educating the patient isn’t their job, and liability makes them careful about sharing
- Some patients would rather learn on their own
Searching online
- Generic, shallow and not personalized
- Time-consuming to browse
- No way to tell whether a page applies to you
- Some sources are unreliable or out of date
Patients didn’t want to log data or be reminded of their disease, so the product had to do that work for them.
Ask for permission, not clinical recall.
Asking patients to type in staging, biomarkers and treatment history would recreate the burden Yerbba existed to remove. Consent became the one thing we asked for. The service did the translation after that.
- 01ConsentShe signs up and authorizes access to her records. Nothing to upload or fill in.
- 02RetrieveYerbba pulls diagnosis, staging, biomarkers and treatment history from her providers.
- 03TranslateClinical details are matched to the standard of care and the latest research.
- 04ReportShe sees her options, what comes next and questions for her care team.
Patient’s electronic health recordYerbba ReportStandard of care and the latest research
- 01Make consent the primary patient action.
- 02Retrieve and update records automatically where possible.
- 03Translate clinical data into report sections a patient can read.
- 04Answer “what do I need to know next?” before deep education.
- 05Use progressive disclosure for patients who want more detail.
- 06Design components for incomplete, inconsistent or changing records.
Design for the record you’ll actually get.
I built the front end in React, and set up and ran the AWS infrastructure and deploys with my co-founder Beltran Figueroa. Records arrived incomplete, in different formats and at different times, so no screen could assume a field existed. Every component had a defined state for missing, partial, pending and updated data.
The first architecture, and what changed
Technical specification v0.5 · Nov 2018I wrote the first technical specification. In a previous role I had written a health service’s workflow on top of its system architecture, and saw how the architecture set the structure for everything after it. For Yerbba I modeled the plan on architectures from services close to our business model, set up AWS from it, and changed the structure as the product changed.
- Medical recordinput
- Web appupload / sign-in
- Parserstructure the data
- Data storerecords + metadata
- Executerdecision tree
- Model serverknowledge
- Visualizationreport UI
- Reportto the patient
- Consentpatient signs in once
- 1upHealth APIpulls her records from providers
- Executercompares with the last run
- Results + metadatano medical records stored
- Reportupdates when something changes
We used 1upHealth’s API to retrieve each patient’s records with her consent. We never stored the medical records themselves, only the executer’s results and metadata. On each run the executer compared what had changed and updated the report on the server.
The patient uploads her medical record.
ShippedShe consents once, and 1upHealth’s API retrieves her records from her providers (direct EHR access, Apr 2019).
How do we protect the patient data we collect?
ShippedWe don’t keep it. Only results and metadata are stored.
Records aren’t standardized across providers.
Shipped1upHealth’s API standardized data from most EHR vendors.
From kickoff to launch in two years, and still live.
We launched in May 2020. In 2021 I ran the product with one of my co-founders, who still runs it today. I stepped away when I left the company. It’s live at yerbba.com.
- Jul 2018R&D kickoff
- Sep 2018Incorporated
- Jan 2019First angel round
- Mar 2019SPARK grant
- Apr 2019EHR access via 1upHealth
- Oct 2019MVP launched
- May 2020Product launch
- Jul 2020Marketing campaign
- 2021Operated with a co-founder
Angel rounds of $35K (Jan 2019), $10K (Jan 2020) and $30K (Jun 2020), plus a $10K SPARK grant (Mar 2019).
New test results and new research change what a patient should know, so the report is billed monthly or quarterly. Today: Basic $89.99 and Premium $129.99 a month.
See current pricing →