How to Build Health Technology That Treats Regulation as a Design Input

The best way to build health technology that people trust is to write the clinical claim before you write the code, then design the whole product as the evidence that proves it true. Regulation is not a gate you reach at the end of the road. It is the specification you should have started with, and treated as a design input from day one it becomes an honest record of what your product does for a patient.

I learned this building an AI clinical decision-support system for type 2 diabetes and an AI symptom checker. The teams that move fastest in the long run decide early, in one sentence, what they are claiming and for whom.

What does regulation-first product development actually mean?

Regulation-first means the regulatory definition of your product comes before the feature list. In medical device language, the anchor is the intended use: a plain statement of what condition the product addresses, in which population, in what setting, and to what end. Everything downstream flows from that statement, from the data you collect to the trial you run. Get it precise and the work has a target. Leave it vague and you build for months with no definition of done.

A definition worth keeping: Software as a Medical Device (SaMD) is software intended for a medical purpose without being part of a hardware device. A tracker that counts steps is not SaMD; software that reads those signals to flag a likely arrhythmia and prompt a clinical action is. The difference is the claim, not the algorithm.

Why does the clinical claim have to come first?

Because the claim determines almost everything else, and changing it late is expensive. Consider two products that look identical on screen and both suggest explanations for a patient's symptoms. Product A claims to "help users learn about general health topics." Product B claims to "triage acute symptoms and recommend whether to seek emergency care." Same interface, very different products to a regulator, because the second carries real risk: send someone home who should have gone to hospital and that is harm. The claim sets the risk class, the risk class sets the evidence burden, and that burden shapes everything you build and spend.

A common and costly trap is to build the feature first and reverse-engineer the claim to fit it. The product then claims whatever the demo happened to do, broader than anything the data can defend, and validation becomes an exercise in shrinking the claim until the evidence catches up. Writing the claim first inverts that: decide what you are willing to stand behind, then spend only on proving it.

How do you turn a clinical claim into a product specification?

Pull four things out of the intended-use statement: the condition, the population, the setting, and the decision the software influences. The population sets which patients must appear in your training and validation data. The setting, a busy clinic or a patient at home, changes the interface and how much error you can tolerate. The decision tells you what a wrong output costs.

When we built EASY Diabetes, the work was framed around a concrete claim: support clinicians in managing type 2 diabetes so that outcomes improve and the workflow gets lighter. That framing is what made the EASY-1 randomized controlled trial (NCT03258268) answerable. We ran it as a multi-clinic study evaluated against standard of care. You cannot run a trial against a slogan, only against a falsifiable statement.

This is educational content about how products get built, not medical advice, and anyone making decisions about their own diabetes care should talk with their own clinician.

How do EU MDR and the FDA pathway differ, and why does it matter on day one?

They ask the same fundamental question in two different grammars, and you want to design for both before you pick one. Under the EU Medical Device Regulation (MDR), and the In Vitro Diagnostic Regulation (IVDR) for diagnostic software, devices are sorted into risk classes, and most clinical decision software lands higher up the scale than founders expect. The MDR leans on a clinical evaluation: a structured, evidence-backed argument that the device performs as intended and that its benefits outweigh its risks. The FDA frames the same idea through intended use and premarket review, with growing attention to how AI models are watched after they ship.

The certificate work I did at KTH covered exactly this terrain, MDR, IVDR, the FDA framework, and the handling of Software as a Medical Device and AI-ML models. The throughline is consistent: define the purpose, characterize the risk, generate proportionate evidence, and keep watching the product after launch. The vocabulary differs. The discipline does not. Design your evidence for the stricter regime and you usually have most of what the other one needs.

How do you prove a SaMD claim without overbuilding?

Match the strength of your evidence to the size of your risk, which a chain of questions makes concrete. Analytical validity asks whether the software correctly processes its inputs. Clinical validity asks whether the output corresponds to a true clinical state. Clinical utility asks whether acting on the output actually helps patients. A low-risk wellness feature may need only the first link; a tool that influences an acute treatment decision needs all of them, and the last usually means a real study.

The mistake I see most is teams pouring effort into model accuracy while neglecting clinical utility, the link regulators and clinicians care about most. A model can be impressively accurate and still change nothing at the bedside, or worse, add work without adding benefit. Accuracy is necessary, but the claim is that a patient is better off because your software exists.

Designing for trust beyond approval

Clearance is a milestone, not the goal. The goal is a product clinicians and patients rely on, and that trust is built into the design long before any review. AI models drift as the populations and practices around them shift, so regulating yourself well means planning for the product's life after launch: monitoring performance, watching for the failure modes you predicted, and being honest when reality diverges from the claim.

Treating regulation as a design input is a way of being honest early. You decide what you are claiming, prove it in proportion to its risk, and keep proving it. That is slower at the start and faster afterward, and it is the version of health technology I would trust around someone I love.