Under both the EU MDR and the EU IVDR, the MDCG rules specify the conditions for a product to qualify as medical device software (MDSW). An MDSW product can enter the market in one of the ways:
1. As a standalone medical device or
2. As a component of another medical device regulation.
The former demands a lengthy regulatory process that includes a conformity assessment to determine whether the medical device meets EU MDR requirements. However, that rule does not apply to products in the latter group with the same rigour.
Ready to Streamline Your Regulatory Compliance?
Join hundreds of companies who trust OMC Medical for their regulatory needs.
Get expert guidance and ensure compliance across all markets.
Call Now +44 208 066 7260
As a result, MDSW, as an integral component of a medical device, can be placed on the market through the medical device’s conformity assessment route.
The term “Software as a Medical Device” (SaMD) is defined as Software intended to be used for one or more medical purposes that perform the below purposes without being part of a hardware medical device.
1. SaMD is a medical device and includes an in-vitro diagnostic (IVD) medical device regulation.
2. SaMD is capable of running on general-purpose (nonmedical purpose) computing platforms.
3. “Without being part of” means Software is not necessary for a hardware medical device regulation to achieve its intended purpose.
4. The Software does not meet the definition of SaMD if its intended purpose is to drive a hardware medical device regulation.
Examples of Software as a Medical Device
1. SaMD may be interfaced with other medical devices, including hardware medical devices and other Software such as medical device software and general-purpose Software. The Software provides parameters that become the input for a different hardware medical device or other SaMD.
For example, treatment planning software that supplies information used in a linear accelerator is Software as a Medical Device.
2. Software with a medical purpose that operates on a general-purpose computing platform, i.e., a computing platform that does not have a medical purpose, is considered Software as a Medical Device. For example, Software intended to diagnose a condition using the tri-axial accelerometer that operates on the embedded processor on a consumer digital camera is considered Software as a Medical Device.
3. Software that is connected to a hardware medical device but is not needed by that hardware medical device regulation to achieve its intended medical purpose is Software as a Medical Device and not an accessory to the hardware medical device regulation.
4. Software as a Medical Device can run on general-purpose (nonmedical purpose) computing platforms.
Top 7 Manufacturer Obligations for Medical Device Regulation
1. For SaMD manufacturers, the definition in GHTF/SG1/N55:2009 applies: “Manufacturer” means any natural or legal person with responsibility for the design and manufacture of a medical device to make the medical device available for use under his name; whether such a medical device is designed and manufactured by himself or on his behalf by another person(s).
2. Unless the Regulatory Authority (RA) within that jurisdiction imposes this responsibility explicitly on another person, this ‘natural or legal person’ has ultimate legal responsibility for ensuring compliance with all applicable regulatory requirements for the medical device in the countries or jurisdictions where it is intended to be made available or sold.
3. The manufacturer’s responsibilities are described in other GHTF guidance documents. These responsibilities include meeting pre-market and post-market requirements, such as adverse event reporting and notification of corrective actions.
4. ‘Design or manufacture’, as referred to in the above definition, may include specification development, production, fabrication, assembly, processing, packaging, repackaging, labelling, relabelling, sterilisation, installation, or remanufacturing of a medical device; or putting a collection of devices, and other products, together for a medical purpose.
5. Any person who assembles or adapts a medical device already supplied by another person for an individual patient, per the instructions for use, is not the manufacturer, provided the assembly or adaptation does not change the intended use of the medical device.
6. Any person who changes the intended use of, or modifies, a medical device regulation without acting on behalf of the original manufacturer and who makes it available under his name should be considered the manufacturer of the limited medical device.
7. An authorised representative, distributor or importer who only adds its address and contact details to the medical device or the packaging without covering or changing the existing labelling is not considered a manufacturer.
8. To the extent that an accessory is subject to the regulatory requirements of a medical device, the person responsible for the design or manufacture of that accessory is considered to be a manufacturer.
Quality Management Principles
Medical device QMS principles allow the measurement of activities depending on
1. The type of medical device.
2. Risk of the product to patients.
3. Size of the organisation.
4. Technology or automation is used to manufacture.
5. And other factors are determined by the manufacturer to control quality and maintain the safe and effective performance of the medical device regulation.
6. The manufacturing of SaMD, a software-only product, is primarily based on the development lifecycle activities often supported by automated software development tools.
7. These computerised activities may, in some cases, replace discrete or deliberate actions (e.g., transfer of design to production) typically found in the manufacturing of hardware products.
8. However, the principles in a QMS that provide structure and support to the lifecycle processes and activities are still applicable and essential to controlling the quality of SaMD.
An effective QMS for SaMD have to include the following principles:
1. An organisational structure ensures SaMD’s safety, efficacy, and performance by providing leadership, accountability, and governance with enough resources.
2. A set of SaMD lifecycle support processes that are scalable to the organisation’s size and applied consistently across all realisations and use processes
3. A set of realisations and use processes that are scalable for the type of SaMD and the organisation’s size takes into account essential elements required for assuring the safety, effectiveness, and performance of SaMD.
Does MDSW need to be re-assessed for risk classification when transitioning from MDD to MDR?
Yes, SaMD also requires a re-assessment of risk classification since the new classification rules are more stringent than the MDD. This must be carried out as the first step in the MDR compliance roadmap.
The gap analysis in the technical documentation also needs to be performed while transitioning to MDR.
What are the additional requirements in the technical documentation for MDSW in MDR?
Pre-clinical & Clinical Data, Clinical Evaluation and PMCF requirements, Clinical Investigation and implementation of UDI.
How is Software as a Medical Device considered in MDR?
Software shall be deemed to be an “active device” both in MDR and IVDR.
What are the UDI assignment criteria for a Software only device?
For a Software that constitutes as a device on its own, the UDI shall be assigned at the system level of the Software itself. The UDI that is applied to the physical medium that contains the Software shall be identical to the UDI assigned at the system level.
Are there any guidance documents for Software as a Medical Device by the EU commission?
Yes, Specifically
1. “MDCG 2019-16 Guidance on Cybersecurity for medical devices” guides manufacturers on how to fulfil the Annex I requirements regarding cybersecurity.
2. “MDCG 2019-11 Guidance on Qualification and Classification of Software” in Regulation to MDR 2017/745 and IVDR 2017/746
