QMSR and EU MDR Usability: The Quiet Convergence
Published On: September 15, 2026Categories: Medical Device, Product Design, Regulatory Affairs

“You don’t need two usability programs. You need one that speaks both regulatory languages.” I’ll admit that’s not how I expected to start a response, but since February 2026, it’s one I’ve offered up more than once. A prospective client, a design controls lead at a Class II device manufacturer, had spent weeks reconciling a usability file that had effectively been built twice: once for the US and once for Europe.

A shift in the procedural landscape

When the Food and Drug Administration’s (FDA) Quality Management System Regulation (QMSR) took effect. QMSR amended 21 CFR 820 with a framework aligned to ISO 13485:2016. Buried in that shift is a quieter change, one that matters enormously if you’re developing medical devices for both the US and Europe. Usability engineering stopped being two separate conversations.

Historically, MedTech startups have chased a beachhead: Europe or the US first, market presence next, and additional territories after that. At IDE Group, we’ve noticed that pattern is breaking down. Businesses are now exploring parallel regions, with first, second and third market milestones running independently rather than sequentially. The changes under QMSR make that easier.

What’s changed and why it matters

While QMSR doesn’t mention the international usability standard, IEC 62366-1, by name, by incorporating ISO 13485:2016 by reference, and routing design and development through ISO 13485 clause 7.3, the FDA moved the US quality system closer to the same design control backbone that other international manufacturers already use. IEC 62366-1 remains a practical way to structure usability engineering evidence that can speak to FDA human factors expectations and EU usability expectations.

IEC 62366-1 isn’t suddenly a new mandatory FDA standard; in fact, the FDA has recognized IEC 62366-1 as a consensus standard for several years. But what is different is that spirit of ISO 13485 now sits inside US regulation, which means now more than ever the FDA will expect the same use-related risk thinking IEC 62366-1 has always required. For manufacturers already running EU programs, the two frameworks just got a lot closer.

Same process, different vocabulary

Here’s where we’ve seen teams waste real time. FDA and IEC 62366-1 often describe overlapping usability activities using different terminology. If you’re treating the terms as unrelated requirements, you’re writing everything twice.

FDA Term IEC 62366 Term What it means
Critical task Hazard-related use scenario A step where a use error could cause harm
Human factors validation testing Summative evaluation The final study proving the design is safe to use
Design validation Design validation (same term) Confirming the device meets user needs

 

With this context, the motive behind the Use-Related Risk Analysis (URRA) becomes clear. Take the prospective client’s device: an infusion pump platform sold into both markets. Instead of one hazard analysis mapped to FDA critical tasks and a second mapped to EU hazard-related use scenarios, our approach would be to build a single URRA which covers both. Every foreseeable use error traces to one row, one use-related hazard or harm pathway, one risk-control rationale, one residual-risk assessment, and two regulatory labels. One document does the work that used to take two, while preserving the traceability a reviewer needs to understand why each task or scenario matters. The client’s next submission cycle runs from that single file, not from two files that need to be reconciled afterwards.

Where the two roads diverge

It’s worth noting that the FDA still requires US population participants for human factors validation testing, and while FDA’s overall approach is aligned with IEC 62366-1, there is still US-specific guidance and policy that must be navigated satisfactorily. IDE Group is equipped for this through our dedicated Simulated Usability Lab, SULi. IEC 62366-1 has no residency requirement, though local-language testing often makes sense for CE Marking under EU MDR, particularly as availability of labelling (including UI/UX elements in certain cases) in official languages of the individual member state market is a requirement in the EU MDR (subject to certain member-state-dependent exemptions, for example, professional users). However, in most practical cases, a well-designed US study carries most of the weight for both filings, provided the use specification and context of use are explicitly linked back to the EU market with a clear rationale.

If your URRA, study protocol, recruitment rationale, test environment, training assumptions and reporting structure are built with both audiences in mind from the outset, this can represent a meaningful reduction in duplicated effort.

The Key Takeaway (and Why This Matters Beyond Compliance)

As the old saying goes “A stitch in time saves nine”, meaning a little work taken on early can save a lot of work later. Alignment of your regulatory strategy, usability and human factors strategy, and go-to-market strategy early will pay dividends in credibility with investors and regulators as well as saved team time and resources on non-value-added work. IDE Group’s Human Factors Engineering and Regulatory teams are strategic thinkers and can help you focus on the things that matter most.

Particularly with the closer alignment of the QMSR with certain international standards, it’s true now more than ever that usability compliance in multiple markets should not be treated as separate, isolated jobs. The teams who strategize and plan for their immediate markets and for those future markets at the outset will spend less time reconciling paperwork and more time on value-added validation of their products.

Alexandra Smythe, Director of Regulatory Affairs, IDE Group

Alexandra Smythe

Director of Quality, Regulatory Affairs and Legal

Share this article
Medtech Manufacturing Consulting​The Manufacturing Gap That Can Make or Break a Medical Device Launch
Person design a medical device appHuman Factors and Accessibility in Medical Device Interface Design