Is Your Software a Medical Device?

Under EU MDR Article 2(1), a medical device is "any instrument, apparatus, appliance, software, implant, reagent, material or other article" intended for a medical purpose. The key question is the intended purpose — not the technology itself.

Software IS a medical device if it is intended to:

• Diagnose, prevent, monitor, treat, or alleviate a disease, injury, or disability
• Predict a medical condition or predispose a patient to a condition
• Compute a dosage, treatment parameter, or physiological value used in clinical decisions
• Control or influence a medical device through software commands

Software is NOT a medical device if it is intended only for: administrative hospital management (scheduling, billing), general wellness without medical claims, education and training without diagnostic output, or data storage without decision support.

The grey area is broad — when in doubt, consult your Notified Body or Competent Authority for a formal classification opinion before investing in development.

SaMD Classification Under EU MDR

SaMD classification under EU MDR follows Rule 11 (for non-IVD software) or IVDR rules (for IVD-related software):

The MDR MDCG 2019-11 guidance document on SaMD classification provides the authoritative interpretation framework — it is essential reading for any SaMD developer.

IEC 62304 — The Software Lifecycle Standard

IEC 62304 (Medical device software — Software lifecycle processes) is the key technical standard for SaMD development. EU MDR requires compliance with applicable harmonised standards — IEC 62304 is listed and its compliance creates a presumption of conformity for the software lifecycle requirements of EU MDR Annex I.

IEC 62304 applies three safety classification levels based on the potential harm of a software failure:

• Class A: No injury or damage to health is possible — lightweight documentation requirements
• Class B: Non-serious injury is possible — full lifecycle documentation required
• Class C: Death or serious injury is possible — most rigorous requirements including full traceability from requirements to code to tests

Key IEC 62304 processes: software development planning, requirements analysis, architectural design, detailed design, unit implementation, integration and testing, system testing, release, and maintenance. Each must be documented with appropriate records for audit.

The Technical Documentation for SaMD CE Marking

SaMD Technical Documentation (EU MDR Annex II/III) must include:

• Software description and intended purpose: Precise description of the software's medical intended purpose, intended user, patient population, and clinical environment of use
• IEC 62304 software lifecycle documentation: Requirements specification, architectural design, unit and integration test records, software release notes, version history
• Risk management (ISO 14971): Risk analysis specifically addressing software failure modes — algorithm errors, cybersecurity vulnerabilities, human factors of the user interface
• Cybersecurity documentation: MDCG 2019-16 cybersecurity guidance compliance — threat modelling, vulnerability disclosure policy, security testing evidence, and post-market security monitoring plan
• Clinical evaluation: Clinical evidence supporting the software's performance claims — literature review + clinical validation data for the specific algorithm/functionality
• Usability engineering (IEC 62366-1): Formative and summative usability testing evidence — critical for user interface design validation
• Post-Market Surveillance plan: PMCF for SaMD — real-world performance monitoring, algorithm drift detection, and ongoing clinical evidence generation

AI/ML in SaMD — Special Considerations

AI and machine learning SaMD (AI/ML-SaMD) create additional regulatory challenges because the algorithm's performance can change over time (algorithm drift, retraining). The EU MDCG and FDA have both issued specific guidance on AI/ML-SaMD:

• Algorithm validation: Training, validation, and test datasets must be documented — dataset composition, data quality, and representativeness of the intended population
• Performance metrics: Sensitivity, specificity, PPV, NPV, AUC — documented against pre-specified acceptance criteria
• Bias assessment: Demonstrate that the algorithm performs equitably across demographic subgroups (age, sex, ethnicity) relevant to the intended population
• Change management: EU MDR requires that significant changes to the algorithm (retraining, new data sources) are assessed for regulatory significance — substantial changes may require NB notification or a new CE assessment
• MDCG 2021-6: EU guidance on qualifying and classifying AI/ML SaMD — essential reading for Turkish AI medtech developers

Practical Pathway for Turkish SaMD Developers

1. Intended purpose definition: Write a precise intended purpose statement — this is the regulatory anchor for all subsequent classification and documentation decisions
2. Classification: Apply MDR Rule 11 or IVDR rules to determine device class; consult MDCG guidance and NB if uncertain
3. QMS implementation: Implement ISO 13485 with scope covering SaMD design, development, and distribution — IEC 62304 processes integrated into QMS
4. Technical Documentation: Prepare Technical File with all elements above; Notified Body assessment for Class IIa, IIb and III (only Class I software is self-declared)
5. NB selection: Choose a NB with SaMD experience — not all NBs have equal AI/ML expertise; BSI, TÜV SÜD, and DNV have established SaMD review practices
6. EU AR appointment: Turkish SaMD developers need an EU Authorised Representative