Lifecycle Engineering

Intrinsic Safety is a protection technique for safe operation of electronic equipment in hazardous atmospheres. The underlying principle is to ensure that the available electrical and thermal energy in the system is always low enough that ignition of such hazardous atmosphere cannot occur. Note that no single component or circuit is intrinsically safe of itself, but only in the context of an overall and properly designed Intrinsic Safety system.

Within life sciences, similar concepts can be deployed:

Intrinsic Quality is a protection technique for quality operation of manufacturing equipment in GMP environments. The underlying principle is to ensure that hazard thresholds within the system are always low enough that the @risk product or specification cannot be compromised. Note that no single component or ‘circuit’ can be said to exhibit intrinsic quality of itself, but only in the context of an overall and properly designed Intrinsic Quality system.
 

The design of the ‘Biopharma Quality Engineering Data Management’ program in the Avenio engine facilitates the portrayal of plant processes in producing safe, pure and efficacious products. The process streams are supported by plant, facilities and systems whose attributes are all individually risk assessed by virtue of their inclusion based on the principles highlighted in ASTM E2500. However this does not in itself guarantee a low risk process as process steps in themselves are interlinked, often interdependent and subject to both individual and collective risk.

As an example a bioreactor as an entity may be designed and engineered to function in accordance with its associated specifications but may be operated incorrectly or fed by a system that in itself was operated incorrectly etc.

As such the process as an entity must be risk assessed, controlled and reviewed using the quality risk management principles defined in ICH Q9. Avenio therefore becomes a vital tool as a risk communication/mitigation vehicle, when used as a system for maintaining and updating process data supplied by process, plant and quality subject matter experts.

This recently published ASTM guide defines a risk-based and science-based approach to the specification, design and verification of pharmaceutical and biopharmaceutical manufacturing systems and equipment. It is applicable to all elements of pharmaceutical and biopharmaceutical manufacturing systems including: facility equipment, process equipment, supporting utilities, monitoring & control systems and automation systems, with the potential to affect product quality and patient safety. The guide may also be applied to laboratory, information and medical device manufacturing systems.

For brevity, these are referred to throughout the guide as ‘manufacturing systems’. The guide is applicable to both new and existing manufacturing systems throughout their total lifecycle, from concept to retirement; and may be used for the implementation of changes to existing systems and their continuous improvement during operation. Avenio’s 3-way approach to lifecycle modeling (identification, characterization & verification) is an exact fit for ASTM E2500 and the company is actively discussing implementation assignments with its expanding client base.

UCC’s School of Pharmacy and Campbell Informatics have entered into a 2-year E.I. sponsored Innovative Partnership Project, effective August 2007.

The project – ‘BioPharma Quality Engineering Data Management’ - involves the compilation of interdisciplinary datacentric standards within the Avenio engine. The project is targeted towards the heavily regulated and paper dependent Pharmaceutical and Biopharmaceutical industry in which written and electronic data are difficult to retrieve and analyze. From a regulatory perspective, increasing demands are now being made on the sector to be more efficient, agile & flexible in both its product development and manufacturing operations.  The project, which has been discussed with FDA, provides a unique opportunity to deliver a world-class knowledge base in support of Manufacturing Science and Technology (MS&T), and our life science clientele will benefit greatly as a result. From the university’s point of view, the presence of such a repository of information within the School of Pharmacy will serve as an invaluable teaching and research asset.

Your filter may have a different pore size to mine, your column a different resin, and your temperature control sequence a different ramp rate; but filters are filters, columns are columns and controllers are controllers, in the overall scheme of things.

 So long as we can nominate context-specific target values for our dependent variables, we can share class-based standards and protocols; in fact we’d be foolish not to.
 

There is a longstanding Lifecycle Unification problem relating to Bills of Material, known in Industrial Engineering circles as the multiple BOM reconciliation problem.

The difficulty is this: any reasonably complex system has not one, but several BOMs, each representing a distinct configuration of the system across its lifecycle (e.g. as-required, as-specified, as-designed, as-built, as-used, as-maintained etc.). These BOMs differ from each other both in structure and in the number and kinds of parts that comprise them.

Identifying and propagating the consequences of even a single modification to one feature of one component in one BOM, to its counterparts in other BOMs for the same system, requires the coordinated expertise of a team of people that span several speciality disciplines such as process, mechanical, instrumentation and software engineering, not to mention quality assurance. 

Sound familiar?

Following on from my previous message in support of standardization, I cannot understand why each phase and sub-phase of the lifecycle deserves its own data/documentation format. The way I see it, each and every ‘regulated technical element’ needs to be explicitly (i) identified, (ii) specified and (iii) supported by a test procedure for the phase in question. End of story - almost. While the content and timing of each of the three aspects can certainly vary from item to item (depending on class, risk etc.), there is no justification for the degree of ‘format variability’ that exists across phases, disciplines & projects. I am also arguing for absolute connectivity between successive stages, with specification being treated as a logical extension of itemization, and testing a further extension of specification. This is a classic example of continuous processing, in my view.  This message invites discussion and feedback in regard to ‘frugality of formats’ as a constituent of Self-Evident Engineering (SEE).

Current-state compliance relies on 100% document-by-document approval, with little or no provision for modular or family-based acceptance. The desired-state alternative is summarized here courtesy of Genentech’s Ron Branning, a major advocate of standardization as a prerequisite of Self-Evident Engineering (SEE).

 “Developing and applying agreed industry standards for specification and validation would:

1. Yield reliable, self-validating outputs at each stage of the development process
2. Eliminate redundancy in testing and documentation
3. Eliminate ambiguity in specifications
4. Eliminate gaps and overlaps in departmental roles and responsibilities
5. Allow regulatory/quality to audit the standards rather than individual tests
6. Save companies time and resources
7. Adapt readily to innovation.”

I look forward to your feedback re the above, particularly in regard to the opportunities/implications associated with item 5.

I came across a staggering quotation recently when reading NIPTE’S excellent Strategic Roadmap for Research & Education. For more on NIPTE (National Institute for Pharmaceutical Technology and Education) be sure to visit www.purdue.edu/dp/nipte.

Meanwhile, here’s the quote: ‘There is typically little transfer of knowledge and information from development to manufacturing, and no transfer of knowledge and experience back to development. Because of limited systematic institutional memory for knowledge generated over time, relearning occupies over 25% of developmental resources’. Enough said? Once again, your feedback requested. 

Current-state compliance is based on ‘documentation, documentation, documentation’, with fragmentation and discontinuity the order of the day. This need not be so. Following on from my previous messages, systems and components can be itemized and codified with a view to acquiring front-loaded attributes and procedures across their lifecycle, this information being used to auto-generate the documented evidence that we require. The advantages in terms of standardization, transparency and scalability are obvious, along with the derivative benefits of data-exchange to & from other business applications (e.g. maintenance, calibration etc.). This message invites feedback in regard to the implications of a data-driven approach to Self-Evident Engineering (SEE).

« Previous entries