As the regulated sector becomes more and more computerised it is paramount that you understand how to deploy computerized systems in a compliant manner adhering to FDA regulations and best practices.

It takes careful planning between the client (the regulated company) and the vendor (the software company) to ensure a smooth transition from planning to go-live.

The following series of articles will focus on this journey and help to explain in detail the process to follow when deploying software systems to the life sciences.

The deployment process will be broken down into five main phases:

• Phase 1: Planning and Design
• Phase 2: Configuration
• Phase 3: Deployment
• Phase 4: Validation
• Phase 5: Go-Live

Planning Tool

Before we get into the detail about the design phase it’s important to choose a planning tool that will make your life easier to track and plan all activities.

The planning tool of choice for many project managers in the life sciences still seems to be Microsoft Project for its ease of use and familiarly.

This is a personal choice and what you feel comfortable with but there are also an abundance of cloud based services out there that are superb at helping you manage complex projects.

Two of the most popular been Basecamp and Lighthouse. For global projects with global teams I would recommend test driving a cloud based service, even for automating the review and approval cycles on documents alone it’s worth it!

Phase 1: The Design Phase

Table 1 below lists some of the documents/tasks that form the design phase of the deployment. The tasks in this table do not represent an exhaustive list and may change depending on the project.

Vendor Audit

Conducting a vendor audit is essential to ensuring that your supplier has a robust Quality Management System (QMS) in place and takes quality seriously.

If the vendor is ISO: 9001 certified this should give you further reassurance that they are doing things the correct way, but it is still advisable to audit them to further ensure that they are maintaining their standards on an on-going basis.

Like all businesses there are good vendors and bad vendors, it’s up to you to find the difference between them as once you get locked into an agreement with a vendor it’s very difficult to break it as the application may already be implemented.

Do your research; ask other people in the industry about vendors they have used and their experience to date with them. Don’t just look at what the vendors give you – ask for documentation that is not on display.

For a comprehensive analysis of vendor audits click here to view a related article

The Project Plan

The project plan is the cornerstone of the entire project, this document whether you use MS Project or a cloud based application should tell you the following:

• Task Name
• Duration (Usually days)
• Start Date
• End Date
• Responsible Person

This plan is a living document and will probably change throughout the project so it’s a good idea to review on a daily basis to ensure milestones are on-track.

Installation & Security Plan

The installation and security plan is generated by the vendor with buy in from the client’s IT department to ensure adherence to global IT policies and standards.

This plan should give a detailed account of how the Installation Qualification will occur later in the deployment phase and cover the security aspects required by the client.

This plan will vary depending on whether the application is taken in-house or if the client decides to purchase a cloud based application that resides on a regulated cloud.

Cloud based applications are a relatively new phenomenon in the regulated space but they will become increasingly more common in the coming years.

Validation Plan

The Software Validation plan is a document that expresses the philosophy of the vendor and how they intend to establish a working model for the project at hand.

This plan can be created by the vendor with input from the client team to ensure they agree with the approach been taken.

Unlike the project plan, this plan specifically focuses on the activities required to validate the system.

The software validation plan may contain some of the following sections:

• Introduction
• Organizational Structure
• GxP Criticality Assessment
• Validation Strategy
• Validation Deliverables
• Acceptance Criteria
• Go-Live
• Change Control
• Standard Operating Procedures
• Training
• Document Management
• Maintaining the Validated State
• Validation Activities Timeline

If you would like to learn more about Software Validation Plan’s click here.

Disaster Recovery Plan

The disaster recovery plan can be included in the overall validation plan but it’s such a critical aspect of deployment that it may be deemed necessary to create an individual plan to emphasis its importance.

According to the FDA’s guidance document on computerized systems, this plan should focus on two key areas:

• (A) The Contingency Plans: Written procedures should describe contingency plans for continuing the study by alternate means in the event of failure of the computerized system.
• (B) Backup and Recovery of Electronic Systems: Backup and recovery procedures should be clearly outlined in the SOPs and be sufficient to protect against data loss. Records should be backed up regularly in a way that would prevent a catastrophic loss and ensure the quality and integrity of the data.

It also needs to be emphasized that it is not just sufficient to have the plan in place, the plan must be executed as part of the validation phase to ensure it works!

User Requirement Specifications (URS)

The user requirement specification (URS) is a document generated by the client and given to the vendor so the vendor can respond with a corresponding functional design specification (FDS) document to show the client how their system meets the clients specific requirements.

This document should be clearly written by the client with unambiguous requirements; it’s basically a wish list of what the client wants from the system.

Usually this document is submitted to multiple vendors before the final decision on vendor selection is made. It allows the client to compare vendors and clearly see which vendor suits their requirements best.

For more information on how to write an effective URS click here.

Functional Design Specifications

The Functional Design Specification describes what the system does and how it does it.

This document is generated as a direct response to the URS to demonstrate how exactly the system works based on the clients requirements. All requirements outlined in the User Requirement Specification should be addressed in the Functional Design Specification.

The Functional Design Specification should be signed by the System Owner and Quality Assurance. If key end-users, developers, or engineers were involved with developing the requirements, it may be appropriate to have them sign and approve the document as well.

Functional Requirements should include:

• Descriptions of data to be entered into the system
• Descriptions of operations performed by each screen
• Descriptions of work-flows performed by the system
• Descriptions of system reports or other outputs
• Who can enter the data into the system
• How the system meets applicable regulatory requirements

The Functional Design Specification is designed to be read by a general audience. Readers should understand the system, but no particular technical knowledge should be required to understand the document.

Risk Assessment (RA)

Performing a risk assessment is an important step in being prepared for potential problems that can occur within any software project. During the risk assessment, if a potential risk is identified, a solution or plan of action should be developed. (A problem analyzed and planned early is a known quantity. Likewise, unanticipated problems can affect a project with no resolution plan.)

Risk assessments can take a lot of forms; the important thing is that you document your assessment and findings so you can justify the decisions you have based on that assessment.

One of the most common risk assessment tools used in industry is FMEA (Failure Mode Effect Analysis).

For more information on risk assessments read this post.

Requirement Traceability Matrix (RTM)

The Requirements Traceability Matrix (RTM) is a document that links requirements throughout the validation process. The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are tested in the test protocols.

The traceability matrix is a tool both for the validation team, to ensure that requirements are not lost during the validation project, and for auditors, to review the validation documentation.

The requirements traceability matrix is usually developed in concurrence with the initial list of requirements (either the User Requirements Specification or Functional Design Specification).

As the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which they are tested.

Summary

As you can see deploying software applications in a regulated environment takes careful planning and design. Good project management skills and knowledge of the complexities of regulated software are essential to a successful deployment.

Once the planning and design phase is complete, the configuration phase can commence where the vendor and client work closely together to configure the system to suit the business needs of the client. We will be covering Phase 2: Configuration in the next article in this series.

If you have any opinions on this article please feel free to comment below.