Skip to main content

Software as a Medical Device — Overview

Overview​

This page provides an end-to-end overview of regulating standalone software as a medical device (SaMD) in Switzerland under MedDO. For detailed coverage of specific topics, see the linked pages.

Step 1 — Qualification: Is This Software a Medical Device?​

Not all health-related software is a medical device. The key question is whether the software has a medical intended purpose — specifically whether it is intended to perform an action on data beyond storage, communication, or search, and whether its output is intended to drive clinical decisions. Use MDCG 2019-11 (applicable in Switzerland) as the qualification framework. See MDCG 2019-11 Applicability.

Step 2 — Classification: Which Class?​

Once qualified as a medical device, SaMD is classified using MedDO Annex VIII. Key rules for software:

  • Rule 11: Active devices for administering/removing medicines or providing therapy — Class IIb or III
  • Rule 22: Closed-loop systems for serious conditions — Class III
  • Software IVDs: IVDO Annex VIII Rule 7 Most clinical decision support SaMD falls into Class IIa or IIb; closed-loop therapeutic control systems are Class III.

Step 3 — Technical Documentation ​ SaMD-specific documentation requirements include: Software description: system architecture, software modules, programming languages, operating system dependencies, third-party components and libraries (software bill of materials / SBOM with versions) IEC 62304 compliance evidence: software development lifecycle documentation, software safety class determination, requirements traceability matrix, design specifications, code review records, unit and integration testing reports, verification and validation protocols Cybersecurity documentation: threat model and risk assessment, security testing results, vulnerability management process, security patch deployment procedures, minimum system requirements and security configurations Usability evaluation: IEC 62366-1 usability engineering file including user profile analysis, use scenarios, interface design justification, and human factors validation testing AI/ML documentation (where applicable): training dataset description (size, sources, inclusion/exclusion criteria), training/validation/test data splits and stratification, algorithm performance metrics on each dataset, algorithm change control procedures, documentation of retraining triggers and frequency

Step 4 — Conformity Assessment​

SaMD follows standard MedDO conformity assessment routes by class. For Class IIa+ SaMD, an EU-designated NB must assess QMS compliance under ISO 13485 (including IEC 62304 scope) and review technical documentation.

Step 5 — Post-Market Obligations​

SaMD post-market surveillance has specific features:

  • Performance monitoring: real-world performance metrics must be collected and compared against the performance claims in the technical documentation
  • Software updates: security patches and feature updates must be managed through a documented change control process; significant algorithm changes may require new conformity assessment
  • Cybersecurity incidents: security vulnerabilities that could lead to patient harm must be reported to Swissmedic via eVigilance

Official Sources​

Disclaimer

AI-assisted navigation aid only. Always verify against official Swissmedic and Fedlex sources. Not legal or regulatory advice.

Under 'Step 5 — Post-Market Obligations', expand the 'Software updates' bullet point: