BME66 design group aiming to improve pipetting efficiency and reduce associated error
User Need Exploration
Big thanks to Jake for getting in contact with his mentor Ryan for an interview to bolster our current understandings (we added User Need 1.7 and edited 1.3 and 1.6 based on his input).
Section 1 – Functional Requirements
Reduce human pipetting error, increase pipetting efficiency overall
1
Increase overall pipetting and experimental setup efficiency
2
Accurate evaluations of pipetting (liquid volume detection, low Type 2 error)
3
Cost-effective vs. automated pipetting alternative
4
Customizable to different plates and assays via user input
5
Simple, time-efficient setup and maintenance
6
Reduces volume and contamination errors associated with high-volume pipetting backsplash
7
Reasoning, Evidence, Citations
This was the main need that our project set out to address in the first place – we realized that both pipetting errors and inefficient experimental setup (tip waste, etc.) could add up in the long run to incur significant time and material costs that could be avoidable with some solution.
As previously stated (this overlaps a bit with our previous need), from interviews with various mentors for our research (Jake was the main point of contact here), along with our own experience as researchers ourselves, we noted that both pipetting errors and efficiency (i.e. when a tip doesn’t need to be changed, the order that reagents are added to wells, etc.) are significant factors in this space that need to be addressed by relevant solutions
From our personal perspectives, we’ve noted that many assays (qPCR, etc.) require extremely small liquid volumes (around 20 µL or less) – thus, to make sure that the device can detect pipetting errors, it should also use a detection system that is sensitive enough to confirm these small volumes at high efficiency/rate with minimal interruptions to the normal workflow.
Considering that automatic liquid handling systems exist, we wanted to target this device to more of an academic audience (who usually don’t have the resources to spare on $22k automated pipetting apparatuses). Thus, we wanted to be accessible and preferably self-fabricable using easy 3D-printed parts that reduce cost and increase the amount of usage such a device could see in an academic lab.
In our experience (and corroborated by Jake’s mentors), many assays do not use the entire 96-well plate. Furthermore, some assays use 48-well or similar plates that have different dimensions and well depths. Thus, we wanted to implement the ability to specify an experimental setup into the device, such that the device’s “efficiency-boosting” and “error-reducing” solutions could be applied to multiple different setups and fields.
Because the main purpose of this device is to increase efficiency, it was reasonable to assume that it does not take a significant amount of time to set up. Furthermore, the method of “liquid-checking” should not impinge on the experimental setup – either the device would “check” a plate after it was done (less preferable), or the device would shadow an ongoing setup to “check” each well/column/row as it was completed (more preferable).
One of our interviews with one of Jake’s mentors noted that not only should the device be compatible with very small volumes, but that large volumes often carry their own degree of associated error. Our method of integrating this into the current device would likely fold into the “planning” algorithm of the device, by attempting to advise an experimental setup that reduces the amount of high-volume pipetting required (as high-volume pipetting incurs backsplash and other issues that decreases its accuracy).
Section 2 – Performance Requirements
Construction is mobile to be moved to alternative lab locations
Operation of evaluation function does not disturb plate/liquid volumes
Either: operate in parallel with experimental setup, runs quickly enough after experimental setup as to not disrupt workflow
Reasoning, Evidence, Citations
As mentioned previously, we wanted this device to be used simultaneously or in close connection with the actual experimental setup itself. Thus, it would be best if the device was small enough to be movable to different locations depending on lab usage.
Following this trend, whatever the device mode of operation should be, it should make sure not to disturb the plate and cause issues with cross-contamination.
This outlines the thinking that we discussed for Section 1 – we identified two main methods for the device to operate: either in parallel as a “shadow” behind the experimental setup procedure, or a quick “final check” afterwards. However, regardless of which mode proves superior, the operation should be quick, efficient, and not disruptive to the overall workflow.
Section 3 – Biocompatibility Requirements
Compatible with experimental constraints (sterility, cross-contamination, etc.)
Does not alter experimental reagents (including biologicals) in any way and is not degraded over time
Reasoning, Evidence, Citations
Because this device should work with any sort of experimental setup, it must be able to conform to any experimental requirements that involve sterility, cross-contamination, etc. This could either arise from materials or the method by which the device checks liquid volume.
Furthermore, the method by which the device checks experimental progress should not disrupt the viability of reagents (photobleaching, etc.) significantly – the device should also be resilient to multiple run-throughs.
Section 4 – Interfacing Requirements
Import/export experimental plate setup from other mobile devices
Can be linked with additional copies of itself to increase parallel plate verification
Reasoning, Evidence, Citations
These interfacing requirements are less important than the prior constraints – however, if implemented, we think that these needs could greatly streamline high-throughput experiments.
Firstly, we thought that it would be useful for experiments that are run often (e.g. qPCR with the same genetic markers) in the same format could be “saved” as some file format, to reduce time spent setting up the device.
Similarly, these formats could be exported to other copies of the same device such that multiple researchers doing the same experiment could have their setup verified in parallel (rather than in series).