Just share notes and thoughts about the Software Configuration Management in IEC 62304 (section 6 in the 2015 version).
Share notes and thoughts on Software as Medical Devices
Just share notes and thoughts about the Software Configuration Management in IEC 62304 (section 6 in the 2015 version).
Just a friendly reminder đ - the FDA guidelines is for preparing your submission packages. So even if the FDA doesnât require a specific document for submission, you must still ensure you cover all the necessary steps according to 21 CFR 820, ISO 13485, and IEC 62304 â if you claim conformity.
If you are stepping into the Software as Medical Devices (SaMD) world, chances are you will come across terms like âanomaly,â âdefect,â âbug,â or âsoftware failureâ in various standards, guidance, white papers, and such. These words often seem interchangeable, but have you ever wondered if there are any nuances you need to be aware of? This post dives head-first into the regulatory/software language. Weâll unravel how these terms are defined by different entities â from the FDAâs perspective to the guidelines laid down by IS 62304, and of course, in the everyday lingo of our very own software engineers. Understanding these terms and their context not only helps us communicate more effectively but also enhances our comprehension of the complex dynamics of software creation and maintenance. So, letâs get started!
Latest Posts
In medical devices, âinteroperable medical devices refer to the ability to exchange and use information through an electronic interface with another medical/non-medical product, system, or device. Interoperable medical devices can be involved in simple unidirectional data transmission to another device or product or in more complex interactions, such as exerting command and control over one or more medical devices. Interoperable medical devices can also be part of a complex system containing multiple medical devices.â [The US FDA, Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Device, issued on September 6, 2017]. For example, a blood glucose meter that can send data to a smartphone app, an x-ray that can communicate with a picture archiving and communication system, or a ventilator that can adjust its settings based on the patientâs vital signs are all examples of interoperable medical devices.
A common query from entrepreneurs establishing a software as a medical device company is, âWhen should we start to implement a QMS system, especially design control?â In response, itâs suggested to initiate this process when youâre prepared to construct your Minimum Viable Product (MVP) (p.7).
It has been more and more often that equipment and software companies providing their products to clinics and hospitals are, actively or passively, due to requests from the regulatory authorities, documenting/filing their products as medical devices. Such changes in the status of a product particularly often occur on software. This is [thankfully] due to the huge progress in the use of software in improving physical and mental health. Common scenarios that a company needs to consider converting an existing software product to a medical device or bringing a legacy software item into part of a Software as Medical Device (SaMD) include: