Dr. Erkan Hassan

Monthly Writings

Evaluations and reviews of the latest in the field.

FDA Shift with New Regulated Software Guidance

After reading this article, you will be EMPOWERED to understand the new software assurance guidelines to be compliant with the proposed shift in THE FDA’s approach.

SUMMARY:

  • The FDA has proposed to move away from “business as usual” for software validation.

  • Previously, the Computerized System Validation (CSV) was built on thorough testing of every feature and documenting every outcome.

  • The new Computer Software Assurance (CSA) guideline is designed to evaluate the intended use of software, with assurance activities tailored to proportionate risk to safety and quality.

  • The goal is to streamline hours of redundant testing and documentation while focusing on maintaining a validated, safe system.

COMMON PAIN POINTS

  • Teams will need to be trained on critical thinking and risk-based assessments.

  • Operating procedures will need to be redesigned.

  • The challenge of adoption

REVIEW

BACKGROUND

  • Guidelines issued September 2025

  • Moving from the Computerized System Validation (CSV) process to the Computer Software Assurance (CSA) process.

    • CSA is designed to emphasize risk, critical thinking, and efficiency over paperwork for paperwork’s sake.

  • Major shift from testing every feature and documenting every outcome (CSV) to provide assurance activities proportional to the risk of failure of the software’s intended use in quality and safety.

INTENDED USE:

  • Software may have 1 or more intended uses

  • Must examine each intended use and develop a risk-based assurance strategy for each.

  • Validation should occur with software considered to be used directly or in support of production or quality systems (BOTS, data collection & processing, data analytics, artificial intelligence or machine learning tools, maintenance of quality records, developing and running scripts).

  • Cloud computing may or may not be included.

RISK PROCESS:

  • Systematically focus on identifying foreseeable software failures that may impact or prevent software from working as intended, with potential harm to the patient or user.

  • Determine risk level for each factor, function, or operation based on intended use.

    • Low

    • Intermediate

    • Moderate

    • High

  • FDA concerned with “High” risks for review and assurance

    • Categorize risks as “High” vs “Not High”

  • HIGH RISK:

    • If function fails, may lead to compromised safety

    • Parameters affecting essential properties

    • Parameters that:

      • Measure

      • Inspect

      • Analyze

      • Automated surveillance

      • Trending to tracking of essential data

      • Perform process corrections without human awareness

    • Provide instructions or materials for safe operation to patients and users.

  • NOT HIGH RISK:

    • Data or monitoring not directly impacting performance

    • Used for corrective and preventive actions within the system

    • Intended to manage, auto-calculate, and send relevant alerts to manage the data.

  • Any changes in software that may compromise safety should be submitted within 30 days, otherwise annually.

APPROPRIATE ASSURANCE ACTIVITIES:

  • A greater amount of objective evidence should be generated for “High Process Risk”

  • There are 2 types of testing:

    • Scripted

    • Unscripted

  • High processes should have scripted testing procedures.

  • SCRIPTED TESTING:

    • Test cases recorded within the documentation tool.

    • Easily inspected manually or automatically.

    • Level of detail based on risk identified.

       

  • UNSCRIPTED TESTING:

    • Written instructions are not necessary

    • Scenario Testing:

      • Specification-based test cases

      • Based on the sequence of interactions between the test item and the user.

    • Experience-Based Testing:

      • User experience of the tester to generate test cases targeting the identified problem.

      • Error Guessing: test cases designed based on testers’ knowledge of failure.

      • Extrapalatory Testing: Testing based on existing knowledge of common software behavior and types of failures.  Looks for hidden properties and unanticipated behaviors.

  • ADDITIONAL ASSURANCE CONSIDERATIONS:

    • Procedures to ensure integrity of production data

    • Established purchase control processes for selecting vendors

    • Cybersecurity

    • Periodic or continuous collection of data by software to monitor and detect anomalies in software without implementation

    • Software bug detection

    • Iterative and continuous testing cycles throughout software life cycle

APPROPRIATE RECORD KEEPING:

    • Intended use

    • Goals of testing

    • Documentation of activities checklist

CONCLUSIONS:

  • The new CSA system is designed to improve the vast resources previously necessary for software validation from a regulatory perspective.

  • CSA emphasises the maintenance of a validated state throughout the software’s life cycle.

  • The challenge will be the adoption of this new process.

For the new FDA CSA system:

  • Document risk decisions clearly

  • Start with non-critical pilots first

  • Train teams on risk assessment

  • Combine vendor evidence

  • Demonstrate why tests were or were not done

  • Eliminate reams of irrelevant reports

Although this is challenging, it should not be left to chance.

Let’s have a brief chat to discuss your unique situation

Erkan Hassan