A number of things are different e.g. Development processes Pharma companies understand drug development People know what to look for, and what is likely to go wrong Very few pharma companies regularly go through the full device development process People are often learning about the process as they do it… … and may move on before the next device development Familiarity is required with a new set of regulatory constraints: Unlike for many products, the development of medical devices is very highly regulated Device designers (including many design consultancies) have often gained their experience outside of medical device development Inventors by their nature aren’t always good at playing by the rules (That’s why there are inventors.) User Issues After being dispensed, most drugs have to deal with the same environmental issues: temperature, time, oxygen, moisture loss, and then differences in patient physiology and genetic makeup… After being dispensed, most devices have to deal with patients… who represent a far more complex and creative environment Production Issues The manufacturing processes involved are totally different
WHAT ARE THE REALITIES OF DRUG DELIVERY DEVICE DEVELOPMENT? rigidities of regulatory industry - real challenge associated with late changes uncertainties of drug pipeline - demands flexibility 'right first time' risk focused quality imperative vs. reject drug batches (pre-PAT) - little opportunity to 'reject batches' and 'fix it on version 2' time pressure of the drug income before patent expiry We can summarise this as a pair of paired 'conflicts' … rigidity AND flexibility … right first time AND immense time pressure
Device development has many facets. Understand what doesn’t need to be in the plan Early front end development work can sometimes be best done outside of the full development controls Quick, iterative explorative work Generation of simple models that can be easily tested Requirement for rich feedback rather than ‘statistical proof’ The information is needed for ‘understanding the landscape’ and ‘direction setting’, when many variables need to be accommodated Use ‘Rolling Wave’ planning – detail what you need to, when you need to - but outline all key phases and milestones from the outset
The DHF typically includes: Design and development plan Design inputs, including product requirement specifications Design reviews Risk management Design output including design specifications Design verification and validation History of design changes (after start of change control)
Not everybody does it properly Generally because they don’t do medical device development day in, day out Plan before the project has started, not part way through A good plan allows clear communication of deliverables and responsibilities, in advance! Development plans are a regulatory requirement The final device can not be too much of a compromise or it won’t be competitive… or safe.. So, do need to burn some bridges at some point. Can’t be all things to all men,
There are many specifications to think about. Three key sets of documents form part of the development process: User Requirements Specification What the users will get from the product / device Typically validated through clinical trials Product Requirements Specification What the product / device will do (or not) Typically verified through design verification Design Specifications What the product / device is Allows the manufacturer to validate manufacturing processes
This is how the specification maps onto the waterfall development process. Specified requirements need to be verified or validated, so consider how you will do this as you create it Don’t specify something that you can’t verify or validate Be clear on who is responsible for verifying which requirements Good specifications (and a good risk management process) should lead to good verification and validation plans. Bad specifications, however ….
There are many different kinds of injector devices! So you will need to describe the one that you are developing This is where the specifications come in
Consideration of the requirements for two different therapies starts us on the process of working out what it is we need to know… what we need to design to… what are the USER needs
What about more detailed, product/technical requirements Some elements of specification can be fixed early. Others can not, so for development to be swift it needs to be flexible and remain as accommodating as possible for as long as possible The final device can not be too much of a compromise or it won’t be competitive… or safe..
Users (patients, carers, clinicians) are often overlooked in device development until late in the day Consider the user from the very beginning of the development process when it’s cheaper to get it right in order to identify major risks early on Consider the context of use Drug + User = predictable Device + User = less predictable….. You can just about get away with a change in component colour or an adjustment to the IFU, but significant changes to avoid potential use error are a big deal.
The device should fit the user, not the other way around. Interaction design is key, and requires detailed understanding of device function. This analytical thinking helps drive the empirical side – what are the objectives of the studies… what do the protocols need to cover
Users (patients, carers, clinicians) are often overlooked in device development until late in the day Consider the user from the very beginning of the development process when it’s cheaper to get it right in order to identify major risks early on Ensure a permanent presence on the development team of a human factors specialist, working closely with the industrial designers and engineers
IF you mess up your mobile phone design, you have another coming along in six months time… If you launch a dud device….. COST DIFFERENCES … the immense costs of drug development vs. "under-investment" in drug delivery device development?? The huge cost of product recall……