An introduction to SaMD

The IMDRF defines ‘SaMD’ as ‘software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device’

In 2007, the Swedish Medical Products Agency, Läkemedelsverket, analysed the top 10 incidents in healthcare. It noticed that software was often the root cause[1] – for example medical data being lost from a temporary database, medication being assigned to the wrong patient, the wrong dose being calculated, failure to caution that a patient is allergic to an active substance, etc. In several cases, software had caused the death of a patient. Läkemedelsverket investigated and found that a lot of the software used in health care qualified as a medical device but had not undergone a conformity assessment and did not carry CE marking. Even though EU regulators had long considered that software-only products could be subject to medical device legislation, it had not been very clear to people that the term ‘device’ could also be applicable to something intangible like software.

Sweden took the issue forward when it held the presidency of the Council of the European Union. In 2009, it convinced other regulators to add the word ‘software’ to the EU definition of ‘medical device’. In 2011, the Global Harmonization Task Force (GHTF), the predecessor of the International Medical Device Regulators Forum (IMDRF), also changed its definition. This caused a ripple effect across the world. Following the direction of the World Health Organization (WHO), other countries started putting in place medical device legislation and leveraged the new GHTF definition for ‘medical device’, in effect regulating software as a medical device (SaMD). Later, in 2013, IMDRF published its guidance to clarify what software it considers to be a medical device.

The IMDRF defines ‘SaMD’ as ‘software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device’. The IMDRF provides clarification through notes, further supplemented by U.S. Food & Drug Administration (FDA) guidance.[2] An important clarification is that the italicized term does not refer to the physical location from where the software is running but to the regulatory status of the software. Software can run on general-purpose IT equipment in ‘the cloud’ but also on the computing platform of a hardware medical device and still be SaMD. When the hardware medical device needs the software to achieve its intended medical purpose – for example because it drives the hardware or fulfils a purpose claimed for the hardware device – then the software is not SaMD but part of the medical device in the regulatory meaning of the term. For example, consider software for automatic nerve detection intended to run on the computing platform of an ultrasound device. A manufacturer can place such software on the market as SaMD or as part of the ultrasound device, depending on whether the manufacturer wants to assign the nerve detection claim to the ultrasound device or just to the software. Software that does not fulfil a medical purpose on its own, on the other hand, is not SaMD. For example, software intended to solely drive an ultrasound transducer can be placed on the market as an integral part of the ultrasound device or as an accessory of the ultrasound device.

This is an excerpt from the forthcoming BSI medical devices white paper, Software as a medical device: A comparison of the EU’s approach with the US’s approach. To browse our collection of medical device white papers, please visit the Insight page on the Compliance Navigator website.