CSA vs. CSV: FDA’s Computer Software Assurance Draft Guidance for Production and Quality System Software

What Is CSA?

The U.S. Food and Drug Administration (FDA) released the draft guidance “Computer Software Assurance (CSA) for Production and Quality System Software” in September 2022. The draft guidance provides an objective basis for subjective opinion, causing differing views of what it means and how it compares to computer software validation (CSV).

Proponents of computer software assurance have compared it favorably to computer software validation in somewhat absolute terms, stating computer software assurance adds value, whereas computer software validation produces documentation. Computer software assurance may be more efficient and provide superior results to computer software validation. However, this is only possible if your organization has subpar FDA software validation practices and can practice computer software assurance well. With a minor exception, CSA doesn't change or revoke any portion of CSV. The computer software assurance guidance clarifies how to define risk based on the intended use and what types of testing are appropriate for different levels of risk. As the draft guidance states, computer software assurance supplements existing computer software validation guidance and does not replace it.

Computer software assurance corrects misinterpretations and misapplications of computer software validation in how some organizations have practiced compliance. Much of the misapplication applies to software-centric risk assessments, such as risks based on software categories or risk and mitigation calculations that result in complex numeric scores with no practical meaning and often lead to no differentiation in the test approach. Misapplication of a risk-based approach to FDA software validation is likely to lead to poor results. The new guidance clearly states that risk should not be software-centric; the focus is on the process and the patient.

The Benefits of CSA for Life Sciences

The benefits of computer software assurance depend on your organizational maturity, regulated products or services, and the level of current validation. If your organization has strayed from risk-based computer software validation principles, your organization may be producing documentation with no integral value. An organization risks having non-value-added testing that compromises its effectiveness. Applying computer software assurance principles can benefit organizations not following computer software validation guidance.

Computer software validation presumes a waterfall methodology and computer software assurance assumes an agile development environment. Computer software assurance implies agile methods as a conceptual framework. Likewise, computer software validation is typically a waterfall step at the end of the development process, usually performed by a specialized group, before handing off to Quality Assurance for final approval. In concept, computer software assurance is part of an agile process in which you only document what has value to your organization. In contrast, CSV documents everything needed to satisfy an internal or external auditor. At its worst, computer software validation can be detached from the rest of the process, adding weeks or even months to the end of the development or deployment.

Implementing computer software assurance can allow CSV to no longer occupy its silo with self-contained information. With CSA, information captured does not need to stand independently with the reliance on other data such as vendor testing, software development life cycle (SDLC) artifacts, and quality assurance artifacts from activities further upstream in the development process. A broader array of processes and related artifacts may be relied upon to assure FDA software validation. A Requirements Traceability Matrix (RTM) mapped to various tests will come in multiple forms, from numerous sources, and at different points in the process.

A CSA implementation effort will affect more than a self-contained computer software validation model. CSA will likely require redefining job duties as CSV becomes a more integrated part of SDLC. For example, business users may perform unscripted or ad-hoc testing without a stringent documentation standard to require an FDA software validation specialist. The existing protocol applies more to a documented risk and test management program than a single test case or plan.

Conclusion

With computer software assurance, covering up poorly executed SDLC processes as backend artifacts in the CSV silo is no longer possible. With computer software assurance, an organization needs documented SDLC procedures with defined intended use, assessed risk, and defined SDLC testing. An organization demonstrates related artifacts follow a process, requiring a more coordinated level of IT governance that includes IT, business, and quality stakeholders to oversee the process from design to release.

The CSA draft guidance intends to supplement and help refine computer software validation. The best compliance approach depends on an organization's current FDA software validation practices. Every organization strives for ongoing improvement, but the pace derives from an honest assessment of a current compliance state. Arbour Group helps manage a holistic approach to computer software assurance, assisting organizations in their current state of compliance.