Computer System Assurance

  Data Integrity App Steps in CSA   The CSA process can be described in below broad steps: Identify the software’s intended use.  The CSA approach starts with identifying intended use of the software or software feature. If the system directly impacts patient safety, device quality, or quality system integrity, then it would be considered a direct system (e.g., software within the device, electronic device history, adverse event reporting, etc.). If it does not, then it would be considered an indirect system (e.g., lifecycle management software).   Prioritize risk and determine your approach.  This is where you use critical thinking to develop a validation methodology appropriate to the risk of the system.   The FDA knows that you will have the best insights into how risk is introduced into your products and where it matters, and they expect you to have an element of understanding and contr...

  Data Integrity App The Root Cause of Testing Issues Testing is a fundamental and crucial part of computer system validation (CSV). Computer software assurance (CSA), the FDA's new methodology for performing CSV, won't change that. The hope, however, is that CSA will streamline testing by encouraging us to rely less on scripted testing and pre-approved protocols and more on existing test/vendor records and automated tools in our testing efforts. In other words, CSA is designed to help us test smarter, not harder. The Root Cause of Testing Issues The foundation of good software, or software that performs as intended, is good requirements. The same is true with testing. If you want to write good tests, you must start with good requirements. Inferior or incorrect requirements are often the root cause of a testing problem. User requirements define the intended use of the system. Functional requirements outline how the system must perform to meet those user req...

  Data Integrity App Scripted vs Unscripted Testing: what’s the difference? Traditionally each test script was written in great detail, regardless of whether the system or feature was a Direct or Indirect system or feature. So, the same level of effort was being put into creating test documentation for low risk systems or features and high-risk systems or features. CSA introduces the terms Scripted Testing and Unscripted testing. Let’s examine these terms:  ‘Scripted Testing’  ‘Scripted Testing’ is what we would know as traditional testing. Scripted tests as we know usually contain at a minimum a test Objective for the test script, a step-by-step test procedure, Expected Results and a Pass/Fail. Scripted Testing is to be used to test to higher risk (Direct) systems or features as the software does directly impact the product or patient safety. Scripted testing requires significant preparation and follows a prescribed step-by-step...

  Data Integrity App Direct & indirect system in Computer System Assurance FDA new re-defined terminologies as Direct and Indirect system on the basis of the impact on patient safety, product quality and integrity This change allows manufacturers to define testing strategy and apply critical thinking. Let’s get familiar about systems and new testing terminologies: ‘Direct System’  Direct systems have a direct impact on patient safety or product quality—like electronic device history , Laboratory Information Management or adverse event reporting—and may require increased testing based on risk. In other words, the riskier a system impact is to the end-product and to the safety of the patient, the more testing and documentation is required. (e.g. Inspects or dispositions product, labeling systems) will require testing based on risk, and expected deliverables are similar to current expectations, i.e. the riskier the application, the more testing and documentation is re...

Data Integrity App   CSA- Same Regulations; Different perspective A system whose software does not impact Patient Safety, Product Quality is considered Non-GxP, e.g., Systems or Tools used for Document Management, Compliance Management, and Lifecycle Management. The risk associated with such systems is low, and the same level of rigor on Testing, Documentation is not needed. GxP systems (Systems having a direct impact) such as LIMS, MES, Adverse event reporting have a higher risk of impacting Patient Safety and Product Quality. Hence such systems require adequate Testing and sufficient documentation. In a nutshell, the higher the risk, the higher the need for detailed Testing and Documentation. The below picture depicts how CSV and CSA differentiate from one another without compromising on the regulation requirements. This is done while keeping in mind the critical aspect  of documentation, which takes a lot of time and effort in a System Validation process for a...

Data Integrity App   New Approach to Validation 01 AUTOMATION: USFDA supports and encourages automation as it has the potential to improve productivity and efficiency, help in tracking and trending, plus a host of other benefits. Manufacturers can gain advantages from automation throughout the entire product lifecycle. They can reduce or eliminate human errors, optimize resources, and reduce patient risk.   USFDA’s position is that using these software products can be an excellent way to enhance product quality and patient safety, which in the end, is the overarching goal.   02 CHANGING THE PARADIGM: Current industry practice as part of CSV program is documentation heavy. Documentation is done at the expense of critical thinking and testing. CSA brings paradigm shift in this approach by encouraging critical thinking over documentation. By using CSA concepts, companies can execute more testing with less documentation based on risk associated with requiremen...