Smartlogic

Menu

תגית: ולידציה

ולידציה היא אוסף של כללים מנחים על פיהם נבחנת איכות של תהליכי הייצור. ולידציה נסמכת על תקנים קבועים מראש וסמארט לוג'יק המתמחה בבקרה ואוטומציה מגישה תיקי ולידציה בפורמט קבוע ומוגדר.

ולידציה לנוהל 126 של משרד הבריאות

Posted on by אביב צברי

חברת סמארט לוג'יק מומחית בולידציה לנוהל 126 של משרד הבריאות

כמו שראינו במאמר הקודם מהי ולידציה  הבנו מה היא ולידציה ומה החשיבות שלה בכל מתקן יצור של מוצר איכותי.

במאמר זה נדבר על מרכיבי הולידציה ונפרט מהם, כמו כן נפרט על הבדיקות הנדרשות במהלך הולידציה.

ובקצרה ולרענון הזיכרון מהי ולידציה : ולידציה היא הוכחה מתועדת כי תהליך / ציוד / מערכת / תהליך עומדים בקריטריוני הקבלה והדרישות אשר הוגדרו מראש ותועדו בנוהל מאושר בכל הנוגע ל:

  • מפרטים שונים
  • הגדרות שונות
  • איכות
  • צרכי הלקוח
  • דרישות רגולטוריות של הרשויות הרלוונטיות לאותו התחום, אשר מתפרסמות מעת לעת.

 הולידציה נדרשת למגוון תחומים והיא כוללת תעשיות שונות כגון :

כימיה

קוסמטיקה

מזון ותוספי תזונה

מכשור רפואי

תוכנה ומערכות מחשוב

מדעי המחשב

כימיה ואנליטיקה

הנדסה

 

תהליך הולידציה לרוב יכלול את השלבים הבאים:

VP – Validation Plan – תכנית הולידציה

Impact/criticality and risk assessments –  הערכת קריטיות, השפעה וסיכונים

DQ – Design Qualification –  ולידציה תכנון המערכת

IQ – Installation Qualification –  ולידציה להתקנה

OQ – Operational Qualification – ולידציה לפעילות

PQ – Performance Qualification –  ולידציה לביצועי המערכת

PPQ – Process Performance Qualification –  ולידציה לתהליך הייצור

Re-Validation –  ולידציה חוזרת / תקופתית

 

ולהלן פירוט מרכיבי הולידציה (בהתאם לנוהל משרד הבריאות תנאי אחסון והובלה של תכשירים נוהל מספר 126)

 

הסמכת התקנה IQ Installation Qualification

הסמכת התקנה I.Q Installation Qualification באה לאמת את ההתקנה והתצורה של המערכת. ההסמכה יכולה להבטיח כי הקבצים הדרושים הוטענו, הציוד הותקן, ההליכים הדרושים אושרו, והצוות המתאים הוכשר. הדרישות להתקנה נכונה של המערכת הוגדרו במפרט העיצוב. הסמכת התקנה I.Q Installation Qualification חייבת להתבצע לפני השלמת הסמכת פעולה O.Q Operation Qualification. או הסמכת ביצועים P.Q Performance Qualification

פרוטוקולי הסמכת התקנה חייבים להיות מאושרים לפני ביצוע הפרוטוקול. עותק של פרוטוקול שלא בוצע צריך להישמר בחבילת האימות. פרוטוקול שלא בוצע צריך להיות מאושר על ידי מנהלי  מערכת אבטחת האיכות. פרוטוקול שבוצע צריך להיות חתום על ידי הבוחן ונסקר על ידי מנהלי מערכת אבטחת האיכות.

 

הסמכת פעולה OQ Operation Qualification

השלב הבא הוא הסמכת פעולה Operation Qualification O.Q. בשלב זה, במידה וציינתם כי הציוד מיועד לזמן ריצה בטווח של 50-150 סל'ד ותמשוך כמות מסוימת של כוח, תרצו לוודא כי הציוד עומד בדרישות. אז, בדקו את הפרמטרים האלה ואתגרו אותם. ושוב, וודאו כי הציוד בפועל, פועל בזמן הריצה שהוא אמור להיות.

 

הסמכת ביצועים PQ Performance Qualification

בשלב הסמכת ביצועים  PQ Performance Qualification  אנחנו אוהבים לאתגר את הציוד, כמו בשלב של ה -OQ, אבל בשלב הזה תחת עומס. אמנם זה טוב כי טווח הפעולה הוא בזמן ריצה של ב 50 סל'ד או 150 סל'ד כאשר קו הייצור ריק, אבל עולה השאלה הבאה : מה קורה כאשר יש 300 קילוגרמים של חומר? האם עדיין ניתן להשיג את טווחי המהירות האלו? זו המהות והמיקוד של שלב PQ. לאחר שתשלימו את שלושת השלבים האלה, הציוד זמין לשימוש בכל תהליך שהתכוונת לכך.

פירוט מרכיבי הולידציה

הסמכת התקנה Installation Quafilication, כוללת את הבדיקות הבאות:

  • בדיקת התאמת מרכיבי המערכת לתכנון והתקנתם בהתאם לתכנון ו/או הוראות יצרן.
  • בדיקה לגבי כל המרכיבים אם הם מסומנים ומזוהים כנדרש וכל הרגשים מכוילים

הסמכת פעולה Operation Qualification  כוללת את הבדיקות הבאות:

  • בדיקת פעילותם התקינה של כל המרכיבים כולל מרכיבי הבקרות וההתרעות.
  • מיפוי טמפרטורה בחלל ריק ובהתאם לתוצאות המיפוי יקבעו מיקומי הרגשים בנקודות הקיצון.

 הסמכת ביצועים  Performance Qualification   כוללת את הבדיקות הבאות:

  • בדיקת ביצועי המערכת בזמן אמת במצב עבודה בחלל מועמס (מחסנים, חדרי קרור, מקררים נייחים וניידים ומארזים).
  • בדיקות מיפוי טמפרטורה של חללים / מחסנים / מארזים ניידים – הבדיקות תתבצענה גם בחורף וגם בקיץ.

היקף הולידציה : תהליך ולידציה טיפוסי יכלול את המרכיבים לעיל ואת הבדיקות להלן כולן או מקצתן. היקף הולידציה הנדרש יקבע בהתאם לשיקולים של ניהול סיכונים.

 

במהלך תהליך הולידציה נדרשות בדיקות מסוימות והן:

  • כיול רגשים (באמצעות מעבדה מוסמכת על ידי הרשות להסמכת מעבדות, ההסמכה תתאים לטווח הכיול הנדרש).
  • מיפוי טמפורטורה חלל מלא/ריק, קיץ / חורף
  • קביעת זמן התאוששות המערכת לאחר פתיחת דלתות.
  • קביעת זמן התאוששות המערכת לאחר נפילת מתח והפסקת חשמל.
  • תקינות בקרות והתרעות.
  • תקינות אמצעי בטיחות (מנגנון שחרור דלת/התרעת אדם לכוד בתוך חדר הקרור).
  • תחזוקה שוטפת.
  • קיום נהלים וקריטריוני קבלה לכל הבדיקות.

דו"ח ולידציה

כמו שהזכרנו לעיל, את תוצאות הולידציה יש לסכם בדו"ח כתוב הכולל את המרכיבים הבאים:

  • היקף ולידציה מנומקת (IQ, OQ, PQ).
  • אישור פרוטוקול.
  • פירוט ציוד נבדק
  • פירוט פרמטרים נבדקים
  • פירוט ציוד הבדיקה ואישור כיולים.
  • אישור הסמכת בודקים
  • תוצאות בדיקות ומדידות שבוצעו

 

הדו"ח יכלול תוצאות מפורטות, ניתוח תוצאות ומסקנות.

 

לפגישת ייעוץ , אנא התקשר אלינו 08-9102070

 

 

 

 

 

 

 

 

ולידציה – Validation case study – part 2

Posted on by אביב צברי

ולידציה – Validation case study – part 2

 This article was written by Iian Shaya, validation,automation and control expert

Validation Requirements

Documentation for Initial Tender

Project schedule and milestones design and construction detail

Project quality plan

Supplier’s local subsidiary/agent

Supplier’s documentation that the system / configurable software versions are released to the market and are FDA/EMEA compliant

Compliance to the 21 CFR Part 11 operational requirements – the contractor should ensure covering of all the requirements described below

Contractor to state the system/product status and implementation planned for each requirement – User's approval pre-delivery

Documentation for Design Review

PID for the system

Electrical and pneumatic schematics

:Installation data

General arrangement drawings

Floor loading

Utility requirements

Details of electronic records and approvals that may be subject to regulatory controls under CFR Title 21 part 11

Instrumentation documentation

:Main components specification

Equipment

Instrumentation

Valves

Piping

Control system

Pipe welding documentation

General installation book

Procedures

User guide

Security

Preventative maintenance + spare parts list

Operation procedure

Pressure test procedure

Leak test procedure

Passivation procedure

Calibration

:Functional Design Specifications for

Complete manufacturing system

Software – SW and hardware –HW

Functional Design Specifications

System Detail Design Specifications for HW and SW.

SW source code, with comments, for customized SW

SW complete version history

HMI alarm list, message list and graphical displays

I/O list

:List of materials

Product contact materials

Potential product contact lubricants

Welding procedures for product direct and indirect contact parts

Pre-delivery Inspection and Factory Acceptance Test (FAT) protocols

Steel certificates and gasket certificates

Documentation Prior to FAT or Pre-Delivery Inspection – PDI

:Progress visit report which will include

Mechanical and technical development

Automation and SW development

:Supplier’s factory test results for

Unit tests – The test protocols shall be traced to low level design document and will be approved by the user prior to execution. The approval of the report shall be performed by representatives of the user's validation team, IT QA.

Automation and SW development

:Integration Tests  – Simulation Testing

Approved PDI and FAT protocols

Commissioning

MCCR

Purpose

Scope

Responsibility

Execution instructions

System scope

System description

Drawing verification

Equipment verification

Valve verification

Instrument installation and calibration

Utility verification

Documentations verification

Piping Verification

Sample Point Verification

Safety, health and environment verification

Slopes verification (if relevant)

Electrical and communication activities

Pump installation verification, if relevant

Heat exchanger installation verification, if relevant

Air break verification, if relevant

Dead leg verification, if relevant

CE

Purpose

Scope

Responsibility

Execution instructions

System scope

System description

System startup

Equipment verification

Main equipment operation checks

System FDS (SSO) verification

System performance testing

 This article was written by Iian Shaya, validation,automation and control expert

ולדיציה – Validation case study – part 1

Posted on by אביב צברי

ולדיציה -1 Validation Requirements – case study- part

 This article was written by Iian Shaya, validation,automation and control expert

Validation Requirements is a document which may be part of the validation documentation that describes the validation strategy for a system or subsystem. This document is generic; the system or subsystem may include a PC with Human/Machine Interface (HMI), a Programmable Logic Controller (PLC), virtual hardware (HW), software (SW), and other components designed to maintain the user's facility in proper conditions specified by the user.

Validation Requirements Document Contents

This document is structured in a relatively standard fashion, with predetermined chapters and sections, where the final contents are tailored according to the type and size of the system under validation.

The main chapters and sections of a Validation Requirements document are:

Responsibility

Validation Requirements

Documentation for Initial Tender

Documentation for Design Review

Documentation Prior to Factory Acceptance Test (FAT) or Pre-Delivery Inspection – PDI

Commissioning

Documentation For Installation and Operational Qualification (IQ and OQ) – to be checked at PDI/FAT

Design Qualification (DQ) Protocols (Including PC/PLC) Architecture

Installation Qualification (IQ) Protocols (Including PC/PLC

Operational Qualification (OQ) Protocols (Including PC/PLC

Performance Qualification (PQ) Protocols

Computerized System Validation

Responsibility

This section lists the responsibilities of contractor, the user, and the required contents of the documents composing the validation file

The contractor is responsible for creation and performing the DQ, Design Review, Commissioning, IQ and OQ validation protocols

The user is responsible for creation and performing the PQ validation protocols

Design Qualification (DQ) – The design of the system will be documented and checked in the Design Specification. This specification will include details of the system and must be traceable to the URS and BOD documents

Mechanical Completion Check Report (MCCR) of the system will be documented and checked only by the contractor. This document will check system readiness for the IQ

Commissioning Execution (CE) of the system will be documented and checked only by the contractor. This document will check system readiness for  OQ

Installation Qualification –IQ

IQ will establish documented evidence that the system is installed according to the manufacturers’ specifications and user requirements, and assure that the environment is appropriate for its intended purpose

Each IQ protocol will include an appendix of deviation report, which describes the deviations (if they existent) of the specific system, and the contractor will be responsible to correct them

Operational Qualification – OQ

OQ will establish documented evidence that the system is operated according to manufacturers’ specifications and user requirements, and assure that the environment is appropriate for its intended purpose

OQ will establish documented evidence that the system is operated according to manufacturers’ specifications

.Each OQ protocol will include an appendix of deviation report, which describes the deviations (if they existent) of the specific system, and the contractor will be responsible to correct them

Performance Qualification- PQ

PQ will establish documented evidence that the system performs according to manufacturers’ specifications and user requirements, and assure that the environment is appropriate for its intended purpose

The PQ protocols are user's responsibility

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – FSD – System Functions and Facilities

Posted on by אביב צברי

ולידציה – FDS – System Functions and Facilities

 This article was written by Iian Shaya, validation,automation and control expert

.The Function Design Specification (FDS) is part of the validation documentation. In this article I will continue to elaborate the  parts of the FSD of system function and the system facilities

Modes of Operation

This section details all modes of operation for the system, including

Automatic/Manual

Start-up/Shutdown

Overrides

Emergency Shutdown

System Failure and Recovery

Functional Operation

This section divides each of the sequential functions into logical areas (determined by the process), and provide complete description of each function, including

Normal Control Functions – such as normal sequencing, control, etc

Interlocks – details of all interlocks within the function

Alarms – lists of all associated alarms and actions for recovery

Operator Requirements

This section describes the interface between the operator and the detailed function. It is probably the most important to the user during the design phase, as it fully details all the functions to be supplied by the system in order to meet the user's requirements. It must be written clearly and concisely, so that operators and users without technical background can visualize the system to be supplied. Inputs from the user should be clearly detailed so that the operational requirements can be determined

Human/Machine Interface – HMI

This section describes in detail all points of operation, local terminals, remote terminal, message displays, pushbutton stations, etc

Where computerized interfaces are used, such as SCADA or HMI, a list of the screens and the proposed content should be included

Dynamic Attributes – dynamic color changes for status

Display Values – Values to be displayed on screen and resolution- No. of decimal places

Input Devices – Operator interaction devices, mouse, keyboard, touch screen, etc

Alarm and Event Displays

Security – Password Access

System Data

All the data gathered, generated or calculated by the system should be detailed. The detailed data should include

Type

Range

Accuracy/Resolution

Scaling

All the data to be stored should be detailed. This includes historical trend data, alarms and events, taking into consideration the following

Location of data to be stored – fixed disk, floppy disk, etc

Retention period – length of time for the data to be maintained

Data Archive – procedures for backup to removable medium

Data Export – export facilities to other formats, such as Excel, Access, Lotus, etc

System interfaces

This section provides complete details of all inputs and outputs from the control system. When separate I/O schedules are generated, these documents must be referenced in the FDS, or else, the complete schedules must be included in the FDS appendix

For digital and analog I/O, this section should provide details of voltage, current, etc., being specific where interfacing to 3rd party equipment. The signal states should be included as follows

Digital inputs – two states

False or Off

True or On

Analog inputs – detailed range

Detailed communication interfaces between systems should include protocols and formats, and also provide complete details of data to be transferred, paying special attention to 3rd party devices

 This article was written by Iian Shaya, validation,automation and control expert

אילן שעיה ilan Shaya

ולידציה – FRS – Regulatory & HMI Requirements

Posted on by אביב צברי

ולידציה – FRS – Regulatory & HMI Requirements

 This article was written by Iian Shaya, validation,automation and control expert

Regulatory Requirements

These requirements cover all the FDA specifications regarding the system compliance with the 21 CFR Part 11 definitions, and also with usual validation documentation demands

Method to provide a computerized system that complies with 21 CFR Part 11 definitions, such as the system access control by the user's managing personnel, who shall be responsible for the content of the electronic records (ERs) contained in the system

Method to restrict logical access to the system according to specified authorization levels

Method to restrict logical access to the system only to specific user ID and password

Method to provide system capability to record the values, alarms, user changes and any other events, and provide readable forms and reports of ER data

Method to allow storage of historical events, current alarms and historical alarms data records on the computerized system database

Capability of data display to the user in "view only" mode, so the user cannot alter or delete data/records

Provision of user's capability to backup data daily, weekly and monthly, according to his procedures, to ensure protection of the records and to enable their accurate and ready retrieval throughout the records retention period

Provision by the supplier of a project plan and quality assurance (QA) processes during development and the testing stages as part of his QA systems

Provision by the supplier of the following documents

Functional Requirements Specification – FRS

Functional Design Specification- FDS

IO List

Schedule of System Operation – SSO

Installation Qualification (IQ) protocol

Operation Qualification (OQ) protocol

Performance Qualification (PQ) protocol

HMI Requirements

These requirements are intended to provide the URS demands from the HMI screens, regarding proper graphic design and functionality for controlling and monitoring the system, as specified in customer's contract with the supplier. The HMI screens provided usually are of the following types

Main Screen

Synoptic screens for displaying online values and status

Parameters screens for displaying temperature, humidity and pressure parameters values

Data logging and storage of historical trends, alarms and events

Tabular screens for displaying alarms

Graphical screens for displaying trends

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – FRS Contents

Posted on by אביב צברי

ולידציה -FRS Contents

 This article was written by Iian Shaya, validation,automation and control expert

The FRS presents functional requirements for installing and operating a monitoring and control system, in response to and compliance with the user's requirements

For example, the FRS may propose to fulfill the URS requirements using a system that includes a PC with control capabilities using HMI screens, PLC, and varied environmental conditions sensors and control devices. The FRS may also propose a color-code display for ongoing environmental conditions, including indications of alarm conditions. An SMS or e-mail notification may be sent to specified personnel in case of specified alarm conditions.

The FRS requirements are organized accordingly with the same order and numbering of sections as the URS for clear correspondence. These requirements are divided into 4 categories- as the user's requirements

Installation Requirements

Operation Requirements

Regulation Requirements

HMI Requirements

Installation Requirements

These requirements cover all the issues regarding system installation to ensure its proper functionality and reliability. Examples of this type of requirements are

List and characteristics of specified hardware (HW) components capable of meeting the system functional requirements

Labeling and identification method for each HW component

List and characteristics of specified software (SW) programs installed on the system PC and the PLC, capable of performing the required operations

Definition of equipment to meet the storage capacity requirements

Definition of equipment and method for achieving the required connections to various types of sensors, communication units, temperature, humidity and pressure transmitters, illumination devices, etc

Definition of equipment and method for achieving the communication compatibility with equipment already installed at the user's facility without extra sensors

Operation Requirements

These requirements cover all the operations that the system must be capable of performing. Examples of this type of requirements are

Environmental conditions (such as pressure, temperature and humidity) to be monitored and controlled

Type of systems to be monitored and controlled, such as Heating, Ventilation and Air Conditioning (HVAC) system, types of sensors, etc

Definition of computerized system capabilities and starting conditions

Definition of system capabilities to recover from failures

List of internal tests to be performed regularly, and alarm indications to be issued in case of failure

Definition of current and historical alarms to be provided regarding all parameters in any case of deviation from the limits specified in the system

Definition of system real-time screens display capabilities

Provision of the following data and HMI displays

Synoptic screens for displaying online values and status

Data logging and storage of historical trends, events and alarms

Tabular screens for displaying events and alarms

Graphical screens for displaying trends

Display of the following information for each alarm

Status -new/acknowledged alarm

Time at which the alarm was activated

Parameter/Tag/Name of the module that activated the alarm

Alarm Description

Alarm Priority

Display of alarms to warn the user, collect alarm history, and enable the user to view current and historical alarms. The system alarms shall include

Component malfunction/failure

Irregularity in parameter reading – such as disconnection of communication lines

Parameters values exceeding the high/low parameter limits

Deviations of system operation from predefined parameters/operations

Method for providing capability to configure the graphs parameters according to

Date and time

Measured parameters

Predefined number of displayed parameters

Definition of trend graphs with maximum and minimum allowed limits of the monitored parameters

Definition of logging interval defined by the user and configured by the supplier

Method for providing capability of authorized user's personnel to define low and high limits and delay time for each

alarm parameter

On FRS regulatory & HMI Requirements you can find out in our next article

 This article was written by Iian Shaya, validation,automation and control expert

אילן שעיה מרצה Ilan Shaya

ולידציה – URS Contents

Posted on by אביב צברי

ולידציה – URS Contents

 This article was written by Iian Shaya, validation,automation and control expert

A URS usually presents the user's requirements for installing and operating a system designed to monitor and control specified conditions at its facility

:The user's requirements may be divided into 4 categories

Installation Requirements

Operation Requirements

Regulation Requirements

HMI Requirements

Installation Requirements

These requirements are intended to cover all the issues regarding system installation to ensure its proper functionality and reliability. Examples of this type of requirements are:

List of required hardware (HW) components, such as system PC, Programmable Logic Controller* (PLC), and varied environmental conditions sensors and control devices

Labeling and identification requirements for each HW component

Requirements for the software (SW) programs installed on the system PC

Storage capacity

Required connections to various types of sensors, communication units, temperature, humidity and pressure transmitters, illumination devices, etc

Communication compatibility with equipment already installed at the user's facility without extra sensors

Operation Requirements

These requirements cover all the operations that the system must be capable of performing. Examples of this type of requirements are

Environmental conditions (such as pressure, temperature and humidity) to be monitored and controlled

Type of systems to be monitored and controlled, such as Heating, Ventilation and Air Conditioning (HVAC) system, types of sensors, etc

Computerized system capabilities and starting conditions

System capabilities to recover from failures

Internal tests to be performed regularly, and alarm indications to be issued in case of failure

Provision of current and historical alarms regarding all parameters in any case of deviation from the limits specified in the system

System real-time screens display capabilities

Provision of the following data and HMI displays

Synoptic screens for displaying online values and status

Data logging and storage of historical trends, events and alarms

Tabular screens for displaying events and alarms

Graphical screens for displaying trends

Display of the following information for each alarm

Status – new/acknowledged alarm

Time at which the alarm was activated

Parameter/Tag/Name of the module that activated the alarm

Alarm Description

Alarm Priority

Display of alarms to warn the user, collect alarm history, and enable the user to view current and historical alarms. The system alarms shall include

Component malfunction/failure

Irregularity in parameter reading – such as disconnection of communication lines

Parameters values exceeding the high/low parameter limits

Deviations of system operation from predefined parameters/operations

Capability of configuring the graphs parameters according to

Date and time

Measured parameters

Predefined number of displayed parameters

Trend graphs with maximum and minimum allowed limits of the monitored parameters

Logging interval defined by the user and configured by the supplier

Capability of authorized user's personnel to define low and high limits and delay time for each alarm parameter

  .On URS regulatory & HMI Requirements you can find out in our this link: URS – Regulatory & HMI Requirements

*Here are some examples of the PLCs used by smartlogic: 6XV1830-0EH10, 6ES7131-4BF00-0AA0,6ES7193-4CA40-0AA0,6ES7134-4GD00-0AB0,6ES7193-4CA40-0AA0, 6ES7138-4CA01-0AA0,6ES7193-4CC20-0AA0, 6ES7590-1AB60-0AA0, 6ES7511-1AK00-0AB0, 6ES7954-8LP01-0AA0,6ES7155-6AU00-0BN0

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – URS and FRS Preparation Overview

Posted on by אביב צברי

ולידציה – URS and FRS Preparation Overview

 This article was written by Iian Shaya, validation,automation and control expert

User Requirements Specification (URS) and Functional Requirements Specification (FRS) are the first and starting points of a validation process and a validation documentation file

  – The validation process must comply with regulations issued by the United States Food and Drug Administration FDA

:The FDA regulations that are most relevant to the validation process are

Good Manufacturing Practice  – GMP.

Current Good Manufacturing Practice – cGMP

Good Automated Manufacturing Practice – GAMP

The validation process includes design, installation and operation of a monitoring and control system for a production facility, as well as planning and execution of test procedures, to verify that a monitoring and control system meets the FDA standards

Validation documentation is part of the validation process that includes written and/or electronic records regarding the installation and operation of the monitoring and control system, and the corresponding test procedures for this system

Electronic records are often required to fulfill regulations set by the FDA. These regulations regard the scope and application of Part 11 of Title 21 of the Code of Federal Regulations; Electronic Records; Electronic Signatures (21 CFR Part 11). Electronic Records may contain any combination of text, graphics, audio, pictures, or other information represented in electronic form, which are created, modified, maintained, archived, retrieved or distributed by a computer system

Electronic Signatures may contain computer data compilation of any symbol or series of symbols executed, adopted or authorized by an individual to be legally binding equivalent of the individual's handwritten signature

Electronic records and signatures are generally used in Closed Systems, in which the system access is controlled by personnel responsible for the contents of the system electronic records

The responsibility for writing and approving the URS and FRS is shared in practice by the user, who operates the production facility, and the supplier or vendor, who provides the monitoring and control system for ensuring the proper operation of the production facility. Usually, the URS is written by the user and the FRS by the supplier

:Note

The final contents of the URS and FRS are tailored according to the type and size of the system under validation. Since the URS and FRS regarded herein are generic, they include requirements that may not be necessary in small or simple systems

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – DQ – Design Review

Posted on by אביב צברי

 ולידציה – DQ – Design Qualification / Design Review

DQ  – Design Qualification is for Design Review by verifying that the system has been designed as specified in the URS (User Requirements Specification), FDS (Functional Design Specification), and relevant equipment specifications satisfying all GMP requirements. The Process User Requirements in the URS have been identified by the Quality Risk Assessment. Since the Quality Risk Assessment is an iterative process, it may be performed again, whenever necessary, during the DQ and subsequent lifecycle qualifications.  For  hardware and software of the control system, verification data will be collected to prove that the system has been designed in accordance with the URS and FDS including the requirements of 21 CFR Part 11. As DQ is the final step to formally review and document the proper design of the system, the protocol must enable the reviewers to verify that all quality-critical attributes and essential technical attributes of the system have been incorporated in the design. When the DQ report is approved, the system is ready for fabrication and construction.

DQ PROTOCOLS
PROCESS EQUIPMENT AND SYSTEMS
Media Preparation and Hold Tanks
Buffer Preparation and Hold Tanks
Process Tanks
Reactors – Organic Synthesis
Bioreactors
Evaporator Systems
Distillation Tower Systems

CLEAN UTILITY SYSTEMS
USP Purified Water Storage and Distribution Systems
WFI Storage and Distribution Systems
Clean Steam Generation and Distribution Systems
Process Air Systems
Nitrogen Gas Systems

SUPPORT SYSTEMS
CIP Systems
Biowaste Kill Systems – Continuous
Biowaste Kill Systems – Batch
Autoclaves

HVAC SYSTEMS AND CLEANROOMS
HVAC Systems
Cleanrooms – Aseptic
Air Locks – Gowning

LABORATORY EQUIPMENT
Incubators
CO2 Incubators
Water Bath Incubators
Ultra-Low Temperature Freezers
Refrigerators

ולידציה – FRS for Compliance with 21 CFR Part 11

Posted on by אביב צברי

Functional Requirements Specification -FRS Regarding Requirements for Compliance with 21 CFR Part 11

This FRS presents SmarLogic's functional requirements in response to the User Requirements Specification (URS) . These functional requirements should be met in order to ensure  Control and Monitoring System complies with 21 CFR Part 11.

This FRS must be considered for the system design, build, installation, operation and testing requirements, and for traceability purposes along the product life cycle up to the Operational Qualification (OQ) stage.

                              Responsibility

The Validation Engineer is responsible for writing this protocol. The Control, Automation & Validation Engineer is responsible for ensuring the preparation and approval of this protocol.

The Control Engineer, Division Process Engineer and QA Manager are responsible of approving this document before development and on-site implementations.

The following sections list the functional requirements determined by the relevant groups of the system upgrading. Each functional requirement number is followed by the corresponding user requirement paragraph number for design qualification purpose

                            Glossary

ER – Electronic Record

DB – Database

FRS – functional requirements Specification

HMI – Human/Machine Interface

HSP – High Set-Point

HW – Hardware

IQ –  Installation Qualification

LSP –  Low Set-Point

OQ – Operational Qualification

OS – Operating System

PLC ָָ*- Programmable Logic Controller

QA – Quality Assurance

SCR – Screen

SOP – Standard Operating Procedures

SP – Set-Point

SSO – Schedule of System Operation

SW – Software

TP – Test Point

URS – User Requirements Specification

Requirements for Meeting 21 CFR Part 11

                        Top-Level Requirements

This section covers the proposed solutions for meeting 21 CFR Part 11 presented in the URS for a new WinCC HMI System. This system must allow the :following five main functionalities

Ensure the system integrity

Control the access to the system by logical security

Audit events that create and modify electronic records

Apply electronic signatures to the system

Backup and archive data to ensure record integrity in case of failure

                      Detailed Requirements

This section describes SmartLogic's solutions that will meet the detailed requirements listed in the URS. These requirements are divided into 6 categories for the sake of clarity:

Electronic Records

Security

Audit Trail

Archive

Backup

* Here are some examples of the PLCs used by smartlogic: 6XV1830-0EH10, 6ES7131-4BF00-0AA0,6ES7193-4CA40-0AA0,6ES7134-4GD00-0AB0,6ES7193-4CA40-0AA0, 6ES7138-4CA01-0AA0,6ES7193-4CC20-0AA0, 6ES7590-1AB60-0AA0, 6ES7511-1AK00-0AB0, 6ES7954-8LP01-0AA0,6ES7155-6AU00-0BN0