FDA Device Software Regulation

Overview:

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 that are associated with deaths and serious injuries beyond what should be necessary to quantify. FDA sees firms revise software only to create more problems rather than solve them. The infusion pump industry is a classic example that drove FDA to implement a new rigorous paradigm for device evaluation.

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. You need to understand and apply the current provisions that NIST has put forth in recent reports FDA will integrate them into its regulatory oversight.

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
• Voluntary standards
• National Institute of Science and Technology
• Cybersecurity
• Interoperability
• Mobile Apps
• Predictive analytics
• Software validation
• Software recalls

Who will benefit:

• Regulatory Affairs
• Quality Assurance
• Software Design Engineers
• Manufacturing
• Complaint Dept.
• Hospital Risk Dept.

 Agenda:

Day 1 Schedule:

Lecture 1:

FDA authority and regulatory program

• Types of Software are devices
• Regulatory strategy
• Risk classification
• Function and outcome
• Medical Device Data Systems (MDDS)
• Office of the National Coordinator (ONC) for Health Information Protection
• Software regulatory applications
• FDA Guidance
• Premarket submissions
• Paradigms: aeronautics
• Quality System Regulation (QSR)
• Design verification and validation
• Voluntary standards
• Corrective and Prevent Action Plans
• Voluntary standards
• Recalls:
• Service / maintenance / recall.
• Implementation strategy
• Corrections and Removals reporting
• Updates: FDA vs. non-FDA
• Predictive analytics

Lecture 2:

Interoperability

• Compatibility by design
• Hardware
• Software
• Labeling
• Precautions
• Instructions for use
• Use of Voluntary Standards
• Proprietary information
• Failure management / follow up
• User's vs. manufacturer's legal responsibility
• System configuration
• Customization
• Environment of use
• Professional
• Home use

Day 2 Schedule:

Lecture 1:

Cybersecurity

• Device vulnerabilities: malfunction and failure
• Pre-emption design
• Latent malware/virus
• Post-event management
• Corrective action for software
• Disclosure to users
• National Institute of Science and Technology Report

Lecture 2:

Medical Mobile Applications (mobile apps)

• Mobile apps defined as a device
• FDA regulatory strategy
• FDA guidance
• National Institute of Science and Technology Report and Collaboration
• Updates (FDA vs. non-FDA updates)
• Criteria for corrective and preventive action deemed recalls
• Reports of Corrections and Removals
• Reports of adverse events
• Professional vs. lay use / home use
• Labeling: instructions for use and precautions
• Environment of use
• FDA regulation of accessories
• Federal Communications Commission (FCC) regulation

Read More:https://www.linkedin.com/pulse/fda-device-software-regulation-ronald-gardner?trk=mp-reader-card