A regulatory strategy for global market access is not a stack of separate country plans. It is a single framework with a shared evidence core and a shared quality management system, plus thin country-specific overlays for each jurisdiction the company actually intends to enter. The shared core is built around the EU Medical Device Regulation (Regulation (EU) 2017/745) as the anchor, EN ISO 13485:2016+A11:2021 as the QMS baseline every major market recognises in some form, and the MDSAP audit model as the leverage mechanism that lets one audit satisfy multiple national QMS expectations. Each new market reuses the same technical documentation, the same risk file, the same clinical evidence, and the same QMS — overlaid with whatever the target authority requires on top. Scalability comes from that reuse. Startups that build country plans in parallel pay for the same evidence five times.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • A scalable regulatory strategy for global market access treats the technical documentation, the risk file, the clinical evidence, and the QMS as a single shared core that is reused across jurisdictions, not rebuilt for each one.
  • The MDR, Regulation (EU) 2017/745, anchors the core because its Annex II technical documentation structure and Annex IX QMS-plus-technical-documentation assessment route are the most demanding baseline in common use — evidence that passes MDR generally transfers well to other frameworks with additions, not rewrites.
  • EN ISO 13485:2016+A11:2021 is the common QMS language recognised in some form by the EU, Canada, Australia, Japan, Brazil, and the US FDA under the updated Quality Management System Regulation alignment. One QMS, many overlays.
  • The Medical Device Single Audit Program, governed by IMDRF and its participating authorities, is the leverage mechanism that collapses multiple national QMS audits into a single coordinated audit when Canada plus one other MDSAP jurisdiction is in the plan.
  • Scalability fails when the company builds each country as a separate project with its own technical file, its own risk file, and its own QMS binder. That is not a global strategy — it is five local strategies sharing a letterhead.

Why "a stack of country plans" is not a strategy

The most common failure mode we see in MedTech regulatory planning is the country-by-country binder. One folder for the EU, one for the US, one for Canada, one for Australia. Each folder has its own technical file draft, its own risk file, its own QMS procedures, its own labelling set. The team tells itself this is careful, market-specific work. What it actually is is the same evidence copied five times, maintained five times, and audited five times, with silent divergence between the copies as change orders hit one folder and not the others.

That is not scalable. It is the opposite of scalable. Every new market doubles the maintenance cost rather than adding a thin increment. The first sign of trouble is usually a Notified Body finding or an FDA observation that references a version of a document that the team cannot find, because the document exists in four versions across four folders and none of them is the master.

A scalable framework inverts the model. There is one technical file, one risk file, one clinical evaluation, one QMS. Each market is an overlay on top of that core — a set of deltas, not a parallel universe. When the core changes, every market inherits the change. When a market needs something the core does not have, the overlay holds that specific item and nothing else.

This is a boring architectural decision. It is also the difference between a MedTech company that can enter three markets in two years and a MedTech company that collapses under the weight of its own paperwork trying to enter two.

What scalable compliance actually means

Scalable compliance has three properties that non-scalable compliance does not.

The first property is a single source of truth per artefact. There is one technical documentation set structured to MDR Annex II, not one per market. There is one risk management file maintained under EN ISO 14971:2019+A11:2021, not one per market. There is one clinical evaluation, updated on a single cadence, not one per market. Multiple markets read from these artefacts. None of them own forked copies.

The second property is a shared QMS spine. EN ISO 13485:2016+A11:2021 is the baseline. Every major market recognises it in some form — the EU uses it as the harmonised QMS standard under the MDR, Canada requires it as the MDSAP audit basis, Australia accepts it as one of the TGA's recognised QMS routes, Japan and Brazil use it as the reference standard within their MDSAP overlays, and the US FDA has aligned its Quality Management System Regulation to ISO 13485 as the foundation. One QMS, audited once or a small number of times, covers all of them with jurisdiction-specific overlays for what each authority adds on top.

The third property is that country-specific work is additive, not reconstructive. The French labelling set is added on top of the core. The Japanese J-DSUR formatting is added on top of the core. The FDA-specific predicate comparison for a 510(k) is added on top of the core. None of these trigger a rewrite of the core artefacts. They live in defined overlay locations and are maintained separately.

If the architecture does not have these three properties, it is not scalable, regardless of how carefully the country folders have been organised.

The shared evidence core

The shared evidence core is the set of artefacts that every market reads from. It is not the full compliance package for any single market — it is the reusable substrate that every market's compliance package is built on.

The shared core typically contains the technical documentation structured according to MDR Annex II (device description and specification, design and manufacturing information, general safety and performance requirements checklist, benefit-risk analysis and risk management file, product verification and validation), the risk management file under EN ISO 14971:2019+A11:2021, the clinical evaluation and its supporting clinical data, the usability engineering file under EN 62366-1:2015+A1:2020, the software lifecycle documentation under EN 62304:2006+A1:2015 if the device contains software, the biocompatibility evidence under EN ISO 10993-1:2025 if applicable, and the labelling masters.

The MDR is the anchor for this core because its Annex II structure is one of the most demanding in common use. A technical file that satisfies MDR Annex II generally contains every element that FDA, Health Canada, the TGA, PMDA, and ANVISA also want to see — the difference is format, presentation, and a handful of jurisdiction-specific additions. A technical file built first to satisfy the FDA 510(k) structure, by contrast, is usually missing several elements that MDR requires and triggers substantial rework on the way to Europe. Building to the higher bar first is not a bureaucratic preference — it is the architecture that minimises total rework across the whole expansion.

Country-specific overlays

Each market adds an overlay on top of the shared core. The overlay holds exactly the things the core does not and nothing more.

For the United States under the FDA framework, the overlay holds the 510(k) submission package or De Novo request itself, the predicate device comparison, the FDA-specific labelling elements, the US agent designation, the establishment registration and device listing, and any FDA-specific testing that goes beyond the core (for example, specific biocompatibility testing to FDA-recognised versions of ISO 10993 parts where they differ from the European harmonisation).

For Canada under Health Canada, the overlay holds the Medical Device Licence application, the Canadian Medical Device Conformity Assessment System documentation, bilingual labelling, and the MDSAP audit certificate.

For Australia under the TGA, the overlay holds the ARTG inclusion application, the Australian Sponsor designation, and the TGA conformity assessment evidence route selection.

For the United Kingdom under the MHRA, the overlay holds the UKCA or CE-recognition route documentation (depending on the current transitional position), the UK Responsible Person designation, and the Device Online Registration with the MHRA.

For Switzerland under Swissmedic, the overlay holds the Swiss Authorised Representative designation and the Swiss-specific registration.

None of these overlays contain a reconstructed risk file. None of them contain a reconstructed clinical evaluation. None of them fork the technical documentation. They point back to the core and add exactly what the jurisdiction demands in addition.

The QMS as the common foundation

The QMS is where scalability is won or lost. A company that runs one QMS under EN ISO 13485:2016+A11:2021 with well-defined jurisdictional overlays can enter five markets with incremental audit scope. A company that runs five versions of its QMS for five markets has built a machine that is expensive to operate and impossible to audit cleanly.

The architecture that works is a single QMS with clearly marked jurisdictional procedures. The core QMS covers the processes every market expects — management responsibility, resource management, design and development, purchasing, production, monitoring and measurement, CAPA, internal audits, management review. On top of the core sit jurisdiction-specific procedures where an authority adds something the core does not: US complaint handling and Medical Device Reporting under 21 CFR Part 803, EU post-market surveillance and vigilance under MDR Articles 83–92, Canadian mandatory problem reporting, Japanese and Brazilian overlays specific to those markets.

The jurisdictional overlays are not separate QMSes. They are named procedures inside the one QMS, activated for the jurisdictions they apply to. The internal audit covers them all on one cycle. The management review sees them all on one dashboard. The CAPA system has one queue, not five.

This is the architecture that lets one QMS audit — especially an MDSAP audit — actually cover multiple jurisdictions without pretence. For the mechanics of MDSAP as a multi-market audit mechanism, see post 635.

How to plan market additions without re-doing the file

The operational question a scalable framework has to answer is: when we add a new market to the plan, what actually has to change?

The answer, in a well-architected framework, is narrow. The shared evidence core does not change unless the new market demands something genuinely additional to what the MDR-anchored core already contains — which is rare for the common expansion jurisdictions. The QMS gains a new jurisdictional overlay for whatever that authority expects beyond the core. The labelling set gains new language variants and any jurisdiction-specific statements. The regulatory submission for the new market is assembled by pulling the existing core artefacts, adding the jurisdictional overlay documents, and producing the submission in the format the authority expects.

What does not happen in a well-architected framework: the risk file is not rewritten. The clinical evaluation is not redone. The software lifecycle documentation is not reconstructed. The QMS procedures for design and development are not forked. The technical file is not split into a "European version" and an "American version."

When a team finds itself doing any of these things, that is the signal the framework has stopped being scalable and is drifting toward the country-folder antipattern. The fix is usually to refactor the core so that the thing the new market demanded lives in the core once and is referenced by every market, rather than being duplicated into one market's fork.

For the startup-scale view of how this sequencing plays out in practice, see post 636. For the full end-to-end checklist that operationalises the framework into a step-by-step plan, see post 645.

The IMDRF and MDSAP leverage

The International Medical Device Regulators Forum and its Medical Device Single Audit Program are the mechanisms through which global regulatory convergence actually reduces work rather than just producing harmonisation papers.

At the general framing level, IMDRF produces guidance documents and technical papers that several major authorities cite or adopt in their own frameworks. The practical leverage for startups comes from MDSAP specifically: a single QMS audit, performed by a recognised Auditing Organisation against EN ISO 13485:2016+A11:2021 plus the country-specific regulatory overlays, can satisfy the QMS inspection needs of the US FDA (for routine QMS inspections, with the exceptions defined by the FDA programme), Health Canada (where MDSAP is effectively mandatory for most device classes), the Australian TGA (as one recognised QMS evidence route), Japan's PMDA, and Brazil's ANVISA.

The leverage is not that MDSAP grants market access. It does not. Each jurisdiction still requires its own premarket submission — the FDA 510(k), the Canadian Medical Device Licence, the ARTG inclusion, the Japanese and Brazilian registrations. What MDSAP collapses is the QMS inspection layer, which without MDSAP would be five separate national audits on five separate calendars with five separate findings lists. One MDSAP audit replaces that with one coordinated visit.

For a startup building a scalable framework, MDSAP is the mechanism that turns the shared QMS foundation from a design intention into an operationally audited reality. Without MDSAP, a startup can architect a single QMS across jurisdictions in theory, and then have five national auditors each find something different to raise about it in practice. With MDSAP, the same QMS is tested once against all the overlays in one go.

The MDSAP bundle does not cover the European Union. EU conformity assessment under MDR Annex IX remains a separate activity performed by an EU Notified Body under the MDR. The scalable framework contains both: the EU route through a Notified Body, and the non-EU QMS audit route through MDSAP where the markets in the plan justify it. For the Canada-specific forcing function behind MDSAP sequencing, see post 634.

Common framework mistakes

The mistakes that break scalable frameworks are architectural, not procedural. They are usually decisions someone made early in the company's regulatory life that felt local and reasonable at the time and created scaling drag three years later.

  • Building the first technical file to the FDA 510(k) structure instead of MDR Annex II. The 510(k) format is narrower than Annex II in several places, and retrofitting the missing sections for Europe later costs more than building to Annex II first. The MDR is the higher bar; build to the higher bar first.
  • Treating the QMS as the EU QMS with plans to "add" the US QMS later. There is no US QMS separate from the core. The US requirements live as jurisdictional overlays inside the one QMS. Building a separate US QMS is the country-folder antipattern applied to quality management, and it scales just as badly.
  • Forking the risk file by jurisdiction. Every major market accepts a risk management file maintained under EN ISO 14971:2019+A11:2021. One file, one cadence. The moment a team maintains two risk files for two markets, the scaling is broken.
  • Treating MDSAP as something to decide about later. MDSAP is an architectural choice, not a late-stage optimisation. If Canada is in the plan, MDSAP is part of the QMS architecture from the start, because retrofitting an MDSAP-ready QMS after the fact is significant work.
  • Letting clinical evaluation diverge per market. The clinical evaluation under MDR Article 61 and Annex XIV is structurally compatible with what other major jurisdictions expect, with additions. Maintaining one clinical evaluation and adding jurisdictional commentary is the scalable pattern. Running two or three clinical evaluations in parallel because each market's template is slightly different is not.
  • Confusing language variants with substantive forking. Translating labelling into French, German, Japanese, and Portuguese is overlay work. It does not fork the core. Teams sometimes treat translated labelling as the beginning of a separate country file — it should stay a labelling variant and nothing more.
  • Not naming an owner for the shared core. The shared core needs a single responsible owner — usually the head of regulatory affairs or the PRRC under MDR Article 15. When ownership is diffuse, the core drifts into per-market forks because no one is enforcing the architecture against local pressure.

The Subtract to Ship angle on the framework

Subtract to Ship applied to a global regulatory framework means the opposite of what it sounds like. It does not mean cutting the regulatory work. It means cutting the duplication that makes regulatory work unscalable.

The subtractions that matter are the parallel country plans that should have been overlays, the forked technical files that should have been one file, the separate risk files that should have been one file, the jurisdictional QMSes that should have been one QMS with overlay procedures, and the per-market clinical evaluations that should have been one clinical evaluation with jurisdictional annotations.

Every one of those subtractions trades a short-term feeling of local control for a long-term scaling property. The company that makes the trades can enter new markets as incremental overlays. The company that does not ends up maintaining five parallel regulatory projects that happen to share a product.

The MDR is the anchor because its evidence requirements set the highest commonly applied baseline. Build the core to the MDR and most other jurisdictions become additive. Build the core to any other baseline first and the MDR step turns into a rewrite later. That is not a philosophical claim — it is a sequencing observation from working through both directions with many companies. For the full methodology, see post 065.

Reality Check — Is your framework scalable?

  1. Do you have exactly one technical file structured according to MDR Annex II that every market reads from, or do you have separate drafts per market?
  2. Do you have exactly one risk management file under EN ISO 14971:2019+A11:2021, or has it started to fork by jurisdiction?
  3. Is your QMS one system with named jurisdictional overlay procedures, or is it drifting toward separate QMSes for separate markets?
  4. When you add a new market to the plan, do you know exactly which overlay documents change and which core documents do not, or is the answer "we will figure it out when we get there"?
  5. If Canada is anywhere in your three-year plan, is MDSAP part of your current QMS architecture, or is it something you are planning to retrofit later?
  6. Does the shared core have a single named owner, or is responsibility diffused across whoever happens to be working on which market this quarter?
  7. Can you hand a new regulatory affairs hire a one-page description of the framework architecture, or would they have to read five country folders to understand how it works?

If more than three of these produced a "not yet," the framework is on the country-folder antipattern trajectory. Refactor the core before the next market is added, not after.

Frequently Asked Questions

What does "scalable compliance framework" mean in a MedTech context? A scalable compliance framework is a single set of regulatory artefacts — technical documentation, risk file, clinical evaluation, QMS — that is reused across multiple markets, with thin jurisdictional overlays added on top for country-specific requirements. It is the opposite of maintaining a separate technical file, risk file, and QMS for every market. Scalability means adding a new market is an incremental overlay, not a new project.

Why is the MDR the anchor for a global framework? Because the MDR's Annex II technical documentation structure and its general safety and performance requirements are among the most demanding in common use. A technical file that satisfies MDR Annex II generally contains the evidence elements that the FDA, Health Canada, the TGA, PMDA, and ANVISA also expect, with jurisdiction-specific additions. Building to the MDR first minimises rework when expanding to other markets.

Can one QMS really cover the EU, the US, Canada, Australia, Japan, and Brazil? Yes, when architected correctly. The QMS is built around EN ISO 13485:2016+A11:2021 as the common baseline, with jurisdictional procedures as overlays for what each authority adds on top. The FDA Quality Management System Regulation alignment with ISO 13485, the MDR harmonisation of ISO 13485, and the MDSAP audit model all point to one-QMS-many-overlays as the feasible architecture for multi-market operation.

What is the role of MDSAP in a scalable framework? MDSAP is the leverage mechanism that lets a single QMS audit cover the QMS inspection needs of five participating authorities — the US FDA, Health Canada, the Australian TGA, Japan's PMDA, and Brazil's ANVISA. It does not grant market access; each jurisdiction still requires its own premarket submission. But it collapses five national QMS audits into one coordinated audit, which is the operational difference between a scalable framework and five parallel audit programmes.

How do we know our framework has drifted into the country-folder antipattern? The most reliable signals: multiple technical file versions for the same device, multiple risk files, separate QMS procedures per market for processes that should be common, change orders that hit one market's documents and not the others, and no single named owner of a shared core. If any of these are present, the framework is drifting. The refactor is to consolidate into one core with overlays before adding any new market.

Is building to the MDR first always the right sequencing? For a team whose operating base, clinical partners, and first customers are in Europe, yes. For a team whose operating base is in the US, the practical answer is often to start with the FDA and then retrofit to the MDR later — at a higher cost than doing the MDR first. The decision depends on where the company actually operates, not on which framework is architecturally cheapest to build to. The architectural argument favours the MDR; the operational argument sometimes favours the FDA. Both are legitimate inputs.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices (MDR), Article 10 (general obligations of manufacturers), Annex II (technical documentation), Annex III (technical documentation on post-market surveillance), and Annex IX (conformity assessment based on a quality management system and on assessment of technical documentation). Official Journal L 117, 5.5.2017. Cited here as the anchor framework for the shared evidence core.
  2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Cited as the shared QMS baseline recognised in some form by every major jurisdiction discussed.
  3. Medical Device Single Audit Program (MDSAP) — programme documentation maintained by the International Medical Device Regulators Forum (IMDRF) and the five participating regulatory authorities (US FDA, Health Canada, Australian TGA, Japan MHLW/PMDA, Brazilian ANVISA). Referenced at the general framing level; for current programme parameters, consult a recognised Auditing Organisation or the participating authorities directly.
  4. US Food and Drug Administration, Health Canada, Therapeutic Goods Administration (Australia), Pharmaceuticals and Medical Devices Agency (Japan), Agência Nacional de Vigilância Sanitária (Brazil), Swissmedic (Switzerland), and MHRA (United Kingdom) — the non-EU regulatory authorities referenced in this post. Each operates its own framework cited here at the general framing level; for current submission parameters in any specific jurisdiction, consult that authority's current guidance.

This post is part of the FDA & International Market Access series in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. A scalable global framework is boring the way good infrastructure is boring — it does not announce itself, it just keeps working when the fifth market gets added. The companies that end up with five parallel regulatory projects did not plan to. They just never refactored the country folders into a shared core while refactoring was still cheap.