When I first described Doseframe as a perfusor calculator, the obvious engineering problem seemed to be the formula. The project documentation now spends at least as much attention on the information around the formula. Which preparation does the syringe contain? Is the concentration expressed in milligrams or micrograms per millilitre? Which version of the hospital protocol was approved? Did someone change the weight after the result appeared?
The planned application must answer those questions before it can show a usable number. Doseframe is still a design and prototype. The clinical calculations and protocols are not validated for patient care. This article explains the engineering choices the team intends to test; it gives no preparation or dosing instructions.
Units belong to the calculation#
A number without its unit is incomplete. The same digit can represent a drug mass, a volume, a weight or a flow rate. Time adds another conversion: a prescribed amount per minute and a pump setting per hour cannot be compared until their bases match. A thousandfold difference between milligrams and micrograms is also easy to hide if software treats both as plain numbers.
Doseframe’s design represents these quantities explicitly and rejects incompatible combinations. The result screen shows the prescribed dose, preparation, final concentration and pump rate together, each with its unit. The intent is that a clinician can compare the screen with the original order and the actual syringe rather than trusting a single large result.
Even good unit handling cannot detect every wrong input. If a weight is typed incorrectly but remains plausible, dimensional checks still pass. The interface therefore cannot turn “the arithmetic is consistent” into “the clinical choice is safe.” Where a hospital supplies approved bounds, the application can make an out-of-range value visible; the clinical team must define those bounds.
A protocol has a history#
A preparation rule should carry its source, scope, version and approval state. Doseframe’s proposed lifecycle moves a protocol through drafting, clinical review and release. A withdrawn protocol cannot be selected for a new calculation. Editing a released protocol creates a new draft rather than silently changing the published rule. The person performing a calculation should be able to see which rule produced the result.
This is an important distinction in a project that began with historical hospital tables. A document can be valuable evidence about past practice without being a current order. Discrepancies in old tables are questions for the responsible clinicians and pharmacy, not values that I can correct by inference. The first real medicine would be implemented only after its current protocol and worked examples have been confirmed.
The system also needs a clear answer when a protocol becomes unavailable. The present design refuses to issue a new clinically usable result if it cannot check the necessary status. What staff do during an outage is a local operational decision. Calling the web application an emergency fallback would be premature without that decision and testing.
Read the calculation in both directions#
The forward path begins with a prescribed dose and an approved preparation. It produces a calculated pump rate. The reverse path begins with the actual preparation and a rate already set on the pump. It produces the dose those entered values imply. Putting both on one review screen can help a second person compare prescription, syringe and setting.
That review is only as independent as the procedure around it. Two people pressing the same button do not independently verify a software defect. Doseframe’s design calls the screen a countercheck, not an independent certification. The team still needs to learn which source information each person will actually have at hand and how the hospital records its checks.
The screen must also respond to changes honestly. If the user edits weight, concentration, selected protocol or rate, an older result must lose its valid appearance immediately. A delayed or stale result is especially dangerous because its formatting can make it look current. Visible version and input details are therefore part of the safety design, not decorative metadata.
What the prototype can test#
The current clickable demo has fictitious values and no calculation backend. It can test whether staff find the relevant fields, understand the handover and spot a changed input. It cannot establish that the mathematical engine is correct. The planned engine needs independently calculated reference cases, tests across unit and weight boundaries, and checks that an unapproved protocol never returns a usable result. A later test must compare what the browser shows with what the backend calculated.
Usability testing matters just as much. The WHO identifies high-risk medication situations as involving system and work-environment factors alongside medicines and people. For this project, that means asking nurses and doctors to carry out representative tasks without coaching, then observing missed information and misunderstood warnings. A confident green “safe” label would say more than the software could establish.
If this work eventually moves beyond a study prototype, clinical validation, ownership, quality processes and the applicable medical-software requirements must be addressed. The European MDCG guidance is one reference for assessing software’s intended medical purpose. The design does not become a clinical product because its formula passes unit tests.
The principle I want to test is modest: a calculation is easier to challenge when the application shows where every number came from, which rule was used and what it could not check. That is the standard Doseframe’s next prototype and clinical conversations need to meet.