How to Design a Protective System for Infusion Pump

Roland chung

Trusted Information Resource
#31
Failure in protective systems against for overinfusion and reverse delivery should also become obvious to the operator. Why the self-test time depends on the time that air bubble can reach the patient? Even 10 s may be long enough to cause the overinfusion hazard, especially for infusing critical drugs.

A silly question: we frequently consider the failure of CPU, RAM and ROM, etc. All are hardware failures. Are there pure software failures?
 
Elsmar Forum Sponsor

Peter Selvey

Staff member
Super Moderator
#32
The reason that the air bubble protection needs special attention is that the "triggering event" is considered normal condition, i.e. caused by an empty bag or operator mistake, and with high severity (death). Therefore, if anything to do with the air bubble detector fails (detector, CPU, software), the patient is at significant risk.

The other protection is triggered only if there is a fault in the control system which is rare. If the protection fails, it's not immediately any risk; so a more relaxed timing of the self check is reasonable (e.g. once per day).

I'm not sure about the latest edition, but clearly in the previous edition, the timing for air bubble is separately stated to the other protection systems.

For software: like hardware, if there is separate control and protection, and good design controls (e.g. IEC 62304), the chances of a software bug leading to harm should be very remote because there are two systems.

However, for the air detector, there may be only one software routine. Even with the best design controls, it may not be enough. Good practice would be to have two software engineers write independent routines monitoring the air detector signals. Maybe if the structure of the software simple and well tested, you might be confident. But you need to be 99.9999% sure ...!
 

Roland chung

Trusted Information Resource
#33
If software likes hardware in regard to the failure, why test houses do not simulate the software faults? For software part, just documents review in medical industry. But I heard that other industries (e.g. gas appliances) are indeed required to simulate the software faults in addition to the documents review.
 

Peter Selvey

Staff member
Super Moderator
#34
You could be referring to a couple of things here.

When testing PEMS, you can use any many equivalent failure points in the system, mechanical, hardware or software, which give the same test result. For example, in an infant incubator you could modify the software to force the heater all the time; or you could short the heater SSR, or you could just put the control sensor in cold water. All force the heater on, and hopefully trigger the protection system, which itself could use software.

I prefer hardware faults for a number of reasons. So if you ask me to do the tests, you might feel the testing seems hardware based, but really it's representative of software faults in the control system, and also verifies the software in the protection system. So it is software testing.

But you might be asking why some test houses not do any testing at all once software gets involved. If it's just general PEMS, it's OK because the standard allows it. But if a particular standard calls for specific protection (like IEC 60601-2-24), then they should at least witness the manufacturer's testing, not just a doc review.
 
D

dionysisf

#35
Hello,

We are manufacturing ambulatory infusion pumps for more than 10 years in EU. We are using piezoelectric buzzers for the audio alarm system of the pumps covering the requirement for at least 45dBA at 1m.

We need help for the implementation of the 208.6.3.3.1 subclause of 60601-2-24:2012.
The specific subclause mentions that "because of the technique is used for the audible alarm source" and "it may be better to retain similar auditory ALARM SIGNALS in new devices, subject to a RISK assessment by the RESPONSIBLE ORGANIZATION".

How can we handle this? and what is the responsible organization?

According to Table 208.102, we comply only to the pulse frequency:
PULSE FREQUENCY (fo) 150 Hz to 3 000 Hz --> OK
Number of harmonic components --> Only main frequency
Effective PULSE duration (td) --> NOK
RISE TIME (tr) --> NOK
FALL TIMEa (tf) --> NOK

Thanks in advance for your help!
 
D

dionysisf

#36
Hello,

We are manufacturing ambulatory infusion pumps for more than 10 years in EU. We are using piezoelectric buzzers for the audio alarm system of the pumps covering the requirement for at least 45dBA at 1m.

We need help for the implementation of the 208.6.3.3.1 subclause of 60601-2-24:2012.
The specific subclause mentions that "because of the technique is used for the audible alarm source" and "it may be better to retain similar auditory ALARM SIGNALS in new devices, subject to a RISK assessment by the RESPONSIBLE ORGANIZATION".

How can we handle this? and what is the responsible organization?

According to Table 208.102, we comply only to the pulse frequency:
PULSE FREQUENCY (fo) 150 Hz to 3 000 Hz --> OK
Number of harmonic components --> Only main frequency
Effective PULSE duration (td) --> NOK
RISE TIME (tr) --> NOK
FALL TIMEa (tf) --> NOK

Thanks in advance for your help!

Any comments please!
 

Peter Selvey

Staff member
Super Moderator
#37
For harmonics, the fundamental (f0) is considered a harmonic, so for example the original standard requires 4, that actually means the fundamental plus 3 overtones. That's based on some research I did some time ago. So, you meet the second requirement as well.

For rise, fall and pulse time, probably good to update these according to the standard they are pretty flexible limits and reasonable.

For you, the reference to the responsible organisation is not relevant (in the normative text it is only for additional sound types, in the rationale it is just info not requirement). So, you only need to worry about the revised table, which is a relaxation on the more strict requirements in the original IEC 60601-1-8, so they are trying to help you.

By the way these requirements have been around for a long time, dating back to EN475 in Europe, published 21 years ago, and the first edition of IEC 60601-1-8 published 13 years ago.
 
D

dionysisf

#38
Hello Peter,

Thanks for your useful answer!

Our devices comply with IEC 60601-2-24 1st edition and are being used for more than 10 years.

According to Subclause 208.6.3.3.1 of IEC 60601-2-24 2nd edition:
"If OPERATORS are familiar with the auditory ALARM SIGNALS of existing INFUSION PUMPS or VOLUMETRC INFUSION CONTROLLERS which are not in accordance with IEC 60601-1-8, it may be better to retain similar auditory ALARM SIGNALS in new devices"

As we read this, it is not only for additional sound types, and we could keep the existing alarm design.

What do you think about this?

Thanks in advance!
What is your opinion on this?
 

Peter Selvey

Staff member
Super Moderator
#39
The quote is from the rationale which is the informative only. It is not a requirement, just extra info. Also it always needs to be read together with the normative text otherwise, it often to get the wrong impression.

In this case, when the normative text refers to the responsible organisation, it is with respect to the alternative alarm sound. So when the rationale refers to the same subject, it is in the same context.
 

Roland chung

Trusted Information Resource
#40
The clause 201.11.8.101.2 of 60601-2-24:2012 states that if the supply mains and the internal electrical power source BOTH fail, the equipment shall give an alarm signal of HIGH PRIORITY lasting for at least 3 min. This overrules the 60601-1-8 which allows a non-standard auditory alarm signal after power failure.
The particular standard actually requires a second backup power supply (big enough to store sufficient energy), not a super capacitor or button cell battery. Any comments?
 
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