Clarify your software's CE requirements with expert guidance from easyCE.

• Standalone software can qualify where its intended purpose meets the relevant medical-device definition. General administrative, storage or communication functions do not automatically qualify.
• Under the MDR, software that drives a device or influences its use generally follows that device's class. Independent medical device software is classified in its own right, applying the relevant rules.

• Documenting the qualification and classification decision.
• Applying the relevant assessment procedure, including risk management, clinical or performance evidence and software verification and validation.
• Preparing the required documentation and EU declaration of conformity, and fulfilling applicable registration and marking requirements.

Software providing information used for diagnostic or therapeutic decisions is generally Class IIa. Higher classes apply where those decisions can have more serious consequences:

• Class III where the decisions may cause death or irreversible deterioration in health.
• Class IIb where they may cause serious deterioration in health or require surgical intervention.

Software intended to monitor physiological processes is generally Class IIa. It is Class IIb when it monitors vital physiological parameters whose variations could create an immediate danger to the patient.

Other software is Class I under Rule 11 only after medical-device qualification and the other applicable classification rules have been considered. This does not make all non-medical software a Class I device.

• For eligible Class I software, the manufacturer may use self-declaration. The applicable quality management, documentation, surveillance and registration obligations still need to be fulfilled.

• Appointment scheduling, billing and administrative patient records.
• Prescription administration without a medical calculation or recommendation. Patient-specific dose calculation may have a medical purpose and requires its own assessment.
• Storage or transfer of records without medical interpretation.
• Administrative functions in radiology information systems. A diagnostic or treatment-support module may need a different assessment.

The examples below illustrate the importance of intended purpose. They do not replace a product-specific qualification decision.

For example:

• An app that records food intake for general lifestyle awareness may fall outside the medical-device definition.
• An app that processes patient-specific food intake to support diabetes treatment may qualify as medical device software, depending on its functions and intended purpose.

A label alone does not determine the outcome. Document why the functions and claims do or do not meet the relevant medical-device definition.

Technical documentation

The technical documentation connects the intended purpose and product specification with risk management, development records, verification, validation and clinical or performance evidence. It must identify the versions and configurations being assessed.

Legacy MDD documentation

Records prepared under Directive 93/42/EEC may remain relevant for devices legitimately using transitional provisions. Do not treat the former MDD as the default route for new software. Review whether the transitional conditions apply and which current obligations must also be met.

MDR documentation

MDR Annex I sets out general safety and performance requirements. Annex II describes technical documentation and Annex III covers post-market surveillance documentation. Relevant records include:

Product identification and applicable UDI information.

• Product description, software versions, variants, configurations and accessories.
• Intended purpose, users and use environment.
• Labelling and instructions for use.
• Design and development information, including relevant interfaces.
• Risk management records and the measures addressing identified risks.
• Verification and validation evidence, including software testing and evidence of the relevant clinical performance.

Plan post-market surveillance before release and use feedback to keep the evidence current. Document the findings and any preventive or corrective actions.

Class IIa, IIb and III devices generally require notified-body involvement under the relevant assessment route. The depth and sampling of technical-documentation assessment depend on the route and class. It is incorrect to assume that only Class III software documentation is reviewed.

Agree the submission requirements with the designated notified body where one is needed. The manufacturer remains responsible for complete and consistent technical documentation.

• Identify where and how the assessed software is installed.
• Control the supported configuration and any customer-specific settings.
• Verify the final configuration and the software's operation with relevant hardware and interfaces.

Define responsibilities where installation or configuration is performed by a customer or another party. Record the checks required before use and provide clear instructions.

Assess reported defects, update the risk analysis where necessary and document the response. Determine whether an issue triggers corrective action, vigilance reporting or notified-body notification under the applicable rules.

Relevant technical references can include IEC 62304 for medical-device software lifecycle processes, IEC 62366-1 for usability engineering and IEC 82304-1 for health software product safety. IEC 60601-1 may be relevant to medical electrical equipment incorporating software. Check the actual edition and published EU harmonisation status; an IEC designation alone does not establish a presumption of conformity.

Post-market reporting is a separate obligation. Under the MDR, Class I uses a post-market surveillance report. Class IIa, IIb and III use a periodic safety update report, with the required update frequency depending on the class. Annual software releases do not create a universal annual PSUR rule.

Document the change decision, verification and validation results and any required notifications before release. For a legacy device, also check whether the change affects eligibility for the transitional route.