Treating Regulation as a Design Input, Not a Box to Check

The teams that build the best medical software treat regulation as a design input from the first sketch, and the product comes out clearer and safer for it. When a requirement like a defined intended use or a documented risk analysis arrives at the end, it feels like a tax. When the same requirement shapes the design from the start, it does the opposite: it forces good questions early, while they are still cheap to answer. This is a perspective on building, not medical or legal advice, and any real product still needs qualified regulatory and clinical review.

I came to this view by living on both sides of it. I trained in medicine, worked in global clinical development at Novo Nordisk, and earned training in medical device regulations at KTH covering EU MDR, IVDR, and software as a medical device, along with FDA clinical investigator training. Then I co-developed EASY Diabetes, a decision-support system we put through a randomized trial. Doing the regulatory reading first and the building second taught me that the rules are mostly a checklist of the questions a careful engineer would want answered anyway.

Where the resistance comes from

Most of the friction is about timing, not substance. A small team wants to move fast, show something working, and learn from users. Regulation looks like paperwork that arrives to slow that down. The instinct is understandable, and I have felt it. The trouble is that leaving the regulatory questions for later does not remove them. It just defers them to the most expensive possible moment, after the architecture is set and changing it means rework.

There is a quieter cost too. A tool built without those questions tends to be vague about what it is actually for, who it is safe for, and what happens when it is wrong. Users feel that vagueness even when they cannot name it. Clarity about purpose is not a compliance nicety. It is what makes a tool trustworthy at the point of care.

What an intended-use statement does to a design

The single most useful regulatory artifact is also the simplest: a clear statement of intended use. Who is the user, which patients, in what setting, for what decision, and explicitly not for what. It reads like bureaucracy. In practice it is the sharpest design tool I know.

Write that sentence honestly and the product almost designs itself. If the tool supports a clinician choosing a treatment, the interface should present evidence and options, not a single command. If it is for a specific patient group, the onboarding should check that the person in front of the screen belongs to it. If it is not for diagnosis, the language must never imply one. Every screen inherits its job from that one statement. Skip it, and the design drifts toward doing a little of everything, which in medicine is how a tool ends up unsafe for everyone.

Risk management as a source of better defaults

Formal risk management sounds like a register of unlikely catastrophes. What it really produces, when you do it early, is a set of better defaults. You sit down and ask what could go wrong, how badly, and how often, and the answers change the product.

A simple example from decision support: what should the system do when its inputs are incomplete or strange? Without the risk lens, the easy choice is to give an answer anyway, because an answer feels helpful. With it, you design the tool to notice its own uncertainty and say so, because a confident output from bad inputs is the failure mode that hurts people. That single decision, to make the safe behavior the default, came straight out of asking the regulatory question first. Good risk thinking does not add features. It removes the dangerous ones before they ship.

What I learned building under these rules

With EASY Diabetes, the discipline of defining the clinical claim before building it shaped everything that followed. Because we knew what we were claiming, we knew what we had to prove, which is why the work went into a randomized trial rather than a benchmark. The intended use told us who to enroll. The risk analysis told us which behaviors to make conservative. None of that slowed the real work. It aimed it.

The honest summary is that the regulation rarely told us something we would not have wanted to know. It told us to find out now rather than later, and to write it down so the next person could check it. That habit, deciding the claim first and proving it second, is the difference I would defend to any team.

The cultural shift worth making

The deepest change is cultural, not procedural. A team that sees regulation as an enemy hides problems and races to launch. A team that sees it as a design partner surfaces problems early, when they are cheap, and treats the documentation as a way of thinking clearly rather than a chore. The same rules feel heavy to the first team and light to the second, because the second one is using them for what they are good at.

None of this means every rule is perfectly written or that compliance is the same as quality. Regulation can be done badly, as a stack of documents nobody reads. Done well, it is simply the engineering discipline that medicine has learned the hard way over decades. Bring it in at the start, let it shape the design, and you do not get a slower product. You get one a clinician can trust with a patient.