Regulatory-compliant categorization. Correctly classified. Approval-ready.

Software & AI

Software as a medical device, AI-supported systems, digital diagnostics – the regulatory requirements are complex and rapidly evolving. We support manufacturers of digital products with regulatory categorization, classification and documentation – according to MDR, IVDR, IEC 82304, IEC 62304, and the AI Act.

Is our software a medical device – and if so, what does that mean?

Most manufacturers come to us with this question, which often leads to others: Is it software as a medical device or embedded software (control of the medical device)? Which class? Accessory or component? We provide clarity – before incorrect assumptions lead to costly corrections.

Our services in the area of software, AI & digital medical devices

Regulatory categorization and classification

  • Your software is correctly categorized according to regulations – SaMD qualification under MDR/IVDR
  • The correct risk class is determined – classification according to MDR/IVDR and safety classification under IEC 62304
  • Borderline cases and demarcation questions are argumentatively clarified before they become an approval problem

Software Lifecycle & Documentation

  • Your existing Software Lifecycle processes are assessed and structured from a regulatory perspective
  • Software-related documentation is fully built up and review-ready in accordance with the required standards
  • The requirements of the software standards are correctly applied from a regulatory perspective – not merely formally fulfilled
  • Cybersecurity evidence and IEC 62304 documentation are part of the Technical Documentation – and must be readily available for review
    → Technical Documentation

AI & AI Act

  • Your AI system is classified from a regulatory perspective – according to MDR/IVDR and the AI Act
  • AI risk assessment from a regulatory perspective is structured and documented
  • The use of AI- supported tools in QM or regulatory processes is assessed and validated from a regulatory perspective

Usability

  • Regulatory requirements in accordance with IEC 62366 have been correctly applied and documented
  • Usability engineering is seamlessly integrated into technical documentation and risk management

    Note: We support the regulatory implementation of usability
    – we do not provide design or UX services.

Interface assessment

  • Quality Management System, risk management, Clinical Evaluation, Technical Documentation, and PMS are consistently linked with software-related requirements
  • Gaps between regulatory disciplines have been identified and closed

    Technical documentation for digital products:
    → Technical Documentation
    Software-related quality management requirements:
    → QM & Audit Support
    Training teams in the regulatory handling of software:
    → Trainings & Seminars

Regulatory clarity for digital products – from the start.

Incorrect classification costs time and money. regular services helps you ask the right questions early – and answer them with confidence.

Schedule a free initial consultation

When manufacturers come to us

New digital products

Software or AI systems must be classified from a regulatory perspective before development continues.

Existing software

Lifecycle processes, documentation, or classification must be reviewed  for regulatory compliance.

AI & AI Act

AI-powered systems or tools in the regulatory environment must be assessed and prepared for compliance.

Our services

Our customers

Medical Device
manufacturers

Start-ups

Suppliers for medical devices / IVD

Authorities

IVD manufacturers

Investors

Frequently Asked Questions about software, AI & digital medical devices

When is software a medical device according to MDR?

Software is considered a medical device when it is intended for a medical purpose – such as diagnosis, monitoring, or treatment of diseases. The decisive factor is the manufacturer’s intended purpose, not the technical function alone. Pure storage, archiving, or communication functions do not automatically qualify software as a medical device. The distinction is often complex – we help you clarify it properly.

What is the difference between SaMD and SiMD?

SaMD (Software as a Medical Device) is standalone software that is itself a medical device. SiMD (Software in a Medical Device) is software embedded as an integral part of a hardware medical device. Both categories fall under the definition of Medical Device Software (MDSW) according to MDR and IVDR – with different regulatory consequences for classification and documentation.

Which classification applies to software – MDR or IEC 62304?

Both – but they measure different things. The MDR classifies according to the risk of the product to patients into Classes I to III, while IEC 62304 classifies the software safety class according to the potential harm from a software failure into Classes A, B, and C. Both classifications are required and must be aligned with each other.

Must AI in medical fevices be additionally assessed under the AI Act?

Yes – AI-powered medical devices can fall under both the MDR and the AI Act. Both regulatory frameworks impose their own requirements, which partially overlap but are not identical. Whether and to what extent the AI Act applies depends on the specific AI system, its intended purpose, and its regulatory classification. We evaluate AI systems from both perspectives and prepare you for both sets of requirements.

What are the regulatory requirements for cybersecurity in medical devices?

Medical devices with an external interface – such as USB or Ethernet – are subject to the IT security requirements of the MDR, which are formulated in Annex I as General Safety and Performance Requirements. Additionally, there are MDCG guidelines on cybersecurity. We identify the requirements relevant to your product and help you document compliance. Most guidelines and Regulatory Requirements reference IEC 81001-5-1, and in some cases also IEC/TR 60601-4-5.

Is IEC 62304 mandatory for software medical devices?

Application of IEC 62304 is technically voluntary – the MDR does not directly reference it. However, to demonstrate conformity as required by the MDR, the standard is well suited. It introduces sensible procedures and documentation for software development and allows for the derivation of a sound software development process. Depending on the software characteristics, certain standards can be integrated, as, for example, the cybersecurity standard IEC 81001-5-1 and the supplementary standard for SaMD IEC 82304 are structurally aligned with IEC 62304.

The most costly question is the one asked too late.

Is your software a medical device? Which class? What are the requirements? The sooner this is clarified, the less it will cost you later on. We provide clarity before development goes off track.