Software as a Medical Device.

Software as a Medical Device (SaMD) is software intended to be used for one or more medical purposes without being part of a hardware medical device. Previously referred to as ‘standalone software’, ‘medical device software’ or ‘health software’, SaMD can be used across a broad range of technology platforms, including medical device platforms, commercial off-the-shelf platforms and virtual networks, and its use is increasing.

If you are new to SaMD, a natural question is, “How do I get my medical software CE-marked (for sale in Europe) or FDA-approved (for sale in the US)?” And it is likely that you will be frustrated by the answers, because no one will give you the process to follow. Instead, regulators define constraints on the development process, such as traceability, and leave the details up to you. For a start-up, this is a difficult situation to navigate.

But there is help out there. The International Medical Device Regulators Forum (IMDRF) is a voluntary group of medical device regulators from around the world who have come together to reach harmonisation on medical device regulation. They have written an easy-to-read guide to medical software development and the only one we have seen that includes illustrative examples, using both a large company and a start-up.

If you are a start-up building a medical device, go to their document online http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-151002-samd-qms.pdf and search for “Parva” to see the examples relating to this fictional start-up company.

Note that medical device software development can follow either Agile or iterative methodologies, provided that the process is traceable, evidenced and includes risk management. This usually implies a process by which product, safety and clinical requirements are translated through functional specification and development tasks into software, and in which the results are tested, verified and validated – and the results recorded.

The process often uses a traditional ‘V-model’ to distinguish distinct levels of software development and testing. This is a model which describes increasingly detailed software design and the corresponding level of testing. The {design, test} pairs are (in order of increasing detail):

Development tests are the lowest level, automated and run very frequently. At the highest level, validation is a manual process of checking with users that the product built meets the requirements.

Note that we use the V-model to provide our terminology, but we do not interpret it as requiring a waterfall approach to software development.