How to handle Discrepancies during Computer System validation?

Data Integrity app for Pharma Compliance

In Earlier post we understood What is Qualification protocol (IQ/OQ/PQ/IFQP), Its Necessity & When requalification performed in CSV? Computer system validation?

Now in this article we are going to understand How to handle Discrepancies during Computer System validation?

What is Discrepancy?

Datum or result outside of the expected range; an unfulfilled requirement; may be called nonconformity, defect, deviation, out-of specification, out-of-limit, out-of-trend

Discrepancy Form:

It is form on which any discrepancy observed during computer system validation process has been recorded.

Quality Assurance Team shall issue the Discrepancy form & assign unique number to each Discrepancy & maintained log for the same.

Discrepancy Form must include:

  1. Discrepancy Details,
  2. Type of Discrepancy,
  3. Severity of Discrepancy,
  4. Discrepancy occurred & Recording Date,
  5. Discrepancy Identified By,
  6. Target Complete Date,
  7. Root Cause why discrepancy occurred,
  8. Rectifications / Corrective Actions taken for all type and severity of Discrepancy etc.

Discrepancy Log:

In Discrepancy Log maintained Log of all discrepancy observed during computer system validation process.

It include Discrepancy Number, Recorded by, Date of Discrepancy & Resolution status of Discrepancy

Finally same Discrepancy Log should be reviewed by Quality assurance team.

How to handle Discrepancy?

All discrepancies that occur during qualification Testing should be documented on Discrepancy Form.

The all details of all discrepancy forms should be recorded on Discrepancy Log which should summarize all the discrepancies that occur during the execution of the qualification Tests

All discrepancies status should be recorded in Qualification Report. Based on impact of discrepancy, risk assessment may be required to perform for that particular requirement and propose mitigation (procedural or technical) to close.

Categorization of Discrepancies:

  1. Discrepancy Type
  2. Discrepancy Severity Level
  1. Discrepancy Type. All discrepancies that occur during Qualification Testing will be assigned a discrepancy type as follows:
    • System; The discrepancy is due to a failure of the application software.
    • Environmental/Setup: The discrepancy is due to environmental and/or configuration parameters being set up improperly.
    • Script: The discrepancy is due to the test script being incorrect.
    • Tester: The discrepancy is due to an error on the Tester’s part when executing the test script.
    • Other: The discrepancy is due to causes not covered by the above mentioned Discrepancy types.
  1. Discrepancy Severity Level: All discrepancies that occur during qualification Testing will be assigned a severity level as follows:
    • Critical
    • Major
    • Minor
  • Critical: A discrepancy determined to have a potential impact to product quality, purity, strength, and integrity, an event representing a significant breach of GxP or a failure of a GxP system 
  • Major: A discrepancy determined to have no impact to product quality, purity, strength, and integrity. Impact to product and / or process can be determined through preliminary analysis of data available at the time of discrepancy. No evidence of a failure in GxP systems. 
  • Minor: Not a GxP failure, no product impact

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is Qualification Protocol (IQ/OQ/PQ/IFQP), Its Necessity & When re-qualification performed in CSV?

Data Integrity app for pharma Compliance

In Earlier post we understood what is Software Code Review & Its Checklist to review source code in Computer system validation?

Now in this article we are going to understand What is Qualification Protocol (IQ/OQ/PQ/IFQP), Its Necessity & When requalification performed in CSV? Computer system validation?

What is Qualification?

Qualification is defined as an action of providing that equipment or ancillary systems are properly installed, work correctly, and actually lead to the expected results

It is the process used to establish confidence that the equipment is capable of consistently operating within established limits and tolerances.

Need of Qualification

  • To manufactured a quality product
  • Proof “suitability for intended use”
  • Regulatory requirements
  • Cost effective

What is Qualification Protocols:

Qualification protocols are methods for demonstrating that equipment being used or installed will offer a high degree of quality assurance such that production processes will consistently manufacture products that meet quality requirements.

Writing effective IQ/OQ/PQ protocols is a must for following the regulations required by the FDA for equipment, systems, and utilities to demonstrate suitability for the intended use and to operate according to their design and functional specifications

In order to prove the requirements are met, Qualification protocols have to be written and followed. These protocols are documented evidence that manufacturing firms are in compliance with cGMPs.

Following these guidelines, your facility’s IQ/OQ/PQ protocols will be effective and provide adequate proof of compliance. 

Validation is a systematic approach where data is collected and analyzed to confirm that a process will operate within the specified parameters whenever required and that it will produce consistent results within the predetermined specifications.

Validation is concerned mainly with processes. When the same approach is applied to a machine or any equipment instead of a process, it is referred to as qualification instead. 

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

To initiate the qualification of pharmaceutical equipment a frame work before startup is required:

  • Defining User Requirements (URS) Defining Functional Requirements for given User requirements (FRS)
  • Defining Design based on URS & FRS (DQ)
  • Factory Acceptance Test at the site of manufacturer (FAT)
  • Site Acceptance Test at the site of user (SAT)
  • Installation Qualification (IQ)
  • Operational Qualification (OQ)
  • Performance Qualification (PQ)
  1. User Requirement Specification

User Requirement Specifications consist of Design Specifications and Functional Specifications.  Design Specifications provide explicit information about the design requirements for equipment e.g. the dimensions, material of construction, layout, etc. Functional Specification denotes how each feature of the equipment/system must function.

2. Factory Acceptance Test (FAT)

  • Checks for completeness of installation.
  • Verification of URS with the actual.
  • Proof of functionality, by either a conventional function test or by simulation.
  • Verification of documents (availability and quality).
  • Overall Review/Inspection.

3. Site Acceptance Test (SAT)

  • Verification of equipment design
  • specifications of received equipment at site of User by received documents/drawings from Manufacturer / vendor
  • Physical verification

4. Design Qualification (DQ)

It includes activities that define the design elements of the instruments such as functional and operational specifications as well as vendor selection criteria.

DQ can be performed by the manufacturers, developers or even the end users.

5. Installation Qualification Protocol (IQP)

Should confirm that

System has been installed as specified in design document; Specified hardware has been assembled and installed correctly. All the connection such as power supply, network is installed as specified.

For a system is associated with an instrument, whether the instrument has been calibrated (if applicable) and installed correctly

IQ comprises all activities during the installation of the instrument.

IQ checks whether the environment where it is installed is suitable, if the instrument is in accordance with the desired specifications and if the installation procedures have been complied with.

6. Operational Qualification protocol (OQP)

Should confirm that

Testing or Verification of the system against specifications to demonstrate correct operation of functionality that supports the specific business process throughout all specified operating ranges.

It involves collecting document evidence showing that the installed instrument’s performance in the chosen environment will be according to the criteria specified in operational specifications.

7. Performance Qualification Protocol (PQP)

Should confirm that

System is capable to demonstrate fitness for intended use and to allow acceptance of the system against specified requirements

It requires measuring if the instrument is performing its intended purpose against the activities documented in the PQ stage, which consists of maintenance, change control and calibration.

.

8. Infrastructure Qualification:

A separate infrastructure Qualification protocol (IFQP) shall be prepared by IT to perform the qualification of all infra components which are required to implement the software application or based on the design /architecture of application.

Based on complexity& risk of the system, Infra component qualification merged with IQ& OQ protocol of software application.

Hardware Qualification (like Server, workstation etc) shall be performed prior to installation of any Software application on that.

Re-Qualification

Re-Qualification carried out for one or more of the following reasons:

  • To address deficiencies observed in an executed qualification
  • Need for additions in qualification test criteria
  • To qualify changes done in the equipment or a process involving the equipment
  • Failure
  • CAPA
  • Findings/Recommendations from Inspections/Audits/ PQR, etc.
  • Inputs from Preventive Maintenance/Calibration Program
  • Equipment Up-gradation

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is Software Code Review & Its Checklist to review source code in Computer system validation?

Data Integrity app for Pharma Compliance

In Earlier post we understood what is Traceability Matrix, Its Use, & Benefits in Computer system Validation.

Now in this article we are going to understand what is Software Code Review & Its Checklist to review source code in Computer system validation?

Software code review is performed to detect and fix coding errors before the system goes into formal testing. It verifies that the software has been developed in accordance with the design & programming standards have been followed.

Software code review is performed when supplier audit is not possible & vendor unable to provide strong evidence.

If vendor provide satisfactory evidence that source code was developed in effective manners & follow guidance software development life cycle then source code review not required.

Software code review is often implemented as code inspections & code walkthroughs. Such static analyses provide a very effective means to detect errors before execution of the code.

Code review is best done as early in the process as possible, preferably before submitting a module to test.

Software Code Review Checklist

A checklist is a useful means of ensuring that common mistakes are identified.

1 General Check:

  • Comments must be added at the beginning and the end of the blog code that user modify.
  • Comment must clear, correct & it explain purpose.
  • All parameters have descriptive names?
  • Does the code work? Does it perform its intended function, the logic is correct etc.
  • Is all the code easily understood?
  • Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.
  • Is there any redundant or duplicate code?
  • Are Folder names and types in conformity with the content and standard of developing tools?
  • Do loops have a set length and correct termination conditions?
  • Do the names used in the program convey intent?

2 Documentation Check:

  • Do comments exist and describe the intent of the code?
  • Are all functions commented?
  • Is the use and function of third-party libraries documented?
  • Are data structures and units of measurement explained?
  • Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?

3 Security Check:

  • Are all data inputs checked (for the correct type, length, format, and range) and encoded?
  • Where third-party utilities are used, are returning errors being caught?
  • Are output values checked and encoded?
  • Are invalid parameter values handled?

4 Performance Check:

  • Are there any obvious optimizations that will improve performance?
  • Can any logging or debugging code be removed?

5 Testing

  • Is the code testable? The code should be structured so that it doesn’t add too many or hide dependencies, is unable to initialize objects, test frameworks can use methods etc.
  • Do tests exist, and are they comprehensive?
  • Do unit tests actually test that the code is performing the intended functionality?

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is RTM & Its importance in CSV?

Data Integrity app for pharma compliance

In Earlier post we understood What is Configuration Specification, Its Roles & Elements in Computer system Validation.

Now in this article we are going to understand What is Traceability Matrix, Its Use, & Benefits   in Computer system Validation.

What is Traceability Matrix? (TM)

A TM is a document that co-relates any two-baseline documents that require a many-to-many relationship to check the completeness of the relationship.

It is used to track the requirements and to check the current project requirements are met.

What is RTM?

RTM is a method used to establish the relationship between documents. Its purpose is to ensure that requirements have not only been traced to the appropriate design elements but also that requirements have been met through test or other means of verification.

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 RTM traces the deliverables by establishing a thread for each requirement, from a project’s initiation to completion.

Traceability Matrix is often used to:

  • Track Requirements: Objectives being met by the current process and design?
  • Ensure that all requirements that are defined for a system, are tested in Test Protocols
  • Help auditors in reviewing the validation documentation
  • Assist in creation of an project plan tasks, Request for proposal, deliverable documents, and test scripts.
  • Form the basis of a projects SCOPE, by incorporating specific requirements and deliverables that will be produced.

What regulations say?

FDA (Code of Federal Regulations Title 21) and TGA (PE 009-8 – 15 January 2009) currently do not have any specific regulation around requirements traceability.

However, the European Commission (Volume 4 Annex 11 Clause 4.4 (part)) and PIC/S Guide to Good Manufacturing Practice for Medical Products (PE 009-11 1 March 2014 Annex 11 Clause 4.4) do state “User requirements should be traceable throughout the life-cycle.”.

Types of Traceability Matrix

  • Forward traceability: This matrix is used to check whether the project progresses in the desired direction and for the right product.
  • Backward or reverse traceability: The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, test or other work that is not specified in the requirements.
  • Bi-directional traceability (Forward + Backward): This traceability matrix ensures that all requirements are covered by test cases. It analyzes the impact of a change in requirements affected by the Defect in a work product and vice versa.  

A Matrix is considered to be bi-directional when it:

  • tracks the requirement “forward” by examining the output of deliverables
  • looks at the business requirement that was specified for a particular feature of product “backward”

Advantage of RTM

  • It confirms 100% test coverage
  • It highlights any requirements missing or document inconsistencies
  • It shows the overall defects or execution status with a focus on business requirements
  • It helps in analyzing or estimating the impact on the QA team’s work with respect to revisiting or re-working on the test cases

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is Configuration Specifications in Computer system validation?

Data Integrity app for Pharma Compliance

In Earlier post we understood what is project validation plan (PVP) & What Content should include in PVP?

Now in this article we are going to understand What is Configuration Specification, Its Roles & Elements in Computer system Validation.

What is Configuration Specification (CS)?

The Configuration Specification details the configuration parameters & how these settings address the requirements in the URS. This may be a standalone document or detailed in the FS.

Configuration specification is specific & describes in detail how the function will be configured, and what you must do to test the function.

The configuration specification includes the configuration items for the application hardware and software, operating system, interface (if any) and data for the implementation of system.

The Configuration Specification document is defined in order to describe the list of HW/SW components included in the Computerized System.

Here you define the configuration of the application required for your business purposes based on your requirements (for example, Audit Trail Settings, Electronic Signature, User Administration, Authorization Concept).

Functional and configuration specifications are not required when using commercial off-the-shelf software (Category 3). As a result, the extent of the testing performed would also be reduced.

System Configuration Specifications includes

  • Hardware Configuration
  • Operating System Configuration
  • Software Configuration
  • Interface Configuration
  • Data Configuration

The Configuration Specification identifies the System Configuration Baseline addressing the SW components and interfaces and the System Parameters, focusing on the configuration items which may affect the GMP functionalities.

A Security Matrix is created (included in the document or in a separated document) in order to identify the user profiles defined in the system and the related functions included.

The assignment of the users to each profile shall be executed according to the security-related procedures. The document shall also describe the IT landscape on which the software resides and how it is to be connected to any existing system or equipment.

Therefore the document shall include also (or make reference to other document) a description of the system landscape and a specification of all elements shown on the Landscape (e.g. Operating systems, Middle ware, Ancillary Software e.g. PDF viewer, System environments, Interfaces, Relevant IT Infrastructure components e.g. Servers).

The CS describes how the system will be configured to match its functions to the business process. The actual configuration process usually occurs on-site after system installation, and may be performed by the system vendor.

The elements of the CS should now be recorded in the trace matrix beside the corresponding requirements and functions each configuration item is meant to satisfy.

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is Project Validation Plan (PVP) in Computer System Validation?

Data Integrity App for Pharma Compliance

In Earlier post we understood What is Design Specification, Its Type & Elements in Computer System Validation.

Now in this article we are going to understand What is project validation plan(PVP) & What Content should include in PVP?.

What is Project Validation Plan(PVP):

CSV processes should be guided by a good plan that is created before the project starts. Project Validation Plan should be developed during this planning phase of the SLC

Validation plan will define the objectives of the validation, the approach for maintaining validation status over the full SDLC & satisfy all regulatory policies & industry best practices (e.g., GAMP 5).

It also defines roles and responsibilities along with the most important part, the Acceptance Criteria.

A project validation Plan shall be created to identify and define the Validation strategy and deliverable s generated as an outcome of the execution of the strategy.

The PVP should be project specific and describes the approach for the validation of the system, required activities and deliverable s

The validation plan will be created by people who have a good knowledge of the technology involved (i.e., informatics systems, instruments, devices, etc.) and serve to minimize the impact of the project on day-to-day lab processes.

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

A Validation Plan should include:

  • Deliverable (Documents) to be generated during the validation process
  • Resources, departments & personnel to participate in the validation project
  • Testing Approach – Defines the types of data that will be used for testing, along with the kind of scenarios that will be tested.
  • Time-lines for completing the validation project
  • Acceptance criteria to confirm that the system meets defined requirements
  • Testing Team and Responsibilities – Lists the members of the validation team, along with their roles and responsibilities in the validation process.
  • Compliance requirements for the system, including how the system will meet these requirements

The plan should be written with an amount of detail that reflects system complexity.

The plans should be approved, at a minimum, by the System Owner and Quality Assurance. Once approved, the plan should be retained according to your site document control procedures.

Following deliverable’s must be generated as a result of execution of these planning phase/stages-

  • Project Plan (schedule)
  • Change control Approval
  • Updated Inventory List
  • GxP Assessment & system Categorization checklist
  • System level risk assessment
  • Electronic Record & Electronic signature Assessment
  • Vendor survey form (if applicable)
  • Vendor Audit report (if applicable)
  • SOW/NDA ( if applicable)
  • User Requirement Specification (update if required)
  • Project Validation Plan/Validation Master Plan
  • Updated Inventory List

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is Design Specification, Its Type & Elements in Computer System Validation?

Data Integrity App for Pharma Compliance

In Earlier post we understand Function Requirement Specification (FRS) & Its Checklist that should followed while finalizing FRS.

Now in this article we are going to understand What is Design Specification, Its Type & Elements in Computer System Validation.

The Design Specification (DS) describes the hardware and software platforms of your system to be validated. The DS also quantifies the how each system component is to be configured as well as how each component factors into making a completed system.

Design Specification: The system design specifications is a description of what software should do and how it should it. For each requirement, a set of one or more design elements may be produced.

Vendor or Implementation partner shall develop and provide the DS to Project team for review & Approval

Some general guidelines should be kept in mind while preparing the DS –

  1. The Design Specification must state the system design from a technical and infrastructure perspective
  2. Each Design specification statement must be stated with technical clarity.

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

Design Specification should ensure the following:

  1. Design satisfies product and process requirements
  2. Design appropriately addresses critical aspects of manufacturing systems
  3. Risks to product quality and patient safety have been identified
  4. Unacceptable risks are mitigated by design or other means

Types of Design Specification

  • Hardware Design Specification (HDS)
  • Software Design Specification (SDS)

1 HDS

The HDS Hardware Design Specification is a document that provides an overall description of the hardware and implementation. It provides description of main components and interactions and as well requirement for proper connection to utilities and installation.

SDS

The SDS Software Design Specification is a document that provides an overall description of the software, implementation,functions and interface with the users.

Design Specifications may include:

  • Specific inputs, including data types, to be entered into the system
  • Calculations/code used to accomplish defined requirements
  • Outputs generated from the system
  • Explaining technical measures to ensure system security
  • Identify how the system meets applicable regulatory requirements

Design Specification document contains all of the technical elements of the systems includes:

  • Database Design – file structures, field definitions, data flow diagrams, entity relationship diagrams
  • System Use- Description of the intended use of the system
  • Logic/Process Design – pseudo code for logic and calculations
  • Security Design – virus protection, hacker protection
  • Interface Design – what data will move from one system to another; how and how often, and failure handling
  • Architecture Design – required hardware, operating systems, application versions, middle ware, etc.
  • Network Requirements
  • Specific peripheral devices – scanners, printers, etc.

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

What is Functional Requirements Specifications (FRS) & Checklist that should followed while finalizing FRS

Data Integrity App For Pharma Compliance

In Earlier post we understand User Requirement Specification & Its Guidelines should be kept in mind while finalizing URS in computer system validation.

Now in this article we are going to understand Function Requirement Specification (FRS) & Its Checklist that should followed while finalizing FRS.

User Requirements describe the end-user requirements for a system. Functional Requirements describe what the system must do.

The purpose of a functional specification is to define the requirements to be implemented by the software solution.

The Functional Requirements Specification documents the operations & activities that a system must be able to perform. FRS describes what the system must do; how the system does it is described in the Design Specification.

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

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

Requirements outlined in the Functional Requirements Specification are tested in the Operational Qualification.

The Functional Requirements Specification should be signed by the System Owner & 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.

Depending on the size and complexity of the program, the Functional Requirements Specification document can be combined with either the user requirements specification or the design specification.

Functional Specifications (FS):

Vendor or Implementation partner shall develop & provide the FS to Project team for review & Approval.  Wherever required Project team shall developed FS

FS defined what the system should do, and what functions and facilities are to be provided.

General guidelines should be kept in mind while preparing the FS –

  1. FS must state essential business needs from a functional & technical perspective.
  2. Each requirement specified in the URS document for the system shall be addressed in the FRS document. In case any specific requirement defined in the URS cannot be implemented as a part of the system then reason for the same shall be addressed.
  3. Each functional requirement must be uniquely numbered for each traceability
  4. Requirement must be unambiguous
  5. Each requirement must be verifiable and /or testable
  6. FRS document serve as the foundation to implement the functionality

Examples of Functional Requirements

Functional requirements should include functions performed by specific screens, outlines of work-flows performed by the system, and other business or compliance requirements the system must meet.

Interface Requirements

  • Field 1 accepts numeric data entry.
  • Field 2 only accepts dates before the current date.
  • Screen 1 can print on-screen data to the printer.

Business Requirements

  • Data must be entered before a request can be approved.
  • Clicking the Approve button moves the request to the Approval Workflow.
  • All personnel using the system will be trained according to internal SOP AA-101.

Regulatory/Compliance Requirements

  • The database will have a functional audit trail.
  • The system will limit access to authorized users.
  • The spreadsheet can secure data with electronic signatures.

Security Requirements

  • Members of the Data Entry group can enter requests but can not approve or delete requests.
  • Members of the Managers group can enter or approve a request but can not delete requests.
  • Members of the Administrators group cannot enter or approve requests but can delete requests.

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

Functional Requirements Specification Checklist

  • Is there a genuine business need and benefit outcome planned from the specification?
  • Is there an approved budget for providing and spending time on the specification?
  • Does specification include a version history?
  • If there is an assumptions section where those assumptions have been verified?
  • Have all functional solutions been considered?
  • Is it confirmed there are no questions left to answer?
  • Does specification include layouts of proposed screens?
  • Does specification include details of validation to be imposed on any inputs?
  • Does specification include detailed logic for any workflow required?
  • Does specification include details of any messages that will be output?
  • Are any help facility requirements present?
  • Does specification outline/exclude any performance requirements?
  • Is it mentioned how exception handling will be handled?
  • Is it clear what documents will be delivered as part of the work?
  • Is each of requirements mentioned and appropriate based on the business requirements specification?
  • Have all dependencies been identified?
  • Have all ambiguities been replaced with exact requirements?

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

Guidelines should be kept in mind while finalizing User Requirement Specification

Data Integrity App for Pharma Compliance

URS provide the knowledge of basic user requirements to manufacturer / supplier about equipment / utility / facility proposed to be procured by the user.

The URS is then provided to the manufacturer/Supplier as an input for the quotation, design, construction, commissioning and validation of the system.

URS should clearly & precisely define what the user wants to the system to do. It should define the functions to be carried out, the data on which the system will operate.

The URS may also define any non-functional requirements, constraints. The emphasis of the URS should be on required functions & not on the methods of implementing those functions

  1. Operational Requirements
  2. Function Requirements
  3. Technical Requirement
  4. Environment Requirements
  5. Regulatory Requirements
  6. Safety Requirements
  7. Documentation / Training

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

1.Operational Requirements include:

Operational requirements are those statements which identify the capabilities, requirements & performance measures to satisfies the needs of a person, group or organization.

Enable an organisation to produce a clear, considered and high level statement.

  • Available functions
  • Data flow
  • Interfaces
  • environment

2. Function Requirements:

Functional requirements are those which are related to the technical functionality of the system. Functional requirements specifies a function that a system or system component must be able to perform.

  • Safety
  • Security including access control
  • Audit trails
  • Use of electronic signatures
  • Output (e.g., reports. files)
  • Unambiguous error messages”

3. Technical Requirement:

  • Basic Requirements: Specify the basic requirements form the manufacturer like basic layout of the equipment, installation Layout of the equipment, list of all components including material description, total weight and capacity.
  • Specific Requirement: Specify the other specific requirements related the specific equipment/utility/system.
  • Change over parts Requirement: Specify the required change parts if needed.
  • Any other specific requirements: Mention if applicable.

4. Environment Requirements

The environment in which the system is to work will be defined. The following will be addressed as appropriate:

  • Layout: The physical layout of the plant or other work place may have an impact on the system, such as long distance links or space limitations.
  • Physical Conditions: (e.g., temperature, humidity, external interference)
  • Physical Security:
  • Power Requirements: Voltage, amperage, filtering, Earthing protection, Uninterruptible Power Supply (UPS))
  • Any special physical or logical requirements    

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

5. Regulatory Requirements:  

  • 21 CFR Part-11 compliance: Specify the regulatory requirement as applicable. When a new equipment/instrument is ordered need to comply as per IT manual and clearly specify IT related controls.
  • Data integrity: Specify the requirement of access control level for the data integrity.
  • Requirements of piping welds and product contact welds: Shall meet ASME and 3A specification requirements.
  • Inspection and testing: Specify the requirements of inspection and testing (FAT) at the supplier’s site before delivery.  

6. Safety Requirements:  

  • Requirements of Emergency stop, Alarms, and Indications and Interlocks: Shall available on the criticality of the equipment.
  • Desired personnel safety systems: Mention other safety requirements like electrical wiring must be concealed, Warning stickers on all hot surfaces, emergency stop function etc.
  • Power failure and recovery: Specify the requirement as needed.
  • Any other specific requirement: As required.

7. Documentation/Training:  

  • Desired Documents: Specify the required documentation support from the supplier.
  • Training: Specify the training requirements of technical staff.

Data handling requirements:

Consideration will be given to understanding the impact upon patient safety, product quality, and data integrity.

The following will be addressed as appropriate:

  • Definition of electronic records
  • Definition of data, including identification of characteristics, formatting, critical parameters, valid data ranges,
  • limits and accuracy, character sets, etc.
  • Required fields
  • Data migration
  • Data input and subsequent editing
  • Backup & Recovery
  • Archive requirements
  • Data security and integrity”

Guidelines for URS:

  1. URS must only state the essential business needs from a user perspective, rather than various design aspect
  2. Each requirement must be uniquely referenced to easy traceability
  3. Requirement must not be repeated or contradicted
  4. Each requirements must be testable & verifiable
  5. The requirements should be defined at a high level as compared to the requirements defined in the FRS

Wherever possible, requirements should be prioritized. It should be to identify essential & desirable requirements.

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

System Level Risk, Impact & Complexity Assessment in CSV

Data Integrity App for Complete Pharma Compliance

In Earlier post we understand GxP Assessment & Categorization of Computerized System. It is first stage of whether a system requires a validation is to identify whether the system has a GxP impact.

Now in this article we are going to understand System Level Risk, Impact & Complexity Assessment in computer system validation.

Applying risk assessment procedures to validation is a highly effective means of ensuring that all critical requirements are tested with the appropriate level of documentation in order for a system or process to be considered as validated or verified.

Validation risk assessment is a structured & documented approach to assessing risks in a computerized system, equipment, instrument & process.

Risk is the combination of the probability of occurrence of harm & the severity of that harm.

A measure of the probability & severity of undesired effects, often as the simple product of probability & consequence.

Risk Management should be viewed as an on-going Quality Management process.

A Systematic Evaluation of the risk of a process by determining

  • What can go wrong (Risk Identification)
  • How likely is it to occur (Risk Estimation)
  • What the consequences are.

Examination of process & develop safety barriers to minimize chance of error. Understand where risk comes from & how people process information.

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

System Criticality & Impact Assessment

1 Does the system impact patient safety?

2 Does the system impact or capture data about the quality of the product?

3 Does the system impact on GMP regulated records?

4 Is the system involved in capturing information that would alert Wockhardt to take an action or support the execution of an action that impacts the product quality (e.g. product recall, adverse event reporting)?

5 Does the system functionality create any hazards to the environment including people working on the system such as process control systems?

Complexity Assessment

1 System complexity nature as Standard COTS/Configurable COTS/Customized (bespoke)

2 Is the system interfaced with other system/s?

3 Is the technical contingency plan in place if system becomes non-functional?

4 Does the system impact multiple or companywide functions, or is new infrastructure required?

5 Does the system implementation involve data migration?

6 Does the Product Vendor or system implementation vendor have any prior experience of implementing the system at any other pharmaceutical organization?

7 Are the estimated numbers of concurrent users as 5- 10 or 10 -15 or more than 15?

Determine level of Risk & Assessment using below scale:

Rating Scale of above Assessment:

2  ≥  3High
1 ≥ 2Medium
0  ≥ 1Low

TAccess full content we recommend you to download our Free “Data Integrity“ App Contains All most important Pharma IT Compliance concepts which help you to understand Data Integrity in simple word.

Data Integrity App for Complete pharma Compliance Reference

Initial Risk Ranking

To determine the Initial Risk Ranking of GxP Computerized system, follow below matrix between Overall System Impact & complexity

Overall Risk Rating is determined using the traditional 9 box grid image.

Complexity >
Overall Impact
Low Complex  Medium Complex  High Complex  
High ImpactMEDIUM RISKHIGH RiskHIGH Risk
Medium ImpactLow RiskMEDIUM RiskHIGH Risk
Low ImpactLow RiskLow RiskMEDIUM Risk

Decision based on Risk Rating:

Many decisions can be made from the initial risk ranking including the approach and extent of the validation.

Supplier Auditing – High Risk items only. Medium and low risk computerized systems have only a postal questionnaire.

Risk Assessments – High and Medium risk systems will be subject to more detailed risk assessments, low risk computerized systems will not.

Level of verification activities – High and Medium risk systems have detailed formalized testing, Low risk computerized systems have reduced testing, either commissioning or supplier verification.

Level of security – Low risk computerized systems minimal controls over security, High and Medium Risk computerized systems have full security controls applied.

The above list is not exhaustive; the regulated company can use Risk Rating to determine level of validation, deliverables & controls through lifecycle of computerized system.

Data Integrity –Risk Assessment

• Risk assesses all lab areas prior to the audit to identify equipment that produce electronic data files.

• Categories the equipment according to GAMP5.

Auditors will focus on instrumentation that falls under USP<1058> categories B & C and GAMP5 categories 3, 4 and 5.

• Perform an internal Data Integrity audit on medium & high risk equipment.

• Does the equipment meet the requirements of 21 CFR part 11 (as yourself the 5 questions regarding electronic data)?

• Check that electronic data can only be accessed through the instrument software & not via the operating system.

• Identify gaps and implement short term corrective action before audit (if possible):

• Discuss longer term corrective actions with management team.

Risk Severity:

Critical: Very Significant Non-Compliance with GMP or Patient Injury

Major: Significant Non-Compliance with GMP or Patient Impact

Minor: Minor Infringement of GMP No expected Patient Impact

Risk Assessment – Assess Potential Risks and Consequences

Risk Identification – Identify the Potential Risks

Risk Estimation – Determine the Likelihood that the Risk will Occur

Risk Impact – Determine the Potential Impact of the Risk

Risk Detection – Determine the Detectability of the Risk

Risk Classification – Define & Quantify Risk Level

Risk Analysis – Determine Cost/Benefit Analysis

Risk Mitigation/Avoidance – Determine Risks which can be Lessened or Avoided

Risk Strategy – Determine and Document Strategies for Managing Risk

Risk Monitoring – Monitor Changes, New Risks, Risk Levels & Update Risk Plans

Download our Free Data Integrity App to access more related content.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

  • Current Regulatory Agencies thinking on Data Integrity.
  • Importance of Mock Inspection & its tricks and techniques how to conduct.
  • Checklist for Inspection
  • Best Practices for CSV.
  • Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

Design a site like this with WordPress.com
Get started