The Food and Drug Administration has issued the draft guidance for Computer Software Assurance for Production and Quality System Software. This guidance provides “recommendations on computer software assurance and automated data processing systems used as part of medical device production or the quality system.” Read the guidance document here, or connect with one of our quality assurance experts here.

For those who have worked in industry and been part of computer validation projects, this is an exciting time. I am sure many of us have experienced the mountains of paperwork generated by the lone error in a test script due to a simple typo. For supply chain professionals, the computer system validation process can become a tremendous burden, especially when the concern is about getting the right product to the right customer at the right time. However, working within a regulated industry requires the validation of the computer system we use to conduct our business within; therefore, it’s required that those of us in supply chain be a part of the validation of any computer system used within the organization.  

Below, we unpack the transition to Computer System Assurance (CSA), an approach that can lead to faster validation activities and streamlined documentation.

Considerations for Computer System Assurance 

This new focus on CSA shifts the validation process from creating lots of documents to use as evidence to auditors that the validated system is compliant, to instead focusing on how the computer system impacts the product quality and patient safety. It then uses a risk-based approach to determine the level of validation required. While it may seem there is no difference, focusing increased attention on applying the right level of testing to higher risk activities will result in less time writing, reviewing, and approving documents, thus faster validation.  

Changes will be required early in the validation process where the risk assessment is performed, and we’ll need to add questions about the intended use of the system to help classify the system as direct or indirect. Other areas in the anticipated CSA to leverage would be the supplier/vendors documentation supporting the software design, user requirements, and testing traceability. Ensuring there is a robust supplier selection, management, and audit program will also allow us to leverage the benefits of the CSA approach.   

Additionally, it’ll be important to consider the software type – “Out of the box,” “Configured,” or “Customized” – in addition to if the software impacts the product or patient safety during evaluation and documentation. When reviewing each type of software and its intended use, it’s necessary to assess if the decision should be high-risk, medium-risk, or low-risk, and as well as what level of testing is needed to support this classification. 

During this evaluation and documentation, you’ll need to consider that: 

• “Out of the box” software requires no changes to settings or parameters, and you may leverage the supplier qualification documentation. 
• “Configured” software changes to features by parameters without changing code and may only need ad-hoc testing. 
• “Customized” software, code, or programing changes made to the software will be considered higher risk and will need more testing. 

Additionally, If the software does not impact the product or patient, then they should be considered an indirect system and require less testing and documentation – again, leading to faster validation. 

The Transition to Computer System Assurance 

The goal of the new CSA process is to identify higher risk areas to execute better, more relevant testing while considering the value-add of any documentation. Lower risk equals less formalized testing, but documenting the testing is still a requirement. This is a great time to look at the current documents in the QMS to see how they can be re-imagined (combined, remove complex steps, identify duplication) all to eliminate confusion.   

With CSA, there’s an opportunity to reduce much of the paperwork previously required. While there’s really no way around the core documentation that must be created, reviewed, and approved, there is a way to reduce the mountain of documentation while still demonstrating a strong validation process that auditors will accept.  

Clarkston is working with clients to assess their current validation processes, identify ways to simplify them, and start the transition to computer system assurance. Developing a plan to leverage all that CSA is expected to offer will be important for all organizations for better use of available resources, faster validation activities, and streamlined documentation. 

Contributions from Linda Plumley