Mar 07, 2023
Medical Device Software Changes: Getting the RA and Dev Teams on the Same Page
Most regulatory affairs (RA) professionals are not especially eager to interact with software developers, and generally that feeling is mutual. Sometimes it can seem as though we were born on different planets, each with our own languages and customs. Yet, if you manage regulatory compliance for your company and your medical device incorporates software, you’ll need to make sure those developers fully understand their regulatory obligations.
Get to Know Your Code-Loving Colleagues
Yes, we know what you’re thinking. You can’t just march over to the software development team and ask them to mold their process around your regulatory needs. You can, however, make an effort to develop a closer relationship with the team to better understand their language, their software development process, and how that process can peacefully coexist with your needs. After all, after making safe and effective devices, your mutual #2 goal is to avoid the ire of FDA inspectors or European Notified Body auditors.
Explain Why, Not How
FDA inspections can result in the issuance of an FDA Form 483 “Notice of Inspectional Observations.” FDA issued 500+ Form 483 notices to medical device manufacturers in 2022. The majority of those cited problems with manufacturer design control processes, design documentation, or design verification / validation. It’s clearly an area of focus for FDA.
When things get seriously out of control, FDA may issue a warning letter to a manufacturer, and those are posted online in all their unredacted glory. While warning letters are quite rare for device companies (fewer than 20 issued in 2022), the results can be calamitous for the recipient.
| More than 50% of Form 483 notices issued to medical device manufacturers cited problems with manufacturer design control processes, design documentation or design verification/validation. |
Understand How They Currently Manage Change Control
Many medical device and IVD companies use TRACE reporting tools (such as Jama) to track and report software development progress. TRACE stands for “test, review, analyze, control, and evaluate.” This methodology is used to ensure that software development projects are on track and that any issues are identified and addressed in a timely manner. TRACE reporting tools allow your software development team to:
-
- Perform verification and validation
- Demonstrate traceability
- Manage risk analysis
- Maintain audit trails and export data
- Support compliance with 21 CFR Part 820.30 (Design Controls), 21 CFR Part 820.70(i) (Validation), and 21 CFR Part 11
TRACE reporting is often used in combination with other project management methodologies (like Agile) to provide a comprehensive view of the development process and changes. As such, you’ll want to sit down with someone on the software team who can show you which tools they use to manage this process. (Hopefully they use something!) During this meeting you can open a discussion about the specific types of changes that get made and whether they need input from regulatory.
Questions to Ask
- How does the change process work?
- What tools are you using for change control?
- Do you batch changes?
- Who has access to record / edit changes?
- How do you classify changes to software?
- How does our device software connect into networks?
- Which cybersecurity tools do you use?
- How do you classify threats?
- How do you handle changes to operational technology (OT) vs. information technology (IT)?
Be Clear About the Changes That Require Input From Regulatory
If you’ve ever scanned the release notes that accompany every iPhone, Microsoft Office, or app update, you won’t be surprised at the variety of issues the software team deals with on a day-to-day basis. As the regulatory liaison, you should familiarize yourself with the types of software changes and which among them require specific action. This is where change management can go haywire, because some software developers operate on an “ignorance is bliss” basis about regulatory issues, or simply are not aware of them. The key here is to explain that it is not your goal to slow them down or stifle innovation, but rather to make sure that the company remains in compliance with FDA, EU, and other regulations, especially regarding risk management.
| Changes That Require Input From Regulatory | Changes That DO NOT Require Input From Regulatory but DO Need to Be Documented |
|
|
*Be sure to discuss patch management, as this may or may not require input from regulatory.
Major Software Updates: When a New 510(k) Submission Is Required
As you may know, FDA has issued guidance entitled “Deciding When to Submit a 510(k) for a Software Change to an Existing Device.” Your new software friends are highly unlikely to read it, so it’s up to you to share the highlights with them.
Appendix A of the software guidance walks you through some real-life examples that definitely warrant a discussion between the regulatory and software development teams prior to implementation. They all center around one of three questions FDA says you should ask yourself to determine whether a new 510(k) is required:
1. Is the change made solely to strengthen cybersecurity and does NOT have any other impact on the software or device?
2. Does the change introduce a new risk or modify an existing risk that could result in significant harm and that is not effectively mitigated in the most recently cleared device?
3. Is the change made solely to return the system into specification of the most recently cleared device?
We recommend that you cover this guidance with the software team and cite some of the examples provided in Appendix A of the guidance.
Part 11: It’s Not All About the Code
Section 820.30 of the FDA quality system regulation deals with design control, and most senior software developers are familiar with these basic requirements. Many are less familiar with the nuances of 21 CFR Part 11 dealing with electronic records, signatures, file access, and audit trails. As part of your outreach to the team, you’ll want to gauge their awareness of Part 11 compliance and train them as needed on the four most critical aspects of Part 11 compliance:
1. Maintaining security and user access controls
2. Complying with electronic signature requirements
3. Validating your process
4. Creating an audit trail
We have an outstanding article on this topic here.
Remember those warning letters we mentioned earlier? They provide some telling insight into how FDA inspectors look at this issue. Here are some verbatim comments (emphasis added):
- Your analysts had access to delete and overwrite data.
- Failure to exercise sufficient controls over computerized systems to prevent unauthorized access or changes to data, and failure to have adequate controls to prevent omission of data.
- To ensure data integrity, actions performed must be attributable to a specific individual in your CGMP computer systems, and equipment should be appropriately controlled to prevent deletion and / or changes except by authorized personnel.
- Personnel had administrative privileges including, but not limited to, the ability to delete data sequences and change method parameters.
- IT staff share[s] usernames and passwords to access your electronic storage system for data – your IT staff can delete or change directories and files without identifying [the] individuals making changes.
Just reading these examples may elicit some uncomfortable squirming among the software engineers you speak to, but it’s important that they know FDA really scrutinizes these things.
There’s So Much More to Know…
Oriel STAT A MATRIX offers a wide variety of training classes regarding software, including:
- Medical Device Software Regulations and Standards
- Medical Device Software Development Life Cycle
- QMS Software Validation Training for Medical Device Companies
- Medical Device Non-Product Software Validation
- Medical Device Cybersecurity Risk Management Standards & Regulations
Our team is here to help. Contact us online
or
Get answers right now. Call
US OfficeWashington DC
EU OfficeCork, Ireland
