Some observations from the 2024 AAMI/FDA neXus conference

I (Mike Russell) attended the neXus conference on medical device standards this year. Below are some observations and suggested takeaways from the talks I heard and the panel I was on. Remember, these are just selected highlights, not everything said 🙂

Session: Reducing Submission Rejections and Recalls with Software Standards

This year’s conference added a third track/focus area for standards application. Therefore, a session about applying software standards was added. Fellow AAMI instructors Dave Nelson and Jeremy Jensen joined with me as panelists. We provided some brief introductory comments, then focused on Q&A/discussion.

Why we had the panel:

• Software is usually one of the top three reasons for medical device recalls.
• Software portions of submissions continue to be a frequent stumbling block.
• Manufacturers still struggle with standards application.
• Applying standards in an efficient way is even harder.

Some notes from our panel:

• New standard and guidance releases are accelerating. This means:
  • Guidance documents are a way to keep the industry up to date compared to the often longer cycle for standards.
    ➡️  Don’t ignore guidance documents.
  • The longer the product development and total lifecycle, the more likely that standard and guidance versions will change.
    ➡️  Incorporate ability to adapt accordingly in plans and processes.
  • From a practical perspective, surveillance can also mean appropriate monitoring of draft standard and guidance development – not just releases. This can provide forewarning of potential needed quality system and/or product changes.
    ➡️  Standard and guidance monitoring should be included in plans and plan execution.
  • ➡️  Make ongoing quality system and process improvements for standard and guidance changes. This will help achieve repeatable and consistent compliance.
  • Device categorization based on prior standards and regulatory requirements can change.
    ➡️  This means revising practices and documentation for that product.

• Standard and guidance harmonization across regulatory jurisdictions is helping companies cope with compliance.
  ➡️  Don’t miss or underappreciate is appropriate harmonization across major company internal functions. Otherwise, regulatory, quality, compliance, and development etc. can have conflicting internal requirements. The pace of standard/guidance change can also cause disconnects when one area makes updates and others haven’t.
• As products get more complex, it is harder for submission reviewers to do their work.
  ➡️  Make it easier for them to do their work and reduce chances the submission will be rejected:
  • Include what is needed but nothing more in submissions. More (information than needed) is often less in this situation. Not everything in a standard or guidance is required for a submission.
  • Construct the submission tells a consistent and easy to follow “story.” Also make titles of any attachments and other files easy to find/follow.
• ➡️  Don’t equate required submission information with internal development information … they are not necessarily the same. Because some evidence is not needed in the submission does not mean it isn’t needed. A DHF will include more for quality management or software development than what is in a submission.
• Appropriate practices are the foundation for developing safe and effective software. “Good” software development for medical devices is different from “good” for a low-risk web app. This also has implications when recruiting from outside the medical device realm.
  ➡️   Determine what your practices should be, implement effectively, and train to them.
• Understanding of what is/constitutes a SaMD seems to vary significantly.
  ➡️  Don’t evaluate risks – including cybersecurity – solely for a SaMD (e.g., phone software app) if connected to other systems. Take a systems-of-systems approach to assess risks and architecture.

AI and Cybersecurity

As might be expected, AI and cybersecurity were dominant themes across many sessions.

Here is an AAMI summary of one session about the implications of new cybersecurity standards: https://array.aami.org/content/news/new-cybersecurity-standards-iec-aami-compliance

In a different session, Jessica Wilkerson of the FDA provided information about FDA new rules and recommendations around cybersecurity. Section 3305 (and subsection 524B specifically) of the Consolidated Appropriations Act of 2023 updated medical device cybersecurity requirements. The FDA final guidance Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions, dated September 27, 2023, helps manufacturers implement the new requirements. Observations from her presentation:

• The definition of a “cyber device” includes “Has the ability to connect to the internet.”
  ➡️  Note that “ability” is just that. A device with an unused Internet ability is still considered a risk just because of ability.
• Similarly, the definition includes “Contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats.”
  ➡️  Any kind of port or connectivity falls here, whether used by the system or not.
• Cybersecurity considerations apply for entire system and for the entire product life cycle.
  ➡️  Plan accordingly.
• The guidance requires cybersecurity updates done in a timely manner.
  ➡️  This implies that how to be timely should be part of product planning.
• Cybersecurity efforts are going to be evaluated as a minimum against guidance Appendix 1.
  ➡️  Review Appendix 1 and then incorporate appropriately into internal expectations.
• Pictures can be worth a thousand words.
  ➡️  Provide visuals along with text for the architecture views listed in the guidance.

General notes

Interesting coincidence. While we were discussing software standards and processes in our panel. I and some others did not have AT&T cell service. AT&T disclosed “the application and execution of an incorrect process used as we were expanding our network.” Operational processes matter too. 😉

One last note. I heard in multiple sessions the advice to personally read standard and guidance information. Assistance from others can help a lot; however, in the end you are responsible for knowing and understanding what and how to implement.