As shop-floor automation and enterprise-level ERP vendors increase their capabilities and services, the traditional middle layer of drug manufacturers’ IT architecture (stand-alone MES, CAPA, etc.) is disappearing. A natural outgrowth of this trend is a struggle between engineering and IT professionals as to who has rightful control of critical drug manufacturing data. Who should own which data, and how is it possible to get engineers and IT professionals on the same page? We speak with Jim Macdonell, VP of Patni Life Sciences.
PhM: What is the general state of data management within drug manufacturing? What is happening out there in the factories?
J.M.: As a regulated industry, the general state of data management in the pharmaceutical production facilities is that the data are well secured, reasonably well archived and generally very, very accurate. However, the accessibility and capability to merge data and generate consolidated reports are still lacking. With this also comes risk of errors and possible noncompliance.
The generation of consolidated reports for tasks such as corrective action and preventive action (CAPA), electronic batch records (EBR) and device history records (DHR) has been addressed during the last two generations of shop-floor systems. But the issues were addressed mostly within individual systems. Consolidated reports from distributed control systems (DCS), programmable logic controllers (PLC), supervisory control and data acquisitions systems (SCADA), statistical process control (SPC), or human machine interface (HMI) systems can now be generated across process units and can also include environment data necessary for product release. Similarly, the laboratory information management systems can generate consolidated reports for the lineage of a product from raw material testing through manufacturing and final product testing. Again, the consolidated reporting necessary from laboratory analysis is available.
However, the consolidation of data across systems still remains an area that poses risks and opportunities for improvement. The data from the systems listed above must also be consolidated with data from ERP, training systems, execution systems, and in many cases supplier data systems. Additionally, for reports that need consolidation across longer time horizons—such as annual product reviews or reports required for product recalls or quarantining products—pose even greater difficulty. The days of Excel sheets and Access databases, with their security and compliance requirements, still exist. It is in this manual data merging, calculations and reporting that the risk of noncompliance becomes a concern. Control systems, laboratory systems, ERP, training systems, etc. were most likely implemented under a controlled software development lifecycle, validated appropriately, and operated under proper regulated change control processes. Yet now, the data these processes were designed to protect are handled in a manual environment. These data and these manual processes are regulated and must also be validated and controlled.
PhM: Why is the question of “Who owns your data?” becoming more critical?
J.M.: The question is becoming more critical because the opportunities for improvement are available. Addressing how to consolidate data across systems will not just close the consolidation gaps, it will also improve the accuracy of the reports, reduce the turnaround time (and accrue the associated supply chain and patient benefits) and reduce costs. Processes for consolidation extend across the traditional boundaries among IT, engineering systems and also laboratory informatics systems.
Tools to achieve these benefits have been available for several years, but they often involved implementing a middleware layer designed for integration, implementing new applications to manage the various shop floor data sources, or even implementing an extensive inventory of application-to-application interfaces, all of which must be built, validated, maintained and updated.
Some life science companies are adopting one of two different strategies. These companies are solving this shop-floor integration by either: 1) expanding the best of their strategic applications (ERP, control system or MES) as the environment for integration; or 2) beginning to adopt portals, business intelligence tools and data warehouse technology to consolidate data and generate the required reports.
PhM: Do you sense that IT and Engineering at most drug companies are not on the same page, and may even be combative in some instances?
J.M.: They may not be on the same page, but they are singing from the same hymnal. They are certainly not combative.
IT and Engineering work in different environments, different technologies, different applications and different time horizons. Real time for the engineering teams is certainly a far smaller horizon than real time for enterprise IT organizations. Additionally, we cannot neglect the engineers’ and IT professionals’ associates in the laboratories. The laboratory technologies and data management needs offer yet another environment to address.
Therefore, even though the environments force these organizations to be on a “different page,” these teams are all governed by regulations that demand methodical, documented, controlled, and validated systems. Each team may have its own policies and procedures, but they are not at odds, nor are they combative.
The primary opportunity is to join these diverse teams and technologies into a unified, cohesive systems strategy. We now have the opportunity to execute such a unified systems strategy. Not a supply chain systems strategy, or a control strategy, or a laboratory informatics strategy, or a standardized HMI or SPC tool—but a single strategy that defines how these functions will work together.