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.
PhM: But there has been a traditional disconnect between IT and Engineering. Where does that come from?
J.M.: The traditional disconnect comes from the classic separation of functions, the vendor provided applications and the fact that technology was developed for the primary focus—process control, testing and bench analytics, statistical analysis, inventory management, purchasing, etc. Now platforms (operating systems, networks, databases, report generating tools, browsers, portals, etc.) have become more common than unique. Not so long ago each environment had its own platform, or more precisely each had its own set of platforms, designed and optimized for the primary focus.
Now when control engineers, IT architects, business analysts and laboratory informatics professionals come together they are coming from a common technology platform. The traditional disconnect is now bridged by a common technology toolset on which to base their unified systems strategy.
PhM: In your view, where do drug manufacturers compromise data integrity?
J.M.: As stated earlier, data integrity and security are very high in the pharmaceutical industry, primarily from the good development practices and good IT operation practices that have been implanted by diligent professionals. Certainly, the governing regulations—GLP, GMP, GLP, HIPAA and more recently SOX—have formalized and institutionalized these practices.
The place where the risk to data integrity creeps in is, as I stated, when manual reporting, consolidation and merging of data need to be performed. We still have highly-professional, well-intended, regulatory-governed analysts and engineers, but they are, in this case, working in a more open, manual data handling environment. This poses a higher degree of uncertainty and occasion for data integrity compromises than in an ITIL-governed suite of regulated applications.
Please, let me be clear. These applications must also be validated, 21 CFR Part 11 compliant, and under change control and proper application management. The nature of these environments, however, clearly poses more risk of compliance gaps.
PhM: What data programs and platforms are the most uncertain and contentious in terms of who should oversee them, have ownership and assure compliance?
J.M.: Most Life Science companies have well-established computer systems validation and operation SOPs (ITIL, for instance). There is a heritage of regulatory compliance, and it is now becoming part of their DNA. Typically, QA or IT QA drives these programs. They are often driven through the IT organization or through central engineering. The governance at some companies begins to become less comprehensive on systems that are not directly under IT development or operations procedures and on systems that were implemented prior to the adoption of the company’s current methodologies. The other areas that sometimes lack sufficient QA/CSV governance, and resultantly have greater risk, are the embedded computer systems in advanced analytical instruments and automated production equipment. These are computer systems just as the servers in the data centers are computer systems and must be validated and controlled.
So, if I were to advise where to check for risk and potential compliance gaps, I would say check the validation documentation for:
- systems that were implemented prior to enactment of current company CSV SOPs;
- analytical instrumentation;
- automated production equipment, inline analyzers and HVAC controllers; and
- systems developed by individuals or work groups that are used in regulated functions.
PhM: How do manufacturers move towards a more integrated approach?
J.M.: In an ideal world, a unified system strategy and the documented development, operations, compliance audit procedures would be in place. It might never get to common procedures but certainly common strategies and policies are beginning to emerge. It is best to consider this in two dimensions: 1) the unified systems strategy, and 2) the assurance of data integrity and compliance.
To drive the unified systems strategy, you need to address:
a) which are the company’s strategic systems (ERP, MES, CAPA/QMS or Control Systems) that will be global and are the preferred environment into which you map new functionality;
b) which business functions are not properly supported, underserved or supported by obsolete systems;
c) which of these functions can be mapped into your strategic systems;
d) how do new tools (e.g. portals, data warehouses, business intelligence tools, etc.) help you drive this strategy; and
e) who are your internal champions and vendor/partner champions that can help you drive this strategy.
To establish a higher assurance of data integrity and compliance:
a) create an environment where lack of compliance is absolutely forbidden and quality failures are investigated, corrected, and future occurrences are prevented;
b) establish portals or forums where practices or issues can be shared, best practices developed and continuous improvement can be instituted;
c) have proven champions train and coach emerging champions; then take on the rest of the organization;
d) investigate the systems listed above where data integrity or compliance gaps may be first evident;
e) institute a quality management system (QMS) that includes the organization, processes and technology – not just a CAPA application that gets attention when audits are scheduled;
f) assure there is real-time executive awareness of quality status and resolution of non-conformances (a perfect BI opportunity); and
g) set an expectation and appreciation for the mature users who raise data integrity and compliance issues to IT or QA and are proactive in their responsibilities – not just audit ready.
PhM: What role should IT and equipment vendors play, and do they recognize this obligation?
J.M.: Most IT, control system, equipment vendors and analytical instrument vendors want to be able to sell to the life sciences industries and want to be recognized as offering technologies that can be validated. The level of success varies. Those that serve life sciences companies as their primary set of clients are most mature and most capable of achieving this goal. Most major vendors who serve multiple industries are also well prepared and after a few implementations in life sciences, understand the requirements. They enhance their development, testing, documentation and support processes to the life sciences industry’s expectations and regulatory requirements. Obviously, the technology must meet minimum standards and regulations (audit trails, e-signatures, e-records, etc.) before the vendor can even approach the life sciences industries.
Most importantly, the technology is only as good as the environment into which it is implemented and operated. Only the manufacturer can validate a system for the purpose for which it is intended. The vendor must build the system components properly and be audited by the life science company. But again, only the life science company can validate the system.
PhM: Can you share any success stories where there is a seamless integration regarding data ownership?
J.M.: There are many successes that we see and in some cases are helping to implement. The one trait I see in common is that companies are addressing or solving shop floor application areas one or two at a time. They are solving them as I said above by mapping unserved or underserved functions into their strategic applications—applications that the company views as global and in which they are willing to invest. Examples include:
- Incorporating electronic batch record and shop floor scheduling into a common control system technology;
- Incorporating CAPA functions into the ERP system;
- Incorporating MES functions into the ERP system;
- Utilizing data warehouse and business intelligence (BI) tools for annual product reviews;
- Mapping customer complaints and CAPA into a seamless solution in the ERP system; and
- Utilizing electronic laboratory notebooks with control systems or ERP systems to establish a real-time laboratory instrument environment.
Other examples are available. The first step is to envision a unified strategy and then to take the vision to the champions that will embrace the challenge, move past the traditional barriers, and achieve the benefits of the strategy. The original promise and ROI of each laboratory, IT or control system, are then achieved and maximized as this unified strategy is realized.
