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.

There are a number of interpretations of the term ‘lifecycle’, ranging from NIPTE’s all-encompassing Design-Development-Manufacturing on the one hand, to ISPE’s more focused Commissioning & Qualification on the other.

My contention is that within the transition state, Lifecycle Unification principles can be applied to simple and complex situations alike; complex lifecycles being treated as concatenations of simpler phases and sub-phases.

FDA’s Target Product Profile (Draft Guidance, Mar 2007) provides a current and relevant benchmark in support of this argument, with its emphasis on development milestones/endpoints and the provision of ‘a dynamic summary that changes as knowledge of the drug increases’. 

With the TPP example in mind, here are three suggested rules in support of Lifecycle Unification within the transition state.

• Individuate your phases & sub-phases within a shared interdisciplinary framework
• Register your systems & components as a function of phase (e.g. tech transfer, design, operation, aftercare)
• Create class-based rules enabling systems & components to inherit standardized procedures across their lifecycles 
   

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?

In this message I want to introduce the concept of Quality by Design (QbD) arrays. Since I want to accentuate the positive here, I won’t dwell too long on ‘disarray’, other than to say that it’s a fair description of the current state. We’ve already introduced the concept of System & Component itemization, specification & verification; and if we call these dimensions X,Y&Z, then a basic but powerful calculus emerges, where

X = Σx, Y = Σy and Z = Σz

and

 x = + x_s + x_r + x_d + x_i + x_o + x_p + x_m + x_c + …
 y = + y_s + y_r + y_d + y_i + y_o + y_p + y_m + y_c + …
 z = + z_s + z_r + z_d + z_i + z_o + z_p + z_m + z_c + …

Each of the subscripts corresponds with an episode in our lifecycle continuum, and these are extendable in both directions (you’ve guessed it, the ultimate continuum addresses all aspects of DDML in algebraic format). In the above example, the subscripts relate to specification, risk, design, installation, operation, performance, maintenance, change; but the array is configurable rather than compulsory. Sub-phases can also be accommodated by ‘bracketing’ as required e.g. [design = design_basic v design_detailed] and so on…..

What does all of this do on reality street? Very simply, it means that systems & components are subject of single point of data entry only, with multiple perspectives

(i.e. datasets and protocols) available at different stages of the macro or micro lifecycle. Get it?

MIT has identified the field of Engineering Systems as a missing-link discipline which precedes and facilitates traditional engineering, particularly when dealing with complex implementations and infrastructures.

Given the intricacies of pharmaceutical technology and the emergence of PAT etc., their monograph on The Influence of Architecting in Engineering Systems is a very valuable benchmark - in my opinion. Amongst other things, it introduces the concept of the “ilities”: ‘systems are intended to have certain primary functions, plus other properties that we call ilities: durability, maintainability, adaptability, scalability, extensibility, flexibility and so on. The primary functions have immediate value while the “ilities” tend to have lifecycle value’.

There’s that lifecycle word again, and I’d welcome your feedback as to how the ilities can be best incorporated into our specification, verification and improvement programs.

You’ll find the monograph itself at www.esd.mit.edu/symposium/pdfs/monograph/architecture-b.pdf

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

« Previous entries