There are several important factors to consider to ensure a successful transition to CSA. They are focused on those areas that can provide a major impact to your CSA implementation.

• Leveraging Agile Methodologies

  • Leverage Scrum – Scrum is an approach that relies on teams working together in short phases, enabling rapid feedback, continual improvement, and fast adaptation to change to accomplish an objective. By incorporating this agile approach with the CSA implementation the organization will be able to bring in efficiencies and optimization into their processes supporting CSA.
  • Test-driven development (TDD) – TDD is a software development methodology that focuses on establishing unit test cases before writing actual code. It’s a method that combines programming, unit testing, and refactoring in an iterative. TDD will enable organizations and teams to reduce the amount of documented testing that would need to be performed as part of the system release.
  • Follow Behavioral-driven development- BDD is an agile software development process in which an application is documented and designed around the behavior that a user expects to see when interacting with it. BDD will help reduce the rigor and the complexities of developing test cases from the requirements alone – incorporating the learnings from the BDD sessions into the testing phase will greatly reduce the time for the testing phase as well as bring in efficiencies.
  • Introduce early testing techniques – By incorporating configuration and experimentation in lower environments to find defects early, organizations can improve process efficiencies across the SDLC as well get to release faster.

• Leveraging automation and digital technology

  • Continuous Integration – The method of automating the integration of code changes from various contributors into a single software project is known as continuous integration (CI). It’s a key DevOps best practice that allows developers to merge code changes into a common repository, from which builds and tests can be executed. Using this approach, organizations can test more holistically and focus more on the integration testing rather than the functional testing.
  • Continuous Delivery (CI/CD) – This refers to the ability to securely and swiftly deploy updates of any kind, such as new features,  configuration changes, bug fixes, and experimentation, into production or into the hands of users. By adopting CI/CD into the deployment / release processes, quality is incorporated and hence tested at various phases of the process, thus reducing the final testing that needs to be done prior to the release of the product. This further results in a reduction of the workload for the Quality team.
  • Employ Automated Controls and Quality Management System (QMS) tools – By leveraging automated controls throughout the organization the quality function can receive feedback quickly from systems that are able to collect that data and provide it in a consolidated fashion. A QMS or Enterprise Quality Management System (EQMS) is an important component to any digital quality framework. The objective of EQMS is to manage content and business processes for quality and compliance across the value chain. This EQMS platform integrates with the IT architecture and data model and facilitates cross-functional communication and collaboration.

It is essential that the EQMS is not siloed. Quality information should be collected as data and leveraged across the organization to make informed decisions.

The EQMS has to also have an interface to other systems whether it is ERP, PLM,  supplier quality, vendor management, or other enterprise systems integral to the organization. Those interfaces are critical because that is where data resides, and access to that data is vital for decision making.

EQMS also needs to be mobile. It can’t be at one particular location or region or within one area. The EQMS has to provide the ability to look at data wherever, whenever, and however needed. Having this visibility to the pertinent data allows teams to make decisions faster as well as implement controls that prevent issues and non-conformances further in the processes.

Conclusion

As we’ve outlined, there are multiple methodologies and technologies to consider when the organization is looking to transition to CSA. By leveraging the right mix of tools and methodologies, the organization’s move to CSA will result in lower risks during the transition.

Additionally, it is equally important to have the right skill sets (internal and external) to assist with implementing these approaches and tools.  Knowing the various methods and technology and being able to apply them are effectively two distinct requirements.

Why it Matters to You

Organizations making the transition from Computer System Validation (CSV) to Computer Systems Assurance (CSA) will benefit from this information in the following ways. It will:

• Assist in identifying and implementing efficiencies and optimization of the processes supporting CSA.
• Enable organizations and teams to reduce the amount of documented testing that would need to be performed as part of the system release.
• Provide a way to greatly reduce the time for the testing phase as well as provide for efficiencies.
• Enable tests to be done more holistically and to focus on the integration testing rather than the functional testing.
• Reduce the final testing that needs to be done prior to the release of the product.

About Astrix

For over 25 years, Astrix has been a market-leader in dedicated digital transformation & dedicated staffing services for science-based businesses.  Through our proven laboratory informatics, digital quality & compliance, and scientific staffing services we deliver the highly specialized people, processes, and technology to fundamentally transform how science-based businesses operate.  Astrix was founded by scientists to solve the unique challenges which science-based businesses face in the laboratory and beyond.  We’re dedicated to helping our clients speed & improve scientific outcomes to help people everywhere.

The post Computer Systems Assurance – Methodologies and Technologies to Consider appeared first on Astrix.

• Determine how the software will be used in the organization

Is the software affecting the quality of the product or the safety of the patients? If this isn’t the case, you won’t need the same level of assurance as you would for software that affects the product or patient safety. Document management, change management, and audit management software, for example, do not require the same level of testing as device software.

• Determine if there is the potential to influence product quality, patient safety, or system integrity.

CSV validation of computer systems focuses on evaluating the severity of the impact and the likelihood of failure, which leads to risk prioritization. Conversely, with CSA, the emphasis is on calculating the risk/impact on patient safety and product quality, as well as the implementation approach of the software program functionality.

The first step is to determine the degree of impact of the specific software on patient risk and product quality. If the risk is high in one or both of these areas,  more time should be spent in the testing phase. If the impact is very low on these areas, testing can be reduced.

When looking at the software itself, there are different degrees of implementation risk depending on the software’s origin. If the software is out-of-the-box with the pertinent documentation, then it should most likely be of lower risk.  If however there is a need to configure or completely customize the software, there is then a significant increase in the risk  to the situation.

• Wherever feasible, make use of vendor documentation.

If the software vendor’s documentation is audited and validated, then there is no need to reproduce this documentation. Use the vendor’s documentation and validation if it is of high quality, based on an initial assessment of the vendor provided documentation.

• Based on risk, conduct the specific level of testing required for that system or function.

With CSA, which is a risk-based approach, the focus is on critical thinking and professionals determining which systems and functions provide the greatest risk to patient safety and product quality. The highest level of testing should be applied to these areas. To those other low to no risk areas a significantly lower level of testing should be applied.

Testing with Computer System Assurance

Now that we’ve defined the process to follow to determine which areas are high-risk to patient safety or product quality, the next question to answer is, how is testing performed in a CSA context?

In the past, test scripts were written in great detail and were not as concerned with whether or not the system and its functions had a direct impact on patient safety or product quality. With CSA, this has changed. There are now new approaches to testing i.e., Scripted Testing , Unscripted Testing, and Ad-hoc Testing.

Scripted Testing is the traditional form of testing that has been done with CSV. It requires a step-by-step test procedure, required results, and it is pass/fail. However, the difference with CSA is that Scripted Testing is only applied to higher risk systems and features that directly impact the product or patient safety.

Unscripted Testing is less detail oriented than Scripted Testing. It is used to test the lower risk systems or functions that do not directly impact the product or patient safety. They do however impact the quality system. With Unscripted Testing there needs be a test goal and a pass/fail, however, there is no step-by-step test procedure.

Ad-hoc Testing – a third testing method can be used on those systems and functions that are low business risk to the quality area. This testing is performed without planning and required documentation.

Summary

The new CSA risk-based approach to systems validation requires the professional to spend more time focused on critical thinking and less time on documentation. The objective is to focus on those areas that have the largest impact to patient safety, product quality, or the quality system overall.

With this new process, CSA involves different levels of testing. Scripted Testing is used for those systems and functions of high risk to patient safety and product quality. Unscripted Testing is used for those systems and functions with low impact to these areas, however, they do have an impact to the quality system. And finally, Ad-hoc testing is used on those systems with low risk to the business.

Why it Matters to You

This new CSA risk-based approach is important for you to learn about because:

• It will potentially lower the cost of quality by requiring less time in testing and documentation.
• It will drive the team to achieve higher, quality, and productivity.
• Helps to maximize the use of validation and project resource expertise.

 About Astrix

For over 25 years, Astrix has been a market-leader in dedicated digital transformation & dedicated staffing services for science-based businesses.  Through our proven laboratory informatics, digital quality & compliance, and scientific staffing services we deliver the highly specialized people, processes, and technology to fundamentally transform how science-based businesses operate.  Astrix was founded by scientists to solve the unique challenges which science-based businesses face in the laboratory and beyond.  We’re dedicated to helping our clients speed & improve scientific outcomes to help people everywhere

The post Computer Systems Assurance – What are the Steps and How to Test? appeared first on Astrix.