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" link on 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, complete
  7. Redesign system architecture, in progress
  8. New architecture code development, in progress
  9. Optimize wiring layout, not started
  10. Field prototype, not started
  11. Field prototype testing, not started


product requirements, design targets, product classification

sheet - 15.55 kB - 10/18/2020 at 17:22


sheet - 16.33 kB - 10/18/2020 at 05:57



preliminary design review presentation

Adobe Portable Document Format - 1.07 MB - 10/05/2020 at 23:16


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



bill of materials for one unit, component pricing, component common use, component source

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


View all 10 files

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

  • OpenFluidWarmer Gen 2 Prototype

    John Opsahl11 hours ago 0 comments

    After about two and a half weeks of system design and component selections, it was very fun to finally see this second generation come together over the last four days. I started with writing the microcontroller prototype code. Then tested that code with the benchtop prototype and made corrections as needed. Once I was confident in the code, it took only a couple of hours to decide how to arrange the electronic components in the enclosure and put everything together. 

    I intend to cover the details of the operating procedure and how the device works in later project logs, but I think it makes sense to provide a high level overview here. The second generation OpenFluidWarmer uses a commercially available sous vide cooker to warm and maintain the temperature of a water bath. While the IV fluid is being administered, the operator immerses a length of IV tubing in the water bath. Heat from the water bath will warm the IV fluid as it flows through the length of IV tubing that is immersed in the water bath. The custom electronics assembly can be thought of as a "safety companion" for the sous vide cooker. It includes safety protections like redundant temperature monitoring, a sous vide cooker power disconnect, and fault detection and alerts.

    The next step is to develop and perform several tests to ensure that the device operates as intended. 

  • Benchtop Prototype and Operating Logic

    John Opsahl7 days ago 0 comments

    I assembled the benchtop prototype yesterday in about 20 minutes. I will be using it to test the Arduino code in the coming week. 

    All-in-all, the signals are very simple. Most of the microcontroller inputs and outputs only have two states - "on" or "off". Even for the 4 digit, 7 segment display and the water bath temperature sensors, there are existing code libraries that make controlling or reading from the components easy.

    Five microcontroller inputs:

    • two water bath temperature sensors
    • sous vide cooker power momentary push button
    • set point monitor momentary push button
    • IV tube switch

    Five microcontroller outputs:

    • sous vide cooker power button red LED ring
    • set point monitor button blue LED ring
    • 4 digit, 7 segment display
    • buzzer
    • sous vide cooker power relay

    The challenging part is developing the logic to enforce a conditional operating sequence. Enforcing which and when controls are available to the operator is a strategy to reduce the cognitive load on the operator as well as to prevent the operator from creating a hazardous condition. Ultimately, this approach is used to ensure the safety of the operator and the patient during device operation.

    With the understanding that detailed and easy-to-understand documentation is an important part of open-source design, I have taken the approach of documenting the operating logic in table format. It is something I made up and it does not yet capture all the nuances. I imagine there has to be a better format out there for this type of logic (pseudo code maybe?). Please leave a comment if you have a suggestion.

    The table below details the following statement in Boolean logic: "When the device is plugged in, the sous vide power standby and water bath temperature monitor will be activated." The columns represent only the objects that are effected by the control action. The initial conditions must be satisfied in order for the action to be valid. The final conditions are enforced once a valid control action has occurred.

    In the example above, the descriptive statement provides more clarity than the table. I find that the opposite quickly becomes true when documenting a control action that is dependent on multiple initial conditions and results in a multitude of final conditions.

    It's hard to identify gaps and improve the conditional operating sequence without a good comprehensive format. I know I can just start coding without a solid plan upfront and eventually arrive at the intended operating logic. For the OpenFluidWarmer, the goal is not to just arrive at the intended operating logic but also to justify each line of code and prove that all gaps are closed.

  • Hazard Analysis - risk reduction as-far-as-possible

    John Opsahl10/18/2020 at 05:54 0 comments

    A hazard analysis of the OpenFluidWarmer sous vide cooker design was performed using a reduction as-far-as-possible (AFAP) risk management approach (the latest revision of  the hazard analysis is "OpenFluidWarmer_HazardAnalysis" in the project files). The goal of the hazard analysis is to identify the harms and develop the mitigation controls for each significant hazardous condition that can occur during device operation. EN ISO 14971, an ISO standard detailing the application of risk management to medical devices, was used as a reference to perform the analysis.

    The OpenFluidWarmer hazard analysis identified six hazards (all with multiple potential causes) and four resulting harms. Many risk controls were identified to further reduce the probability of a hazard condition occurring, but none were identified that would reduce the severity of the harm once a hazard condition does occur.

    When following the AFAP approach, risk is to be reduced to the R1 rating (per image above) regardless of economic practicality. In cases where it is not possible to reduce risk to a R1 rating, a risk-benefit analysis is to be performed. The risk-benefit analysis must provide evidence (with no consideration given to economic practicality) that the medical benefits of using the device outweigh the residual risks. 

    The reduction as-far-as-possible risk management approach provides an exciting opportunity to explore the feasibility of electromechanical open-source medical devices like the OpenFluidWarmer. With the number of risk reduction controls required, adherence to AFAP risk reduction presents the most difficult cost challenges for the OpenFluidWarmer design. On the other hand, if it is possible to follow the AFAP risk reduction approach and achieve a low-cost, easy-to-manufacture, component-flexible design, that has huge implications beyond the development of just the OpenFluidWarmer. It means that it may be possible to develop other safe and economically practical open-source medical device designs; some that may even provide more medical benefit to the patient than IV fluid warmers.

  • New Prototype in Development

    John Opsahl10/16/2020 at 20:31 0 comments

    It was decided last week to explore what it would take to develop a safe OpenFluidWarmer design with a sous vide cooker. Testing showed that the constant temperature water bath method with the sous vide cooker was able to meet the thermal performance requirement that the previous two hot plate design could not. Since performance with the sous vide cooker has been so promising, the recent design effort has focused on improving the safety and reliability of the system. The image above is the latest build progress towards the OpenFluidWarmer sous vide cooker prototype.

    The most notable design compromise with the sous vide cooker design is the amount of time it takes for the device to warm up and be ready for use. The two hot plate design could warm up in less than 60 seconds from 25°C to 105°C. Whereas the sous vide cooker design takes about 11.5 minutes to warm the water bath from 25°C to the lower required heater set point temperature of 70°C. It is a little misleading to make this comparison because the two hot plate design was never able to meet the thermal performance requirement at the 105°C set point anyways. 

    At this time, I don't believe a warm up time close to 11.5 minutes to be a significant issue with this warmer. The device could be turned on 10 minutes before the procedure or run continuously during a procedure when need for warming IV fluids was anticipated. Then the IV tubing can be placed into the water bath at a moments notice when warming is needed.

    The sous vide cooker design starts to outshine the two hot plate design when it comes to operational redundancies and simplicity of assembly. The sous vide cooker itself includes an independent power button, temperature controller, and temperature display. The additional system housed in the electronics enclosure (what I am calling the sous vide cooker "safety companion") includes button controls, a sous vide cooker power disconnect, temperature monitoring, and state and fault indicator displays. If for whatever reason the sous vide cooker failed, the "safety companion" system will alert the user and potentially disconnect the power. If the "safety companion" failed, it's very possible that the sous vide cooker will continue to operate as intended without issue. Hardware redundancy really helps to ensure safe operation of the device. On top of that, it's very convenient that a full package, cost-optimized constant temperature bath solution like sous vide cookers are readily available for purchase. All you have to do is supply power to it.

    Instead, the two hot plate architecture only included one microcontroller/control system and no backups if that failed. Adding redundancies to the two hot plate architecture would greatly increase the complexity of the hardware, software, and assembly.

  • Architecture with Sous Vide Revision 1

    John Opsahl10/13/2020 at 04:56 0 comments

    The first design stage of this project was to find a solution that was capable of the required thermal performance. During this stage the sous vide cooker solution was found. The focus of this next design stage is minimizing the number and severity of operator and patient safety hazards as well as minimizing opportunities for human error in the operating procedure.

    The wiring diagram above depicts the first revisions from this second stage design effort. 

    The big changes:

    • No more toggle switches. Toggle switches are no longer used because they maintain state if the operator unplugs the device. So if the power switch was in the "on" state and the device was unplugged and plugged back in, the safety involved with the operator being able to anticipate and be confident in their ability to control the device state is compromised. Momentary push buttons are used instead.
    • Microcontroller is always powered. The microcontroller and associated safety features are always powered whenever the device is plugged in to the AC supply. Ensures that temperature of the water bath is always being monitored and displayed regardless of whether the sous vide device is on or off. 
    • 4 digit, 7 segment display. During normal operation, the water bath temperature will be displayed. When a fault occurs, the display will transition between the water bath temperature and the number and type of fault that is occurring.
    • LED rings on the push buttons instead of independent indicator lights. The "Sous Vide Power" and "Temperature Set" push buttons are the only means to control device state with the microcontroller once the device is plugged in. From a operator perspective, I believe it will be more intuitive that the state indicator lights that change in response to button presses are on the buttons themselves. The "Sous Vide Power" button will use a red ring (implying heater/hot) and the "Temperature Set" button (for setting water bath temperature monitoring) will use a blue ring (implying water bath). 

    The main design challenge I am working through right now is on how to ensure that the operator submerges the correct length of IV tubing and to ensure that it remains submerged throughout operation. 

    Most of the electronic components for this new architecture arrive this week. Hope to have a semi-operational assembly by this weekend.

  • New Architecture with Sous Vide

    John Opsahl10/09/2020 at 03:25 0 comments

    For the new OpenFluidWarmer architecture, the electronics monitor the water bath, alert the user of state and faults, and disconnect the sous vide cooker in the event of a high temperature fault. The new architecture requires fewer electronics components than the previous two hot plate architecture because those components are standard offering in sous vide cookers.

    The idea is to package all the electronics in a single enclosure that will be mounted near the sous vide cooker.

    Theory of operation is as follows:

    1. user plugs in the unit into an AC source. If the power switch is in the "off" position, nothing happens. If the power switch is already in the "on" position, see step 2.
    2. user flips the power switch to the on position. The microcontroller gets powered. If the temperature monitor switch is in the "off" position, the microcontroller commands the relay to close. Closing the relay, provides power to the sous vide cooker. At the same time, the buzzer sounds and yellow LED flashes once a second; indicating that the device is in a warm-up state.
    3. using the controls on the sous vide cooker, the user sets the temperature and starts the device. Temperature is set based on the IV fluid flow rate. The buzzer sounds and yellow LED flashes once a second; indicating that the device is still in a warm-up state.
    4. once the sous vide cooker warms the water bath to the temperature set point, the user flips the temperature monitor switch to the "on" position. The buzzer turns off the and the yellow LED stops flashing. The green LED turns on solid; indicating that the device is warmed up and ready to be used. At this point, the microcontroller will be reading the temperature sensors and ensuring that temperatures do not significantly deviate in either direction starting from the moment that the temperature monitor switch was flipped to the "on" position. 
    5. user submerges the appropriate length of IV tubing in the water bath and starts administering the IV fluid/blood product to the patient. If the temperature measured is too far above the set point, the red LED will flash, the buzzer will sound, the relay will open, and sous vide cooker will no longer receive power. If the temperature measured is too far below the set point, the red LED will flash and buzzer will sound. Then it will be up to the medical professional recognize that there is a fault and either turn off the device or allow it to continue operating. 
    6. user removes the IV tubing from the water bath and flips the power switch to the "off" position when finished.

    Couple of other thoughts:

    • I am thinking of staggering the water bath temperature sensors at different heights in the water bath. Then track the temperature difference between the two sensors. If the temperature difference is too high, that indicates that either the temperature bath is not at a uniform temperature or one of the sensors is out of the water because the water level is too low. At least one water bath temperature sensor should be positioned at either the minimum water level required for the sous vide cooker or minimum water level required to submerge the IV tubing (whichever is greater) to ensure proper water level is maintained. 
    • After writing about many of the fault scenarios above, it's clear to me now that three colored LEDs is not sufficient to effectively communicate device state and faults to the user. Whatever is considered next needs to have more resolution, but also be able to be clearly read/understood from 1.5m away.
    • My intention is to use a Arduino Uno microcontroller instead of the Nano depicted. The 5V pin on the Nano can only supply up to 50mA. Whereas the Uno can supply up to 500mA at the 5V pin. The 5V relay draws about 70mA. I could stay with the Nano if I added another DC-DC step down and tuned it to 5V, but the combined cost of the extra step-down and Nano is more than what I purchase an Uno for. Ideally, I would get rid of the 12V to 9V DC-DC...
    Read more »

  • FDA Product Code, 510(k), Medical Device Standards/Regulations

    John Opsahl10/08/2020 at 16:40 0 comments

    Chris Justice of Engenious Design, a medical product development firm, recently volunteered some valuable insight into the FDA approval process for medical devices in the United States. While the OpenFluidWarmer project is unlikely to pursue FDA approval because of how expensive the process is, it is a goal of this project to meet as many FDA approval requirements as possible. 

    A good first step of understanding the FDA approval process is to identify the product code for the type of medical device being evaluated. This search is done through the FDA Product Code Classification Database. For IV fluid warmer designs like the OpenFluidWarmer that to not use electromagnetic radiation (radio waves or microwaves) to warm the IV fluid, the product code is BSB. We also learn that device class is II and submission type is 510(k) for BSB medical devices. The image below is the database search result.

    In addition, with knowledge of the product code, we can look up the competitor BSB devices that have already received FDA approval

    "A 510(k) is a premarket submission made to FDA to demonstrate that the device to be marketed is as safe and effective, that is, substantially equivalent, to a [existing] legally marketed device." The content of a 510(k) submission is summarized in the image below. More information on the premarket notification 510(k) program can be found here and here

    The following standards/regulations also apply to the OpenFluidWarmer device:

    • IEC 60601 design standard - "a series of technical standards for the safety and essential performance of medical electrical equipment"
    • 21 CFR 820 US FDA quality management regulations - "requirements in this part govern the methods used in, and the facilities and controls used for, the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use."
    • ISO 13485 international quality management regulations, "specifies requirements for a quality management system where an organization needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and applicable regulatory requirements." 

    More work is required to fully understand all the implications of everything discussed in this log on the final OpenFluidWarmer design, but I see just having a clear understanding of what medical device standards and regulations to follow as a big step forward.

  • Fail Better With Sous Vide

    John Opsahl10/07/2020 at 20:41 0 comments

    Testing this afternoon with a sous vide cooker shows a more promising path forward than the two hot plate design that has been in development for the last three months. 

    The sous vide cooker (center of image with lit display) maintains the water bath at a constant temperature. The set point temperature is selectable by the user. In the water bath I submerged 660mm of IV tubing. 660mm is the same length of IV tubing used by the two hot plate prototype. Then the peristaltic pump pulls water from the far right bucket, through the IV tubing in the temperature bath, and back to the bucket. There is temperature sense in the water bath, in the bucket, and at the IV tube outlet.

    Results from today's testing show that this technique can warm the fluid flowing in the IV tube from 4°C to 38°C at 20mL/min with the water bath at a 70°C set point. The two hot plate design could only warm fluid from 4°C to 24°C at 20mL/min with a 105°C heater set point. Using the same length of IV tubing, the sous vide method uses a 35°C lower set point and achieves a 14°C higher temperature rise! 

    It accomplishes this through a higher rate of heat transfer between the heating elements and the IV fluid. As a liquid, water achieves maximum contact with the outside surface of the IV tubing. More contact area -> lower thermal resistance. The sous vide cooker has a agitator that circulates water through the heating elements and mixes up the water in the bath. Mixing the water ensures that the water that rejected heat to the IV fluid is continuously replaced by warmer water. Higher flow rate across outside of IV tubing -> higher temperature at the outside surface of the IV tubing. Both the lower thermal resistance and higher temperature differential results in a higher rate of heat transfer to the IV fluid.

    While I have not yet fully vetted the sous vide design solution, there are a few additional benefits that are clear already. The first and most important is that the sous vide method has the potential to cost less in materials than the two hot plate design. It packages a heating element, adjustable temperature control, a motor, and temperature display in a water resistant, easy-to-clean enclosure for under $50. That's about 4X more functionality than the two hot plate design and at a lower price point. In addition, the adjustable temperature control provides opportunity for the user to better tune the set point to match the IV fluid flow rate that is being used. 

    The sous vide method is certainly promising, but it does not have all the safety features that are going to be required to use a device like this in a medical setting. I already have an idea of what is required to "hack" sous vide cookers for safe IV fluid warming and will flesh out these ideas in the next few project logs. 

  • Post Prelim Design Review Updates

    John Opsahl10/07/2020 at 04:18 0 comments

    The preliminary design review was very productive. In all, three mechanical engineers and one electrical engineer were in attendance. 

    A big focus of the design review discussion was on how to significantly improve (i.e. reduce thermal resistance of) the heat transfer interface between the silicone heaters and the IV fluid. The thermal performance design requirement for the OpenFluidWarmer device is to warm 4°C fluid to 38°C at 20mL/min flow rate. Based on testing, the current prototype design can only warm the fluid from 4°C to 24°C at 20mL/min. A lower thermal network between the heaters and IV fluid is required to close that 14°C gap. There are three approaches that have the potential to reduce the thermal resistance and still satisfy the cost target for this device:

    1. increase the length of tubing that is in contact with the hot plates. Heater set point and contact area staying the same, it could likely take just as much if not more tubing length to close the 14°C gap to 38°C than it does to achieve the 20°C temperature rise from 4°C to 24°C. The reason is Netwon's Law of Cooling -> the rate of heat transfer between two bodies is proportional to the temperature difference between them. The closer the fluid temperature is to the heater set point the longer the tube must be to achieve each successive 1°C fluid temperature rise because the reduced rate of heat transfer. At the same time, the heater set point is 105 degC; far from the 38°C target outlet temperature. An extra 150mm tube length (20% increase) in contact with the hot plates may result in something close to an additional 5°C temperature rise.

    A couple other factors at play here are the maximum length of IV tubing that can be used by the device without requiring an IV tubing extension (a cost add) and the minimum allowable bending radius of the IV tubing before it kinks. It is not well known what the acceptable length of IV tubing can be used by the device. Obviously, if it uses up too much of the IV tubing, the IV tubing will not be able to reach the patient. More research and feedback from potential users is required here. IV tubing can be made out of different types of materials. In general, the cheaper IV tubing option is more likely to be the less flexible and more prone to kinking. More research is required to identify the IV tubing option most likely to be used by users in medical settings with few resources and determine the minimum allowable bending radius of that tubing.

    2. increase the surface area contact between the IV tubing and hot plates per unit length of the IV tubing. The current prototype design sandwiches the IV tubing on two "sides" between the hot plates. So the thinking is that by better form fitting to the IV tubing outside surface, the thermal resistance contribution of the IV tubing can be reduced without increasing the length of tubing used by the device. Form fitting the IV tubing achieves more efficient heat transfer per unit length of IV tubing. Of the three approaches, this one arguably has the most potential for closing the 14°C gap. But it is dependent on finding a low-cost, thermally conductive, material that can form fit the IV tubing. Initial thoughts on this material are thermal gap pad, gel/gel-like material, or a fluid. 

    3. increase the heater temperature set point. The temperature rating of insulative materials currently used at the heaters is just above 100°C. So the 105°C heater set point being used is pushing the limit of the current materials. These insulation materials could be replaced with higher temperature rated materials and the heater set point increased. The increased heater set point would create a larger temperature differential between the heaters and the IV fluid and drive up rate of heat transfer. The only downside is that higher heater set points potentially result in increased...

    Read more »

  • Preliminary Design Review

    John Opsahl10/02/2020 at 01:08 0 comments

    The preliminary design review for the OpenFluidWarmer will be held at 3pm CST on Monday, October 5th. See "OpenFluidWarmer_PrelimDesignReview" in the files section of this project for a copy of the presentation. All are welcome to attend and provide feedback.

    Video conference access and any last minute changes will be communicated in the WeBuildBrazil "theopenfluidwarmer" Slack channel,

View all 31 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