Doula Care Portal: UX Case Study

Context

Care Medi-Cal now pays for, on a system built for clinics

California's Medi-Cal now covers doula care: prenatal visits, support during labor and postpartum visits. For community doulas that should mean steady income for work they already do. In practice, billing Medi-Cal means codes, visit limits per pregnancy, eligibility checks and claim forms designed for clinics with billing staff.

A Bay Area birth-justice nonprofit that matches families with community doulas asked me to build the platform that would let its doulas get paid. I was the only designer and developer, working weekly with the nonprofit's leadership from October 2025.

The brief centered Black doulas and doulas serving underserved communities, and its goal was billing support that kept them independent: their own clients, their own records, their own relationships with families. That became a product requirement. A doula sees her own clients, visits and claims, and chooses whether to bill through the portal at all; billing tools unlock only after she picks the billing plan and signs a billing agreement. Admins get enough oversight to support the work, and when they look at a doula's screen it's read-only.

The Problem

Make Medi-Cal billing invisible, without hiding the rules

Client sign-ups lived in Google Forms and email, and the information involved is protected health information. The rules couldn't be simplified away: every visit has a code, every pregnancy has caps, and every claim has to survive an audit. The design problem was making a doula's day feel like care work while the system did the compliance work underneath.

prenatal and postpartum visits

8

One shared pool per pregnancy

initial visit, labor and delivery

1 + 1

Per pregnancy

extended postpartum visits

2

Billed in 15-minute units

claim form per submission

CMS-1500

With HCPCS and ICD-10 codes

The Medi-Cal doula benefit rules the portal tracks per client.

The Service

Billing starts before the first visit

I treated intake, visit documentation and claim preparation as one workflow, not three features. Each step has to hand the next person what they need: the client supplies insurance and signs consent, the doula documents care, and the biller turns both into a claim without chasing anyone for a member ID.

Client roadmap recreated with sample data.

Decisions

Five calls I made, and what I turned down

1. 01

   Show the visit cap before the visit, and warn instead of blocking

   Medi-Cal pays for a fixed number of visits per pregnancy, and prenatal and postpartum visits share one pool of eight. I put the pool on every client as a row of boxes that turns amber at half, orange at 80% and red when it's used up, so a doula sees the limit while planning, not when a claim is denied. Over the cap, the visit still logs and is flagged for an extra authorization.

   Rejected: Blocking the visit at the cap. A doula supporting someone in labor can't stop for paperwork, and an authorization can follow the visit.

2. 02

   Separate what an auditor sees from what the doula keeps

   With a single notes field, a doula has to guess what an auditor will read. I split notes into three: a short claim note that is visible on audits, structured notes from templates the state requires, and private notes that are never attached to a claim. Each field says who will read it.

   Rejected: A single rich-text notes field. Simpler to build, and it made every doula guess what counted as part of the medical record.

3. 03

   Doulas log visits; the system writes the claim

   Doulas are care workers, not billers. They log a visit in plain language (type, date, duration, in person or remote) and the portal fills in the HCPCS and ICD-10 codes. Completed visits batch into one claim per client, and the CMS-1500 is generated for them to preview.

   Rejected: Asking doulas to fill in a CMS-1500 directly. It mirrors the payer's form and assumes billing training most doulas don't have.

4. 04

   Make the existing billing process workable first

   For the first phase I scoped the portal to what the organization could run right away: collect the documents, record visits, prepare the CMS-1500 and track each claim to paid. Submitting to payers and handling payment stayed outside it, so the biller's screen is built for the handoff. Every field is click-to-copy for retyping into the payer's portal, each claim shows its age with flags at 20 and 30 days so nothing drifts past a filing deadline, and after filing the biller attaches the submitted form for the doula's records. A denial needs a reason the doula can act on.

   Rejected: A clearinghouse integration and payments in phase one. Better long term, and it would have held billing back while billers kept retyping claims by hand with no help.

5. 05

   Make security part of the flow, not a gate in front of it

   Two-factor sign-in for admins, billers and doulas, with an authenticator app or an emailed code for anyone who doesn't use one. Sessions lock after 15 minutes idle with a two-minute warning, files open through short-lived links, and admins can view a doula's screen read-only for support, under a banner that stays on top of every dialog.

   Rejected: Shared logins and letting admins edit as a doula. Faster support, and no way to say who changed a patient's record.

Interactive Prototype

Log a visit, then bill it

A recreation with sample data. Try it in this order:

1. As the doula, look at the caps: with one of eight prenatal and postpartum visits left, the warning is already showing.
2. Log a postpartum visit to use the last one, then log another: it still logs, flagged for an authorization.
3. Create a claim from the visits, then switch to Biller: copy fields, approve, or deny (a reason is required). Every step lands in the audit trail.

Dependencies

The intake flow depended on decisions outside the interface

By November 2025 the intake and signature flows worked, but three documents clients would sign didn't exist yet: the Billing Expectations Notice, the Emergency Referral Consent and the doula contract. No screen could fix that.

I took one question into the next stakeholder meeting: who writes these, and who arranges their legal review? The organization's Program Manager took ownership, and all three are now live in the client portal. Each is signed on its own, with the date it was signed, and shows the client as pending until then.

Access

Five roles, each enforced in the database

Hiding a button isn't access control. Each role's limits are enforced by row-level security in the database, so a doula's session can't read another doula's clients even through the API, and no one can raise their own role.

Outcome

56 accounts across five community birth organizations

56 accounts across the founding nonprofit and four other community birth organizations as of September 3, 2026, and still growing. Doulas log visits and generate claims without touching a billing form, and every claim action is logged. There is no baseline for billing time before launch.

What I Learned

In healthcare, design decides who sees what

1. 01

   In healthcare the hardest design work is deciding what each role must never see. Row-level security made those decisions real instead of hiding buttons.

2. 02

   A rule the user can see early beats a rule that blocks them late. Visit caps warn from 80% so authorization can be sorted before the visit, not after the denial.

3. 03

   Billers don't need a prettier form; they need fewer keystrokes into the payer's portal. Click-to-copy and claim age did more than any redesign.

Hindsight

What I'd do differently

1. 01

   Log when an admin starts viewing as a doula. Today that view is read-only and clearly bannered, but starting it isn't written to the audit trail.

2. 02

   Measure claim turnaround from day one. The queue flags claims at 20 and 30 days, but there's no before-launch baseline to compare against.