STRATEGYRegulatory & SaMD strategy

Regulatory strategy for software as a medical device is the work of deciding early what your product legally is, and building the quality system and evidence that follow from that answer. It covers qualification, classification, the certification route, and the QMS structure needed to survive an audit — while those decisions are still cheap to change.

What the work involves

Qualification: whether the software is a medical device at all, judged on its intended purpose
Classification under EU MDR Annex VIII — in practice Rule 11 — and the corresponding FDA device classification
Route selection and sequencing: CE marking, 510(k), De Novo, and which market to enter first
Quality management system structure for a software-only manufacturer, including what can legitimately be excluded
Design control architecture: making the engineering process produce the records the standard expects, as you work
IEC 62304 software safety classification, and the architectural segregation that follows from it
Risk management setup under ISO 14971, including how to treat software failure probability honestly
Notified body selection and timeline planning against real review queues
Technical documentation structure, so the submission assembles rather than gets written

Who it's for

Founders pre-certification, typically pre-seed to Series A
Engineering leaders from consumer technology now facing design controls for the first time
Clinicians, scientists, and research spinouts moving a discovery toward a product
Teams with a working prototype and no regulatory plan behind it
Companies whose investors, partners, or first hospital customer have started asking about the pathway

What it isn't

Not a template QMS package. Document trees are cheap; the evidence behind them is the work.
Not outsourced regulatory affairs. Someone inside the company has to own the quality system, and the goal is to get you there.
Not a notified body, a certification body, or an auditor.
Not legal advice.

Common questions

When should we start thinking about regulatory strategy?

Before the architecture is fixed. Classification determines your IEC 62304 safety class, which determines both the documentation burden and how the system should be segregated. Retrofitting design controls and traceability onto an existing codebase is the most expensive avoidable mistake in this field, and the reconstruction is visible in the record.

Is our software actually a medical device?

It depends entirely on intended purpose — what you claim the product does, including in your marketing. Under EU MDR, software providing information used to take diagnostic or therapeutic decisions is a medical device, and Rule 11 usually places it in Class IIa or above. A landing page claiming the product detects a condition can qualify software your regulatory file describes as wellness.

Should we launch in the EU or the US first?

Both are defensible; the answer depends on your evidence, your market, and your investors. Sequencing matters because the two systems now share a quality system baseline — FDA’s QMSR incorporates ISO 13485 — but differ on premarket route and clinical evidence expectations. Building for one while keeping the other reachable is usually cheaper than converting later.

How long does certification take?

For anything Class IIa or above, notified body capacity is usually the binding constraint rather than engineering effort. Plan in quarters rather than weeks, and contract review capacity early — the queue is not something a well-run project can compress.

Do we need a full QMS before we can sell anything?

For Class IIa and above in the EU, yes: conformity assessment includes an audit of the quality system, and the surveillance and post-market plans are reviewed before you have any post-market data. What varies is scope. A software-only manufacturer excludes or justifies large parts of ISO 13485, and the design control clauses carry nearly all the weight.

A limited number of advisory conversations are taken on at any time.

Get in touch →