Research did not exactly go to plan, and it showed in the mini-presentation. The other teams had their things together in a nice organized fashion (especially Can’t Brachius, props to y’all!) while ours were split across documents in various structures and lacking any real depth. Part of it was we were just bad about recording things in a cohesive manner. Bigger than that though is that we had gone into research with a preconceived notion of how the solution should be and what it should measure. It’s never that simple. If it was, they wouldn’t need an outside engineering team.

After our rough presentation, we decided to do a rewind and try to research again from essentially scratch. It was an eye-opening experience; finding some relationship to the inner diameter is not the end-all-be-all. There’s also direct thickness measurements through tangential measurement, flow rate controls through pressure, and a whole other world of dozens of different types of flow meters. We would never have found these other ideas had we not got searching for them.

It’s a good thing we stopped tunneling, because the solution we thought of at first ended up to be infeasible. The nurse pulls the plunger, pusher, and thus the distance potentiometer back from zero to fill the syringe. Unfortunately, they also overfill the syringes to prevent underdosing when medicine stays in the IV line or some measurement error is made. Measuring the movement of the plunger fails if it doesn’t correspond to a known volume, once thought to be the nominal volume of the syringe.

When making our design criteria, we stumbled a bit on how to implement ease of use. We will never see our end user, so how do we test for this? Can we quantize it in terms of steps or buttons? Is there a proxy? Eventually, we arrived at the Trease of Use, a beautiful dichotomous tree that breaks it down into simple bins that we can test anyone on:

This remarkably simple chart breaks down discrete difficulty levels for rating the device and helps us understand how much instruction to include with various solutions. It’s not a user defined scale, but it still manages to create clear, even steps to quantify user experience. Maybe this (or something like it) could be taught alongside User Defined Scales; we spent way too long mulling over how to make a UDS work when this made the task simple.

 

Brainstorming was successful, with ideas ranging from the absurd (measure the black body radiation of the syringe) to ridiculously ambitious (decentralized live database combined with measurement protocol) to remarkably (draw two lines on the Kasupe). What this really meant was it was finally time for the most fun part of the design process: screening! After a sanity check and multiple sorts, our ideas arrived into three categories: automatic hardware, manual hardware, and software. Each category hard their own unique boons, making it hard to compare across them, i.e. software is essentially no end cost, dimensionless, weightless, and infinitely durable. It’s kinda got a lot going for it.

Seven ideas made it out of screening, but doing a bit more research shot them down one by one. Ultrasonic is a direct-line measure, flow meters are ridiculously expensive, and syringes are transparent in infrared. We were left with three ideas, not enough to really score. What do we do? Find out next week, because this is about as far we got.

On a different note, we had our potluck lunch on Friday, which was a huge success! I made a big pot of turkey chili, and everyone loved it. It was a take on my dad’s recipe, with added onion, jalapeno, and cayenne for some heat. I had made something on the order of nine pounds of food, and had barely enough for a single leftover meal. I was pretty worried because I hadn’t made this before, but everything turned out delicious. When I get home, I’m going to let my dad see for himself that it’s better than his!