Subtract to Ship is a methodology for shipping under constraints by removing work that does not contribute to the outcome, instead of adding work that looks productive. Applied to MDR, the framework means: strip every activity, every document, every feature, and every process step that does not trace back to a specific article, annex, or harmonised standard required for your device. What remains is the work that actually gets you certified. Everything else is waste, no matter how diligent it looks.
By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.
TL;DR
- Subtract to Ship is not a MedTech framework. It is a general methodology developed by Felix Lenhard across 44 startups and refined under real resource constraints. This post applies it to MDR.
- The central move is subtraction: every deliverable, every process, every feature, every document must earn its place by tracing to a specific MDR obligation. If it cannot, it comes out.
- The framework has four passes: the Purpose Pass, the Classification Pass, the Evidence Pass, and the Operations Pass. Each one removes a category of waste that shows up consistently in startup regulatory projects.
- Subtraction is harder than addition. Cutting a document feels reckless. Cutting the wrong document is reckless. Cutting the right document is survival.
- The framework ends with a single test: can every remaining activity be defended by pointing to a specific MDR article or annex? If yes, ship. If no, cut more.
Why subtraction, not addition
The instinct in regulatory projects is to add. Add documents. Add processes. Add checklists. Add review layers. Add consultants. Every addition feels like diligence. The cumulative result, in almost every startup we have watched, is a regulatory project that is too slow, too expensive, and too brittle to survive first contact with a Notified Body audit.
The underlying reason is that regulatory work rewards the appearance of rigour. More pages look like more quality. More signatures look like more control. More processes look like more maturity. None of these are actually true. More documentation is not more quality — the phrase is Tibor's, and it applies to every chapter of the regulatory file. EN ISO 13485:2016+A11:2021 does not require volume. It requires that documentation represent real processes accurately and completely. A half-page procedure that is followed beats a twenty-page procedure that is ignored.
Subtract to Ship is the discipline of cutting the work that is not real. It does not mean cutting corners. It means cutting the parts that add no compliance value and drain the runway. The test is always the same: does this activity trace to a specific obligation in the MDR, an annex, or a harmonised standard? If not, it comes out.
The framework came out of Felix's work with startups in non-regulated industries, where the discipline of removing everything that did not move the needle saved companies during the pandemic. When a consumer company like Vulpine had to strip to the essential features to survive, three things became clear. Nobody used most of the side features. Scarcity forced better decisions than abundance would have. And the founder's stubbornness compounded only when the scope was small enough to finish. Every one of those lessons transfers into regulatory work, even though the domains look different.
The four passes
Subtract to Ship for MDR runs through four passes, each one targeting a different layer of waste. The passes run in order because later passes depend on the decisions made in earlier ones. Running them out of order produces the Graz over-documentation pattern — a mountain of work against a moving target.
Pass 1 — The Purpose Pass
The first pass asks: what is the intended purpose, and does this product actually need MDR at all?
MDR Article 2(1) defines a medical device by intended purpose. The intended purpose in turn is defined in Article 2(12) as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, or in promotional or sales materials or statements, and as specified by the manufacturer in the clinical evaluation. That definition is the single most leveraged sentence in the entire Regulation. Change the intended purpose, and the device might not be a medical device at all.
We have worked with a company that arrived convinced they were building a medical device and expecting to start certification. The Purpose Pass produced a different outcome. We documented everything proving the product was not a medical device: we analysed the intended purpose, removed medical claims from the website, and separated the product page from the scientific literature page — because scientific context is not the same as a medical claim, and the two had been tangled together in a way that moved the product across the line. The product stayed on the market. The company continued generating revenue. Years of certification work and hundreds of thousands of euros — saved, because the intended purpose made clear the regulation did not apply.
Another company we worked with — based in Graz — had spent months building an MDR strategy. After the Purpose Pass, a small revision to the intended purpose re-framed the product as a wellness device. Not a change to the technology. Not a change to the product. Just a change to the regulatory positioning, made deliberately and with expert input. Market entry became much faster. (The lesson is not that every product can do this — it cannot. The lesson is that the Purpose Pass is where this discovery happens, if it is possible at all.)
The Purpose Pass ends with one of three outcomes. Either the product is not a medical device and MDR does not apply. Or the product is a medical device and the intended purpose is written down, stable, and defensible. Or the intended purpose is still unclear and the project is not ready for Pass 2.
Pass 2 — The Classification Pass
The second pass asks: what is the lowest defensible classification of this device, and what is the lightest conformity assessment route consistent with that classification?
MDR Article 51 and Annex VIII govern classification. Classification is not always black and white. We worked on a combined hardware-software device where the software side was clearly Class IIa — no dispute — but the hardware side was disputed: was it Class I, or Class I with measurement function? The distinction mattered because measurement function triggers additional conformity assessment requirements. A deep dive into the evidence produced a defensible argument that the hardware was Class I only. The Notified Body accepted it. This is not gaming the system. It is applying the classification rules correctly with supporting evidence — the rules allow for judgment, and the judgment produced a lighter path.
The Classification Pass has two outputs. The first is the classification itself, with the specific rule in Annex VIII that applies. The second is the conformity assessment route, selected from MDR Article 52 and the corresponding annex.
Subtraction in the Classification Pass means cutting every activity that would only be required at a higher class than the one that actually applies. Startups frequently over-scope their QMS, their risk file, and their clinical evidence because they are vaguely worried about "the requirements." The requirements are not vague. They are specified by class. Know the class, read the requirements, do those, and subtract the rest.
Pass 3 — The Evidence Pass
The third pass asks: what is the minimum evidence needed to demonstrate conformity, and what is the cheapest path to that evidence?
Every GSPR in Annex I must be addressed in the technical file. Every applicable harmonised standard provides presumption of conformity for the specific requirements it covers. Clinical evaluation under MDR Article 61 and Annex XIV can draw on literature, equivalence, or new clinical investigation — the three sources are not equivalent in cost or time, and the choice matters enormously.
There is a Graz-based company we worked with that had an innovative technology using two established measurement methods. Their initial plan was to run 2–3 clinical investigations — years of work, hundreds of thousands of euros. The Evidence Pass asked a different question: do existing harmonised standards cover the established measurement methods? They did. Because the measurement methods were well-established and covered by recognised standards, clinical investigations were not required for those aspects of the device. The Notified Body accepted the approach. The company saved EUR 400,000–500,000 and 1–1.5 years of development time.
This is what the Evidence Pass looks like in practice. Before defaulting to expensive evidence pathways, exhaust the cheaper ones. Literature review where literature exists. Equivalence where equivalence can be demonstrated per MDCG 2020-5. Existing standards where they cover the question. New clinical investigation only when nothing else suffices. These are not shortcuts. They are legitimate pathways that the Regulation explicitly recognises.
Subtraction in the Evidence Pass means cutting every piece of evidence that duplicates another piece of evidence already in the file. One well-documented chain beats three parallel chains that confuse the auditor and obscure the argument.
Pass 4 — The Operations Pass
The fourth pass asks: given the decisions from Passes 1–3, what is the minimum QMS and PMS system required to support this specific device, and how much of the work can be done by the smallest possible team?
EN ISO 13485:2016+A11:2021 scales with risk class and organisational size. MDR Article 10(9) requires the QMS to be proportionate to the risk class and type of device. "Proportionate" is a word that most startups interpret wrongly — they either assume it means "full QMS as large as the consultant suggests" or they assume it means "whatever we feel like." Neither is correct.
Proportionate means the QMS covers every required process and does so at a depth that matches the risk. For a Class I device, this can be a small, focused QMS run by a two- or three-person team with external PRRC coverage under Article 15(2). For a Class IIb device, it cannot. The Operations Pass works out which of these two scenarios you are actually in and removes everything that belongs to the other one.
We worked with a Vienna-based QA manager who built a QMS for a small startup by taking a basic framework from a previous company and going through every single process — matching each one to the actual company operations, removing what did not apply, adding what was missing. No overkill. Nothing missed. The result was lean, accurate, and a perfect fit. That is the Operations Pass done right. The Berlin template disaster we mentioned in other posts — the company that bought templates and replaced the placeholder company name — is the Operations Pass done wrong.
The Operations Pass also covers PMS. MDR Article 83 requires every manufacturer to have a PMS system proportionate to the risk class and appropriate for the device. MDCG 2025-10 (December 2025) describes what this looks like in practice. For a Class I startup, a minimal PMS system that actually runs beats an elaborate PMS system that exists only in the binder.
The final test
At the end of the four passes, apply the single defining test of the framework. Walk through every activity, every document, every process step, and every feature that is still in scope. For each one, ask: what specific MDR article, annex, or harmonised standard requirement does this trace to?
If the answer is a clear, specific article or annex, keep it. If the answer is "audit best practice" or "consultants usually recommend it" or "someone said we should," cut it.
Some things will survive this test that founders are surprised by. Vigilance reporting, PMS data collection, CAPA records, training records — all required, all traceable to specific provisions. Others will not survive — the nice-to-have documentation templates, the speculative risk analyses of hazards that cannot occur, the redundant review layers, the project management artifacts that exist to make the project look organized.
The final test is uncomfortable to apply because it forces founders to defend every piece of work against the actual Regulation, not against a vague sense of what "looks like" compliance. This is exactly why it works.
What Subtract to Ship is not
It is not permission to skip required work. Every obligation in the MDR that applies to your device stays in scope. The framework cuts waste, not compliance.
It is not an anti-consultant position. A good regulatory sparring partner runs this framework with you. A bad one sells you more work.
It is not an anti-documentation position. Documentation that is required and actually used is essential. Documentation that is required and actually used is often less than the volume startups produce by default.
It is not a permission slip to take shortcuts with patient safety. The red lines in this book and in Tibor's practice are absolute. No illegal testing. No unvalidated software in clinical use. No grey-area exports. Subtract to Ship cuts waste. It does not cut safety.
Reality Check — Where do you stand?
- Can you walk through your current regulatory plan and, for each activity, name the specific MDR article or annex it traces to?
- If you cannot name the article for an activity, why is the activity still in the plan?
- Have you run a deliberate Purpose Pass on your intended purpose, or did you assume from day one that the product was a medical device?
- Do you know the lowest defensible classification of your device, with the specific Annex VIII rule?
- For each piece of clinical evidence in your plan, have you evaluated whether a cheaper pathway exists (literature, equivalence, harmonised standard)?
- Is your QMS sized for your actual risk class, or for a larger or smaller one?
- When was the last time you cut something from the regulatory plan — not added, cut — and what happened?
Frequently Asked Questions
Is Subtract to Ship a recognised regulatory framework? No. It is a methodology developed by Felix Lenhard for startups operating under resource constraints, applied here to MDR by Tibor and Felix together. The Regulation itself does not name the framework, and it does not need to — every activity that survives the framework traces directly to a specific MDR article or annex. The framework is a way of using the Regulation, not a replacement for it.
Can you subtract your way out of required clinical evidence? No. Clinical evidence required by MDR Article 61 and Annex XIV is required regardless of framework. What Subtract to Ship does is identify the cheapest legitimate pathway to that evidence — literature, equivalence, existing standards, or new clinical investigation — and eliminate parallel or redundant work. The obligation stays; the path is optimised.
How do I know I have subtracted too much? The final test. If you cannot trace every remaining activity to a specific MDR obligation, you have subtracted correctly. If you cannot explain why a required MDR obligation is missing from your plan, you have subtracted too much. The difference is between cutting unnecessary work and cutting required work, and the Regulation itself is the referee.
Does Subtract to Ship work for Class III devices? The framework applies to every class, but the amount of work that survives the passes is very different. A Class III device after Subtract to Ship still has substantial QMS, technical documentation, clinical investigation, and post-market obligations. A Class I device after Subtract to Ship can be very lean. The framework does not make devices easier than the Regulation allows. It prevents them from being harder than the Regulation requires.
Who should run the framework? Someone with deep knowledge of both the Regulation and startup constraints. A pure regulatory consultant will often miss the subtraction opportunities because their incentive is to recommend more work. A pure startup operator will miss the compliance requirements because they do not know what has to survive. The framework works best when both perspectives are present, either in one person with both backgrounds or in a partnership between a sparring partner and a founder.
Related reading
- The Minimum Viable Regulatory Strategy for MDR — the companion post that operationalises the framework for CE marking with limited resources.
- The Beachhead Strategy: Wellness First, Medical Device Later — a specific application of the Purpose Pass.
- The Two-Phase Development Approach — the time-axis application of Subtract to Ship.
- DIY vs. Hiring a Regulatory Consultant — how to run the framework with and without external support.
- How to Build a Regulatory Roadmap for Your MedTech Startup — placing the four passes within a full timeline.
Sources
- Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(1) (definition of medical device), Article 2(12) (intended purpose), Article 10 (manufacturer obligations, including 10(9) on QMS), Article 15 (PRRC), Article 51 (classification), Article 52 (conformity assessment procedures), Article 61 (clinical evaluation), Article 83 (PMS system), Annex I (GSPR), Annex II (technical documentation), Annex VIII (classification rules), Annex XIV (clinical evaluation). Official Journal L 117, 5.5.2017.
- EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
- EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.
- MDCG 2020-5 — Clinical Evaluation — Equivalence: A guide for manufacturers and notified bodies, April 2020.
- MDCG 2021-24 — Guidance on classification of medical devices, October 2021.
- MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices, December 2025.
This post is part of the MDR Fundamentals & Regulatory Strategy series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The Subtract to Ship framework is the methodology behind everything in this blog and the companion book, applied specifically here to navigating MDR as a resource-constrained startup.