Context

BridgeCare HMIS runs a US regional medical center across eleven modules: clinical care, patient access, revenue cycle, ancillary and supply, and administration. Four roles use it — an attending physician, a patient access and financial coordinator, an ancillary and supply chain director, and a COO who is also the IT admin.

The client is a US hospital software company, unnamed under NDA, so the product is shown here as BridgeCare, a stand-in name, with synthetic data. I joined midway through a refresh of their established product, to rework the compliance use cases and redesign the UX around how doctors actually work.

The constraint

HIPAA's minimum necessary standard means each role sees only the patient information its job requires. The physician sees the full chart. The coordinator sees account, payer and coded data. The COO sees no clinical PHI at all.

And in an emergency, a clinician with no care relationship to a patient still has to get in. That is not a permissions screen. It decides the navigation, what every table shows, what can be exported, and what has to be written down afterwards.

The decisions

What shipped

• 28 screens across 11 modules and 4 roles
• Privacy Mode, automatic logoff, Break Glass, and an append-only audit log retained for six years
• Minimum-necessary exports — a full chart export for a claim appeal is blocked, not just discouraged
• Controlled-substance e-prescribing with EPCS and PDMP
• Single-file HTML prototype, hosted and clickable end to end, on synthetic data

Outcome

• Shorter time to complete a case or consultation
• More time spent in the product, and a larger user base
• Many HIPAA compliance gaps closed, reducing the risk of penalties
• Sales up 7%

Screens

Context

An enterprise governance, risk and compliance (GRC) platform built on Snowflake. Eleven modules cover policies and controls, risk, compliance, audit, third-party risk and AI governance, for an organisation operating in the US, Germany, the UK and India — HIPAA, SOC 2, ISO/IEC 27001, NIST CSF, PCI DSS, GDPR, UK GDPR and India's DPDP Act, with AI models and agents governed alongside them.

I joined at the earliest stage of the proof of concept, working directly with the founder and stakeholders. I gathered the requirements and set the scope: which compliance frameworks, domains and controls the product would target first.

The constraint

Every regulator wants the same underlying thing — evidence that a control existed and operated. But each defines the control differently, on a different cadence, with a different evidence standard.

Model the product around one regime and you produce a tool that satisfies one auditor and fails the others. Model it around the union of all requirements and you produce something nobody can use. The design problem was finding the layer underneath — the atomic evidence event — and letting each regime's view compose from it.

The decisions

What shipped

• A complete, responsive front end covering every use case and user type
• Figma designs for each flow, with both the happy path and the error paths
• Process maps and user flows
• A product demo video
• Flyers, a brochure and supporting marketing material

Outcome

The working product aligned the internal team on what was being built, and it supported the fundraise: investors saw the product working, not a slide describing it.

Screens

Context

A repeat prescription in an NHS GP practice passes through three people who rarely meet: the patient who orders it, the prescription coordinator who prepares it, and the GP who signs it. Most of the hand-offs between them run on phone queues and free-text notes.

Arog Care is one shared workflow with a view for each of them. A single case runs through all three: Anita orders her repeats, Leanne in the practice team prepares the decisions, and Dr Carter decides and signs.

A pharmacy company wanted the system for its own patients, built as a white-label product that other pharmacies could run under their own name. I came to it fresh and led the design on my own, covering the three journeys you can click through in the demo: patient, practice team and GP.

The constraint

Only the GP can prescribe. The practice team can check, prepare and pend against protocols the GP sets, but the signature and the clinical judgement behind it stay with the prescriber.

So the product had to take as much work as possible off the GP’s desk without ever letting the team cross that line, and without asking the patient for anything already in their GP record.

The decisions

What’s in the prototype

• Patient. NHS login, onboarding from the GP record, a four-step repeat order with collection, delivery or barcode, charges and exemptions, home monitoring, test results, messages, and family proxy access.
• Practice team. The repeat request queue, hospital letters, care navigation, home monitoring triage, reviews and recalls, and proxy access checks.
• GP. Signing with a Smartcard, filing results with a note the patient can read, hospital requests, fit notes and forms, QOF, and repeat protocols.

Built to WCAG 2.2 AA. Status is always in words, never colour alone, and the NHS number stays masked until the patient chooses to show it. There is no backend and every patient in it is made up.

Screens

A prototype that gets funded and a prototype that gets built are two different artifacts. Most founders only discover that after the round closes.

The funded one has to survive a specific kind of scrutiny: an investor who has seen a thousand clean flows and is looking for the thing you haven't thought about. Six things separate the ones that hold up.

Show the hard case, not the happy path

Every founder demos the flow where everything works. It proves nothing, because everything working is the easy part. Show the rejected claim, the failed payment, the clinician overriding the alert. The edge case is where you demonstrate that you understand the business rather than the interface.

Real data, never lorem ipsum

Fake data reads as "we have not spoken to a customer." Real names, real amounts, real reason codes. It costs an hour and it changes the entire read of the product.

One flow complete beats ten flows half-built

Breadth signals you have ideas. Depth signals you understand a problem. In a pitch you have eight minutes, and you will spend four of them on one screen — so build that screen to a different standard and let the rest support it.

Clickable, not a deck of images

The moment an investor clicks and something responds, the thing stops being a concept and becomes a product in their head. That transition is worth more than any amount of visual polish.

Design the empty states

That is what your product looks like on day one for every single customer. Skipping them is skipping the first impression of the actual product.

Know which screen carries the pitch

Even quality across forty screens is a worse outcome than uneven quality with the right screen built exceptionally. Decide in advance which one you are spending your time on.

None of this is about visual craft. It is about whether the artifact demonstrates that you have thought past the demo — which is the only question the person across the table is actually asking.

In most products, constraints are discovered in roughly this order: design, build, test, ship, first customer, security review, rebuild.

In regulated products that order is expensive, because the constraints are not preferences that can be negotiated. They are legal boundaries, and a product that crosses one is not a product with a bug — it is a product that cannot be sold.

An example

In US controlled-substance prescribing, a medical assistant can prepare an order and cannot sign it. EPCS two-factor authentication is tied to the prescriber's identity and is not delegable.

Discovered during design, that is an afternoon's work: the MA composes, the order pends, the physician reviews and signs. Discovered during build, it is a rework of the permission model, the queue, the notification system, and the audit trail. Discovered by a customer's compliance officer, it is a lost deal and a rebuild.

What this means practically

The first week of a regulated-product engagement should produce almost no visual output. Roles, boundaries, sequencing, evidence requirements, what has to be true before an action is permitted. Written down, argued about, agreed.

Founders sometimes read that week as slow. It is the opposite — it is the week that prevents the rebuild, and it is the reason a two-to-three week prototype is achievable at all.

The tell

You can usually spot a product designed without domain input in one pass. Permissions modelled as settings toggles. Records with edit affordances where amendments are required. Approval flows ordered by arrival time rather than urgency. Each of those is a design that will work in a demo and fail in a clinic.

A founder told me his design timeline was eight weeks. His runway was five months.

Two months of a five-month runway, spent on screens, before a single investor conversation. Nobody had made that decision on purpose. It was simply what the quoted timeline implied, and the implication went unexamined.

The arithmetic nobody runs

A team burning $60,000 a month spends $120,000 during an eight-week design cycle. Compress it to three weeks and $75,000 comes back — not as savings, but as runway, which is the more valuable currency. It is also five extra weeks of investor conversations at the front of the process rather than the back.

Against that, the difference between a $6,000 and a $12,000 design fee is noise.

What makes it possible

AI-assisted production, used for the parts that are production rather than judgment. Screen generation, component systems, state variations, copy iterations. The saved time goes into the things that decide whether the product works — domain logic, edge cases, the sequencing of a regulated flow.

The failure mode is using the speed to produce more screens. A hundred screens generated quickly is volume, and volume is what cheap vendors sell. The same speed spent on depth is a different product.

The pricing implication

Charging less because the work took less time prices the hours. Nobody buying a fundraise prototype is buying hours — they are buying a closed round, an approved budget, a dev team with something to build. Delivering that outcome a month sooner makes it more valuable, not less.

When a healthcare revenue-cycle team adds automation — a bot that submits claims, an AI agent that drafts appeals — the dashboard usually reports what the automation did. Claims submitted. Appeals sent. Tasks completed.

None of those is the outcome. The outcome is whether the payer paid, and the payer already tells you.

What the 835 is

The 835 is the X12 electronic remittance advice: the file a US payer sends back after it adjudicates a claim. For every claim line it says what was billed, what was paid, and why the two differ — in claim adjustment reason codes (CARCs), remark codes (RARCs), and group codes that say who carries the balance: a contractual write-off, the patient, or something else.

It is structured, it arrives as part of normal payment, and it is the payer’s own record. As evidence goes, that is about as good as it gets.

Self-reported success is not success

An agent that submits an appeal and marks the task complete has reported its own success. Whether the appeal worked shows up weeks later, in a remittance, as a payment or another denial. A dashboard that stops at “appeal sent” is measuring activity and calling it an outcome.

Designing around the reconciled outcome

• Join every automated action to the remittance that settles it, and show the gap. An action with no remittance yet is pending, not successful.
• Report cost per paid claim, not cost per task. A cheap action that leads to a second denial is an expensive one.
• Group denials by reason code, not by the automation’s own categories. CARCs are the shared language of the payer, the billing team and the auditor.
• Keep the remittance one click away from every number, so anyone can check a figure against the payer’s file.

Beyond billing

The pattern holds in any regulated product with an outside record of truth: a bank statement, a regulator’s acknowledgement, an auditor’s sign-off. Find the record you don’t control and design the measurement around it. It is harder to argue with, and it is usually already free.

An organisation operating in the US, Germany, the UK and India can answer to HIPAA, SOC 2, ISO/IEC 27001, GDPR, UK GDPR and India’s DPDP Act at the same time. Each has its own control language, its own cadence and its own idea of what proof looks like.

The tempting design is a tab per framework. It is also the one that quietly doubles the work.

The control is not the unit

Take a quarterly user access review. HIPAA expects access to patient data to be managed and reviewed. SOC 2 tests logical access. ISO 27001 has a control for reviewing access rights. GDPR asks for appropriate technical and organisational measures. Four framings, one activity: someone checked who has access, and signed it off.

If the product models four controls, the team uploads the same review four times — or four slightly different versions of it. When the auditor asks which one is true, nobody can say.

What changes in the design

• One evidence record, many mappings. The review is stored once, with its date, owner and source, and mapped to every requirement it satisfies.
• Jurisdiction is a filter, not a mode. A German auditor filters to GDPR and BDSG. The full picture stays one click away, and nothing outside the filter disappears without saying so.
• Unmapped is a first-class state. An issue with no control behind it shows as Unmapped, with its exposure, instead of falling out of every report.
• Frameworks activate from the footprint. Where the business operates and what it processes decide which frameworks apply, so nobody has to configure one by hand — or forget to.

The test

Pick any number on the dashboard and ask: what evidence is this built from, and which regulators does that evidence satisfy? If the product answers in one click, it was designed around the evidence. If it needs a spreadsheet, it was designed around the frameworks.