Adia Provider Portal — a clinician's workspace for iPhone and iPad. One unbroken flow from the moment a doctor sits down across from a patient to the moment the right lab tests are ordered — filtered by what that patient's insurance will actually cover. I owned the mobile direction while a separate team built the web version.

Context

Adia Provider Portal lives on three platforms — web, iPhone, iPad — and is sold to clinics and labs primarily in the US, where insurance coverage drives what a physician can actually order. The web side was being built in parallel by another team of designers. My slot was the mobile direction: end-to-end ownership of iPhone and iPad, from the first interview through final spec.

The clinical session looks simple from outside — doctor meets patient, doctor orders tests — but inside it carries everything: the patient's history, the chief complaint, ICD-10 diagnoses, a ranked set of lab panels that confirm those diagnoses, and the insurance gate that quietly decides which of those panels can actually be ordered. The product had to compress that into something a doctor could run on a screen they hold in one hand without losing their eyes from the person in front of them.

2
Platforms — iPhone · iPad
3
Long interviews with practicing providers
US
Primary market — insurance shapes every order

Where I started

Medical software is hard not because the screens are complex but because the work behind them is. Before drawing anything I needed to actually understand what a provider does in a session, where the friction lives in the tools they already use, and how the US insurance machinery shapes what they can prescribe. Three research tracks ran in parallel.

Qualitative
3 interviews with providers
Long sessions with practicing physicians on how they prepare for a patient, enter intake data, pull historical data (past labs, chronic conditions, family history), arrive at a diagnosis, decide on tests and medications. Plus a separate strand: how they read incoming results — what catches the eye first, what they flag, what they skip.
Market
Audit of clinical tools
Walked through the products providers already work with daily — most of them ageing EHR systems with crowded interfaces and dated patterns. The goal wasn't to copy, it was to find the parts that consistently fail and the parts users tolerate only because there's no alternative.
Domain
US insurance deep-dive
Weeks of reading insurance rulebooks: how payers decide whether a test or panel is covered for a given diagnosis, what counts as medical necessity, when prior authorisation kicks in, how denials are coded. Without this layer the product would just be a pretty ordering screen detached from the only thing that matters — getting the patient their test.

Three pictures the research drew

Three findings recurred across the interviews, the audit and the insurance literature. The product had to take all three as ground truth.

01
The session is a linear sequence
Providers don't browse — they move through a fixed sequence: confirm the patient, read history, log the chief complaint, decide on a diagnosis, choose tests. A non-linear UI breaks the muscle memory of the job. The interface should hold one step at a time and quietly remember the rest.
Provider interviews · clinical observation
02
Result review is its own job
Reviewing incoming lab results isn't a tail step of ordering — it's a different mental mode. Providers scan a list in seconds: critical and abnormal values jump out, the rest gets skimmed for context. A list that buries those signals is worse than not having a list at all.
Provider interviews · result-review observation
03
Coverage decides first
A test the patient's insurance won't cover is, in practice, a test the patient won't get. If coverage appears as a step after ordering, the provider has to redo the decision. Coverage must be visible inside the choice itself — not as a post-checkout error.
Insurance deep-dive · interviews

Decision 1 — one flow, two devices

iPhone and iPad share the same session, the same components, the same data — but each device gets the layout that matches how it's actually used. On iPhone the doctor works one-handed during the patient meeting itself: one column, a five-tab bar (Home, Search, Order, Tasks, Tests), sheets that open exactly to the depth the current step needs. On iPad the same flow expands into a sidebar plus side-by-side columns — patient details on one side, ordering info on the other — so what was a sequence on the phone collapses into a single glance in the exam room.

Adia Provider Portal — iPhone and iPad layouts side by side
Same flow, two surfaces — iPhone in one hand, iPad in the exam room. The device picks the layout, not the workflow.

Decision 2 — diagnosis-driven test ordering

The hardest interface problem was the mapping from chief complaint to lab panels. The provider types or selects ICD-10 diagnoses; the Adia Health AI layer maps those to a ranked set of relevant lab panels — CBC, PrecisionSTI, respiratory panels, biopsies — and the insurance filter immediately marks which of them are covered for this specific patient. The clinician sees the reasoning at a glance and accepts, edits or skips in a single tap — no leaving the patient's eye line.

From chief complaint to ordered tests — ICD-10 in, ranked panels out, insurance coverage shown inline.

Decision 3 — result review as its own surface

Reviewing incoming results isn't a tail of ordering; it's a different cognitive task and it deserved its own screens. The Results section opens to a list filtered by three signals providers actually look for: Final (the result is complete), Critical (values outside life-safe thresholds) and Abnormal (out of reference range but not critical). Everything else is one tap away but never on top. The detail view holds the specific values, the patient's prior measurements on the same test, and a single line of context — what the value means in plain language.

Adia Provider Portal — results list with Final / Critical / Abnormal filters
Results — sorted by what catches a clinician's eye first: critical, abnormal, then everything else.

Decision 4 — insurance check is in the order, not after it

The biggest source of friction in legacy clinical tools is exactly this: provider picks a test, hits order, gets a denial back hours later, has to start over. We moved coverage into the choice itself. Every test in the ranked list shows whether it's covered for this patient's plan, before the provider commits. When prior authorisation is needed, the form is one step inside the same flow — not a separate task that comes back days later through a different surface.

Adia Provider Portal — insurance coverage inline with test selection
Coverage is visible inside the choice — not surfaced as an error after the fact.
The full ordering flow — confirm, complaint, diagnosis, tests, coverage — in motion on iPhone.

What shipped

One product, two surfaces, one set of components — same session shape on whichever device is closer to the patient. The device picks the layout; the workflow stays the same.

In clinical tools, restraint is the feature. Every click we removed was a second returned to the patient, not to the screen.

What I carry forward

Two things that travelled out of Adia Provider Portal into every project after it.

Lesson 01
Domain first, screens second
On a domain you don't already live in — clinical work, US insurance — the most useful weeks happen before any pixel. Three interviews and a stack of insurance rulebooks did more for the final shape of the product than any number of mockups would have.
Lesson 02
Show the limit before the click
If something silently blocks a user's action — insurance coverage, permissions, business rules — it has to show up inside the choice, not after it. A failure message is just a polite way of saying “you wasted your time.” The same lesson keeps showing up everywhere: in payment flows, in admin tools, in onboarding.