REGULATORY INSIGHT

Software as a medical device — the difficulty of not exceeding the approved scope

22 August 2026

Software as a medical device may be supplied only within the intended use or effect for which it was approved or certified. That much is common to medical devices generally.

Software, however, has a circumstance the others do not. An update adds a function, users find a use nobody anticipated, and the scope drifts without the supplier ever intending it to.

Software on its own became a medical device

The 2014 amendment to Japan's Pharmaceuticals and Medical Devices Act placed software, on its own, within the definition of a medical device. On the Ministry of Health, Labour and Welfare's approach to that question, software as a medical device is software that, if it does not function as intended, may affect human life and health.

The examples given of an intended use include diagnosis of disease — screening, detecting or finding signs of disease early, assessing severity — and treatment of disease, such as proposing a treatment plan or delivering behavioural therapy.

What matters here is that the intended use is set by what the software was approved to be used for, not by what it is capable of doing. That something is technically possible and that you may supply it for that purpose are two different questions.

Two-stage approval makes the scope narrower still

Recognising what is particular to software, there is a route by which a first-stage approval can be obtained for a use or effect limited to what has been established so far, even where the clinical significance ultimately sought has not yet been shown. Approval is granted first for a limited scope, on the basis of non-clinical testing and exploratory clinical work.

For a developer this makes it easier to move forward. Read the other way round, though, the first-stage scope is deliberately set narrower than what the developer ultimately wants to deliver. It is a structure in which claiming or supplying beyond the scope becomes easy to do.

How software departs from the scope

Departures from the approved scope happen without anyone intending them.

• A function added in an update. Something added as a convenience turns out to reach into a use outside the approved scope.
• The way it is described. Sales material or a web page reads more broadly than the approved intended use.
• How people use it. It is used for something the supplier did not anticipate, and requests accumulate that assume that use.
• Wider integration. Connect it to another system and the way its output is used changes.

Is this added function inside the approved intended use? If it is outside, does it need a partial change approval? When was that judgement made, and by whom?

In software development, decisions to add a function are made daily, and they are made in many places at once. The question becomes whether you can show afterwards that each of those decisions was checked against the approved scope at the time it was made.

The move towards certification standards is under way

PMDA describes itself as taking the lead in drawing up and revising certification standards for software as a medical device where there is a track record of approvals. Categories that have become established move towards third-party certification.

Whether you conform to a certification standard is assessed within a different framework from an approval review. Which route your own product takes, and whether a revision to a standard means re-establishing conformity, is something to keep in view continuously.

Worth checking now

• Whether the development team knows, precisely, the wording of the intended use and effect that was approved or certified.
• Whether there is a step that checks a proposed function against the approved scope when it is being considered.
• Whether a record survives of who made that judgement, and when.
• Whether sales material, the website and the in-app text can be read as going beyond the approved scope.
• Where you hold a first-stage approval, whether the limitation on scope is understood across the organisation.

Carry it by hand, or build it in

Having a regulatory affairs colleague check each addition will work as a routine. But the faster development moves, the further behind the checking falls, and you lose the ability to establish afterwards which changes went out without one.

We research and develop technology that carries conformity with regulation as a mechanism rather than as manual routine, and we hold the results as patent applications. We have filed in this area as well.

We follow these rules as they come into force. Updates are available by RSS.

← Back to Insights