Episode description
This is audio from RQM+ Live! #61, recorded 13 October, 2022. To join us live for future shows and ask your own questions, please view and sign up for upcoming events in the Knowledge Center at our website.
Each year RQM+ supports hundreds of FDA 510(k)'s and EU technical documentation files for either medical devices containing software or stand-alone software devices. In this show our regulatory experts will discuss both FDA and EU deficiencies and additional information requests associated with software (real case studies), as well as best practices and solutions to avoid these pain points in your submissions.
- Devices and challenges discussed included:
- Artificial Intelligence (AI) machine learning and acceptability of change control plans
- Defining proprietary algorithms and controlling changes in those algorithms
- Cybersecurity implementation and alignment with ISO 14971 (Risk management)
- Lack of information on connected devices
- Aligning terminology and documentation across various requirements and processes (AGILE, ISO 62304, QSR, MDR, IVDR)
- Off-the-shelf software and expectations for verification and validation testing.
Panelists:
- Allison Komiyama, Ph.D., RAC - Regulatory Consultant at RQM+ and former President and Founder of AcKRS
- Kevin Go, MBA, RAC, CQA - Senior Principal, Regulatory and Quality Practice, RQM+
- Hrishkesh Gadagkar - Principal Engineer, RQM+
Questions with timestamps:
2:55 -- Setting the scene with definitions... what is software as a medical device and how is it defined between the EU and the United States?
3:54 -- What are the main challenges of software from a demonstration of compliance / regulatory perspective? 9:04 -- What are some best practices for creating software documents to avoid deficiencies?
12:21 -- What are you seeing? Are you seeing significant differences between what the EU and FDA are asking for?
18:29 -- What are the regulation standards and documentation requirements for cybersecurity?
23:51 -- If software developers define user stories as their starting point, are additional dedicated software requirements needed?
26:48 -- We are talking about what is needed to make notified bodies or FDA happy... however, the killer point is getting the software engineers into a practical management of requirements, unit, integration testing, etc.
37:00: -- Does a manufacturer need to audit its cloud provider?
39:00 -- Regarding the responsibilities, when a software device is sold and installed in a hospital or a clinical institute, if the software device is disconnected from the Internet and could not perform the functions as designed, who should be responsible for the impact on the patient? The hospital or the manufacturer? Same question: what if the device was hacked?
43:25 -- You just mentioned the connection between SRS and SDS... is traceability between requirements and design critical in your opinion? It seems desirable as it helps add clarity and understanding for the reviewer but also relative to the quality of the design process. Traceability to verification (requirements to verification) is critical, but wondering about requirement to design.
46:24 -- What have you been seeing with AI and machine learning?
52:50 -- What about wearables and AI / machine learning?
55:42 -- Do you have a final piece of advice for our listeners or top tip?