medflow Simulator
Usability evidence for medical products

Find the use errorbefore you build it.

Medflow Simulator surfaces likely use errors before you build — and tells you where to point your real user test. It narrows where to look; it never replaces looking.

The problem

Today, you meet your first real user at formative testing.

By then the architecture is frozen and the design inputs are locked — so the fix is unaffordable, and the use error ships. The earliest you can currently act is after you already have something to test. Simulator moves the first signal earlier, while the design can still change.

What it is

Three studies, each standalone.

Run any of them, in any order. What you can honestly run depends on what you're evaluating.

Triage

Simulation

Synthetic personas, sampled from modelled populations

Find where use errors are likely — before anything is built. Output is a concentration map: where errors cluster, so you know where to aim.

Pre-validation triage
Improve

Formative

Real users, remote

Real, representative users work through the tasks so you can find and fix problems while the design can still change. Diagnostic and iterative.

Real users
Validate

Summative

Real representative users, remote

HF validation on the frozen design — because for software, the screen is the product. Hardware and drug-device summative are not offered.

Software only

A simulation is pre-validation triage. It shows where errors are likely to cluster; it doesn't prove anything, and it doesn't replace IEC 62366-1 evaluation. It narrows where to look — it never replaces looking.

Upload intake

A finding in ten minutes.

Bring a Figma or a plain description of the device and its steps — no account, no onboarding. Synthetic users run your tasks and hand back a concentration map of where errors are likely to cluster. You describe a design, not patient data.

Request early access
What it looks like when it works

A partial dose, and a bystander who believes they saved a life.

An adrenaline autoinjector, used outdoors by a panicking bystander. They hear the actuation click, read it as “done,” and pull the injector at three seconds of a ten-second hold — delivering a partial dose while believing they saved a life. It's the best-documented use error in the class — and Simulator surfaced it from a declarative spec, before anything was manufactured.

An engineering demonstration — not a customer study.
Why now

The regulatory ground is shifting toward exactly this.

IEC 62366-1

The usability-engineering standard requires evaluation with real users. (EN IEC 62366-1 is not MDR-harmonised — state-of-the-art support only, no presumption of conformity.)

FDA human-factors guidance

Finalised 29 May 2026 — organises submissions around critical tasks; eSTAR prompts for the HF submission category from 1 Aug 2026.

ISO 14971

Risk management needs hazard → sequence of events → harm. The sequence column is the one everyone fudges; Simulator populates it with recorded evidence.

MDR Article 117

Integral drug-device combinations need a Notified Body Opinion whose scope includes usability. As of 2024, fewer than half of responding notified bodies had ever issued one.

Why it holds

The trust is the product.

Honesty as strategy

The obviously-sellable features — photoreal environments, headline error percentages, “AI validation” — were left out on purpose. A false claim here is existential; restraint is the point.

One platform

Simulate → improve → validate. Software can go all the way to real, remote validation on screen, because for software the screen is the product.

The calibration flywheel

Consented, de-identified outcomes from real studies sharpen the population targeting over time: better aim — never a rate to quote.

The clean cut

What it deliberately is not.

Not a replacement for IEC 62366-1 usability evaluation. It narrows where to look; it doesn't replace looking.

Not grounds to skip HF validation testing. It tells you where to focus that testing — it isn't a substitute for it.

No hardware or drug-device summative. Validation needs the physical device in hand — no screen reproduces force, feel, or the hold.

No “AI validation,” no headline error percentages, no photoreal “evidence.” Relative, conditional targeting signals only.

FAQ

Straight answers.

Does Medflow Simulator validate my device?
No. A simulation is pre-validation triage — it shows where use errors are likely, so you can aim your real user testing. It never replaces IEC 62366-1 evaluation or HF validation.
Can a Simulated Use Report replace HF validation testing?
No. It's not a substitute for validation with real users; it tells you where to focus that testing.
What can it actually validate?
Software only. Remote summative on the real on-screen interface is genuine HF validation, because for software the screen is the product. Hardware and drug-device summative are not offered — those need the physical device in hand.
What do I put in?
A design — a Figma, an on-screen interface, or a plain description of the device and its steps. Not patient data.
Who is it for?
Medtech founders and small/mid manufacturers — especially drug-device combination sponsors (autoinjectors, pens, inhalers), where human factors is the dominant regulatory activity.

See where your users will trip — before you build.

Bring a design; get a finding. Request early access to Medflow Simulator.

Request early access