What’s IT got to do with it? Rethinking the IT/QA Equation in Life Sciences
Author: Sanjiv Shah, Head, Global Life Sciences Practice, Intelligroup
This past week a giant drug maker expanded the recall of their blockbuster cholesterol reduction medication bottles due to a musty odor in the bottles, bringing the total number of recalled bottles to more than 360,000. In the same week, another giant drug maker agreed to pay a $750 million fine for quality related violations at one of their plants that resulted in contaminated and mislabeled product entering the supply chain.
Causes for these failures and for many other similar product quality and patient safety related issues are traceable to practices inconsistent with current Good Manufacturing Practices (cGMP) at factories operated by the companies themselves or by their suppliers upstream and downstream from their own plants. So what does IT have to do with it? Plenty, and if IT did not have anything to do with, it ought to.
A key player in the IT landscape of Life Sciences companies that manages the planning and execution of product creation are Enterprise Resource Planning (ERP) systems. The typical approach that IT has as far as whether the system comes under FDA purview and hence subject to quality regulations, is to divide functionality into GMP relevant and non-GMP relevant streams, and apply normal SDLC quality process to both streams, but have more stringent quality norms for the functions that are GMP relevant. Given the added effort required for compliance, IT typically goes to great lengths to keep the GMP relevant list as short as possible arguing that the impact on the end product quality or patient safety is remote. Given the consistency and power that such systems have to positively impact product quality this approach needs to be reversed. IT needs to look at expanding and deepening the list of GMP relevant functions by actively seeking out opportunities to support Good Manufacturing Processes.
Example: take a typical plant level operation of moving an active ingredient from Location A to Location B. QA would typically prevail over IT (not without an argument) that the feature/module that tracks such a move needs to be included in the GMP relevant list and therefore be formally tested and documented, and that would be that. The new, proactive approach would have IT asking several more questions to see how it can support GMP, with the answers resulting in a deepening of the associated features: Is the operator performing the move qualified and trained in the relevant operation? Can the system do a live query of say the system that stores training information to verify that the operator is current on reading the relevant, latest SOPs? Was the duration of the material’s storage in Location A within prescribed limits (say for temperature or light sensitive ingredients)? What flags can be raised now rather than at final product inspection time to initiate corrective action if needed? What pre-configured rules or controls can the system check to ensure that the destination Location B is an acceptable storage location? You get the drift.
Is it time for IT in Life Sciences companies to become an active partner in assuring product quality? Are the higher costs and potentially longer production cycle times worth it? Would a proactive collaboration between IT and QA have prevented the musty odor in the recalled bottles or the presence of micro-organisms in antibacterial baby skin ointment and the $750M fine? Can you come up with examples of where IT could have helped to reduce the possibility of or even to prevent the failures? So much like Homeland Security that does not get noticed because when what they do works brilliantly, nothing (bad) happens, can IT become that unsung hero for QA?
Note: Comments will be posted after approved by the author.
Tags: Life Sciences
Excellent point. IT Program/Project leadership must learn the importance of “testing the request.” Prudent practioners of AGILE Project Management recognize how important it is to include QA during the requirements process of the SDLC. Said another way Business Analysts and QA Engineer should collaborate during the requirements gathering and writing to insure all requirements have a valid test case. Afterall, that is one of the gotchas with “waterfall” SDLC. To refresh ones memory, QA is the recipient of specifications after the fact. There can be no proactive collaboration.
@DrFrank, yes IT can help Software Quality Assurance as well as *Product* (pharmaceuticals, medical device etc) Quality Assurance by being proactive and collaborative rather than the typical almost adversarial relationship that predominates.