Digital Urometer (DigUro)
Phillip Trent (Software + Mechanical)
Sahithya Prakash (Electrical + Chemical)
Patient vitals, such as blood pressure and heart rate, are constantly being digitally measured and monitored for nurses to record; however, urine output -- one of the most critical gauges of patient recovery -- is recorded manually and proves an error-prone, non-urgent task for nurses. If we can design and build an automatic and accurate urometer, it will revolutionize the quality and efficiency of hospitals around the world.
Our goal is to build a digital meter that measures the urine output for patients in the ICU and recovery. For our solution, it must be immediately implementable in the hospital. In other words, the product must work with the current catheter equipment and be reusable, disposable, portable, and accurate.
Our first goal is to design the sensor and measurement mechanism for measuring the urine output. We then will confirm the quality and accuracy of the design by testing the mechanism in XLab, keeping certain edge cases like splashing and device orientation in mind. Next, we will program the microcontroller to read the sensor data, convert that value into a volumetric measurement, and output that value to a display. Our final steps will be to scale the size of the device down by combining the hardware (microcontroller and sensor wires) into a PCB and packaging the entire product to look professional and hospital ready.
(Hardware/Software/Mechanical building blocks and tools you will use. This is not a parts list)
Testing and Evaluation
We need to evaluate each step of the project:
Design of the Product
Evaluation: Use a container of liquid (water, gatorade, etc.) as substitute for patient urine. Test if changes in liquid volume correspond to intuitive changes in sensor readings. Account for various orientations of the product. Make sure the urine is being measured and contained.
Desirable Outcome: Sensor readings match changes in liquid volume. Liquid is measured and contained.
Accuracy of the Product
Evaluation: Program the microcontroller to read the sensor values and output the corresponding volumetric measurement on a display. Make sure that the output value matches the actual volume of liquid.
Desirable Outcome: The output value and actual volume should differ by at most ~5mL.
Presentation of the Product
Evaluation: Does the product work as supposed to even after miniaturizing it? Can the product be immediately implemented in hospitals?
Desirable Outcome: The product can be implemented after the end of this course.
Working measurement example (can simulate urine going into the container and sense how much is there, testing already completed)
Tell exactly how much urine has been output (error bound: ±5 mL) and display it on some kind of monitor.
Implemented on a breadboard, with a PCB design already completed and/or ordered. Make and 3D print housing for PCB
Reach Goals - Extra Credit (justify why this should not be in the baseline)
Add the urine monitor output to the current monitors in the hospital along with heart read, blood pressure, etc.
This is a reach goal because it involves knowledge of the current systems in the hospital, which we haven’t had experience with as well as introduces a new kind of display that is used in the field.
Make a graph using the urine output over time and output to the monitor
This is difficult because the urine output data has to persist over a significant amount of time (even after the bag has been emptied and refilled repeatedly), and it introduces the problem with space complexity and storing long-term data.
Make an iPhone application that interfaces with iOS’s HealthKit so that when a patient has to go home with a catheter, their urine can still be monitored in a convenient and doctor-shareable way.
This involves networking the embedded controller with iOS, using the bluetooth protocol, developing an iOS application from the ground up, and integrating HealthKit.
Overall Timeline (in 4 days sprints)
Total time: 03/22/16 - 05/06/16
Week 1: 03/22/16 - 03/27/16
-Gathering all components
-Testing accuracy of the sensors
-Build rudimentary prototype
Week 2: 03/28/16 - 04/03/16
-Test the prototype
-If results are better than we expect, go with Solution #1
-If not, repeat Week 1 for Solution #2 and build + test
-Baseline 1 should be 75% completed
Week 3: 04/04/16 - 04/10/16
-Baseline 1 DONE
-Baseline 2 should be 50% completed
Week 4: 04/11/16 - 04/17/16
-Baseline 2 (almost) done
-Baseline 3 started
-4/14/16 -- Intermediate Demo, we should demo Baseline 1 and what we have of Baseline 2
Week 5: 04/18/16 - 04/24/16
-Baseline 2 DONE
-Baseline 3 should be almost done
-PCB ordered and housing for PCB should be almost done
Week 6: 04/25/16 - 05/01/16
-Week reserved for testing and making the product look professional
-If testing is successful, start on Reach Goals
-4/28/16 -- Demo of the baselines
Week 7: 05/02/16 - 05/06/16
-Constantly testing as each new component is added to the project
-Get ready for final demo (with reach goals)