- You are here:
- Home >
- Our Portfolio >
- Case Studies >
- Drug Delivery System
Drug Delivery System

Case Study: Drug Delivery System - The Syringe Pump
Medical devices, by their nature, have to be safe for the user and the patient alike. When designing a medical electronics device it is essential that safety is considered as early on in the design process as possible so that the systems architecture and final technical design are fit for purpose. With ISO 13485 regulatory requirements now being based more on risk management, the designer must be able to provide evidence that hazards and their effects have been identified, mitigated and controlled. Good risk management in the early product development stages will also help smooth the way through the regulatory approvals later.
In any medical device there could be a number of hazards that could result in injury to the user or patient. Working with clinicians, nurses and other end users of the device, it is essential that use of the product is understood and any undesired effects of its use in normal and fault condition be considered so that the relevant controls can be built into the technical solution.
Drug Injection Device
The simple syringe pump infusion device consisted of a pumping mechanism, motor, micro-processor control system, display, key pad and battery. Just considering the worst case scenarios from a patient perspective there are two key undesirable effects that could arise from using the device: under infusion and over infusion of the prescribed drugs. In both cases, depending on the drug involved, the patient could suffer serious injury and in some cases death. Defining the system's architecture early on in the design process and using risk management techniques such as fault tree analysis (FTA) can provide valuable input into the technical specification.
Let's consider the undesirable effect of ‘over infusion' and brain-storm all the likely consequences this may result in: motor too fast, syringe siphoning, incorrect flow rate set and wrong syringe size fitted, to name but a few. From this small list we can already begin to get a feel for some of the controls we need, e.g. to correctly detect the syringe size so that the motor speed can be set to achieve the desired flow rate, to detect that the syringe plunger is positioned in the mechanism correctly and that the drive mechanism is correctly engaged so that siphoning cannot occur and to ensure that the user interface is intuitive, so that the likelihood of entering the wrong rate is reduced. For instance, in the case of the user interface, a keypad may be more hazardous than a simple increment/decrement control - "death by decimal" (that is, where the nurse unintentionally enters the flow rate with the decimal point in the wrong place) is a real hazard that needs to be managed by good design. Even during the early stages of a product design it is possible to identify and mitigate a huge array of hazards. Once controls have been identified they can be included in the technical specification, the system's architecture updated and a much more robust and reliable design will result.
As the design progresses from feasibility through technical bench studies to the first working prototype, the opportunity arises to perform basic fault insertion testing to ensure that the controls written into the specification work as expected. These can be performed at key subsystem interfaces e.g. break one of the motor wires and ensure that the system alerts the user to the problem or a more in-depth component failure mode effects analysis (FMEA) can be performed where individual components within the sub-systems are short-circuited or open-circuited. Depending on the number of components within the system, this type of exercise can become very costly and time consuming and it is therefore prudent to start at interface boundaries, to have confidence i
n the design and then select key areas for detailed analysis.
At MLE we have a number of years experience developing medical electronics. We understand the demands made on medical products from a safety, regulatory and technical perspective and therefore already have tried and tested design processes in place to ensure that medical device development is, overall, a rewarding and enjoyable experience.
Case Study Medical Device Development
Developing a new medical device and bringing it to market can be fraught with difficulties. Not only do you have to deal with the inevitable technical problems that accompany any product development but you also have to ensure that the regulatory requirements can be met in full. A product that is submitted for regulatory approvals, whether safety or EMC, before it is ready will devour endless resources as last minute fixes are put in place only to find that one issue is fixed but causes another. Any engineer that has been involved in end to end product development will have been stuck in the frustrating loop that can only be described as ‘squeezing the balloon' a problem pops out and a fix is implemented only to have another problem bulge out in another place!
The following case study considers the development of a drug infusion system and looks at ways in which through good management and the sensible application of design processes the risk associated with medical product development can be reduced. The study does not detail the design process in full but aims to highlight the important areas that if considered early enough in the process will help to avoid a lot of ‘balloon wrestling'!
Feasibility
As a design consultancy our medical clients typically have a strong understanding of the market place and the user needs but come to us to flesh out and realise the technical specification. A thorough feasibility study is required the output of which will be a good set of technical requirements that include a system architecture diagramme. Input to the technical requirements will come from the marketing, regulatory and safety requirements.
At this stage safety is of the upmost importance and will heavily influence the design requirements and architecture. Gaining an understanding of the intended use of the device and identifying the undesirable effects is the start of producing a set of top level fault tree diagrammes that will enable hazards and controls to be identified. The controls can then be incorporated in the architecture.
Print This Page