FDA Perspectives on Cloud Technologies

USDM hosted its first virtual event with an all-star line up of life sciences thought leaders. If you missed our Forward-Thinking GxP Compliance & Process Optimization event, you can watch the replays of the four thought-provoking sessions here.

Session 3 – FDA Perspectives on Cloud Technologies

Cisco Vicenty shared an update on the FDA’s Case for Quality, plus:

• FDA’s support of modern cloud technologies and automation
• CSA guidance update
• Case studies in CSA
• Q&A

Speakers

Cisco Vicenty, Program Manager, Case for Quality, FDA
Jim Macdonell, VP Eastern Region, USDM Life Sciences (moderator)

Learn more about this topic in our companion white paper, Considering CSA? Here’s what you need to know.

The structure of the event addressed various stages of cloud compliance maturity. Whether you are getting started, getting better, or getting ahead, this discussion will provide guidance for your cloud transformation journey.

Here are links to the other session replays and companion white papers:

Session 1 video: Your Compliance and Technology Today
Companion white paper: Top 5 Opportunities to Improve Compliance Maturity

Session 2 video: Managing Your Regulated Cloud Technology
Companion white paper: Why You Should Consider Outsourcing Your Cloud Vendor Qualification

Session 4 video: Extracting Value from Your Cloud Data and Processes
Companion white paper: Google Cloud Platform for Life Sciences and Health Technology

Q&A: FDA Perspectives on Cloud Technologies

When will the U.S. Food and Drug Administration (FDA) draft guidance for Computer Software Assurance (CSA) be available? This is very important with respect to having a basis to start any transition to CSA.
The Computer Software Assurance for Production and Quality System Software guidance document is on the FDA’s A List, which means it is a prioritized guidance document they intend to publish in 2022.

Once the guidance is released, the FDA will train investigators in the CSA approach. The Digital Health Center of Excellence is also available to help if an investigator does not approve of your organization’s approach.

The FDA acknowledges that users are validating systems for auditors instead of ensuring the safety and efficacy of their product. The FDA guidance emphasizes patient safety and Quality Management System impact.

Vendors of systems specific to life sciences should be prepared for the CSA implementation with solid documentation that customers can leverage during their audits.

Can we start applying CSA even if though the guidance document has not been published?
Yes. This methodology has been championed for years. The FDA has repeatedly stated that the CSA guidance provides a risk-based framework that can be used now to help you transition to the CSA approach for validation.

It is likely the guidance will have multi-center support between CDRH, CDER, and CBER.

A lot of software will not directly hurt a patient. Tracking someone’s diet is not the same as testing their blood sugar levels. What is the FDA doing to separate these?
The FDA’s CSA framework categorizes computer systems as direct or indirect. Direct systems require more documentation of testing activities due to risk. Indirect systems require less documentation.

Implementation method further reduces risk with a good vendor.
The intent of the CSA guidance is to do more testing with a less burdensome documentation approach.

Is Good Automated Manufacturing Process (GAMP) a favorable approach?
Absolutely! GAMP and CSA are both acceptable approaches to achieve computer software validation. GAMP is especially helpful when you are using a true risk-based approach.

How should technology providers adopt the concepts of CSA given that their internal quality management system (QMS) approach and documentation being leveraged more heavily under CSA?
It is important to note that vendors should not use a CSA approach. Instead, they should employ a software development lifecycle (SDLC) that provides controls and validation activities that can be audited.

Your internal vendor qualifications should be tailored to ensure proper controls for vendor software development and testing activities in order to properly leverage them.

Any thoughts on harmonization between the European Database on Medical Devices (EUDAMED) and Medical Device Information Analysis and Sharing (MDIAS)?
No, at least not yet since the EUDAMED does not fully exist. Perhaps there could be harmonization in the future, but you are dealing with non-U.S. data that would be incorporated into what is essentially a U.S.-based dataset.

FDA’s view of computer software validation (CSV) seems to focus on patient risk, but what about data integrity and quality products? Do these automatically become low risk?
No! The FDA’s risk approach definitely takes data integrity into account.

Patient safety and product quality also impact your QMS and your CSA risk assessment.

The FDA is releasing a guidance document, not an actual regulation. How can we argue that following a guidance document is better than following the legally required documents?
Guidance documents contain the FDA’s current perspectives for meeting regulations, which generally state what to do, not how to do it. Guidance documents are the framework agreeable to FDA (usually best practices) or that provides current thinking (the c in cGMP) to meet regulations.

The existing regulation simply states automated systems must be validated for their intended use. CSA provides a framework to accomplish that.

21 CFR Part 820 is part of the cGMP for medical devices. What applies or is in the works for 21 CFR Part 210 and 211?
The FDA intends for the CSA framework to be multi-departmental and applicable to 21 CFR Part 210 and 211.

GAMP, when applied properly from a risk perspective, can also benefit users.

Unscripted testing is a game changer and will relieve the documentation burden.
For low-risk systems, unscripted testing can be valuable and relieve the burden of your validation lifecycle management process.

The CSA approach requires documentation of the features and functions tested (including any failure modes, boundary testing, etc.), documentation of deviations or issues and their resolutions, a conclusion statement, and a record of who did the testing and when.

Agile likes to pretend paperwork isn’t needed, but you have to prove you did it. ISO has three very simple principles: Say What You Do. Do What You Say. Prove it.
The FDA has stated that the industry overuses screenshots and that they are not usually necessary. Document your testing to meet your needs, not to appease an auditor.

Objective evidence doesn’t need to be a document. The data in your testing tool is fine; however, you still need documentation for the features and function tested (including any failure modes, boundary testing, etc.), documentation of deviations or issues and their resolutions, a conclusion statement, and record of who did the testing and when.

Regulations states “validate computer software for its intended use according to an established protocol.” How does this get reconciled with CSA ad hoc testing option?
USDM recommends having a validation plan that documents your assigned risk as well as your testing approach.

A validation plan is very helpful in communicating testing approaches especially in applications that have functions with different risk levels. A hybrid approach (e.g., some functions using ad-hoc testing and some using robust scripted testing) is perfectly acceptable.

0

0