FDA Device Software Regulation
Software's level of complexity and use is expanding at exponential levels. Likewise the potential risks to health follow suit. Problems with software create a number of different hurdles. Software may be a standalone device, control a device's performance, make calculations, identify treatment options or begin to play a more active role in making clinical decisions regarding patient management and treatment.
FDA's risk classification will gradually clarify how it intends to manage the health risks. Software use has become increasingly complicated with the expansion of software applications, for example: cybersecurity, interoperability, mobile medical "apps," home use and remote use. Another growing concern is the public's use of software programs to manage their health issues rather than go to a healthcare professional.
The increasing sophistication and venue for use create new software design validation considerations. In many instances, validation is limited to the immediate use of the software rather than its environment of use, its performance with other software programs and software hacking. When software causes a problem, fixing the malfunction or "bug" may be more difficult as software becomes more sophisticated, customized by users and placed in a network system. In these kinds of circumstances, it is difficult to decide who is responsible for managing and fixing the software problems. This becomes a major regulatory headache for FDA and generates business to business conflicts. When firms are designing and marketing software, they should be mindful the unknowns that lurk in the future of software regulated as a device by FDA.
Why should you Attend:
For decades, firms have experienced serious problems with software and have been at a loss to make a well informed follow up. Software problems represent one of the most common root causes for recalls. Software failures have been associated with deaths and serious injuries beyond what is necessary to quantify. FDA sees firms revise software only to have it create more problems rather than solve them. The infusion pump industry is a classic example.
The growth of the medical software industry outpaces how FDA's regulatory process is designed. How can you anticipate and defend against the malicious remote hacking and shut down of an insulin infusion pump? In some instances clinicians have weighed the risk of software failure against the benefits of using a device at all. Device software is often used in conjunction with other software based devices, but their interoperability was never anticipated. Can one software program defeat the performance capability or back up safety features of another software program? When interoperability surface, which software manufacturer takes the lead to solve the problem and deal with proprietary software issues?
These are the kinds of issues that will be highlighted during the webinar. The issues require careful consideration even though no obvious answer appears at hand.
Areas Covered in the Session:
FDA legal authority
FDA software guidance
Who Will Benefit:
Software Design Engineers
Hospital Risk Dept.
Learn More: FDA Device Software Regulation