How do you bring your medical software to market as Software as a Medical Device in a regulatory-compliant way and without approval loops?

Software is a medical device as soon as it fulfills a medical purpose in its own right, that is, when it does not merely store or transmit data but contributes to diagnosis, therapy or decision support. From that point on, the same general requirements apply as for physical products, complemented by software-specific standards. The levers on which SaMD projects most often get stuck:

• Classification: Under the MDR (EU) 2017/745, Rule 11 in Annex VIII classifies standalone medical software according to the severity of the supported decision; most SaMD therefore land above self-certification and require a notified body. Diagnostics-related software may instead fall under the IVDR (EU) 2017/746, whose classification rules in Annex VIII determine the risk classes A to D.
• Software safety classification to IEC 62304: Class A, B or C determines the scope of the required lifecycle activities and documentation. It is derived from the risk assessment and cannot be corrected downward after the fact without altering the risk analysis.
• Risk management to ISO 14971 as the connecting bracket: The software-related hazards must feed into the same risk management file from which the classification and verification depth derive. Maintaining software risks separately from the product risk creates gaps.
• Usability to IEC 62366-1: Use errors are a central source of hazards in software; the usability file must document the safety-critical user steps and their validation.
• Cybersecurity across the lifecycle: For connected software, notified bodies and the FDA expect a documented secure development lifecycle including an SBOM, vulnerability management and an update strategy that extends beyond the market phase.