a safe, low-cost IV fluid warmer solution; for when commercially available IV fluid warmers are too expensive or cannot be sourced

Similar projects worth following
The OpenFluidWarmer is a safe, low-cost, easy-to-manufacture solution that provides IV fluid warming capabilities to those with few financial resources or sourcing options. Some IV fluid products must be stored at temperatures below human body temperature. The OpenFluidWarmer reduces the risk of hypothermia in the patient by warming the IV fluids to body temperature before they are administered.

Together we can make IV fluid warmers accessible to everyone. If you have medical device product development, embedded software, hardware design, or business development experience and are interested in contributing to this project, please private message John Opsahl ( through or click the "join this project's team" in the left column of this project page.

The Problem

"Commercial fluid warmers are either cost prohibitive in many contexts or not available for purchase" (Field Ready Fluid Warmer Open Challenge, Hackaday Prize 2020). 

The Solution

An IV fluid warmer solution that incorporates all industry standard safety features and solves the difficult cost and sourcing challenges encountered when constructing this device anywhere in the world.

The Impact

  • A safe, low-cost IV fluid warming solution that is accessible worldwide.
  • A reduction in the cost of commercially available fluid warming solutions either by market pressure from a lower cost option or by adoption of the OpenFluidWarmer approach.
  • A proven product development path for open-source electromechanical medical devices.

Hackaday Prize 2020 Judging Criteria

i. Concept. The OpenFluidWarmer has the potential to become one of the world's first open source life-critical medical devices. Achieving this status requires an innovative new take on IV fluid warmer design. It must incorporate all industry standard safety features and solve the difficult cost and sourcing challenges involved with constructing this device anywhere in the world. 

ii. Design. From product requirements to FMEA and competitive analysis, all design documents are shared in the "Files" section of this project. In addition, significant design efforts and milestones are documented in the "Project Logs". The design will undergo rigorous verification before being released to the public. A user manual will provide instruction on operating procedure, safety hazards, maintenance, and troubleshooting.

iii. Production. Reproducibility is at the core of the OpenFluidWarmer design. Through common off-the-shelf components, widely accessible fabrication techniques, and a flexible design that can accept multiple alternative components, the OpenFluidWarmer will solve the cost and sourcing challenges encountered when constructing this device anywhere in the world. An assembly manual will guide users step-by-step through the assembly process. 

iv. Benchmark. A competitive analysis was performed to understand how the OpenFluidWarmer compares to commercially available IV fluid warmers (see "OpenFluidWarmer_competitive_analysis" in the "Files" section of this project). The most significant findings from the competitive analysis are discussed in this "Competitive Analysis" project log. The price and quantity of each item used in the device is detailed in the "OpenFluidWarmer_BOM" document in the "Files" section of this project.

v. Communication. All significant project efforts have been documented on the OpenFluidWarmer project page so others can quickly become familiar with the current design and the processes used to develop it.

Development Milestones

  1. Initial system architecture and cost study, complete
  2. Initial mechanical design, complete
  3. Heat transfer proof-of-concept prototype, complete
  4. Code development, complete
  5. Proof-of-concept prototype testing, complete
  6. Redesign of heat transfer approach, in progress
  7. Add software faults, in progress
  8. Optimize wiring layout, not started
  9. Field prototype, not started
  10. Field prototype testing, not started

Adobe Portable Document Format - 339.88 kB - 09/28/2020 at 03:53



product requirements, design targets, product classification

sheet - 15.09 kB - 09/24/2020 at 04:34



bill of materials, component pricing, component common use, component source

sheet - 15.34 kB - 09/23/2020 at 03:39


Portable Network Graphics (PNG) - 541.30 kB - 09/26/2020 at 01:46



prototype heater control Arduino sketch

ino - 4.06 kB - 09/26/2020 at 02:00


View all 8 files

  • 1 × Bill Of Materials See "OpenFluidWarmer_BOM" document in the Files section of this project for a complete bill of materials.

  • Two Hot Plate Prototype Thermal Specs

    John Opsahl12 hours ago 0 comments

    The two hot plate prototype is showing promising fluid warming capabilities at the 20mL/min target flow rate! 

    For Test 1 and 2, I increased the heater set points until the outlet temperature was within +/- 2°C of 38°C human body temperature. I hit the functional limit of the heater setpoints during test 2 before outlet temperature was near the target.

    Test 1, approx 20°C inlet temperature:

    • fluid flow rate, 20mL/min
    • inlet temperature, 19°C
    • outlet temperature, 36.5°C
    • total fluid temperature rise, 17.5°C
    • heater-off set point, 105°C
    • heater-on set point, 103.5°C
    • max observed temperature, 112°C
    • ambient temperature, 28°C

    Test 2, approx 4°C inlet temperature:

    • fluid flow rate, 20mL/min
    • inlet temperature, 6°C
    • outlet temperature, 26°C
    • total fluid temperature rise, 20°C
    • heater-off set point, 105°C
    • heater-on set point, 103.5°C
    • max observed temperature, 112°C
    • ambient temperature, 24°C

    Seeing that the device could not achieve an outlet temperature within +/- 2°C of 38°C. I decided to lower the flow rate to find how close I could get to 38°C outlet temperature. Lowest flow rate that the peristaltic pump can run at is 13mL/min. The 7mL/min drop in flow rate resulted in a 7.5°C greater temperature rise!

    Test 3, approx 4°C inlet temperature:

    • fluid flow rate, 13mL/min
    • inlet temperature, 6°C
    • outlet temperature, 33.5°C
    • total fluid temperature rise, 27.5°C
    • heater-off set point, 105°C
    • heater-on set point, 103.5°C
    • max observed temperature, 112°C
    • ambient temperature, 24°C

    Test 4 was run at 64mL/min flow rate to understand temperature rise at higher flow rates. It showed a 8°C temperature rise.

    Test 4, approx 4°C inlet temperature:

    • fluid flow rate, 64mL/min
    • inlet temperature, 5.5°C
    • outlet temperature, 13.5°C
    • total fluid temperature rise, 8°C
    • heater-off set point, 105°C
    • heater-on set point, 103.5°C
    • max observed temperature, 112°C
    • ambient temperature, 24°C

    All and all, I am very happy with what this first prototype was able to achieve. With more development of the heat transfer approach, this device has great potential at flow rates of 20mL/min and below.

  • Constructed Using Widely Available Fabrication Techniques

    John Opsahl3 days ago 0 comments

    The image above details all the tools that were used to build the OpenFluidWarmer proof-of-concept prototype. I already had all of these tools in my toolbox. But if someone was on a tight budget and didn't already have the tools, they could get all the tools they needed for less than $200. Perhaps more important than how much they cost to buy is how readily available these tools are. Chances are that if you own a toolbox, you have at least five or six of these tools already. In addition, their wide availability makes it easy for someone unfamiliar with how to use one of these tools to either look up how to use it online or find someone locally that is familiar with how to use it. 

    Looking back now, I think there are opportunities to reduce the number and cost of tools required. It was convenient to use a electric drill and drill bits on some parts of the build, but I could just as well as bored holes in the insulation foam by plunging in a hot soldering iron tip or by rotating a screw driver. Getting rid of the electric drill and switching to a butane soldering iron would remove the requirement for access to a wall outlet.

  • Prototype Heater Control Sketch

    John Opsahl4 days ago 0 comments

    The OpenFluidWarmer prototype Arduino sketch is detailed below. See the latest version of "OpenFluidWarmer_PrototypeSketch_MM-DD-YYYY.ino" in the files section of this project for the most up to date version of this code.

    This sketch reads temperature from four thermistors (two per heater). Based on whether these temperature readings are above or below the hard coded temperature set points, the sketch will either send a command to the relays to close (and power the heaters) or do nothing.

    // OpenFluidWarmer Prototype Sketch
    // Inputs: 2 thermistors per heater
    // Outputs: 1 relay per heater, indicator lights, buzzer
    #include <math.h>
    const int heater_pin[3] = {2, 3};
    const int led_pin[4] = {4, 5, 6}; // red, yellow, green
    const int buzzer_pin = 7;
    const int thermistor_pin[5] = {A0, A1, A2, A3};
    float thermistor[5]; // degC
    bool heater_state[3] = {false, false};
    bool warmup_complete = false;
    const unsigned long led_blink_delay = 1000;
    unsigned long led_blink_time = led_blink_delay;
    const float heater_off_temp = 52.5; // degC
    const float heater_on_temp = 50.0; // degC
    const float V_0 = 5.0; // V
    const float R_2 = 100000; // Ohm
    // thermistor fit coefficients
    const float c1 = 0.8272069482e-3;
    const float c2 = 2.087897328e-4;
    const float c3 = 0.8062131944e-7;
    // averaging size
    int avg_size = 10; 
    void setup() {
      pinMode(heater_pin[0], OUTPUT);
      pinMode(heater_pin[1], OUTPUT);
      pinMode(led_pin[0], OUTPUT);
      pinMode(led_pin[1], OUTPUT);
      pinMode(led_pin[2], OUTPUT);
      pinMode(buzzer_pin, OUTPUT);
      digitalWrite(heater_pin[0], LOW);
      digitalWrite(heater_pin[1], LOW);
      digitalWrite(led_pin[0], LOW);
      digitalWrite(led_pin[1], LOW);
      digitalWrite(led_pin[2], LOW);
      digitalWrite(buzzer_pin, LOW);
      Serial.println("Setup Complete");
    void loop() {
      for (int i=0; i<4; i++){
        // loop over several values to lower noise
        float loop_sum = 0.0;
        for (int j=0; j<avg_size; j++){
          int sensorValue = analogRead(thermistor_pin[i]);
          float voltage = (sensorValue/1023.0)*V_0;
          float R_1 = R_2*((V_0/voltage) - 1.0);
          float logR1 = log(R_1);
          loop_sum += (1.0 / (c1 + c2*logR1 + c3*logR1*logR1*logR1));
        // average values from loop
        thermistor[i] = loop_sum/float(avg_size)-273.15;
      // average the thermistor readings
      float thermistor_avg[3] = {0, 0};
      for (int i=0; i<2; i++){
        for (int j=0; j<2; j++){
          thermistor_avg[i] += thermistor[j+2*i];
        thermistor_avg[i] /= 2.0;
      float thermistor_sys_avg = (thermistor_avg[0]+thermistor_avg[1])/2.0;
      // readout for Celsius and Fahrenheit
      Serial.print("Thermisor: ");
      Serial.print(" ");
      Serial.print(" ");
      Serial.print(" ");
      Serial.print(" Side Average: ");
      Serial.print(" ");
      Serial.print(" System Average: ");
      // bang-bang heater control
      for (int i=0; i<2; i++){
        if (thermistor_avg[i] < heater_on_temp && heater_state[i] == false) {
          digitalWrite(heater_pin[i], HIGH);
          heater_state[i] = true;
          Serial.println("heater on");
        else if (thermistor_avg[i] > heater_off_temp && heater_state[i] == true) {
          digitalWrite(heater_pin[i], LOW);
          heater_state[i] = false;
          Serial.println("heater off");
      // blink yellow LED during warmup period, turn on green LED when warmup period is over
      if (warmup_complete == false){
        if (millis() > led_blink_time){
          digitalWrite(led_pin[1], LOW); // turn off yellow LED
          led_blink_time = millis() + led_blink_delay;
        else {
          digitalWrite(led_pin[1], HIGH); // turn on yellow LED
          digitalWrite(buzzer_pin, HIGH); // turn on buzzer
          digitalWrite(buzzer_pin, LOW); // turn off buzzer
        if (thermistor_avg[0] >= heater_off_temp && thermistor_avg[1] >= heater_off_temp){
          warmup_complete = true;
          digitalWrite(led_pin[1], LOW); // turn off yellow LED
    Read more »

  • Pitch Deck

    John Opsahl4 days ago 0 comments

  • Prototype Wiring Diagram

    John Opsahl5 days ago 0 comments

    The OpenFluidWarmer prototype wiring diagram is depicted above. The "OpenFluidWarmer_BOM" spreadsheet in the files section of the OpenFluidWarmer page details a complete bill of materials and where to source each component.

  • Thermal Test Plan

    John Opsahl09/20/2020 at 16:06 0 comments

    The goal of the the thermal test plan is to evaluate the thermal performance of the existing two hot plate and new "tube" heat transfer prototypes against the OpenFluidWarmer design requirements.

    Heater Set Point Test

    Determine heater set point required to achieve 38°C outlet temperature at the following conditions (max allowable heater set point of 100°C):

    • 4°C inlet temperature, 20ml/min
    • 20°C inlet temperature, 20ml/min

    Flow Rate Test

    Determine the maximum possible flow rate that keeps outlet temperature above 20°C at the the following conditions:

    • 100°C heater set point, 4°C inlet temperature
    • 42°C heater set point, 4°C inlet temperature


    • 4°C is the storage temperature of some blood products
    • 20°C is assumed room temperature
    • 38°C is assumed human body temperature
    • 42°C is the assumed lowest temperature at which hemolysis begins to occur
    • 100°C is near the maximum allowable temperature of the prototype insulating materials
    • 20ml/min is the lowest "fast" flow rate determined by Field Ready's previous "Low-cost Fluid Warmer" project

    Test results will be posted later this week.

  • A promising new heat transfer concept

    John Opsahl09/18/2020 at 03:15 0 comments

    It's always encouraging to arrive at a promising new design concept this far into product development. It signals to me that all the work I put into developing and testing earlier prototypes (that have resemblance to commercially available IV fluid warmers) was an exercise in "learning the rules". Now that I know the rules, it's much easier to imagine new ways to break them. 

    This new IV fluid warmer heat transfer concept, depicted in the images above, is my latest attempt at breaking the rules. It has potential to be cheaper and perform better thermally than the existing two hot plate design. It uses two low cost silicone pad heaters for deicing windshield wipers (didn't even know they were a thing, but they are readily available online) on two sides of the IV tube. Using these long, thin heaters results in a thermal contact area between the heater and the IV tube that is double the existing design. So potentially, these heaters do not have to be heated to as high of a set point as the existing design to achieve a similar rate of heat transfer to the fluid. While this new concept uses double the length of IV tubing, it can be bent to whatever shape is needed and allows the full length of tubing to be used (i.e. doesn't double 24in of tubing back on itself to result in only 12in of length).

    It may be that using double the length of IV tubing is a deal breaker on this design, but there is always opportunity to not use the full length of the silicone heater and still achieve more thermal contact area between the heater and IV tube than the existing two hot plate design.

    Heaters have already arrived. Waiting on the thermistors to arrive so I can more accurately measure heater temperature. Should have thermal test results for this late next week.

  • Medical Use, Prototype Updates, Demonstration

    John Opsahl09/17/2020 at 04:52 0 comments

    This video explains the basics of how and why IV fluid warmers are used, describes recent updates to the OpenFluidWarmer prototype, and gives a short demonstration on how to operate the OpenFluidWarmer.

  • Thermal Peformance Testing - Round 2

    John Opsahl08/29/2020 at 16:26 0 comments

    The second round of performance testing with this device shows promising results. The main change to the system since the last round of tests is that the built-in 65 degC thermostat has been removed from the silicone pad heaters. The thermostat was previously limiting the max temperature measured by the thermistors at the hot plates to 48 degC. During this round of testing, the max temperature measured by the thermistors at the hot plate was 110 degC. 

    More background on the thermistor locations and length of IV tubing in contact with the hot plates is needed in order to give full context to the results. Two thermistors at located near the top and bottom of each hot plate and on the same side of the plate as the IV tubing. The thermistors are attached to stainless steel tray of the hot plate using foil tape tape. In the image below you can see them on the left hot plate. For the right hot plate, the thermistors are underneath the foam at similar locations. Each hot plate heater is controlled independently based on the average reading of the two thermistors. The length of tubing in contact with the hot plates is 660 mm (26 in). 

    The first test involved determining what hot plate temperature set point and flow rate was required to heat room temperature water to 38 degC. I eventually had to turn pump speed down to 50% in order to get a significant fluid temperature rise with a heater-off set point less than 90 degC.

    Test parameters and results of the first test:

    • inlet temperature, 27.5 degC
    • outlet temperature, 38.0 degC
    • total fluid temperature rise, 10.5 degC
    • pump speed, 50%
    • fluid flow rate, approximately 32.5 mL/min
    • heater-off set point, 88 degC
    • heater-on set point, 86.5 degC
    • max observed temperature, 92 degC

    The second test involved determining what hot plate temperature set point was required to heat ice cold water to 38 degC. It was able to achieve a outlet temperature of 27.5 degC at a heater set point of 105 degC. I wasn't confident how much higher I could push the heater before degradation to the polystyrene insulation foam so I stopped at the 105 degC set point. Inspection after this test showed no damage to the polystyrene so I plan to push the set point higher on the next round of testing.

    Test parameters and results of the second test:

    • inlet temperature, 4.5 degC
    • outlet temperature, 27.5 degC
    • total fluid temperature rise, 23 degC
    • pump speed, 50%
    • fluid flow rate, approximately 32.5 mL/min
    • heater-off set point, 105 degC
    • heater-on set point, 103.5 degC
    • max observed temperature, 110 degC

    92 degC and 110 degC max observed temperatures during the two tests is far above when hemolysis can begin to occur at 42 degC. Until I have the capabilities to prove that hemolysis does not occur at the max temperatures, it is recommended that the device not be used with red blood cell and other blood products damaged by temperatures above 42 degC. This relaxation in requirements is needed to maintain the strategy of heating the fluid through standard PVC IV tubing (i.e. not requiring a custom/expensive sterile in-line high heat transfer module) and using up minimal length of IV line through the device. A rethinking of the OpenFluidWarmer may be needed to achieve the original product requirements.

    The next round of testing will identify what heater temperature set point is required to achieve 38 degC outlet temperature with a 4 degC inlet temperature. 

  • Thermal Performance Testing - Initial Results

    John Opsahl08/13/2020 at 00:58 0 comments

    Thermal performance testing with IV tubing sandwiched between two 100W silicone heaters has continued over the last week. 

    I am waiting to publish test data until I make one more modification to the device. During testing I discovered that the silicone heater pads have a built-in thermostat switch that opens when the thermostat reaches 65 degC. I have since removed the thermostat so I can have more refined control over the heat generation for the next few tests.

    As expected, initial tests indicate that thermal insulation of the PVC tubing greatly limits the rate of heat transfer to the fluid. The simplest solution to this would be to increase the length of tubing that is in contact with the hot plates. Unfortunately, initial results indicate that at least three times the current tubing length would need to be in contact with the hot plates to achieve the desired outlet temperature of 38 degC. Further testing without the thermostat on the heater pads may change these results.

    The IV tubing I am using is from a veterinary infusion fit that I bought online. It is a PVC tubing with 3mm ID and 0.5mm wall thickness. 

    I put the peristaltic pump motor on a speed controller to achieve lower flow rates. Even at 50% speed, there was no significant change to the temperature rise between the inlet and outlet.

    It is clear that the heater will need to be heated to a setpoint above 42 degC in order to achieve the desired fluid outlet temperature with the current device configuration. Unfortunately, 42 degC is the temperature at which hemolysis can begin to occur in red blood cell products. It is beyond the current capabilities of this test setup to determine if temperatures in excess of 42 degC are present and in contact with the fluid at heater setpoints above 42 degC.

View all 20 project logs

  • 1
    Assembly instructions and user manual to follow after completion of the first version of the OpenFluidWarmer.

View all instructions

Enjoy this project?



Enceladus wrote 07/15/2020 at 05:45 point

Hey there. I wanted to make sure I fully understood everything before commenting.

With being a class IIb device and hitting the other regs makes QA/QC kind of straightforward.

You'll need to quality control the firmware, which means, among other things you'll need version control, commit signatures, a bug tracking system, and release testing.

For the firmware release testing you'll need to basically trigger each of the code paths and make sure they work as intended. This means causing each of the 9 faults and verifying the lights and buzzer plus the normal operation ping. The rest of the testing can be saved for the finished product testing. For firmware testing you can use "tricks" such as a resistor or controlled current to simulate temperature, but for product testing you'll need to include the assembled thermistor in the loop.

For each produced unit you'll want to do QA that consists of build integrity (seal condition, etc) as well as functional testing. For functional testing you'll want to ensure that it is able to meet the product specs (i.e. warm from 4deg to 36deg in x seconds, warmup time, flow rate etc). It sounds like a lot but you could trigger the hot/cold with ice cubes and hair dryer. Getting it at exactly 42c etc. is only necessary for the firmware testing, for finished product testing you can overshoot.

You might want to build a testing rig that can test many units at once to not cause a bottleneck in production. Probably 5 is a good minimum but 6 is a very divisible number for handling stock requests on the fulfillment side.

To test warming and flow you could use some kind of analogue. I'm not aware of if there is any official analogs for blood but I'd guess some sort of formulation of water and baking soda could do it. You'd have to of course match the specific heat and viscosity.

QC for finished product consists of verifying QA paperwork is completed properly and signed off, and visual inspection. Visual inspection should be thorough and track things that wouldn't even affect operation such as scratches or extraneous sealant or solder, etc. You should have a library of common defects and their severity, with example photos of each kind of defect. One allowable severity is "cosmetic" and doesn't necessarily fail the QC (unless you want it to).

Assemblers and inspectors should have documented training (a signed log that once a year or release version or whatever is reasonable, they have reviewed the product design manual / inspection procedures)

You should also include in the product documentation a suggested QC for incoming materials, although it may need to be customized to suit individual material choices and sources.

One thing you may want to consider is putting a lifetime operating hours counter in the unit. I'm not sure if the Nano has an RTC or nonvolatile storage but they can be added for very little cost.

I understand you want parts to be easily available too but thinking as a user it might be nice to have a version of the product which uses an LCD screen with full operating status, even if it makes IP54 more difficult. If I was operating one of these things I'd want to see Lifetime power-on, time since power-on, current temp, Alarm history log, estimated flow rate, battery remaining, etc.

Adafruit/digikey has a display for only $10 surprisingly ( ). Might also be able to double as non-volatile storage.

That's probably plenty to start. Hope it helps! Each part can be expanded on in great detail when the time comes.

Oh one more thing you probably want to test at least once, having several fully charged batteries ready then operating the thing for many days on end without interruption and make sure it doesn't overheat the Nano or something. In a variety of ambients (like a desert field hospital). You just know someone will use it in this way...

  Are you sure? yes | no

John Opsahl wrote 07/15/2020 at 15:11 point

Enceladus, this is fantastic! Thank you for the feedback. 

The firmware release testing and functional testing will probably get lumped under what I will call design verification testing. I've got several more weeks of mechanical design work and code development before I will be ready for those tasks.

The topic that I was very glad you touched on was how to ensure quality of the final product when assemblers have an unknown level of assembly experience and materials choices and sources may be different for each build. It has been in the back of my mind since I started this project, and I haven't been able to see a clear path forward until now. 

I really like the idea providing a training path for each assembler to become a "certified OpenFluidWarmer assembler". Then requiring annual retesting to maintain the certification. Possibly only allow full access to the design documents without going through the certification process first. 

On QC of incoming materials, in addition to an inspection plan, I think it also makes sense to detail out the specification requirements for each component. That will provide the information needed to make an alternate material or component selections if any of the materials or components in the bill of materials cannot be sourced. 

This definitely gets me excited about the next stage of this project. So I may ping you later on in the project if that is okay. Right now though, I have to keep focus on a proof-of-concept prototype. QA/QC only helps if the design actually works. :)

  Are you sure? yes | no

Enceladus wrote 07/15/2020 at 23:11 point

You got it exactly right about incoming materials. Ping away...I'll be around

  Are you sure? yes | no

John Opsahl wrote 07/15/2020 at 15:39 point

Perhaps I can include a method to alert the user that the device should be tested/calibrated/maintained after a certain number of operating hours. 

I hadn't considered an alarm history log yet. That would be invaluable for troubleshooting and service of the device. Especially if the fault condition is hard to reproduce. 

With the current design, the only way to determine what condition is causing the fault would be to make a connection to the microcontroller and view any error messages on a serial monitor. This certainly isn't convenient for quick troubleshooting in the field. One of my ideas for a very low cost solution is to have two conductors on the outside of the device. One to microcontroller ground and one to an analog output pin. The microcontroller would output a different voltage from 0-5V based on the last fault condition that occurred. The user could measure across the two conductors with a multimeter and reference a table in the user manual to determine the cause of the fault.

  Are you sure? yes | no

Enceladus wrote 07/15/2020 at 23:14 point

Or you could output morse code text! 3.14159265359 volts for dit and

2.71828182846 volts for dah ;) jk

  Are you sure? yes | no

Enceladus wrote 07/15/2020 at 23:36 point

on a more serious note, BLE might not be a bad way to go either, then theoretically you could monitor multiple devices from a phone or tablet. There are modules out there in the $3-5 dollars range.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates