GSC Engineering, Inc.

Specialists in inter-disciplinary engineering design and troubleshooting

INTERDISCIPLINARY TROUBLESHOOTING

"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.

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 happening.

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
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.

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.

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 software runs.

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 plans.