GAMP5 Validation for Dynamics 365

Prepared by:
Michael Webster, Business Development Director, RSM US LLP
[email protected], +1 617 241 1544

Dynamics 365 is an ideal enterprise resource planning (ERP) platform for pharmaceutical and
medical device manufacturers due to its ability to start small and scale up. A single database and
application for all countries, companies, products, customers, vendors and various business models
avoids the complexity seen with other older products that “integrate” but still require multiple
databases and significant master data management. To that end, RSM has extended Dynamics 365
to support companies in computer system validation and change management.

Microsoft has invested billions into its flagship ERP system and continues to invest over $10 billion
in research and development every year. One outcome of this continued evolution is the ability to
reduce an installation from weeks to minutes. RSM has also invested in a rapid deployment model
that transitions a previously painful, time consuming and expensive solution design to a short, one-
week onsite process to deliver a verified ERP system—configured, loaded with your master data,
tested and ready for verification, user acceptance testing (UAT), and final data conversion and go live
in four weeks. Our proven approach reduces your effort and costs while delivering best practices and
reliability.

RSM developed last-mile solutions to support life sciences customers in the validation process for
Code of Federal Regulations (CFR) 21, Part 11, electronic signatures; CFR 210; CFR 211, current good
manufacturing practice; and CFR 820, quality. Following the FDA’s recommendation for a risk-based
approach, we balance the adherence to regulation with a change management approach that
allows for more flexibility in meeting changing business requirements. Far too many quality and IT
organizations lock the configuration in fear of out-of-compliance problems or significant work to
manage the change, resulting in a degradation of value in the ERP system. In doing so, the system life
cycle is shortened, and companies go through a cycle of system replacement at significant cost.

In this document we seek to answer the who, when, why, what and how-to-validate questions, as
well as discuss our validation deliverables:

Validation according to the FDA guidance is defined as “establishing documented evidence which
provides a high degree of assurance that a specific process will consistently produce a product
meeting its pre-determined specifications and quality attributes.”

•• Computer system validation (CSV) is documented evidence, to a high degree of assurance,

that a computer system performs its intended functions accurately and reliably
-- Computer systems used in a regulated environment must perform their intended functions
consistently
•• The FDA’s final rulemaking on CFR 21, Part 11, demands the “use of secure, computer-
generated, time-stamped audit trails to independently record the date and time of operator
entries and actions that create, modify or delete electronic records.”

There must be documented evidence of the planning, development and challenging of the system.
This documented proof becomes the validation. Without the required documentation, the system
cannot be considered a validated system. You must prove a high degree of assurance, but an
absolute degree of assurance is not expected. However, you must be confident that you have
defensible proof that the system consistently performs as it is intended and has balance between
thoroughness and practicality.

You must understand and document what you need and intend the system to perform. These
intended functions of the system, more commonly known as the requirements, form the basis of
validation. The requirements definition documents system functions that the user performs, not
necessarily all the functions the system is capable of performing. The functionality available in the
system that will not be used must be documented as an exclusion to the validation and specified in
user training and standard operation procedures (SOP).

The system should provide accurate data that can be relied upon and the focus of the validation is on
the intended functions that could affect data integrity.

Why validate?
First and foremost, validation is required by the FDA. Validation helps assure product quality by
locating errors before the system is used in research and development (R&D), manufacturing, quality
control or distribution. Validation leads to better system use, data integrity and increased confidence.
Finally, CSV is good business.

Who should validate?

Manufacturers who must meet and maintain FDA compliance include producers of:

•• Medicinal products and botanicals

•• Pharmaceuticals
•• Diagnostic substances
•• Biological products
•• Surgical and medical instruments
•• Orthopedic, prosthetics and surgical appliances
•• Dental equipment and supplies
•• Ophthalmic supplies

2
The FDA requires that “any computer system must be validated if it is used to control processes,
control equipment, collect and/or calculate data, and/or generate reports in R&D, manufacturing,
quality control, warehousing and/or distribution environments.” Further, any system producing data
to be used for a regulatory submission or for marketed drug products must be validated.

Predicate rules are the requirements that can be found in the CFR 21, Food and Drugs regulations,
promulgated under the authority of the Food Drug and Cosmetic Act or under the authority of the
Public Health Service Act:

•• CFR 21, 210: cGMP in manufacturing, processing, packing or holding of drugs

•• CFR 21, 211: cGMP for finished pharmaceuticals
•• CFR 21, 803: Medical device reporting
•• CFR 21, 806: Medical devices reports of corrections and removals
•• CFR 21, 820: Quality system regulation
•• CFR 21, 11: Electronic records/electronic signatures
What should be validated?
Good manufacturing practices (GMP) are defined as “that part of quality assurance which ensures
that products are consistently produced and controlled to the quality standards appropriate to their
intended use and as required by the marketing authorization.”

GMP covers all aspects of the manufacturing process: defined manufacturing process; validated
critical manufacturing steps; suitable premises, storage, transport; qualified and trained production
and quality control personnel; adequate laboratory facilities; approved written procedures and
instructions; records to show all steps of defined procedures have been taken; full traceability of a
product through batch records and distribution records; and systems for recall and investigation of
complaints.

The guiding principle of GMP is that a product’s quality is built-in to a product, and not just tested into
a product. Therefore, the assurance is that the product not only meets the final specifications, but
that it has been made by the same procedures, under the same conditions each and every time it is
made. For regulated industries such as those in the life sciences sector, computer systems need to
be validated to prove regulatory compliance.

How to validate?
A practical approach to validation includes the following key elements:

•• Validation must be performed in compliance with current cGMP

•• Good automated manufacturing practice guide, version 5 (GAMP5), provides the guidance
•• A validation SOP should be in place to provide the framework within which the validation will
be done; typically, this SOP calls for a plan or approach to be established
•• Map applicable predicate rules (210, 211, 610, 820, Q7a, Q6b and the European Directives) to
the ERP system functions

Among FDA-regulated enterprises, successful ERP software validation hinges on deploying a proven,
structured approach.

The entire validation process is shown in Figure 1. The starting point for all validations are the
validation master plan, risk management plan and assessment and supplier audit.

3
 System usage
User Go live! SOPs
training
System
maintenance
VALIDATION APPROACH Training
records Custom monitoring
program

Corrective and
Validation Risk management Final Updated risk
Supplier Validation preventive action
master plan and validation management
audit review
plan assessment report plan

Protocol text PQ Updated

User PQ protocols records test risk
requirements PQ testing report management
specification User acceptance Sample usage
criteria SOPs

Protocol text
Functional OQ protocols records
requirements OQ testing
specification Trace
IQ/OQ Updated
matrix test risk
report management
Protocol text
Design
requirements
IQ protocols IQ testing
records
specification HW/SW
requirements

Customer Configuration Updated

Off the shelf drawing risk
Installation and management
software
configuration

Configuration
SysAdmin homework
training
Training
records Figure 1: GAMP5 validation approach followed by RSM

Risk assessment
The risk assessment is often the place we start even before the establishment of the master plan. In
the risk assessment, we undertake the process of identifying potential hazards an organization may
face and analyzing methods of response if exposure occurs. The assessment is the most important
tool to determine the required amount of validation. A Class I medical device manufacturer may
require a different level of validation than a Class III device. In addition, a company that outsources
manufacturing may require a different level of validation than one that doesn’t.

While an outsourcing company will rely on the API supplier, CMO and 3PL for maintaining their
respective traceability and the batch records, recording of the full traceability record across the entire
supply chain exists in its ERP as well as recording the transaction for batch release. If the ERP is the
sole system of record for traceability, that system should, at a minimum, have a risk assessment.
While you may, and many do, choose not to perform a full validation, the risk assessment is the
artifact that shows you analyzed risks and documented mitigation strategies.

Risk-based validation approach: “We recommend that you base your approach on a justified and
documented risk assessment, and a determination of the potential of the system to affect product
quality and safety and record integrity.”

•• Guidance for Industry (Part11, Electronic records; Electronic Signatures – Scope and
Application), August 2003

Master plan
The master plan describes all the required validation activities at the site together with assigned
responsibilities, priorities and timings for actions. The plan should be a dynamic document which, at
any point in time, will represent:

•• Which systems exist

•• Which systems require validation
•• Who is responsible for each validation project
•• Status of the individual validation projects
•• Date for completion of each validation project
4
Supplier audit
The supplier audit is usually undertaken for configurable software packages or custom-built
or bespoke software. The audit should be performed either prior to the formal commitment
to purchase or during the development process (for custom-built or bespoke software). The
purpose of the audit is to assess the supplier or development group’s quality management system,
specifically the development methodology and quality plan, to ensure that quality assurance is built-
in during the software development process.

The audit should verify that the development methodology conforms to the system development
standards specified as part of the validation process. The audit reviews SOP, SOP adherence, system
and software development procedures, quality assurance and quality control issues, and software
maintenance procedures.

User requirements
The user requirements define, clearly and precisely, what the regulated company requires the
system to perform and should be driven by the business process needs. The user requirements
specifications (URS) are written in general terms and specify what needs to be done, not how it will
be done. The requirements may be developed independently of a specific solution prior to selection.
This document should be developed by your organization.

Content typically includes, but is not limited to, the following as appropriate:

•• Availability requirements •• Operational requirements

•• Security requirements •• Functional requirements
•• Maintenance requirements •• Data requirements
•• Regulatory requirements •• Technical requirements
•• Migration of any electronic data •• Interface requirements
•• Constraints to be observed •• Environment requirements
•• Life cycle requirements •• Performance requirements
User requirements that are independent of the specific application program are required to contain
a brief description of the system, scope of the validation project including exclusions, where the
system will be installed and used, the intended functions for use of the system, and test protocol
titles for challenging the intended functions. The URS is the foundation upon which the rest of the
validation is built.

Functional requirements specification

The functional requirements specification (FRS) definition describes what the system should do
and what functions and facilities are to be provided. The FRS provides a list of design objectives
for the system and formal testing will often be based on the FRS. The FRS is typically produced by
the supplier, and should be reviewed and approved by the regulated company. Often considered
to be a contractual document, it describes, in a high-level manner, the hardware, software and
peripherals that make up the computer system as a whole. (Note: In system development terms,
this specification will form the basis of system testing.)

The FRS describes how the specific system to be purchased or developed will meet the user and
functional requirements and the specific user requirements that will not be met by the system.
The FRS should include reference to the data model to be used, define the functionality that does
not relate directly to the user interface (e.g., system interfaces), and define the nonfunctional
requirements such as performance and availability.

5
Standard operating procedures
SOPs are a critical component of the validation. They describe the specific procedures to operate
and maintain the system. Procedures include:

•• User guide •• Preventive maintenance

•• System training •• Security
•• Calibration instructions (if applicable) •• Backup and recovery activities
•• Error notification •• Power failure and recovery
•• Change control •• Disaster recovery
•• Periodic review •• System maintenance
Minimum SOP requirements include:

•• cGMP systems validation SOP •• Vendor assessment SOP

•• Backup and restore SOP •• Logical security for IT systems SOP
•• Disaster recovery SOP •• Account maintenance SOP
•• Hardware and software change •• Software development life cycle SOP
management SOP •• Installation qualification (IQ), operational
•• Incident management SOP qualification (OQ) and performance qualification
•• Physical security for IT systems SOP (PQ) for software and hardware
•• Help desk and service level SOP •• Records management and document control SOP
•• Compliance SOP •• Training SOP
•• Validation change control SOP

Qualification scripts describe the step-by-step procedure for qualifying the system. The procedure
may be broken down into multiple discrete scripts for ease of use and should verify that the system
performs as intended against the system specification created during the development process,
include information about test conditions such as security, screen flow, data validation and data
updates, and should be a direct reference between the test script and the specification against which
the testing is being performed. The same test scripts may also be used in any periodic review.

Qualification scripts or qualification test plans should be created for:

•• IQ for hardware and software

•• DQ, if applicable
•• OQ
•• PQ
Installation qualification
The IQ is the process of demonstrating that the system hardware and software is installed according
to the manufacturer’s specifications and that all deliverables are properly accounted for. The IQ is
achieved by writing a protocol and documenting the installation to ensure it meets the acceptance
criteria defined in the protocol.

Design qualification
The DQ is a test to ensure that each component of a computer system performs as intended within
representative or anticipated operating ranges, and is equivalent to the testing performed by the
supplier during the development process (i.e., module and integration testing) and to your system
acceptance test at the completion of the system development process. The DQ is only required for
custom-built software and not part of the standard computer-off-the-shelf (COTS) software as
documented by the vendor.

6
The DQ ensures that the total system performs as intended in the specified operating range. For
example, common DQ information includes:

•• Total system includes all hardware and software components, associated equipment, people
and procedures that make up the system
•• Execution process is conducted using company-specific pre-defined datasets or actual live
data

Production qualification
The PQ should always be performed at the user site (and may involve repetition of all or part of the
system acceptance tests as required) and will include testing specific to the user environment and
defined operations.

Validation report
The validation report is produced by the validation team, and describes:

•• What was done

•• Results obtained
•• Any special considerations regarding the use of the system that were identified during the
validation process
•• Whether the procedure as described in the validation protocol was followed, and if not
followed then what was the deviation and why
•• Whether or not the acceptance criteria were met
•• Documentation that was generated
•• Location of the documentation generated
•• Retention period for the documentation

The validation report is followed by a system release document, certifying that the system is
approved for use.

Validation deliverables should include and be available for inspection:

•• Validation master plan

•• Risk assessment report
•• Vendor assessment (audit) report
•• Training plan
•• URS
•• System requirements specification
•• Project glossary
•• Technical architecture specification
•• Detailed design specification (functional design specification)
•• Code review forms (only if customized)
•• Unit, integration, system and user acceptance test (IQs, OQs and PQs)
-- Plan(s), script(s), report(s), and test incident report(s)
•• Validation summary report
•• Data migration plan
•• System release memo
•• Change request form
•• Periodic review report
•• Business continuity plan
•• Standard operating procedures
•• Training records
7
Traceability
The ability to meet requirements is critical to a successful validation. Traceability and CFR 21, Part 11 are
key components and ensure you know which supplier product lots were used in which finished goods,
and who received those finished goods to track problem products from the customer all the way back
to the supplier that sent the raw materials and the stages between. Successful traceability includes:

•• Tracking supplier lots at receiving: Track which supplier’s materials were received to help ensure
that in the event of a recall, raw materials can be traced back to a supplier in case it was at fault, and
to make sure that you know where else you used that raw material.
•• Tracking raw materials through production: Track which raw materials went into which finished
goods, ensuring that a finished good represents the relevant collection of raw material lots. This
ensures you can connect the dots between finished good lots and supplier lots.
•• Tracking finished good lots to customers: Make sure that finished good lots are tracked by which
customer they were shipped to. This is important in the event of a recall, so the customer can be
contacted and told to pull and return product that was affected.
•• Electronic signatures: These must be able to record who conducted the transaction, at what time,
for what reason (with reason codes), and must not overwrite existing data, be secure and un-
editable, and that re-authenticate the user before executing the transaction.
•• Actual recall situations: In the event of an actual recall, you need access to this information fast; the
government inspection authority will be pressuring for a successful recall as quickly as possible.

Change control
Change control should be utilized for any changes to computer systems that are used to make cGMP
products and any changes to computer systems used to make decisions about product.

Basics of a cGMP change control process include:

•• The scope of proposed changes is documented and the rationale for the changes is justified
•• All affected items are identified in the change control requests
•• All testing requirements are documented on the change requests before approval
•• Changes are assessed for impact to regulatory issues, lot dispositions, validation issues,
product quality and stability
•• Changes are approved, at a minimum by quality assurance and the document and system
owner before changes are implemented; technical and scientific experts review and approve
changes as needed
•• Production equipment is restricted from use until the test results have been reviewed by
quality assurance and the results determined acceptable
•• All testing requirements are satisfied and all affected items resolved before change requests
are allowed to close

Surviving an FDA audit

One of our ERP system leaders, who has direct experience with many FDA audits after working for a
global pharmaceutical plant manager, offers the following keys to surviving an FDA audit:

•• Review the firm’s predicate record-keeping requirements and procedures for providing
electronic and paper copies
•• Review the overall security of the electronic record keeping
•• Review the validation documentation
•• Review the firm’s self-audit, corrective action plan and progress
•• Training of IT and technical personnel
•• Maintain and train employees on what to do and who to contact upon a surprise inspection by
the FDA
•• Build a handbook for employees so they know how to respond to the inspector’s questions

8
 In summary:
•• Document your SOPs
•• Develop training records
•• Maintain accurate records
•• Clearly define roles and responsibilities and signature matrices
•• Document system security
•• Have a change control system in place
•• Conduct supplier audit(s)
•• Be able to demonstrate CFR 21, Part 11 compliance
•• Be able to demonstrate lot traceability
•• Keep your validation up to date
The FDA holds owners and users of the validated system responsible for meeting the
regulatory compliance.

+1 800 274 3978

rsmus.com

This document contains general information, may be based on authorities that are subject to change,
and is not a substitute for professional advice or services. This document does not constitute audit,
tax, consulting, business, financial, investment, legal or other professional advice, and you should
consult a qualified professional advisor before taking any action based on the information herein. RSM
US LLP, its affiliates and related entities are not responsible for any loss resulting from or relating to
reliance on this document by any person. Internal Revenue Service rules require us to inform you that
this communication may be deemed a solicitation to provide tax services. This communication is being
sent to individuals who have subscribed to receive it or who we believe would have an interest in the
topics discussed.

RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global
network of independent audit, tax and consulting firms. The member firms of RSM International
collaborate to provide services to global clients, but are separate and distinct legal entities that cannot
obligate each other. Each member firm is responsible only for its own acts and omissions, and not
those of any other party. Visit rsmus.com/aboutus for more information regarding RSM US LLP and
RSM International.

RSM® and the RSM logo are registered trademarks of RSM International Association. The power of
being understood® is a registered trademark of RSM US LLP.

© 2018 RSM US LLP. All Rights Reserved. wp-nt-tmc-all-0118