Diagnosing 8 systemic UX failures in an FDA-regulated anemia management platform — and proving the model wasn't the problem.

I led the UX research and OOUX/ORCA diagnostic for PhySoftAMS, an FDA-regulated anemia management SaaS used by dialysis clinics to dose ESAs (erythropoiesis-stimulating agents) in stage-5 CKD patients. Output: 8 codified failure patterns from clinician interviews, an ORCA object model on five core entities, a Bet 1 prototype validated with users — and a strategic reframe that surprised the engineering team.

— who

PhySoftAMS · FDA-regulated anemia management SaaS for dialysis clinics

— what

UX Research · Clinician Interviews · OOUX · ORCA · Prototyping · Strategic Reframe

— result

8 systemic failure patterns documented · 5 core OOUX objects mapped · 0 algorithm changes recommended (model validated)

— scope

Lead Researcher · UX research · OOUX · ORCA · prototype validation

PhySoftAMS Patient Modeler — multi-line chart of hemoglobin, ESA dose, iron, and additional labs across time.

— outcomes

UX research themes documented

core OOUX objects mapped

algorithm changes recommended · model validated as sound

— problem

the platform was built around an engineering achievement — not around the clinicians using it.

PhySoftAMS contains a genuinely sophisticated PK/PD engine. The Patient Modeler runs roughly 6 billion calculations per patient to produce individualized ESA dosing recommendations — the kind of precision that is supposed to make narrow-therapeutic-index drug management safer and cheaper. The Expert System fills the gap when patients do not have enough data to model. On paper, this is best-in-class clinical decision support.

But the research surfaced a quieter truth. The platform had been designed around the algorithm, not the people who use it. Experienced nurses arrive with a paper tracker already filled in. They review labs in another tool before they ever log in. The system is not where decisions get made — it is where decisions get documented after the fact. Adoption was strongest among the system's own designers and a small group of power users; everyone else was working around it.

— users

designing for the experienced clinic nurse, not the engineer who built the model.

Three operational personas surfaced.

The super-user — a clinical manager handling 1,000 to 2,000 patients across multiple units, who reviews them in batches and depends on cross-clinic visibility that the system does not deliver. To answer "which patients are out of range across the organization?" she exports to Excel.

The experienced clinic nurse — often already knows the right dose by the time she opens the application, and uses PhySoftAMS primarily for documentation and secondary validation. Her workflow lives in two screens at once — PhySoftAMS and the source EHR — with manual transcription between them and a real risk of error she names openly.

The clinical operations manager — needs an organization-wide view of out-of-range patients, simple metrics for which units are achieving target hemoglobin, and a way to identify outliers without opening individual patient profiles. The current screens are built around the patient, not the portfolio.

The shared characteristic across all three: high clinical expertise, low tolerance for noise, and a strong preference for systems that confirm their judgment rather than override it. The current platform leans the other direction — it surfaces alerts the user has already triaged manually, asks for confirmation on decisions the user has already made, and forces context-switching between PhySoftAMS and the source EHR for every workflow.

— role

lead researcher.

I planned and ran the qualitative research program: clinician interviews across multiple client sites, transcript synthesis, theme codification, and consolidation into an executive-ready insights brief. I led the OOUX/ORCA work that translated the research into a codified object model the product team could build against. I shaped the Bet 1 prototype that turned the strongest finding — the demand for a simplified dosing path — into a testable design hypothesis, and ran it back to users for validation.

— process

the mandate: figure out why a sophisticated clinical engine wasn't being trusted by experienced clinicians.

— phase one — stakeholder research

Semi-structured interviews with nurses, clinical managers, and super-users across multiple PhySoftAMS client organizations. Sessions were recorded, transcribed, and synthesized into a thematic library. The output was an executive summary covering 10 strategic areas, consolidated into 8 prioritized failure patterns: alert overload, multi-clinic blindness, non-modelable patient friction, data-sync errors, low feature awareness, simplified-dosing demand, manual-entry and API gaps, and graphical-display overload.

— phase two — OOUX/ORCA rebuild

The research surfaced a structural problem the rebuild brief needed to solve: the system's interface did not reflect the system's actual objects. I ran the ORCA process on five core entities — Patient, ESA Dose, Lab Value, Readiness Criteria, Patient Model — and produced the Object Map, Nested Object Matrix, CTA Matrix, and per-role attribute requirements. This gave the engineering team a shared structural language to work from.

— phase three — Bet 1 prototype

The strongest, most consistent finding was the clinician demand for a simplified dosing path: a clear default dose, fewer decisions per patient, less ceremony. The Bet 1 prototype tested that hypothesis on the ESA dosing flow — a stripped-back interface with default-mode dosing, surfaced cross-clinic visibility, and re-prioritized alerts. The prototype reached users for feedback and confirmed the strategic diagnosis: the simplified path was preferred even by power users.

— evidence

Eight prioritized failure patterns synthesized from clinician interviews.

ORCA workspace — Object, Relationship, CTA, and Attribute discovery on five core entities.

Object Map and Nested Object Matrix — the shared structural language for the rebuild.

Bet 1 — simplified ESA dosing flow with three modes (recommend, override, why). — Bet 1 — simplified ESA dosing flow with three modes (recommend · override · why).

Bet 1 — cross-clinic patient overview, the surface the research flagged as missing.

— outcome

the model works. the UI is what fails users.

The most important conclusion of the engagement was the one the engineering team did not expect: the Patient Modeler is sound. The PK/PD engine is doing what it claims to do; the algorithm does not need rebuilding. What the research surfaced — and what the OOUX work confirmed structurally — was that every one of the 8 failure patterns lives in the UI layer.

Alert overload buries the high-priority signals the system is computing correctly. The lack of cross-clinic visibility forces experienced clinicians out of the platform and into Excel. The absence of a simple dosing path makes the platform feel adversarial — clinicians who already know the answer have to navigate a system designed to teach them the answer. The lack of a clear distinction between "refused dose" and "missed dose" turns correct data into false audit flags. None of these are model problems. All of them are interface, information architecture, and workflow problems.

That reframe changed the rebuild trajectory. Instead of additional model investment, the recommendation was direct: hold the algorithm steady, fix the layer between the algorithm and the clinician. The Bet 1 prototype became the first concrete instance of that strategy and validated the direction with the users it was designed for.

— bottom line

8 systemic UX failure patterns documented from clinician interviews across multiple dialysis-clinic sites · 5-object ORCA model mapped for the FDA-regulated anemia dosing platform · Bet 1 prototype validating the strategic reframe — the PK/PD model is sound, the UI is what fails users.

— previous

← Lifting member retention by 5% at RAPS, a specialty-credentialing society.

— next

Diagnosing 14 systemic failures in a Saudi healthcare-licensing platform — and shipping the rebuild brief. →

— next step

Want a measurement plan like this for your next quarter?