Characterizing the risks of medical software: what should we learn from IMDRF guide N81 (2025)?

1. A new guide to better understand software risks

The rapid growth of medical software - whether stand-alone (SaMD) or embedded in a device - calls for a new approach to risk assessment. It is no longer simply the device that provides care, but the information it generates, filters or recommends. And this information can itself become a source of risk.

To help manufacturers deal with this growing complexity, IMDRF published a new guide in January 2025: IMDRF/SaMD WG/N81 FINAL:2025, soberly entitled Characterization Considerations for Medical Device Software and Software-Specific Risk.

This guide does more than simply restate the obvious. It provides a framework for better describing medical software, identifying software-specific risk factors and supporting regulatory classification and risk management processes.

2. What the IMDRF N81 guide does (and does not) cover

The N81 guide is positioned as a complement to the 2014 IMDRF N12 guide, which proposed a framework for categorizing SaMD according to their clinical impact. But here, the scope is broadened: we're no longer just talking about SaMDs, but any software that falls under the definition of medical device, including those embedded in hardware.

What it brings:

• A method for accurately describing medical software (intended use + functional description)
• A checklist for identifying specific software-related risks, in particular informational risks
• A common language for discussing the classification of software risks between regulatory bodies

What it is not:

• A classification tool
• A risk management standard
• A checklist of requirements

To remember

The N81 guide is a characterization tool, not a normative reference. It helps structure your thinking, not validate your compliance.

3. Characterizing medical software: dimensions to consider

3.1. Intended use: the 7 key elements

The guide proposes a clear structuring of theintended use / intended purpose, articulated around 7 elements:

1.Medical purpose (diagnosis, treatment, monitoring, etc.)

2.Disease or condition targeted (severity, stage, etc.)

3.Target population (age, vulnerability...)

4.Target user (clinician, patient, caregiver...)

5.Environment of use (home, office, hospital...)

6.Contraindications (if relevant)

7.Software functions: inputs, outputs, and their role in the care pathway

A drafting model is proposed in Appendix A of the guide, useful for structuring sections 1 and 3 of your technical documentation.

3.2. Software description: the 4 proposed axes

In addition, the software description must cover 4 key areas:

• Medical problem addressed (purpose of the software, level of severity, population concerned)
• Context of use (type of user, environment, time of use in the care pathway)
• Software function and use (type of output, data source, level of autonomy, explicability, recipient)
• Change management (learning, updating, infrastructure, deployment)

4. Characterizing software risks: useful concepts

The N81 guide makes a fundamental point: software risks are not always physical. They can be :

• Informational (erroneous, missing or misinterpreted data)
• Indirect (wrong medical decision based on software output)
• Related to reduced efficiency (bias, loss of interpretability, lack of reliability)

Example: software that over-interprets sensor data can lead to unnecessary examinations, or even inappropriate treatments.

The guide also stresses the link with ISO 14971: the risk analysis methodology remains valid, but software specificities need to be integrated.

5. Case studies: when characterization changes the level of risk

5.1. Example 1: diagnosis of pre-diabetes using an algorithm

A software program analyzes patient records to detect probable prediabetes. The guide shows that :

• The risk is moderate, as the error does not entail any immediate danger
• But the exclusion of certain patients (not flagged by the algorithm) is a point of vigilance
• The tool's autonomy and the fact that certain thresholds are not visible influence the perception of risk

A good example of indirect but real informational risk

5.2 Example 2: digital pain therapy

Two scenarios are compared:

• Scenario 1: the software is used as a complement to analgesics
• Scenario 2: the software is the only possible therapy (drug-intolerant patients)

Same function, same purpose, but very different levels of risk. In the event of failure, the second scenario presents a much higher risk for the patient.

6. In practice: how to use this guide as a manufacturer

The N81 guide can help you to:

• Structure your technical file from the earliest stages of development
• Enrich your ISO 14971 risk analyses, particularly for algorithmic functions
• Clarify your regulatory positioning with authorities or NBs

Checklist to remember

• Clearly define your intended use (using the 7 elements)
• Complete the 4 axes of software description
• Identify hazards specific to the information and context of use
• Evaluate the impact of autonomy and explicability
• Document software change management (upgrades, AI, customizations)

7. Mini FAQ

Does this guide replace ISO 14971?

No, it complements it. It provides elements specific to software.

Is it compulsory to follow the tables and checklists in the guide?

No, the guide has no binding regulatory value. It is a structuring tool.

Can it be used for embedded software?

Yes, the scope covers all software falling within the definition of DM.

What if my software is constantly evolving?

The guide includes a section on change management. It invites you to characterize the degree of autonomy and scope of updates.

Does the guide deal with AI algorithms?

Indirectly, yes. Notably through the notions of explicability, autonomy and scalable performance.

8. Conclusion

The IMDRF N81 guide is neither a standard nor a regulation. It is an invaluable structuring tool, which helps to think about and document software risks in a detailed and contextualized way.

At CSDmed, we help manufacturers to integrate these best practices right from the very first lines of code, to secure the product and facilitate exchanges with the authorities.

Need help characterizing or documenting your medical software?

Contact us. We'll discuss clinical use, software architecture and regulatory strategy.

9. Related resources

• ISO 14971 and start-ups: how to get started on risk analysis without getting lost
• FDA vs MDR: 5 differences that count for a DM manufacturer
• ISO 13485 for start-ups: 3 realistic approaches

• Characterizing the risks of medical software: what should we remember from IMDRF guide N88 (2025)?