How Do You Manage Requirements for a Product That Has to Meet Multiple International Regulatory Standards Simultaneously?
The short answer: you stop treating each regulatory framework as a separate document silo and start treating your requirements database as a graph, where regulatory citations, design requirements, verification records, and test results are all nodes connected by typed relationships. When you do that, multi-jurisdiction compliance becomes a query problem, not a copying problem.
The longer answer requires working through what this actually looks like, because the structure changes depending on how similar — or how different — the jurisdictions are.
The Core Problem: Overlap Is Real, But So Is Divergence
Most engineers approaching multi-standard compliance for the first time assume the worst: that FDA requirements and MDR requirements are entirely different animals that demand separate specification documents, separate design histories, separate verification plans. That assumption leads to parallel documentation trees that immediately fall out of sync the moment a design changes.
The reality is more manageable, but you have to earn it by doing the overlap analysis upfront.
Take a Class II medical device — say, a connected continuous glucose monitor sold in the United States, the European Union, and Japan. At the technical requirements level, the three frameworks share more than they differ:
- FDA 21 CFR Part 820 / ISO 13485: Both demand documented design controls, risk management per ISO 14971, and traceability from user needs through design outputs to verification. ISO 13485:2016 is the technical spine of all three markets.
- EU MDR (2017/745): Annex I (General Safety and Performance Requirements) maps closely to ISO 13485 design controls. Clinical evaluation requirements are more prescriptive than FDA’s 510(k) pathway, but the underlying design requirements are largely the same.
- PMDA (Japan): The MHLW Ordinance No. 169 governing QMS for medical devices is a near-direct translation of ISO 13485. Japan also recognizes ISO 14971 explicitly.
So the technical design requirements — electrical safety, biocompatibility, software development per IEC 62304, usability per IEC 62366 — are common to all three. Where the jurisdictions diverge:
| Dimension | FDA | EU MDR | PMDA |
|---|---|---|---|
| Clinical evidence pathway | 510(k) predicate or PMA | Clinical evaluation report, PMCF required | Shonin approval, Japanese clinical data often required |
| Labeling | English, FDA-format | CE mark, authorized rep, UDI | Japanese language mandatory |
| Post-market surveillance | MDR/MDV reporting | Periodic Safety Update Report (PSUR) | Periodic reports to PMDA |
| QMS audit | FDA inspection | Notified Body audit | PMDA/registered certification body |
This tells you exactly how to structure your database: one requirements hierarchy for core technical requirements, with jurisdiction-specific annexes hanging off it for clinical evidence, labeling, and post-market obligations.
Structuring the Requirements Database: The Multi-View Model
The most functional architecture for multi-standard compliance is what systems engineers call a single-source, multi-view model.
Layer 1 — Common Technical Requirements (CTR) These are your ISO 13485 design controls, your 14971 risk controls, your IEC 62304 software requirements, your IEC 62366 usability requirements. They exist once. Every design requirement, every verification test, every risk mitigation maps upward to at least one CTR. This layer is jurisdiction-agnostic.
Layer 2 — Jurisdiction-Specific Regulatory Citations Each CTR gets tagged or linked to the specific clauses in each applicable standard that it satisfies. Req-CTR-042 (battery isolation must prevent leakage current >10µA under single-fault conditions) links to: IEC 60601-1 §8.4.2, FDA guidance on electrical safety, MDR Annex I §14.5, and PMDA equivalent. The requirement exists once; the citations are attributes of that node.
Layer 3 — Jurisdiction-Specific Deliverables Clinical evaluation reports, 510(k) summaries, Japanese Shonin documentation. These are documents that reference and pull from Layer 1 and Layer 2 but live in their own space. They do not duplicate design requirements — they cite them by identifier.
Layer 4 — Verification and Validation Records Test reports, analysis records, clinical study data. These link upward to CTRs. Because a test against IEC 60601-1 satisfies requirements that are cited by FDA, MDR, and PMDA simultaneously, one V&V record closes compliance across all three jurisdictions.
This architecture means that when you run a compliance gap analysis for a new market — say, adding South Korea’s MFDS or Brazil’s ANVISA — you compare their requirements against your CTR layer. Anything already covered is green. Gaps get added as new CTRs or as jurisdiction-specific annexes. You never rewrite the core.
Aviation: FAA and EASA Certification for the Same Component
The aviation case is structurally similar but has one important difference: the FAA-EASA Bilateral Aviation Safety Agreement (BASA) and its Technical Implementation Procedures (TIPs) are designed specifically to reduce duplicated certification work. For Transport Category aircraft, FAA type certification generally gives you a strong foundation for EASA validation — but “strong foundation” does not mean “automatic.”
Take an avionics LRU — a flight management computer being certified to both FAA and EASA standards for installation on a new narrow-body program.
The certification basis under FAA would be established per 14 CFR Part 25 (airworthiness), DO-178C (software), DO-254 (complex electronic hardware), and applicable Special Conditions. Under EASA, the equivalent is CS-25, ED-12C (the European equivalent of DO-178C, essentially identical), and ED-80 (equivalent to DO-254).
The good news: DO-178C and ED-12C are substantively the same document. The software development records, stage-of-involvement review artifacts, and software accomplishment summaries satisfy both authorities from a single set of records.
The complication: EASA has historically been more prescriptive on certain Special Conditions for novel technologies — particularly for AI/ML-based functions, where EASA’s AMC Issue 1 (2021) and subsequent guidance diverges from the FAA’s evolving position on AI airworthiness. A flight management function that uses ML-based trajectory optimization may satisfy FAA’s current guidance but require additional EASA-specific substantiation.
How do teams handle this?
Gap analysis against a bilateral baseline: Start by identifying which requirements are covered by BASA TIPs — these are accepted without further substantiation. What remains is your “delta list.” Each delta item becomes a jurisdiction-specific requirement node linked to the common technical baseline.
Shadow requirements for divergent areas: Where FAA and EASA genuinely require different things — different AMC routes for the same objective, different documentation formats — teams maintain shadow requirements. REQ-SW-0441 is the common DAL B software requirement. REQ-SW-0441-EASA adds the specific AMC 20-115E cross-reference and any additional EASA DDP (Data as Design Plan) obligations. Both trace to the same verification records where possible.
Certification review item (CRI/Finding) tracking: Both FAA and EASA issue findings during review. These need to be tracked as requirements changes — not just comments — with full impact assessment against the design and verification baseline.
Change Management: The Problem That Compounds
Single-authority change management is already hard. Multi-authority change management, done naively, becomes an exponential documentation exercise.
Consider the scenario: you have a certified glucose monitor on the US and EU markets. FDA updates its guidance on cybersecurity requirements for connected devices — the 2023 “Cybersecurity in Medical Devices” guidance now requires a Software Bill of Materials (SBOM) and a documented vulnerability disclosure policy. Your CTR layer needs updating. What happens?
With a document-based system: Someone updates the 510(k) Design History File. Someone else is supposed to update the EU Technical Documentation. Two documents, two reviewers, two change records, and a non-trivial probability that they diverge within six months.
With a graph-based traceability model: The regulatory requirement node for FDA cybersecurity is updated. The system traces forward: which CTRs cite this regulation? Which design requirements derive from those CTRs? Which verification records cover those design requirements? Which deliverables in the FDA Technical File and the EU Technical Documentation reference those CTRs? Every impacted item is surfaced in a single impact analysis. Some of those impacts will cascade to PMDA documentation as well, even if PMDA hasn’t updated their guidance yet — because your SBOM requirement was already tagged as satisfying ISO/IEC 27001 security management clauses that appear in all three jurisdiction mappings.
The practical rule: treat every regulatory update as a change request against your requirements baseline, not as a documentation update. It triggers a formal impact assessment. It gets a change record. It closes only when all impacted verification activities are re-confirmed or re-executed.
For aviation, this is already formalized: FAA and EASA both require that any change to an approved design go through a Change Impact Assessment that re-establishes the certification basis for the changed areas. The discipline is there. The failure mode is treating documentation updates as outside that process.
How Modern Platforms Handle This: From Matrices to Graphs
Traditional requirements tools — IBM DOORS, Polarion, Jama Connect — were designed around the document and the Requirements Traceability Matrix (RTM). These tools are mature, have strong audit trail support, and are deeply embedded in many regulated industry workflows. For single-standard, single-jurisdiction programs, they work.
The limitation appears at scale in multi-standard environments. When requirements must be traced to multiple regulatory frameworks simultaneously, document-based tools tend to solve the problem by copying: a requirement appears in the FDA specification document, then again in the EU technical documentation, then again in the PMDA submission package. Each copy is a liability. Any one of them can drift from the others after a change.
Graph-native platforms approach this differently. Requirements, regulations, tests, risks, and design artifacts are nodes. Relationships between them — “satisfies,” “is verified by,” “is cited by,” “is derived from,” “is impacted by” — are typed edges. A single requirement node can have edges to FDA 21 CFR 820.30(c), MDR Annex I §9, and PMDA Ordinance 169 simultaneously. The compliance view for each jurisdiction is a query against the graph, not a separate document.
Flow Engineering (flowengineering.com) is built on this graph-native model. Its architecture treats the requirements database as a connected model rather than a document hierarchy, which means multi-standard traceability is structural rather than procedural. When a team working on a dual-use medical-industrial device maps their requirements to both FDA and MDR simultaneously, Flow Engineering allows both regulatory citation layers to live as typed relationships on a single requirement node — so a change to that requirement automatically surfaces in both compliance views without requiring a manual update to parallel documents.
The impact analysis capability is where this pays dividends in practice. Flow Engineering’s traceability graph can be queried forward (from a design change: what verification records are now suspect?) and backward (from a regulatory update: which design requirements are affected, and which test plans cover them?). For teams managing three-authority submissions simultaneously, this replaces a manual spreadsheet exercise with a live graph traversal.
One deliberate trade-off with Flow Engineering’s approach: it is optimized for connected systems engineering work — requirements, architecture, verification — and is not a document management system. Teams still need a separate DMS for storing finalized submission documents and managing their version control for regulatory submissions. Flow Engineering’s strength is the living model; the static snapshot for submission goes elsewhere.
For comparison, Jama Connect and Polarion both offer multi-project linking and cross-document traceability, which experienced teams use to approximate the multi-view model. These are real capabilities. The difference is that in document-centric tools, multi-standard traceability requires deliberate process discipline to maintain; in a graph-native model, it is the default state.
Practical Starting Points
If you are building a multi-jurisdiction compliance structure from scratch:
1. Do the overlap analysis before you touch your requirements tool. Map every applicable standard against ISO 13485 or DO-178C (whichever is your common spine). Identify what is shared, what is additive, and what genuinely conflicts. The conflicts are rare but expensive to discover late.
2. Define your identifier strategy. Every common technical requirement needs a stable, unique identifier that travels unchanged through all jurisdiction-specific views. REQ-CTR-042 is the same requirement whether it appears in your FDA DHF or your MDR Technical Documentation. Never let tools auto-number the same requirement differently in different projects.
3. Model regulatory citations as relationships, not as document sections. A requirement does not “live in” the FDA section of your database. It lives in the common layer and has citation relationships to FDA, MDR, and PMDA clauses. This is the structural change that makes everything else work.
4. Treat regulatory updates as change requests. Assign ownership. Require impact assessments. Close with evidence.
5. Run a cross-jurisdiction impact drill before your first major submission. Pick a mid-severity design change and trace it manually through all three jurisdictions. Identify where your process breaks down. It will break down somewhere — better to find it on a drill than on a real change.
Multi-standard compliance is not fundamentally a tool problem. It is a model problem. Get the model right, and the tools — whatever you choose — can support it. Get the model wrong, and no tool will save you from the maintenance burden of parallel documentation trees that drift apart with every change.