Software in Medical Devices, by MD101 Consulting

To content | To menu | To search


Three new FDA guidances

The FDA released three new FDA guidances in July 2016:

  • Two draft guidances on Deciding When to Submit a 510(k) for a Change to an Existing Device,
  • The final guidance on General Wellness: Policy for Low Risk Devices.

General Wellness Policy for Low Risk Devices guidance

The General Wellness Policy for Low Risk Devices guidance was discussed in a previous article when it was in released in draft by the FDA: see article When the FDA releases guidances in burst mode.
The final version of this guidance doesn't change the conclusions of the article. The FDA summed-up the changes between the draft and final versions in the web page announcing a webinar on the guidance.

Deciding When to Submit a 510(k) twin guidances

These two draft guidances are titled:

  • Deciding When to Submit a 510(k) for a Change to an Existing Device, and
  • Deciding When to Submit a 510(k) for a Software Change to an Existing Device.

The first one is no surprise, the existing guidance also titled Deciding When to Submit a 510(k) for a Change to an Existing Device is almost 20 years old! This new one is intended to clarify when a change in a legally marketed medical device would require that a manufacturer submit a premarket notification 510(k). No doubt it will be the bedside book of regulatory affairs professionals.

The second one is more exciting, at least for this blog. The FDA managed the feat of creating a flowchart to assess what a major software change is. No surprise, the flowchart is closely linked to the risk-based approach.

We can see how it is difficult to design a flow chart for software changes in the last box of the chart: Evaluate additional software factors that may affect the decision to file. This box leaves the assessment opened to any kind of situation, which could happen with software changes.
Fortunately, the FDA shipped a good batch of examples in the package. These examples are here to raise alarm bells of reviewers of software changes.

The only surprise is to see nothing on human factors in this guidance. Graphical User Interface is most of times a big part of software systems. But this is not inadvertence, human factors are already addressed in the "main" guidance.
A way to remember that the guidance on software changes shouldn't be used alone to assess changes in a medical device.



Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed