How to Design a Protective System for Infusion Pump

Roland chung

Trusted Information Resource
#1
Hello folks,

Does anyone here have experience on infusion pump? We are developing an infusion pump. When I read IEC 60601-2-24, I felt that the requirements for protective systems are equivocal. Our infusion pump uses a CPU. I am wondering if two CPUs (one for control, the other for protection) are necessary. If one CPU use, it seems that the CPU should have heavy self-monitoring.

Could somebody tell me what do the requirements below exactly mean?

Acceptable methods of complying with this requirement are, for example:
1) a safety system check initiated and controlled by the EQUIPMENT, first at the beginning of the ADMINISTRATION SET CHANGE INTERVAL, and then repeated continuously as warranted;
2) one or more protective systems checks initiated by the OPERATOR and controlled by the EQUIPMENT within the ADMINISTRATION SET CHANGE INTERVAL, with the OPERATOR initiating checks before or during the infusion;
3) a safety system check carried out by the OPERATOR at least once within the ADMINISTRATION SET CHANGE INTERVAL
Thanks,
Roland
 
Elsmar Forum Sponsor

Peter Selvey

Staff member
Super Moderator
#2
The theory, established by the TUVs, is that for very high risk systems where failure of a control system can lead to serious harm with high probability (e.g. an infusion pump, infant incubator), protection systems should be periodically checked, to make sure they are reliable over the lifetime of the device.

Most implementations use self checking initiated by the CPU.

The requirements for an infusion pump in -2-24 are limited to the overinfusion protection and the air detector.

For overinfusion, the protection normally works by watching a feedback signal from an encoder attached to the motor. Since the motor is normally a stepping type, this is not used for control. Since the signal is dynamic (on/off/on/off etc), failures in the encoder itself are failsafe and can be ignored in the self test function. Tests for the rest of the protection system normally include:

- RAM test
- ROM test
- CPU test (ALU sample calculations, functions)
- branch condition tests
- WDT test
- safe state actuator test (e.g. MOSFET used to kill power to the motor)

If a 2 CPU system is used, these can be done every administration set interval (typically once every 24hrs).

For air detector, the standard requires test in a shorter interval. Since air is considered a normal condition, failure of the protection at any time could be dangerous. The interval should be less than the time it takes for a bubble to reach the patient at maximum infusion rate.

This is normally implemented by a periodic stopping of the ultrasonic transducer (or what ever is used to sense the air), and verifying that a stopped signal is seen correctly on the receiving side of the circuit.

If 2 CPUs are used, usually both CPUs watch the air detector signal. In this case, periodic testing of the CPU is not required for this purpose.

However, it is not uncommon for a single CPU system to be used.

In this case, TUVs require that the CPU is continuously self testing itself, using similar tests above (RAM/ROM etc) but with greater depth. Care should be taken to separate RAM and ROM used for control and protection system, and use diverse methods as far as possible. Special monitoring of the CPU power supply (e.g. 5V or 3.3V is needed), and the construction/implementation of the WDT is also critical. In truth these methods are weak and not validated as being effective, but CPUs so rarely fail that the methods don't get tested in practice.

This is really a big, specialized and important subject so better to seek profession external help if this is the first time.
 

Roland chung

Trusted Information Resource
#3
Peter, greatly appreciated for your insight. There two more issues need your help.

In regard to the clause 51.5 b), the standard requires a means to protect the patient from overinfusion caused by the free flow conditions. The intent of requirement actually simulates the patient movement which can cause free flow. But I have no idea what type of the means should be employed?

For clause 51.102, since technical fault could cause the motor to rotate in the wrong direction, a method used to prevent reversal of motor shall be provided during the treatment. The approach I can bethink of is to monitor the duration of first revolution. Is it enough?

Thanks,
Roland
 

Peter Selvey

Staff member
Super Moderator
#4
51.5b - seems they expect a sudden drop in pressure might cause free flow, but I never saw such a case and don't know the exact mechanism. Most infusion pumps use a peristaltic motion (worm drive) which fully occludes the tube at all times. Blood pumps in dialysis don't occlude to avoid cell damage, so maybe non-occluding pumps do exist, which might be more susceptible to free flow.

51.102 - from memory a three phase (3 wheel) encoder. The system watches for the correct sequence: A, B, C not C, B, A. There are other possibilities, for example, watching for correct sequence of pulses to the motor drive, if it has more than 2 phases.
 

Roland chung

Trusted Information Resource
#5
Hello peter,

I have questions on the RAM and ROM test before treatment as part of the boot sequence.

For RAM test (it is a walking pattern test), we just test the critical data. This means not all of data are checked. Do you think it is sufficient? Is it necessary to test the whole RAM?

For ROM test (it is a CRC test), since the startup test programs also stored in the ROM, I am wondering how to test the whole ROM.

Please kindly share your knowledge. Thanks in advance.

Roland
 

Peter Selvey

Staff member
Super Moderator
#6
The answer can depend on whether you are using 1 or 2 CPUs. If it is 1 CPU system (CPU with both control & safety) then you need to look very closely at any justifications. For 2 CPUs, the testing is not all that critical.

For the RAM side, normally there are registers or an area of "local" RAM which the CPU (and compiler) uses without the programmer specifically allocating, make sure this RAM is included in the tests. Also using the term "critical RAM" might not be enough; any RAM used by the protection system should be tested. If the programmer knows how the compiler uses RAM it could be possible to separate out this RAM for testing.

For the ROM, it is a similar case, test any ROM associated with the protection function. The start up tests themselves are not technically part of the "protection" as required by the standard (e.g. air detector, overinfusion etc), so they can be excluded.
 

Roland chung

Trusted Information Resource
#8
I have two more questions on the infusion pump. Any thoughts will be appreciated.

1) Problem for alarms monitoring in battery operated mode. Since the processor and buzzer also powered by the same battery which is being monitoring, the alarm duration could be short if the battery is aged or faulty (battery failure is not uncommon). This would place the patient at high risk if the pump is infusing a critical drug and stopping without enough alarm duration to get attention. I am wondering if it is sufficient by means of checking the status of the battery during the startup test.

2) A wrong supply voltage would be a common mode failure. The over/undervoltage monitoring is therefore expected. But is it necessary to have a monitoring system to detect the output of the switching power supplies? Actually, switching power supplies already have over/undervoltage protections (realized by feedback loop).

Regards,
Roland
 

Peter Selvey

Staff member
Super Moderator
#9
1) Battery
From experience (several manufacturers), "state of the art" seems to be using the same battery to power the circuit that monitors battery voltage and provides the alarm. Trigger points for 1st (low battery, 30 min remaining) and 2nd (infusion stop) alarms are based specific battery voltages. IEC 60601-2-24 does not specify conditions of test, so tests are typically done with a new battery.

However, as you correctly pointed out, this method does not work with a defective or aged battery, because the battery voltage falls much more quickly with time.

A good risk analysis would clearly identify the risk as unacceptable, if the infusion pump is intended for use with drugs which keep the patient alive.

Baxter had a worldwide recall of their colleague infusion pumps, one the key causes was the pump simply stopped infusion without providing an alarm, resulting in patient deaths. I believe battery was part of the issue.

The situation would imply that a 2nd, small but reliable battery is required which has the sole purpose of providing an alarm in case the 1st battery fails. But there could be other solutions.

2) Power supply voltage monitoring
Case by case depending on the effect of out of tolerance power supply voltage.

Example 1: main SMPS output with +24Vdc only. System has two CPUs (one control, one protection), and each CPU has a separate regulator to step down +24V to +3.3V supply and no low impedance connection between CPUs. In this case there really is not much concern. Typical SMPS overvoltage protection is enough.

Example 2: Main SMPS with multiple outputs, one of which is +3.3V which powers a single CPU used for both control and protection. In this case, SMPS overvoltage and undervoltage protection must ensure pump stops if the 3.3V supply exceeds the tolerance of the CPU, or additional protection (e.g. additional voltage monitoring circuit) is required.
 

Roland chung

Trusted Information Resource
#10
Peter, your opinion is always helpful.

I have just reviewed the FprEN 60601-2-24:2009, there is a point to be voted. I would think it makes sense.

The battery of the INTERNAL ELECTRICAL POWER SOURCE shall be SINGLE FAULT SAFE for LIFE-SUPPORTING ME EQUIPMENT.
The test conditions are also specified clearly.

Compliance is checked by inspection and functional tests when the ME EQUIPMENT is operated at the INTERMEDIATE RATE and with a new and fully charged battery.
Actually, I am also struggling the wording that used to describe the 1st and 2nd battery alarms in IEC 60601-2-24:1998.

EQUIPMENT which utilizes an INTERNAL ELECTRICAL POWER SOURCE either as a primary or standby supply shall give an audible and visible warning 30 min before delivery ceases due to battery exhaustion.
It seems that the 1st alarm also related to infusion stop.

At least 3 min before the end of the battery life the EQUIPMENT shall give an audible and visible alarm and cease delivery. The alarm shall be maintained for the duration of the remaining battery lifetime.
I am totally confused for the end of the battery life. It is no doubt that the pump would stop at a specified low battery voltage. This low limit is set for protecting against the overdischarge of the battery (to stretch the lifetime of battery).
 
Thread starter Similar threads Forum Replies Date
DuncanGibbons Section 8.3 relevant for design organisations AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
P DFMEA - Machinery Design Best Practices FMEA and Control Plans 0
R Is a FAIR required on parts that we design? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C Stress / Challenge Conditions for Design Verification Testing to Reduce Sample Size 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 11
J Significant change related to design and intended use EU Medical Device Regulations 3
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
U NOC - What is considered a "design change" EU Medical Device Regulations 5
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 9
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 5
K Joint approval between OEM and Manufacturer on Design Documents ISO 13485:2016 - Medical Device Quality Management Systems 4
M API 4F/7K/8C Design Package Validation Oil and Gas Industry Standards and Regulations 2
A Design History File - Not ready to share the design drawings or Bill of Material US Food and Drug Administration (FDA) 2
W Need for current design or process control FMEA and Control Plans 2
A What is the difference between Design Process, Process Design and Design Control? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
D Test summary report example for design validation wanted - ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
B Why the Greek god Hephaestus should have done a design FMEA (DFMEA) on his giant robot APQP and PPAP 1
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Qualification and Validation (including 21 CFR Part 11) 5
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
A Sample Agreement available for Outsourcing Medical Device Design activity? ISO 13485:2016 - Medical Device Quality Management Systems 1
DuncanGibbons How is the arrangement between Design and Production organisation envisaged? EASA and JAA Aviation Standards and Requirements 4
L Design & Development of a SERVICE Service Industry Specific Topics 13
C Documentation for items used for Design Verification 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Design verification driven by new equipment. How is this different than process validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A AS9102B - 3.6 Design Characteristics and form 3 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
P Design FMEA - Detection Rating criteria ISO 14971 - Medical Device Risk Management 3
U Medical Device Design finalization testing ISO 13485:2016 - Medical Device Quality Management Systems 2
S MDR Delay - MDD design Change? (before new MDR DOA) EU Medical Device Regulations 8
J Iterative design and production for custom made products ISO 13485:2016 - Medical Device Quality Management Systems 3
T Design Input detail & specificity ISO 13485:2016 - Medical Device Quality Management Systems 4
J Design file for pre-existing products - Inputs and Outputs ISO 13485:2016 - Medical Device Quality Management Systems 5
D Design Transfer Template capturing Customer Specific Requirements Other Medical Device Related Standards 3
T Design Control Procedures later in the Development Process ISO 13485:2016 - Medical Device Quality Management Systems 6
M Looking for a Presentation on Design for Excellence (DfX) Manufacturing and Related Processes 2
K Old medical devices -> 7.3.7. Design and development validation ISO 13485:2016 - Medical Device Quality Management Systems 1
R Design and Manufacture Guidelines for Surface Mount Technology Misc. Quality Assurance and Business Systems Related Topics 9
optomist1 Design Exclusion, but now we might have an outsourced Product Design ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
Q Relabeler for patent expired product - design control responsibilities? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
B Supplier of design and manufacture process ISO 13485:2016 - Medical Device Quality Management Systems 10
I Does anybody use Detection in medical device Design FMEA? ISO 14971 - Medical Device Risk Management 18
A Design process goal for ISO 9001 Manufacturing and Related Processes 23

Similar threads

Top Bottom