A syringe pump delivers medication continuously. Preparing one can involve a prescription, a stock solution, a dilution, a final concentration and a pump rate. Each value has a unit. A calculation may be short on paper, yet the handover between prescribing, preparing and setting the pump gives mistakes several places to enter.
Doseframe is a project I am developing during my computer science master’s studies. The idea came from conversations with physicians in neonatal care about perfusor preparation and the work around it. Their feedback has changed the design: the handover of a spoken prescription matters, clinicians need to see the entered dose clearly, and the staff who prepare syringes must still test whether the proposed workflow fits their practice. The project is currently a design and prototype, not a clinical calculator ready for patient care.
The World Health Organization’s work on medication safety describes harm in high-risk situations as a combination of medicine, people and system factors. That is a useful frame for Doseframe. Arithmetic matters, but so do the source of a protocol, the clarity of the display and the chance to catch a mismatch before anyone touches a pump.
What the tool is meant to do#
The planned workflow starts with a dose already prescribed by a clinician and a preparation protocol approved by the hospital. Doseframe would calculate the amount to draw up, the final concentration and the corresponding pump rate. It would show the inputs, units and calculation path together. A reverse check would take an existing preparation and rate and show the calculated dose they imply.
That last word is deliberate. A calculation about an entered setting is not a measurement of what reaches a patient. Device behaviour, lines, preparation and the actual clinical situation still need their own checks. The tool would neither prescribe a dose nor control a pump.
The first full design includes two kinds of preparation: a standard concentration and a preparation adjusted to weight. Later clinical feedback added a two-stage preparation from a stock solution to the intended first version. Insulin has its own protocol questions and cannot simply inherit another drug’s formula. These are requirements under review, not a library of approved drug instructions. The hospital’s historical tables are research material until the responsible clinical team confirms current versions.
Why a framework?#
My course asks for both a reusable framework and an application built with it. That constraint fits the problem. Some rules should hold regardless of hospital: quantities need explicit units, a withdrawn protocol must not produce an apparently valid result, and a changed input must invalidate the old result. Other parts belong to the local institution: which preparations it uses, who approves a protocol, how rounding works and which devices are in service.
The design therefore separates a common calculation and protocol core from a hospital-specific application. Different preparation methods and rounding rules become explicit components of the framework. That is more work than putting every case into one screen, but it makes the choices visible and testable. It also helps prevent a change for one medicine from quietly changing another calculation.
The planned Python backend performs the calculation; a web interface presents it. A clickable interface demo currently uses fictitious data and has no calculation backend. It lets clinicians comment on screen order and wording, but cannot validate the arithmetic or establish clinical suitability.
The questions still open#
The project documentation now includes feedback from physicians, including a senior physician, but the preparation workflow has not yet been tested with the nurses who draw up syringes and set pumps. Their input is essential: a display that seems clear to its designer may hide the one number a person needs during a handover.
Other decisions require the institution’s experts. A protocol’s current source and approval, the exact rounding rule, pump and syringe limits, and the response to a network failure cannot be inferred from old documents or chosen by a developer. The team must also settle who owns the software and how it would be evaluated for clinical use. European guidance on medical software makes the intended medical purpose central to qualification and classification; a successful classroom prototype does not settle that question.
My next step is to put a small, fictitious task in front of the people who would actually use it, record where they hesitate, and refine one preparation path against independently checked reference cases. If the workflow does not help them, the design needs to change. The aim is a calculation that can be inspected at the moment it matters, with no claim of safety that the project has not earned.
In a follow-up article, I explain why the unit, the protocol version and the reverse calculation are all part of that inspection.