- Pharmaceutical Labs
- Manufacturing & Fill Lines
- LIMS Systems
- HPLC Systems
- Electrophoresis Systems
- Pilot Plant Construction
- Scale-up Problems
- Soil & Concrete Labs
"Solving the problems that fall into the cracks between disciplines"
GSC Engineering handles the problems that occur outside the pipes and vessels.
This includes new plant construction, laboratory issues, or process scale-up (from bench to pilot plant to full-scale manufacturing).
The Problem with Systems involving Multiple Disciplines
Many problems fall into the cracks between disciplines. In scientific terms this is a kind of ‘boundary condition’ problem. Most disciplines handle the middle of their fields well. It is like a curve fit that works well in the middle of the data but not as well near the extremes.
This is NOT SUGGESTING ANY LACK OF SKILL IN THE DISCIPLINE SPECIFIC EXPERTS. Often, the more capable the expert, the more focused he or she is in optimizing their discipline. Optimizing one discipline can inadvertently de-optimize another discipline.
INTERDISCIPLINARY DESIGN AND TROUBLESHOOTING IS A SPECIALITY IN ITS OWN RIGHT - like a physician who is a 'diagnostician' and identifies obscure problems, or a pharmacologist specializing in drug interactions.
The interdisciplinary problem is the one usually missed during testing.
Interdisciplinary versus Multidisciplinary
Many firms provide staff from multiple disciplines. Typically these specialists are each focused on a single discipline.
Interdisciplinary specialists are focused on the "no man’s land" between disciplines.
Troubleshooting versus Forensic Investigation
Both use similar techniques, and GSC will conduct forensic investigations.
"Forensics" is focused on what went wrong, and who is responsible - usually to support claims or litigation - often leading to ‘expert witness’ testimony. Note that if you anticipate actual litigation and testimony, the expert should normally be engaged by your attorney to establish "attorney-client privilege".
"Troubleshooting" is focused on designing and implementing a fix to the problem.
Interface Design versus Standards
Interface design and integration engineering can be another type of interdisciplinary problem. An interface must perform useful work under operational conditions.
Interfaces can be 100% compliant with standards and partially, or even totally, fail to function. One classic was the famous phrase "RS-232 compatible". In practice more than 90% of these were custom interfaces, the RS-232 compatibility just meant there were no flames and smoke when they were connected.
Today’s proliferation of standards, and the assumption that devices can be treated as ‘black boxes’, introduces new interdisciplinary interface issues.
How GSC can help you:
GSC brings years of experience coming at these problems from different directions.
Your existing staff may not have time available for the detailed investigations needed.
If it is not working right, GSC can help.
||Return to Top
PROTECTING GOOD SCIENCE FROM POOR AUTOMATION
Today, if you are doing anything related to biotechnology, then,
for better or worse, you are probably using computers. All too often
poor automation ruins good science. GSC helps keep that from
Whether you are conducting biotech research, developing a new product,
or constructing a new manufacturing plant, computers and/or other
automation are almost certainly involved. If the science is not
working, then adding a computer, or a fancy graphic user interface,
or web interface, won't solve the problem. The wrong technology
can create a problem where one didn't exist.
All Problems are "Physics"
Problems may appear as mathematical, mechanical, electrical, thermodynamic,
or chemical; ultimately physics is the issue. A robust solution
for any requirement or problem requires an architectural design
that deals with the physics. Voting on a list of requirements won't
make it work.
The automation system must be designed for the problem at hand,
because the problem won't adapt to the computer.
Integration into the final environment can't be neglected. New problems
arise. No matter how many approval votes or signoffs were done at
the factory, nature is casting another vote in the field. GSC
first understands the physics of your system, then looks for the
automation that will support the system. Sometimes GSC can
suggest changes that will facilitate automation or improve reliability.
Why Use a Professional Engineer
Engineers are scientists in clinical practice, trained to make the
practical decisions needed to implement a solution now - not necessarily
the perfect solution, but a practical solution, and perhaps equally
important a timely and cost-effective solution. Licensed Registered
Professional Engineers are trained to build solutions that won't
come back to haunt you as a liability.
Validation (e.g., GLP, GMP) and code compliance (building,
fire, etc.) must be considered - a system must be designed and documented
to facilitate validation and to survive an audit or inspection.
GSC can help.
Connecting biotechnology and automation since 1982.
||Return to Top
RISK-BASED VALIDATION PARADIGM
The FDA’s initiative
Pharmaceutical Quality for the 21st Century - A Risk Based Approach
introduced in 2002 is driving the biotech/pharma industry to a
new risk-based validation paradigm.
The challenge is to provide a "science-based" and "risk-based" approach to testing.
It is not just that "risk" is considered. The testing should also be based on the science" of the process, and testing should "challenge" the scientific design assumptions.
The "risk-based" approach maximizes risk mitigation for patients. Thus it might either minimize a risk or mitigate it.
One of the goals is the elimination of unnecessary IQ, OQ, and PQ deviations. Many of these are just "paper chases". If a deviation does not actually lead to a change in the system (or perhaps in documentation or training), then it hasn’t done anything to improve the system or reduce patient risk. In one sense this test is a waste because the patient outcome will be the same even if the test was never performed. If nothing is changed, the outcome is the same whether there is one sentence or 50 pages of deviation documentation. The goal then should be to quickly determine whether a change is required. If not, then quickly move on.
"Science-based" testing implies having an understanding of the internal characteristics of a system. The ‘black box’ must be ‘opened’ (either by the vendor’s tests or by user tests).
Control Systems theory spent much of the first half of the 20th Century learning that complex technology can not be successfully employed without understanding the internal characteristics of the 'black box' (technology perfected by the MIT Servomechanisms Laboratory and the NDRC during World War II).
Duplicate testing (e.g., repeating the same tests at the vendor and user sites) is not more or better testing - just duplication. Of course some tests (e.g., Installation Qualifications) may legitimately need to be repeated for each item or site (because an installation mistake can occur after 999 successful installations).Arbitrary testing (without a scientific basis for the tests conducted) will probably no longer be accepted as valid best practice.
Once upon a time, "alchemy" was considered to be real science and ‘magic spells’ were a valid lab technique. The witches in Macbeth were perhaps doing primitive biochemistry.
"Science-Based" testing requires the use of meaningful tests developed by, and with results evaluated by, subject matter experts. Otherwise the testing has little more scientific validity than the use of ‘magic spells’. Traditional validation has worked fairly well because dedicated, experienced, knowledgeable people have implicitly built good tests into their protocols. Often this has been in spite of, rather than a result of, the validation methodology.
As systems become more complex, industry can’t rely on this implicit coverage to catch everything.
The new "science-based" and "risk-based" approaches are necessary to reduce costs and maintain quality.
This new approach is described in
- ASTM E2500-07 Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment
- ISPE GAMP(r) 5: A Risk-Based Approach to Compliant GxP Computerized Systems
However, it has been a feature of traditional/conventional engineering
(e.g., civil, structural, mechanical, electrical) development for decades.
GSC has been including "Design for Verification/Validation" in its
biotech/pharma products and projects since the 1980's.
Forensic products have included concepts that anticipate legal challenges
during courtroom cross-examination.
Let GSC help you transition to this new validation paradigm on your next project.
||Return to Top
TRADITIONAL VALIDATION PARADIGM
Traditional validation is not dead.
These steps still have a useful/necessary place.
However they are not alone sufficient for a modern risk-based approach.
There are many kinds (and names) of plans, tests, and scripts.
There is no 'one approach fits all' road to success. Plans must
be tailored to the project: custom or off-the-shelf, hardware
versus software mix, in-house or purchased, single versus multiple
sites, degree of risk, etcetera.
A partial list of possible tests follows. Not every test applies
in every case.
Unit Test (UT) - Typically for software; also for hardware
components. Tests a single module over a range of conditions,
often greater than those expected in practice.
Integration Test (IT) - Typically for software. Tests
whether the program works as a whole. Much like an OQ (see below).
Alpha (Systems) Test - A development test of a complete
system in the hands of 'users', frequently used to test the logic
and/or completeness of requirements.
Beta (Field) Test - An uncontrolled test in the hands
of real users. This is also a type of development test.
Installation Qualification (IQ) Test - Ensures the 'parts'
are installed correctly. Critical for hardware, people have died
from incorrect wiring or plumbing. Commonly applied to network
cabling. Increasingly important for software due to interaction
between custom, commercial, and system software,
Operational Qualification (OQ) Test - This ensures that
the 'parts' work together and the system will operate over the
full range of conditions. This is often the basic test of whether
Performance Qualification (PQ) Test - This ensures the
system meets requirements under actual operating conditions. Often
this is the same as an 'end-to-end' test.
Ideally a system is designed from the beginning to avoid potential
problems. GSC can help you achieve this goal.
Validation (e.g., GLP, GMP, 21CFR11) must still be considered.
GSC can help you with this.
GSC develops complete system plans, not just software
||Return to Top
GSC ENGINEERING, INC.TM - 298 Prospect Street - P.O. Box 269 - Stoughton,
MA 02072-0269 - voice: (781) 344-0087 - fax (781) 344-2012
Click here to send email to GSC