Which specific challenges apply to SaMD compliance?
Software-as-a-medical-device (SaMD) consulting must combine standard requirements imposed by MDR / IVDR while accommodating the unique challenges of working with software devices.
Unlike hardware products, software is inherently flexible and adaptive. Machine learning protocols, by their very nature, acquire new functionality over time, meaning that traditional consulting approaches focused on demonstrating static outcomes will be insufficient to meet requirements. Furthermore, submissions must be written and structured in a way that ensures reviewer comprehension is maintained at all times.
Furthermore, software routinely undergoes regular updates, unlike hardware devices which may remain unchanged over many years. Updates are also driven by technological advances over time, including changes to operating systems with which SaMD products might need to interface. This process of renewal may lead to questions regarding similarity of older variants, and whether (depending on the degree of evolution) they now comprise a completely separate device.
Specific differences between SaMD and hardware device submissions include:
- Challenges in classifying software products, and a need for detailed understanding of MDCG 2019-11, MDR / IVDR Article 2 and applicable Classification Rules. Under MDR, software may fall into any of the 4 available risk classes.
- Technical documentation must include (in addition to standard requirements) reference to Software Development Lifecycle Processes (IEC 62304), alongside rigid verification, usability data and evidence relating to data security considerations.
- Risk Management must account for risks specific to software and, ideally, should address the IMDRF Working Group publication “IMDRF/SaMD WG/N81 - Medical Device Software: Considerations for Device and Risk Characterization”
- Post-Market Surveillance will need to be adaptable to changes in outputs and account for potential loss of human-in-loop over time. Challenges have been observed in maintaining engagement of clinicians in PMS activities, especially in the case of some radiology SaMD devices.
- Pre-clinical / clinical testing may need to account for training and testing datasets alongside clinical evidence relating to use in ‘live’ clinical scenarios
- Clinical Evaluation / Performance Evaluation in addition to objectives common to all devices must evidence valid clinical association / scientific validity between the MDSW’s output and the targeted physiological state or clinical condition.
All the above need careful handling during any software-as-a-medical-device regulatory submission.
For any questions relating to requirements for gaining SaMD approval under MDR or IVDR, contact us for a free and no obligation discussion.
What about submissions for evolving / modular SaMD products?
Software-as-a-medical-device is in a near constant state of revision and improvement. For this reason, SaMD manufacturers commonly seek our input in relation to software that performs only some of its eventual functions, with others remaining developmental. A common concern is that the addition of these new elements will require fresh regulatory submissions, multiplying costs and complexity over time.
With the experience of working through a multitude of submissions of this type, our experts will work with you to craft submissions that account for this expansion over time. Normally, a single Intended Purpose can be crafted that is specific enough to meet requirements but broad enough to accommodate for future indications and applications.
Engaging an experienced consultancy from the offset is the best way to avoid significant problems downstream. By developing a strategy rather than solving a narrow problem, our SaMD consulting service will ensure your product can breathe and expand while remaining completely compliant at every step.
How about software with evolving functionality?
The malleability of software to almost any purpose means that an infinite number of configurations can be envisaged. During development, it is common for manufacturers to recognise that added functionality might be simple to implement and would add significantly to commercial appeal, meaning that many SaMD products have evolved substantially from the original concept. On other occasions, it is envisaged from the outset that multiple functions would be envisaged operating ‘under the hood’.
In either case, application of a systematic process helps ensure that the correct regulatory strategy is employed every time.
Considerations include:
- Which features of the device perform a medical purpose? Sometimes all elements individually would meet the definition of medical device; on other occasions, software with a medical purpose is combined with non-medical elements such as communication or archiving capabilities.
- Does the software interact with one or more hardware devices? Some SaMD products are standalone while others are intended to be embedded permanently within one or more hardware devices. A further group may do either or both at the discretion of the user, requiring a full understanding from a regulatory perspective.
