Modular software as a medical device explained

The updated MDCG 2019-11 guidance gives manufacturers clearer direction, especially when working with modular software. While it was already possible to certify a medical software module independently, the revised guidance introduces a significant improvement: it formalizes how manufacturers should define, document, and assess software modules within a larger product architecture.

This means if your application contains several features, some qualifying as medical device functions and others not, you may no longer need to certify the full system under the MDR, as long as the medical-purpose modules are clearly identified and assessed accordingly. 

For example, a fitness tracker may include an ECG analysis tool and a blood oxygen measurement feature. Each of these modules can be individually CE-marked based on their intended purpose and risk class, while the broader app may remain outside the scope of MDR, unless it affects the safety or performance of the regulated modules.“You can classify individual software modules separately based on their intended purpose and risk, and even certify them independently. This helps streamline regulatory work and reduce the burden of documentation,” explains Marijn. “It’s not a new option, but the updated guidance gives manufacturers a much more practical framework to make this approach work—especially useful for startups or teams looking to scale medical functionality step by step.”

The updated guidance also supports a more modular certification strategy, allowing you to start small and certify in manageable increments. But there is one caveat: if these modules interact – say a user navigates between a medical and a nonmedical feature – the interoperability and user journey must be validated. This includes the interfaces, data flows, and user journey, to ensure they don’t compromise the intended performance of the medical components.

Manufacturers also have to ensure that software changes in the nonmedical modules don’t affect the performance of the medical components. This requirement has a significant impact on your software architecture, requiring clear functional boundaries and data integrity safeguards between components.

When should you modularize?

Modularization isn’t just a technical design choice; it’s a business strategy. Some manufacturers may intentionally start with a Class I module, launch it quickly, and then up-classify the product as they develop higher-risk functionalities.

“It ultimately depends on the intended use,” says Marijn. “Initially, down-scaling your scope allows you to gain market experience and build your QMS maturity without committing to a full Class IIa or higher conformity process upfront.”

Not every team will prefer this route. Some may choose to certify the entire software suite, particularly if they anticipate integrating other features at a later date. According to Marijn, “Some businesses prefer the ‘full system’ approach for its completeness. Others lean toward modular strategies because the regulatory burden is lighter and more flexible. Ultimately, it’s a business choice.”

Sub-rules for Rule 11: a long-awaited clarification

Perhaps the most significant change in MDCG 2019-11 is the introduction of sub-rules under Rule 11, bringing long-awaited clarity to risk classification:

• Rule 11a: Software that provides diagnostic or therapeutic decision support is Class IIa or higher, depending on the severity of the intended use
• Rule 11b: Software monitoring physiological processes also falls under Class IIa or higher
• Rule 11c: All other SaMD not covered by IIa or IIb can be Class I, offering an easier regulatory path in the form of self-certification

Previously, many manufacturers defaulted to higher classifications out of caution. Now, as Marijn explains, “There are gaps in the system that let you legitimately go for Class I. That’s not a loophole, that’s just better use of the guidance.” 

The upshot? The burden of proof still lies in the intended use statement. Getting this right is foundational for any classification strategy, modular or otherwise.

More examples of medical device software

The new guidance also nods towards the European Health Data Space Regulation (EHDS), particularly in cases where Electronic Health Record (EHR) platforms integrate medical device modules. An EHR isn’t necessarily a medical device, but if it includes a SaMD module, that module must comply with MDR. 

Other examples now referenced in the guidance include:

• VR therapy tools for mental health patients
• Mobile modules for schizophrenia symptom tracking
• Digital rehabilitation apps

Manufacturers should note that even lifestyle devices, such as wearables, may include modules falling under Annex XVI, placing them within MDR scope despite not being traditional medical devices.

A strategic tool for compliance leaders

While the revised guidance is not legally binding, Notified Bodies are likely to expect manufacturers to justify non-adherence. If challenged, you could always point to the MDR itself, but for most companies, proactive compliance is the safer and more strategic choice.

"They’ll likely ask why you didn’t apply the sub-rules,” explains Marijn. “So even though it’s labelled ‘guidance’, you should still implement it in your QMS as if it were enforceable.” The updated qualification and classification of software guidance (MDCG 2019-11) is more than just a revised checklist, it’s a tool for regulatory design thinking. 

For Persons Responsible for Regulatory Compliance (PRRC), QMS managers, and regulatory teams, it’s a reminder to revisit intended use, consider modular architecture, and develop smarter roll-out strategies. 

Need expert support with this or any other aspect of MDR compliance? Contact Peercode’s regulatory consultants for a free discovery call