In previous article we covered details of design of a monitoring system. Especially current regulations, standards and helpful referances were captured in that article. This sequent article will cover monitoring system installation following with validation steps as per ISPE GAMP5.

About GAMP5…

GAMP is an acronym for Good Automated Manufacturing Practice, for a risk-based approach to computer system validation. Volume 5 publised in 2008 by ISPE (International Society of Pharmaceutical Engineers) task team, Subject Matter Experts from field and steering committees from various countries. There are categorization assists in selecting appropriate life cycle activities and documentation from category 1 “infrastructure software” up to Category 5 “custom applications. Categorizing the system helps guide the efficient writing of system documentation (including specifications and test scripts and everything in between). Below table gives more details about categories and intended use.

When coupled with risk assessment and supplier assessment, categorization can be part of an effective quality risk management approach. The categories are useful when applied in conjunction with other risk management tools, and with consideration of complexity and size of system. As per categorization, complexity and risk increased as ;

2 approaches here are quite critical; risk-based & life cycle approach. It is not because they are fasion now in entire Cleanroom industries, but really serves for right system design and implementation

What is Life Cycle Approach?

Since the entire system is living as a concept, many parameter changes, evaluates and/or requirements are changing as system lives. Thats why there is no straight line like A to Z for computerized system validation. Life cycle approach is also described in GAMP5 as shown in Figure 1.

Figure 1 Life Cycle Approach

The life cycle for any system consists of four major phases;

Concept,

Project,

Operation,

Retirement.

As per GAMP5, suppliers of products and services should be involved as appropriate throughout the life cycle. It may be appropriate to delegate many of the described activities to suppliers, subject to satisfactory supplier assessment and control measures.

What is Risk-based Approach?

Appropriate risk management processes should be followed throughout the life cycle in order to manage identified risks and to determine the rigor and extent of the activities required at each phase of the life cycle.

Figure 2 shows the typical use of risk-based desicion making throughout the life cycle.

Figure 2 Risk based approach to Life Cycle

When we are talking about monitoring system softwares, they are all configures systems (category 4) and even custom (category 5) platforms due to complex structures with data modules, PLC’s with custom ladder logics and custom custom firmwares to meet specific requirements from customer.  To be able to apply proper GAMP5 requirements, risk based approach for custom application should be maintained. There are 2 stages here; Initial risk assessment even before forming User Requirement Specification and Fonctional Risk Assessment at the stages of specification (functional, design,module specifications).

For Initial Risk Assessment, Consider following points;

• What are the overall risks to the business?
• System GxP determination,
• What is the overall impact of the system?
• Are more detailed risk assessments required?

For Functional Risk Assessment, identify and define following points;

• Idientify risks to specific processes,
• Identify risks to specific functions,
• Define controls and reduce risk,
• Iterate these step sif necessary

As you can see in Figure 2, project phase covers several activities from planning to reporting. This specification steps on the right side meets verification steps on the right which is called GAMP5 V Scheme.

GAMP5 V Scheme

Figure 3 - GAMP5 General V Scheme

GAMP V scheme simply summarizes all specification and testing activities. Figure 2 shows specification steps on right side and testing/qualification/verification steps on the right side. Each levels on right side also verifies  same level specification steps on the left.

               Figure 3 summarizes steps for online monitoring systems as category 5; custom application from validation planning till validation reporting.

Figure 4 : GAMP5 V Scheme Approach for a custom application (Category 5)

As you can see, from category 1 to category 5, most critical step is the first step; User Requirement Specification. Without proper user requirement specifications defined by customer’s mutli diciplinary steering committee, online monitoring system installation and validation will be limited by the suppliers knowledge, effectiveness of their QMS,  product capacity and project management abilities. Most of the applications on viable and non-viable monitoring systems are limited and not completely satisfy needs due to lack of proper User Requirement Specification

User Requirement Specification

To get proper results, as regulated company, make sure you are executing your own User Requirement Specification with several poeple from different operations such as quality, production, engineering etc. There are template URS’s available in the market, especially suppliers are offering “free” services for URS’s and unfortunately, some end users are tend to internalize such “one size fits all” URS templates.  Even there are certian parameters that are same for many end users such as limits that are defined regulations and/or standards, still there are many aspects that should be considered by end user to achieve targets as planned. However, User Requirement Questionery forms can be helpful to identify Technical aspects, summarize expectations and fill the gap between product’s technical capabilities and their intended use.

Be SMART!

While defining your requirements;

Make sure your are S.M.A.R.T enough being;

• Speicific,
• Measurable,
• Achievable,
• Realistic,
• Testable

Specific enough for testing and checking;

• Unambiguous,
• Clear,
• Precise,
• Self-contained

Pritorized with emphasis on identifying the rwquirements such as;

• Mandatory (High)
• Beneficial (Medium)
• Nice to have (low)

Requirements should be analyzed to ensure that they are fully defined anda re verifiable and objective. For example saying “room shall be controlled at 20˚C” is incomplete requirement. However, “room shall be controlled at 20˚C ±2˚C. Excursions of no greater than 7 ˚C are permitted for < 10 minutes” is a nice example of complete, measureable and objective requirement. 

Functional Specification

Functional Specification (FS) defines a system to meet the user needs as described in User Requirement Specifications. FS should be lean enough to enable design proceed without frequent consultation with the author. Using diagrams and graphics where appropriate can help both parties to understand specifications easily. 

Contents of the document will be;

Introduction : ownership, producer, authority and relationship with other documents such as URS.

Overview : Background, refernace to GxP regulations, impacts (product, patient, quality etc.), main interfaces between the system and other systems and/or the environment. Non-conformance with URS if any.

Functions : The objective of the function or facility, an the details of its use, including interface with other parts of the system should be addressed. Tracibility to specific requirements in the URS should also be addressed here.

Data :  Allowed range of values for all inputs and outputs, data relationship, capacity, integrity, security, migration.

Interfaces ; All interfaces such as server, pc, kewboard, displays, modules, sensors, controllers etc. Should be described, defined and explained here.

 Non-functional attributes ; Additional functions that system will met should be described under this chapter (availablilty, maintainability etc.)

Glossary

Appendices

Figure 5 – Proper labeling with location, cable ID, device ID and serial number

Configuration Specification

Configuration and design specifications provide a detailed, Technical expansion of FS. This part explains how the system will do what is defined in the FS.  Both hardware and software design specifications are captured under this document. Configuration Specification should be provided for configured products and cover the appropriate configuration of the software products that comprise the system to meet specified requirements.

Contents of the document will be;

Introduction : ownership, producer, authority and relationship with other documents such as URS and FS.

Overview : Should briefly describe the configuration and/or design as defined in the document. May cover complete system, hardware, and/or software. Overwiev may be illustrated using diagrams.

Configuration : Required configuration settings and parameters, reasons for settings, tools or methods that will be used to set the required options.Module or systems status, security of settings etc.

Hardware Design ; The computer system, cable & connector specs, drawing, network and other external connections, diagrams (location, layout, wiring, piping, vacuum infrastructure, power cabling, enviromental parameters, electrical supplies etc).

Software Design : SW description, system data, module description, user levels etc.

 Glossory

After finishing left side of our GAMP5 V Scheme; specification, now we can built and instal our online monitoring system as requested in User Requirement Specification which we addressed and fulfilled in Functional Specification which later described in detail in our Configuration Specification. Following article will cover verification; right side of our V Scheme, as well as system maintenance.