Why You Should Prefer Modern Tools to Traditional Methods for Creating CSV Documents

“In the Medical Device and Pharmaceutical industries, the shift from traditional, paper-based Computerized System Validation (CSV) documentation to modern digital tools represents a pivotal change. This transition is driven by the need to meet stringent regulatory requirements efficiently while enhancing the reliability and integrity of critical systems. This article explores the benefits and challenges of adopting modern documentation tools for CSV, highlighting their role in streamlining processes, reducing errors, and improving traceability. Against the backdrop of regulatory landscapes, such as EU GMP Guidelines and FDA regulations, we examine how these tools transform CSV practices, making them more efficient and compliant.”

– ChatGPT 4

While the above text has been created by ChatGPT 4 to demonstrate the capabilities of modern technologies, the following article has been written by us without using generative AI. However, we fully agree with what ChatGPT had to say about the content of this article.

So, let’s get started.

Regulatory Requirements on Documentation

To understand why tools bring huge benefits compared to traditional, paper-based documentation, we need to take a look at the regulatory landscape first. Why do we need to document activities, what do we need to document, and where is it written?

Note: In CSV we typically use the term “system” for the software as the main actor, extended by its Operating System and corresponding hardware. To make the following text easier to read and more accessible, we decided to just use the term “software” instead.

The validation of computerized systems (CSV) is an integral part of the quality management system of medical device manufacturers and pharmaceutical companies. The requirements for the validation of software used in a regulated environment can be found in various laws, guidelines, standards and more. To name just a few: EU GMP Guideline Annex 11, EU MDR / IVDR, FDA 21 CFR Part 11, FDA 21 CFR Part 820.70, ISO 13485 and more. All these regulatory expectations and practical experience have been translated into very useful guidelines, such as the GAMP guidelines, the FDA General Principles of Software Validation, PDA Risk-Based Software Validation and more.

To make a long story short: There are some central elements of CSV that must be covered in any case:

1. Create a plan for your validation activities and follow it. Clearly define the scope, roles, and responsibilities of the project and the intended use of the software.
2. Document the user requirements and the legal requirements for the software and the business processes that are to be covered by the software — usually in the form of a system description and a specification sheet.
3. Document how the user requirements are technically implemented — typically in the form of functional, architectural and design specifications or a functional specification.
4. Evaluate the risk associated with the use of your software and define risk mitigation measures — often in the form of initial and functional risk assessments.
5. Test the software if it has been built in the correct way and that it meets its intended use — typically translated into System Acceptance Tests (verification of technical implementation) and User Acceptance Tests (validation against intended use), following a Test Plan and Test Scripts.
6. Report your activities — typically translated into a Test Report and a Validation Report.
7. Establish a system to control the life cycle of your software to maintain its validated state — typically translated into procedures (SOPs), such as Change Control, Issue Management, Maintenance, Instruction for Use, etc.

And while going through all these exercises, you must achieve the following:

1. Maintain integrity of your documentation. Keep your documentation up to date over the entire lifetime of your software.
2. Create and maintain traceability across all aspects of your software (e.g. user requirement — functional specification—risk—test). You must be able to determine at any time what your software can do, where this is documented, and how the respective function was evaluated and checked.
3. Maintain a high quality of your documentation, even several years after the implementation of the software (see ALCOA++ Principles for Documentation and Integrity).

All of the above points taken together are extensive and sound frightening, don’t they? And up to a point, we agree with you. CSV is a demanding and challenging task, but it creates confidence in your system. And don’t forget: you create documented proof of the reliability and reproducibility of your software. Modern tools can make your life much easier in this process. And this is exactly where we come in.

Paper-based Documentation – Welcome to the Stone Age of CSV

As you may have deduced from the section above, for many years the traditional way of producing documentation was to create piles of paper. Tools such as MS Word are used to write plans, requirements and specification documents, MS Excel is used to create comprehensive risk assessments and so on. All documents are printed out, signed and archived in folders. Traceability tables (traceability matrix) are created manually in MS Excel to link all relevant elements (requirements, specifications, risks, tests, change requests, etc.). An index is created to keep track of all documents. Change control requires a comprehensive impact assessment for software and documentation. There are certainly good reasons why this approach is still found in many organizations, but those who still work this way often find it very cumbersome and wish for a change in their current situation. Let’s take a brief look at the pros and cons of paper-based documentation.

Advantages:

• The paper document is the only source of truth and is in itself independent of a software solution, which in itself would require validation.
• Paper documents are durable by nature and can be archived for many years in a controlled room climate.

Disadvantages:

• Updating documents is a time-consuming process (document management).
• Document maintenance is error-prone and cumbersome.
• Traceability is created in a manual process using an overview sheet and requires a manual search in the documentation.
• The original documents are stored in the archive and require access to a limited area and time to retrieve the desired document from the archive.

Hybrid documentation – welcome to the Bronze Age of CSV

Software companies identified the need to make documents available in a digital format in the 80s, which ended up in the invention of the first electronic document management systems (eDMS). Today, these tools are used by the majority of Medical Device and Pharmaceutical companies. They address two significant disadvantages of paper-based documentation: availability and document handling. The necessity for such tools went through the roof during the COVID-19 pandemic, as people switched from the office to working from home. By design, other disadvantages from paper-based documentation are still found in eDMS solutions. As they store documents like the paper-based process, but in a digital format.

Advantages:

• Near-time to real-time access to documentation, often remote from any location (requirements specifications, validation deliverables, test scripts, etc.).
• Documents can be managed in a convenient way, using metadata, workflows, electronic signatures, document statuses and more.
• Less to no paper documentation.
• Redundant backup and restore management capabilities.
• Document control through access management, user roles, etc.

Disadvantages:

• Validation deliverables remain standalone documents, as in paper-based documentation.
• Traceability is still created through manual processes. Information is hidden within the documents and needs to be searched for.

Tools for Records Management – Welcome to the 21st Century of CSV

In the last five to ten years, tools became increasingly popular that enabled users to create a more granular documentation in CSV and IT projects. Even if electronic documents are also considered electronic records, these modern tools go one step further and break up the structures of these self-contained documents.

While many aspects apply for both, electronic document management and electronic records management, the key idea of records management is to create relations between all individual records stored within the tool, combined with a robust record lifecycle management. They break information down to its atomic structure. Often, in CSV, we see this type of software integrated into an Application Lifecycle Management System (ALM).

Instead of creating documents for each validation deliverable, you create one independent, standalone record per “item”. An item can be a user requirement, a functional specification, a risk, a test case, a change request, etc. Through metadata, you define the relation between these items and create traceability over all records at any time. You can think of it as if you were drawing a red thread from each individual record to the next record. In ALM’s you can link the records to specific release versions of your software, in some cases even to the software code in your code repository. Reporting features allow you to assess the state of your validation at any given point in time. During inspections from competent authorities or audits by customers or Notified Bodies, this makes your life much easier.

Advantages:

• Complete traceability of all entries up to the corresponding software release version.
• Full control over records, leveraging user role models, workflows, statuses, etc.
  Flexibility to update specific, individual items instead of updating whole documents. This will massively simplify and accelerate the lifecycle management of your validated software.
• Improved visibility, traceability, reliability and flexibility for all activities and items.

Disadvantages:

• Requires extensive preparation to make it work (e.g. naming conventions, content structure, metadata, supporting processes such as change management, retention policies, etc.).
• Tools dedicated for CSV and ALM. This makes these tools specific and narrowed down to their business use cases compared to common eDMS solutions, which can store all types of documents / records like a paper archive. But this specificity is in the end a benefit for your validation process.

AI for Records Creation and Management – Welcome to the Future of CSV

So, what’s next? You have probably already guessed this correctly. Everybody talks about AI. Definitely, AI will play a crucial role in CSV in the near future. Today, a few AI applications are in use for processes that are related to CSV. But all future use cases and applications are just theory or extrapolations from current developments on the market.

For example, many eDMS solutions contain functions to automatically recognize the text from scanned documents. This function is called OCR (optical character recognition). However, OCR has been around for some time now, and everybody takes that for granted nowadays.

In addition, the first providers are beginning to use AI to group and filter content or records, perform keyword analyses and more. But all of this is still happening very slowly and cannot be compared with the speed at which companies around the world are releasing new AI models. Adaptation of new AI models takes time, so that there will be a significant delay between what we see and what we get (yet).

Nevertheless, we assume that AI will play an increasingly important role in CSV in the coming years, especially as part of ALM / record management solutions. Due to the data structure in those systems, the use of AI in record management solutions is the logical next step in their evolution.

Below we would like to share a few ideas that could, in our opinion, be potential applications for CSV:

LLM for Requirements Engineering and Risk Management

Requirements Engineering and assessing the risks of the identified requirements is the foundation of all validation activities. Thus, the better the requirements are defined and the better the risks are assessed and addressed, the more reliable the outcome of the entire CSV project will be. LLM (Large Language Models) are a remarkable tool to standardize requirements documentation. While business analysts discuss business and user needs, they can use LLMs to translate all notes and comments into standardized formats for User Requirements. Furthermore, LLMs might be able to even suggest the risks for such requirements when the context of the intended use is provided.

LLM for Writing Test Scripts

There are already AI-assisted solutions on the market that can write unit tests for your source code. But there is no such tool yet on the market, which reliably creates these for higher test stages, such as System Acceptance Test or User Acceptance Test. Soon, LLMs might be able to translate requirements, specifications, and risks into test scripts for manual test execution. Integrated into an ALM solution, they might even create your full set of test scripts automatically based on your input.

Automated Impact Assessment

One of the greatest challenges of CSV is the maintenance of the validated state over the lifetime of the software. That’s because every update, issue, bug, hotfix etc. will require an update of documentation. The older the system gets, the more errors will arise in its documentation. After a few years, the validation documentation will not fully reflect the real state of the software. That is where AI might bring huge benefits. There is a good chance that in a few years, AI will be able to identify and evaluate the impact on all CSV and development records of a software solution just from the description of a change request.
Definitely, there are countless other use cases for AI in CSV. Let’s be excited and curious about what the future holds.

To say it in the words of Steve Jobs: “Stay hungry, stay foolish”. With better tools, we overcome constraints, heavy workflows, delays, and documentation burden and make our lives easier while further improving the quality of our work. We should be open to future developments and integrate them effectively into our way of working.

Written by Marc Assmann

Learn more about our CSV services