Project
Infusion Pump Flow Accuracy Verification Project
Biomedical engineering project for verifying infusion pump flow accuracy with gravimetric testing, rate profiles, startup delay, bolus accuracy, uncertainty budget, risk controls and release evidence.
This project produces a verification and release package for infusion pump flow accuracy. The goal is not only to show that the pump motor runs or that the display accepts a programmed rate. The goal is to prove that the complete pump, disposable set, fluid path, software configuration, calibration state and test method deliver the commanded volume within defined limits.
The example uses a volumetric infusion pump and saline test fluid. The workflow also applies to syringe pumps, ambulatory pumps, enteral pumps and service verification of installed pump fleets. Real medical-device work must use the applicable intended use, risk management file, manufacturer instructions, recognized test methods, clinical workflow, accessories, software version, and regulatory evidence.
Project objective
Verify flow accuracy for an infusion pump after a software-library update and preventive maintenance campaign. The final deliverable is a reviewable engineering package containing:
- intended-use boundary and pump configuration;
- disposable-set and fluid basis;
- gravimetric test method;
- rate-profile test matrix;
- startup delivery and bolus checks;
- uncertainty budget and guard-band rule;
- risk-control traceability;
- release decision and retest triggers.
This project is different from an occlusion-alarm review. Occlusion testing asks whether the pump detects a blocked downstream line fast enough. Flow-accuracy verification asks whether delivered volume matches the programmed delivery profile when the line is not occluded.
Verification basis
Use this simplified pump basis.
| Item | Project value |
|---|---|
| Pump type | volumetric infusion pump |
| Test fluid | saline substitute |
| Fluid density at test temperature | \rho=0.998\ \text{g/mL} |
| Main continuous rate | 5.0\ \text{mL/h} |
| Low-rate therapy profile | 0.50\ \text{mL/h} |
| Bolus command | 1.00\ \text{mL} |
| Main-rate test duration | 2.0\ \text{h} |
| Low-rate test duration | 4.0\ \text{h} |
| Flow accuracy requirement | \pm 5.0\% after guard band |
| Startup accuracy requirement | \pm 10.0\% over first 30\ \text{min} after guard band |
| Bolus accuracy requirement | \pm 5.0\% after guard band |
| Maximum uncontrolled post-test residual volume | 0.10\ \text{mL} |
The test uses a calibrated balance, a collection vessel, evaporation blank, stopwatch or synchronized data logger, controlled tubing height, specified backpressure condition, and the intended disposable set.
Acceptance criteria
Use these project acceptance criteria.
| Requirement | Acceptance value |
|---|---|
| Main-rate delivery error | inside \pm5.0\% with uncertainty guard band |
| Low-rate delivery error | inside \pm5.0\% with uncertainty guard band |
| Startup delivery error | inside \pm10.0\% with uncertainty guard band |
| Bolus delivery error | inside \pm5.0\% with uncertainty guard band |
| Test method uncertainty | stated and included in pass/fail decision |
| Disposable set | traceable lot and configuration |
| Software and calibration state | recorded and locked for release |
| Usability and alarm state | no test bypass left active after verification |
| Release evidence | raw data, calculations, deviations and disposition complete |
Acceptance should be defined before testing. Changing criteria after seeing results weakens the evidence and should trigger engineering review.
Step 1: Convert mass to delivered volume
The gravimetric method estimates delivered volume from collected mass:
where:
- m_{collected} is the measured net mass in the receiving vessel;
- m_{evap} is the evaporation correction from a blank vessel;
- \rho is fluid density at the test temperature.
For the main-rate test, the pump runs at:
for:
Expected volume:
Measured net mass:
Evaporation blank:
Corrected delivered volume:
Flow error:
Engineering comment
The measured flow is slightly low, but the raw result is well within the nominal \pm5\% requirement. The release decision still needs uncertainty and guard banding because a measurement near the limit could be falsely accepted.
Step 2: Check uncertainty and guard band
Use this simplified uncertainty budget for the main-rate test.
| Contributor | Standard uncertainty |
|---|---|
| balance repeatability and calibration | 0.004\ \text{mL} |
| evaporation correction | 0.010\ \text{mL} |
| density correction | 0.006\ \text{mL} |
| timing | 0.002\ \text{mL} |
| test repeatability | 0.015\ \text{mL} |
Combined standard uncertainty:
Use coverage factor:
Expanded uncertainty:
Relative expanded uncertainty for the 10.0\ \text{mL} test:
Guarded acceptance band:
The measured main-rate error is:
Because:
the main-rate result passes the guarded decision rule.
Engineering comment
Guard banding prevents a result near the acceptance limit from being accepted without enough measurement confidence. The guard band should be defined by the verification plan, not invented after testing.
Step 3: Verify low-rate delivery
Low-rate therapies are often more sensitive to startup delay, mechanism backlash, disposable-set compliance and quantization of pump movement.
Programmed rate:
Test duration:
Expected volume:
Measured net mass:
Evaporation correction:
Delivered volume:
Error:
Assume the expanded uncertainty for this smaller delivered volume is:
Relative uncertainty:
Guarded acceptance band:
Because:
the low-rate result passes, but with less margin than the main-rate test.
Engineering comment
Low-rate verification usually has less measurement margin because the delivered volume is small. A longer test, lower evaporation setup, better balance, or repeated runs may be necessary when the result is near the guard band.
Step 4: Check startup delivery
Startup delivery is reviewed over the first 30\ \text{min} at:
Expected volume:
Measured net mass:
Evaporation correction:
Delivered startup volume:
Startup error:
Assume expanded uncertainty:
Relative uncertainty:
Guarded startup band:
The measured error:
does not pass the guarded startup criterion.
Engineering comment
This is an engineering finding, not a mathematical inconvenience. The pump may pass average flow after two hours while underdelivering during startup. The release package should either improve startup compensation, restrict the affected profile, extend priming or stabilization instructions, or justify why the startup behaviour is clinically acceptable for the intended use.
Step 5: Verify bolus delivery
Bolus command:
Measured net mass:
Evaporation correction:
Delivered bolus:
Bolus error:
Assume expanded uncertainty:
Relative uncertainty:
Guarded bolus band:
Because:
the bolus result passes.
Engineering comment
Bolus testing should confirm delivered volume, command logging, user confirmation, cancellation behaviour, dose limit enforcement and post-bolus return to the programmed basal rate. A bolus feature is both a flow-control function and a usability-critical workflow.
Step 6: Trace findings to risk controls
Use the verification results to update the risk-control table.
| Hazardous situation | Evidence from this project | Control decision |
|---|---|---|
| underdelivery during low-rate therapy | low-rate test passes with limited guard-band margin | retain profile but monitor manufacturing and service variation |
| startup underdelivery | guarded startup test fails | require corrective action or profile restriction before release |
| unintended bolus error | bolus test passes | retain bolus function with dose-limit checks |
| wrong disposable set used | test is set-specific | label, lockout or compatibility controls must remain effective |
| occlusion alarm delay | not evaluated by flow test | rely on separate occlusion-alarm evidence |
| service release after software update | test tied to software version | release only for recorded software and calibration state |
Engineering comment
A failed startup check does not necessarily mean the entire pump design is unsafe, but it does mean release is not complete. The engineering action must be explicit: fix, retest, restrict, justify with clinical validation, or hold release.
Verification matrix
The final package should include:
| Evidence item | Required record |
|---|---|
| intended-use boundary | therapy profiles, patient population, clinical environment and disposable set |
| pump configuration | model, serial number, software version, calibration state and service history |
| test method | balance certificate, fluid density, evaporation blank, timing basis and setup geometry |
| main-rate raw data | mass readings, time stamps, calculated volume, error and uncertainty |
| low-rate raw data | mass readings, correction, guard-band decision and repeatability notes |
| startup test | first 30\ \text{min} result, failure disposition and retest plan |
| bolus test | command, collected mass, delivered volume, dose-limit confirmation |
| risk traceability | hazards, controls, verification evidence and residual decision |
| release decision | pass, conditional release, restriction, or hold |
Release decision
The project result is mixed:
| Test | Result |
|---|---|
| main-rate delivery | pass |
| low-rate delivery | pass with limited margin |
| bolus delivery | pass |
| startup delivery | fail under guarded criterion |
A suitable release statement is:
The infusion pump is not released for unrestricted use under the tested software and disposable-set configuration because startup delivery at the reviewed therapy profile does not meet the guarded acceptance criterion. Main-rate, low-rate and bolus accuracy results support the measurement method, but release requires corrective action, retest evidence, or a documented restriction that prevents use of the affected startup profile.
This statement is useful because it prevents a common error: averaging good long-duration flow results and ignoring a clinically important short-duration startup deficiency.
Common project mistakes
Common mistakes include:
- verifying only one nominal flow rate;
- ignoring startup behaviour and small-volume delivery;
- reporting mass without density, evaporation and timing corrections;
- accepting results near the limit without an uncertainty rule;
- testing a disposable set that is not the intended clinical configuration;
- treating occlusion-alarm evidence as proof of delivery accuracy;
- failing to tie a software update to retest scope;
- releasing the device after a failed subtest without a documented restriction or corrective action.
The practical rule is that flow accuracy is a system property. Pump mechanism, software, disposable set, fluid path, accessories, calibration and test method all affect the delivered therapy.