Episode Thumbnail
Episode 72  |  34:31 min

What are the Regulatory Expectations for Software as a Medical Device (SaMD)?

Episode 72  |  34:31 min  |  11.07.2019

What are the Regulatory Expectations for Software as a Medical Device (SaMD)?

00:00
00:00
This is a podcast episode titled, What are the Regulatory Expectations for Software as a Medical Device (SaMD)?. The summary for this episode is: These days, medical devices often include software or are standalone software. So, software as a medical device (SaMD) is a hot topic, and regulatory bodies have been updating regulations and launching new initiatives to seek applications being submitted for approval. However, a lot of confusion surrounds the how, what, and when to do things to meet FDA and other regulatory expectations. On today’s episode, we have Andrew Wu, a software consultant for Rook Quality Systems. He helps SaMD companies ensure that their documentation, platform, and systems they establish during the design, development, and manufacturing of software aligns with regulatory requirements. SOME OF THE HIGHLIGHTS OF THE SHOW INCLUDE: ● SaMD is a standalone software that performs 1 or more medical purposes without being a part of a hardware device. ● Embedded firmware and software that monitors performance of a hardware device are not SaMD. They are still software and an integral part of the device. ● FDA’s guidance is not enough for many applications, so it is planning and engaging in new activities and programs for future SaMD applications. ● 62304 Standard: Consensus standard for manufacturers on how to manage their software lifecycles. Initially, classification determination was unclear. ● Care about the SaMD classification to know what information to provide and understand the impact of its safety profile when a failure or defect occurs. ● Manufacturers should be in constant contact with the FDA and consultants about regulations because of frequent changes and additions. ● SaMD companies need to have a quality management system (QMS) during the development process to address regulations; don’t wait until it’s too late. ● No regulatory standard of method to use or not use; but describe, define, and document your methodology.