Articles by Commala

EDDOs (not Essential Performance Requirements)

Wed, 18 Oct 2023 00:59:49 GMT

Update 28 June 2024 : The FDA have now released draft guidance under the title: Essential Drug Delivery, Outputs for Devices Intended to Deliver Drugs and Biological Products Guidance for Industry .

It is approximately half what I hoped it would be. The balancing concept of ‘Essential Performance Requirements’ has been ditched, leaving just essential performance outputs, now called ‘Essential Drug Delivery Outputs’ (EDDOs). Instead of using existing traceability between (essential) inputs and outputs to derive EDOs, we now have a rather subjective filtering task to perform. This change is simply dismissed in a footnote as little more than re-naming.

However, I have left my original October 2023 EPR blog below for reasons of posterity...

While the FDA’s Office of Combination Products is working on a formal definition of Essential Performance Requirements behind closed doors, Industry is busy second-guessing. There are some clues to be had, and this is how I think it can work.

At first, I thought Essential Performance Requirements are an attempt to override (or undermine) the safety risk management process, dictating specific Essential Design Outputs regardless of evaluated risk. After wrestling with this unhappy thought for a while I realised that, actually, EPRs should perform a different role as the Guardians of Efficacy . Safety risk management stops devices from being unsafe, but it does not necessarily make them work reliably.

It is possible to design a drug delivery device that is safe, but does not always work. Consider an injection device that treats a chronic disease with regular injections. If an injection is missed because the device broke, the consequence may be a minor flare of symptoms. Risk management might evaluate the risk of occasional failure to inject and find it acceptable, when weighed against the benefit of the therapy. The device is safe, but it is not sufficiently reliable (or to put it another way; effective).

There is growing emphasis being placed on ensuring efficacy at the point of use, as well as safety. The language of efficacy has not yet crystalised, but when it comes to medical device functionality, I am going to coin the term ‘Essential Function’. A combination product performs many functions and a lot of them will be supporting acts to its raison d'être; the Essential Functions. Like a potato peeler must, when it comes down to it, peel potatoes.

Risk management still has a part to play. Remember the Hazards and Harms document in Part 4 ? Well, it can be used to generate a comprehensive list of product functions too. It is then an easy job to identify those raison d'être point-of-use functions that are the Essential Functions.

Design Input Requirements: That set of testable goals and constraints that we give to the designers to define the required device performance. Combinations of those Design Input Requirements give rise to product functions.

Now, armed with a list of Essential Functions, it is possible to match them up with their Design Input Requirement building‑blocks to identify the Essential Performance (Design Input) Requirements . Design Input Requirements are the logical place to highlight the desired core performance of the device to be developed. In that sense, it is completely independent of safety risk management which looks at risks embodied in the final design solution – the Design Output. They can both exist in harmony.

Since EPR Design Input Requirements trace to design outputs, we also find any efficacy‑based Essential Design Outputs (see Part 6 ) that risk management has overlooked. Device efficacy can now receive the same enhanced levels of rigour and control in test and manufacture as device safety. And as a bonus, we can have a transparent process that shows how we derive EPRs and then control them for our combination product.

Once again; this is my interpretation of the FDA’s enigmatic concept of Essential Performance Requirements. I’m sharing it because many of us are trying to integrate EPRs into our development processes and I hope it helps in some way.

Not Doing Risk Management is Not an Option - Part 8 of 8

heald.mike@gmail.com (Michael Heald) — Mon, 23 Dec 2019 12:15:40 GMT

It’s hard to argue with safety as a reason for doing, or not doing, something; unacceptable risk is, well, unacceptable. This is the last article on risk management from me for a while – thanks for reading.

This series of articles on safety risk management has hopefully been useful, or at least thought provoking. It is not an exact science and one size definitely does not fit all. Good risk management is an investment in time and effort, and the value in tuning-up your risk management in the research stage cannot be stressed enough, nor can the extent to which it could affect all other parts of a project.

Safety, or the absence of unacceptable risk, is the inalienable pre-requisite for any medical device. Arguably safety is more important than efficacy, since efficacy cannot prevail in the absence of safety. Project and commercial risks, however, are of little interest to the regulators and can be managed elsewhere.

Anyone involved in the development and manufacture of medical devices, from apps to pacemakers, needs to have processes and procedures that not just allow, but promote, a robust safety-based approach to development through effective risk management. The result will help avoid nasty surprises in the long-term, and make for a better, more robust, product. Not doing risk management is not an option, so make it work for you.

Risk Control Verification - Part 7 of 8

heald.mike@gmail.com (Michael Heald) — Mon, 23 Dec 2019 12:14:02 GMT

To misquote Edwin R. Fisher, “In god we trust, all others must provide documented evidence”. Just like a list of new year’s resolutions, a list full of risk controls does not mean anything unless they are acted upon. Fortunately, we don’t have to provide documented evidence that we have stuck to our new year’s resolutions.

An important part of any risk assessment are the risk controls. Most, if not all, risks will probably have some sort of risk control (aka risk mitigation) proposed within the assessment. I say ‘proposed’ because that is all they are, documenting a risk control in your risk assessment is no guarantee that it will be implemented. In fact, it may not be the right or best risk control, but it is what seemed right when the risk assessment team was ‘in the zone’.

Therefore, we need a way of ensuring that ‘proposed’ risk controls are actually implemented. If your residual risk levels are based on risk controls that never made it off paper, you are in a bad place. Documented verification of risk control implementation is required, and this does not need to be onerous. If each risk control proposed in an assessment is traceable to a design input (or URS) requirement, the design verification/validation/qualification processes will complete the implementation audit trail and provide evidence that your proposed design controls actually made it into the final design.

But that is not all. What if a risk control is not as effective as the risk assessment team anticipated? Instead of guessing at the effectiveness of risk controls during risk assessment, it makes sense to set the occurrence of harm at the highest probability until you have evidence that it is reduced. Again, design verification/validation/qualification can then provide a traceable means of verifying the effectiveness of your risk controls. Of course, once effectiveness is proven, the associated risk analysis and evaluation should be modified accordingly.

As ever, it’s not enough to say you are going to do something. You have to do it and then be able to prove that it’s been done, and done properly.

Part 8 – Not Doing Risk Management is Not an Option.

Safety Risk Management and Essential Design Outputs - Part 6 of 8

heald.mike@gmail.com (Michael Heald) — Mon, 23 Dec 2019 12:10:54 GMT

Keep your friends close and your enemies closer. While all aspects of design and manufacture of a medical device should be carefully controlled, special attention should be given to those elements that have the potential to cause the most harm.

The Americans say, “ Design output procedures shall … ensure that those design outputs that are essential for the proper functioning of the device are identified ”. Europeans say, “ specify the characteristics of the product that are essential for its safe and proper use ”.

What is essential? How do we define essentiality? Well it is not spelled out for us, but there are some clues in inspection guidelines that point to risk analysis, and also they link ‘Essential’ with ‘Critical’; another ill defined concept in regular use. So, how do we get our risk analysis to tell us what is Essential, or Critical?

IEC 60601-1 could help here, as well as ISO 13485. Firstly, IEC 60601-1 explains the concept of Essential Performance as the “ performance necessary to achieve freedom from unacceptable risk ”, and then the definition of safety in ISO 13485 is “ freedom from unacceptable risk ”. The common link here being ‘freedom from unacceptable risk’. It is no great visionary feat to see that risk assessment tells us which risks are unacceptable.

But wait, ideally all risks are controlled to acceptable levels which means that there would be no critical risks. This may seem convenient, but it lacks a certain integrity. IEC 60601-1 comes to the rescue again by hinting that the acceptability of uncontrolled risk is key. This makes sense; the Essential or Critical bits of your product are those that have the potential to do the most damage if everything goes a bit Brexit. These are the bits that deserve extra rigour in design and manufacture.

So a test for the acceptability of uncontrolled risk can be built into risk assessments. This will indicate which failure modes are safety-critical, and traceable links can be established between critical failure modes and design outputs that are then, by association, Essential. No need for arbitrary and unsubstantiated ‘Engineers opinion’ or similar, a credible and traceable link exists between risk management and Essential design outputs. That must be worth a good night’s sleep.

Essential design outputs are not limited to safety-based rationale, but safety is the obligatory absolute minimum. It is perfectly valid to make other outputs Essential for reasons relating to function, quality, compliance etc., but a rationale may have to be sought from somewhere other than risk management.

Part 7 – Risk Control Verification.

Should I Use FMEA or Fault Tree Analysis? Part 5 of 8

heald.mike@gmail.com (Michael Heald) — Mon, 23 Dec 2019 12:10:05 GMT

Pressing deeper into safety risk management we look at two tools for performing risk assessment and evaluation: the ubiquitous FMEA and the exotic FTA.

In short; both, and here’s why. Risk Management in medical device development requires, amongst other things, risk analysis and evaluation. That is, a thorough and systematic method for anticipating failures, understanding how those failures might hurt someone, and then deciding if the level of risk will be sufficiently offset by the benefits of using the device. Once risks are identified, 'risk controls' can be proposed to mitigate those risks.

FMEA (Failure Modes and Effects Analysis) is a very convenient tool for doing this. For any anticipated failure they can do all of the above in one row of a spread sheet, and we know how much engineers love a good spread sheet. However, FMEA have some drawbacks; they encourage blind spots and can only cope with one thing going wrong at once.

To go a little deeper into the drawbacks of FMEA, it is a bottom-up process, which is not bad in itself. Starting with a small detail, we imagine how it can go wrong, and then work out what the sequence of events is that cause someone to get hurt. This can be done for design risks, or manufacturing process risks, or use risks, but only one at a time. Whichever type of risk is being worked on, it must be assumed that the other risks don't happen - which is not terribly realistic.

So a device development team can choose to tick a risk management shaped box and just do an FMEA. They will spend a long time doing it, because it is very involved and detailed. At the end of it they will feel tired but probably satisfied that they have done the necessary suffering to comply with regulation. Hopefully the process has exposed some problems that can be rectified before they invest in prototypes; an added bonus.

Is it a complete job? Well not really, because combinations of faults can lead to people getting hurt, and FMEA is blind to these scenarios. The bottom up approach is also not very good at exposing problems with the structural stuff that is in-between the bits of detail being analysed.

This is where FTA (Fault Tree Analysis) comes to the rescue. It is a top-down approach; starting with the ways in which someone might get hurt, and then asking how it could happen. This invites thought about combinations of failures in design, use and manufacture, and nothing need be off-limits. It tends to be better for highlighting structural and physical problems too.

Typically, FMEA and FTA will complement each other. FMEA looks at lots of detail, so it can be very laborious and output masses of broad-spectrum risks, whereas FTA lets you go straight to the big-ticket risks like; "What failures could kill my patients?". FMEA helps with robust design at detail level, quickly highlighting safety critical tolerance analyses and testing that are necessary, FTA exposes significant compound and cross functional failures that may have been invisible otherwise.

There are other risk assessment techniques that are wholly acceptable, but FMEA and FTA are industry favourites.

Part 6 – Safety Risk Management and Essential Design Outputs.

Multi-discipline Safety Risk Assessment - Part 4 of 8

heald.mike@gmail.com (Michael Heald) — Mon, 23 Dec 2019 11:14:16 GMT

Imagine a band performing a piece in which every musician played a different tune. In my fourth article I’m looking at how to coordinate the disparate groups that have to work under one risk management plan. How can they be helped to assess risk consistently?

Risk management in development requires the assessment of risk across a range of disciplines, such as mechanical design, electronic design, software design, use (or application) and manufacturing processes. It is likely that different individuals will be leading risk assessment for the different disciplines. This is where a level of coordination is necessary. Hopefully, anyone running a risk assessment has been given a copy of the Risk Management Plan, which tells them how to score occurrence and severity of harm, and how to evaluate risk for acceptability. This is still not enough to stop things from going awry though. One person’s view on the severity of a harm may be different to another’s, so the same harm appearing in two different assessments gets scored differently. Furthermore, there may be different views on what harms might result from any given hazardous situation. Suddenly your risk management has gone feral.

The product being assessed for risk will have a limited number of ways in which it can hurt people, and most of these will quickly become apparent during those early research phase days. These ‘Hazardous Situations’ that your product can create are the result of a large array of possible failures in each different discipline. Looking at this in reverse, all the different disciplinary failure modes will lead to a limited number of hazardous situations, and their harms. These hazardous situations, harms and severity scores can be documented and shared around with the risk management plan.

By standardising the recognised hazardous situations, their associated harms and the severity of those harms, each different disciplinary team can produce a harmonised assessment of risk for each failure mode. Now risk assessment is coordinated right across the project and apples can be compared with apples.

In fact, this document of harmonised Hazards and Harms can be made to work harder. It is often difficult to get a medical professional to sit in on hours and hours of risk assessment just to give their opinion on whatever harms are thrown-up by the process, many of which will be repeated ad nauseam. Even an enthusiastic medical type can rapidly lose the will to live. Instead, they can be asked to dispense their medical wisdom into the Hazards and Harms document, adding robustness and credibility to the process with medical rationales and their approval. This medical assessment of harm is then hard-wired into each disciplinary risk assessment that uses the Hazards and Harms document.

Part 5 – Should I Use FMEA or Fault Tree Analysis?

What is Acceptable Risk? Part 3 of 8

Mon, 23 Dec 2019 10:46:22 GMT

I admire the achievements of free solo climbers, but I do question their notion of acceptable risk. Modern office health and safety culture operates at the other end of the scale; with carefully sealed hot drinks containers and the mandatory use of handrails on stairs. So, what level of risk is going to be acceptable to the users of your medical device?

As previously mentioned, the aim of risk management is to ensure that use of a medical device will do more good than harm. The concept of benefit-risk balance has some kinship with the regulatory concept of safety and efficacy; safety is the absence of unacceptable risk, and benefit can only come from efficacy.

Often a new device will start with some kind of unmet need, and this can range from a commercial need for product differentiation, to a completely new way to control disease. The point being that we start with notions of good intention, of efficacy and benefit. The reality is that every attempt to interfere with the human body has at least the potential to do harm, and this potential for harm must not outweigh the benefit of the treatment.

As a new medical device comes to life the original pure idea is warped and stressed by the reality of physical, material and human limitations, as well as economics, fashion and regulation. Compromises must be made, and as a design matures, the true level of risk becomes clear with the aid of risk assessment.

Everyone in the business is familiar with the need to document a risk-benefit analysis at the end of development, to demonstrate that the balance does indeed fall in favour of benefit. At the outset of development this goal is long way off and there is no guarantee that you will achieve that balance at the final reckoning. What you need is a means of tracking the balance of risk and benefit as development progresses, and this is where I will make a proposition that some may find controversial: This is what your risk acceptability evaluation is for. It provides a real-time gauge of risk-benefit balance throughout development, tailored to your particular device and application, with regular reviews by Management. Does any other measure of risk acceptability make sense?

This concept can be very helpful in setting up your system for evaluating risk acceptability; usually a simple matrix based on severity of harm and the probability of occurrence of that harm which gives a nice visual 'heat map' representation of the benefit-risk tipping point. Any quantitative rationale for setting the acceptability tipping point that can be provided will help to show that it is not just arbitrarily set.

Your system for evaluating risk acceptability needs to be specific to the product being developed, and a variety of factors go into defining this balance point, including clinical evaluations, standards and similar state-of-the-art products. A risk acceptability matrix for a thermometer will be far less tolerant of risk, evident in the larger area on the unacceptable side of the tipping point, than a matrix for a defibrillator.

On the subject of risk acceptability, I prefer a binary system of either acceptable or unacceptable risk. Some baulk at the idea of documenting any risk as unacceptable, as though it is a mark of damnation. Instead, they favour softer words or phrases that they find more palatable, but ultimately the same decisions must be made.

Part 4 – Multi-discipline Safety Risk Assessment.

Safety Risk Management in Research - Part 2 of 8

heald.mike@gmail.com (Michael Heald) — Mon, 23 Dec 2019 10:43:04 GMT

Risk Mañana (noun): The temptation to leave risk management until is it impossible to ignore. Invest in an early dry run and enjoy the benefits.

Risk management is not just something to worry about during development, it lives on through launch and right up until the last product has been used after it has been taken off the market. Decisions made early in development about risk scoring and evaluation live with the product, and the manufacturer must stand by those decisions the entire time that the product is on the market. If the risk bar is set too low to expedite development for the sake of a launch date, imagine having to defend it when people get hurt by an under-developed product on the market? Set it too high and costly over-engineering or even project failure may result.

The aim of risk management is to ensure that the risk of using a device is always outweighed by the benefits of using the device – a simple enough concept. As development marches on, risk assessments are made to ensure that the device remains on the benefit side of the benefit-risk balance, but where is that tipping point for a specific product? If it is mis-judged because someone had to make some hurried decisions to get the risk management plan out, the consequences of subsequent rework and back-peddling could be very painful.

So, when can you test and refine your risk scoring and evaluation system before committing to it in development? In the research stage of course. During concept development, or bought-in platform device selection, it is the perfect time to size scoring systems and test your benefit-risk tipping point. Apart from providing an opportunity to calibrate your risk management set-up, risk profiling should be central to the concept/buy-in selection strategy anyway. One of the responsibilities of the device engineering team should be to make sure that bought-in device selection for development is not just device Tinder; it should be the result of objective assessment, including risk profiling.

An interesting parallel to bough-in device selection is when a pharmaceutical generics manufacturer is selecting a branded drug to copy as a generic. Sometimes the branded drug is marketed with a delivery device, the design of which which may be rather old by the time the drug patent is expired. In order to market the generic version of the drug the manufacturer often has to ensure that the generic drug delivery device looks-like and works-like the branded one. Here is the dilemma for the device development team, because the risk bar for development of the generic device must be set to reflect current state-of-the-art safety levels. Consequently, the device team can have an important role to play in any decision to develop a generic version of a branded combination product.

Part 3 – What is Acceptable Risk?

Safety Risk Management and Project Planning - Part 1 of 8

Mon, 23 Dec 2019 10:33:36 GMT

This is the first of a short series of articles written to share my insights into the bit of medical device development that is always last to get picked for the team.

1846 Hydrotherapy used pressurised water to push arthritis from the body!

Who thinks that the benefits outweigh the harms?

I will admit to being fascinated by the subject of medical device risk management, particularly in the development of drug delivery devices. The subject of risk management often seems to be regarded as a necessary burden that the development team must suffer, a bit like washing-up, tax returns or root canal surgery. This little series of articles is written in the hopes that some of my enthusiasm is contagious, and maybe helps readers to squeeze more value from the time they commit to risk management.

Any people or organisations represented in these texts are purely fictional with inspiration taken from a multitude of my own experiences, as well as discussions with other professionals in the field. The scenarios presented are a risk management soap-opera intended to illustrate poor practice, and do not reflect the general quality of risk management in the medical device development industry.

Let’s start with a view of risk management from the outside, when a development project is just a twinkle in the eye of a Programme Manager. They need a plan to see how device development stacks up against a pre-determined submission date – because that’s how it often works.

The Project Manager, sometimes grudgingly, accepts that they must build-in some development time for risk management, so they chuck a few lines into the Gantt chart for a risk management plan and a triplet of FMEAs; let’s not get silly. Someone from Quality and/or Engineering is made the responsible resource, if anyone else needs to be involved their time will have to be scavenged. The plan is accepted, and a project is launched in a rush. In the excitement of the research phase and concept development, or bought-in device selection, risk management is hassle on the horizon. Something to be endured later.

On the face of it risk management is very simple, isn’t it? You need to do an FMEA each for design, manufacture and use of the device. It’s a bit of a bind when the time comes but a few days locked in a meeting room with a spread sheet and plenty coffee should see them done. At least, it is easy enough to view it that way when planning a project.

When the research phase is completed and it’s time for development to start in anger, the project plan says that risk management shall be done. The assigned responsible resource carves out some hard-won time to sit down and write a risk management plan, and this is where reality and the project plan start to part company. Alarming questions start to bubble up inside this poor person’s mind, things like, “Our SOP says I need to define a method of evaluating risk acceptability but does not tell me how to do it. Can I use one from another project, or maybe just copy an example from the standard?”, or, “Can I just use the OEM risk assessment for this bought-in device and add a cover sheet?”, or, “Hang on a minute. The output of risk management activities will probably affect design inputs that everyone thinks are fixed, and who in Operations is going to be responsible for the manufacturing process risk assessment? We haven’t even decided on a final assembly location yet.”

Before long the Project Manager wants to know why the Risk Management Plan is not out for review by the planned authoring deadline, and the poor responsible person has a host of gaps in their document that require substantial background work to be done before they can be closed. And so the misery starts.

Part 2 – Safety Risk Management in Research.

Container Closure Integrity Test (CCIT) for Injection Devices

Tue, 03 Dec 2019 13:57:33 GMT

Medical devices designed to inject sterile liquid typically contain a cartridge or pre-filled syringe, usually made from glass, and its job is to contain and protect the sterile drug solution. These glass containers, or primary packs, also have plungers and seals made from rubbery elastomeric materials. As long as the glass and rubbery bits form a hermetically sealed environment, nothing nasty can get in, and nothing precious can escape. For those in the industry this simple concept is lovingly referred to as Container Closure Integrity, or CCI.

Consider the life of a primary pack. Once it has been proven that a filling process is reliably producing sterile primary packs, they can be sent to be assembled into their host drug delivery devices. Device assembly is no pampering session for the primary packs; they are slid down tracks, bump into each other, get gripped and handled by machinery, pushed into some sort of holder, and then they get squeezed and bumped some more during other assembly processes. After all this, are they still safe to use?

Then there is the shipping process as the devices are moved around the world. Happily, they are not usually subject to the professional ministrations of ordinary airport baggage handlers, nonetheless temperature changes, pressure changes and impact forces must all be endured en-route to their new home. Still safe?

Eventually the devices will be stashed somewhere, during which time the primary packs age gracefully inside their host device and packaging. Even now they can fall victim to environmental conditions, or even long term stresses placed on them by the device. Filling and sterility testing is but a distant memory.

It’s pretty obvious that we need to look after CCI right up until the patient gets their jab, and there is some common sense regulation on the subject. With device assembly, shipping and ageing in mind, try these for size:

21cfr211.87 “… drug product containers, and closures shall be retested … after exposure to … conditions that might adversely affect the … drug product container, or closure.”
21cfr211.94 (b) “Container closure systems shall provide adequate protection against foreseeable external factors in storage and use that can cause deterioration or contamination of the drug product.”
FDA Guidance - Submission Documentation for Sterilization Process Validation and Applications for Human and Veterinary Drug Products: “Study designs should simulate the stresses of the sterilization process, handling, and storage of the drug and their effects on the container closure system.”

Glass can form micro-cracks, or worse, and rubbery bits can fail to seal properly. So the big question is; when manufacturing thousands, or even millions, of drug delivery devices, how do we demonstrate that each and every primary pack will continue to keep the bad stuff out and the good stuff in until it’s used?

The answer to our big question lies in a specialist field of testing called Container Closure Integrity Testing (CCIT). The old probabilistic dye ingress techniques are, quite frankly, a bit rubbish. Luckily, a growing number of clever quantitative techniques are available to prove reliable container closure integrity for a range of different applications.

Don’t think for a moment that device design is not involved in CCIT. Firstly, the device simply gets in the way and prevents us from checking CCI (think Schrödinger's cat). Secondly, if the device is dismantled to check CCI, the act of dismantling may itself cause a leak path to develop.

So, to all those engaged in the design and development of drug delivery devices; don’t design a CCIT nightmare, use Design Controls and Risk Management to both improve CCI performance and pave the way for CCIT friendly device design.

Primary Packaging for Drug Delivery Devices

Mon, 02 Dec 2019 22:02:27 GMT

When devices are being developed for the delivery of pharmaceutical drug, two worlds collide. Pharmaceutical regulation meets medical device regulation, and what is at ground zero? The primary pack*. The bit of the device that holds and protects the drug substance.

Often the device itself is referred to as secondary packaging, which hardly does justice to the amazing engineering that can go into it. Then there are more ordinal layers of packaging with trays, cartons, sleeves, wraps, multipack boxes etc. Beyond Primary Pack there seem to be no hard and fast rules for packaging nomenclature, so it is a good idea for everyone to agree on packaging terminology early in a project. But I digress.

Going back to the Primary Pack, I should point out that containers designed to do no more than hold and protect a drug substance are not regulated as devices, and therefore are not subject to medical device regulation. As soon as a container plays a part in controlling the delivery of a drug, it is moving into medical device territory, and the medical device regulations are invoked. There are, of course, grey areas. Eye dropper bottle design seems to be one.

From a regulatory point of view, and the Americans are particularly clear on this, you need to run both drug and device quality systems for drug delivery devices. There are drug constituent parts, and there are device constituent parts. And then there is the Primary Pack, which is both. It is the common interface between device and drug.

For the pharma development team, the Primary Pack has to hold the right amount of drug, and it needs to prevent deterioration or undesirable exchange between the drug, primary pack and environment, all for the entirety of its shelf life. The contents may also need to be kept sterile.

For the device development team, the Primary Pack has to allow accurate, often metered, delivery of the drug. To do this the Primary Pack becomes an integral part of a precision mechanism, which necessitates tight control over dimensional tolerances and operating forces.

There are also shared interests, such as drug visibility, labelling, filling requirements and container closure integrity. Shared interests further extend to compatibility with certain manufacturing processes, so someone from Manufacturing needs to get involved too.

Put simply; the pharma development team and the device development team need to collaborate closely on the design of the Primary Pack from the start. It is surprising, especially in parenterals, how often project risk is unwittingly invited by one-sided Primary Pack decision making.

So which team should have custody of the Primary Pack specification? I think that the right answer to this question is that it doesn’t matter. As long as the controlling team and the governing processes ensure that collaboration is effective, and that both drug and device regulations are met, then ownership is irrelevant. Traditionally the pharma guys have it.

One particularly tricky aspect of developing devices for sterile injection is container closure integrity testing (CCIT). Not very long ago CCIT was subject to a pharmacopeia re-boot with USP <1207> and the industry is upping its game by abandoning old probabilistic methods and moving to deterministic ones. This field of testing is evolving quickly, which is why went along to the Container Closure Integrity Testing workshop run by PDA Europe in March. If you have read this far, maybe you would like to take a look at the CCIT blog that resulted.

* Apart from the Primary Pack, other parts of the drug delivery device can demand a similar mode of co-operation. Typically, these are other components that are in direct drug contact, though usually contact duration is transient instead of being measured in months or years.