OpenSolaDosis

Every hospital has clinical calculators. Dosing tools, unit converters, infusion rate sheets — little apps that do math a pharmacist could do by hand but shouldn’t have to at 3am. They’re everywhere. They’re also, almost universally, black boxes.

Here’s your number. Trust us. Don’t ask how.

The problem with trust-us math

When a clinician calculates a dose, the work matters as much as the answer. Which formula? What values went in? Where did it round? Pharmacy boards require this. The FDA’s 2026 CDS guidance requires this — Criterion 4, transparency, the ability for a healthcare professional to independently review the basis for the output. “Show your work” isn’t a grade school nicety. It’s a regulatory requirement.

Most clinical calculators fail that test. The ones that pass are locked to specific substances, tethered to vendor platforms, or both. Institutions end up choosing between transparency and flexibility, which is a choice nobody should have to make when the math determines how much of something goes into a person.

What OpenSolaDosis does

It runs protocols. That’s it.

A protocol is a declarative JSON file — inputs, expressions, gates, constraints, outputs. The engine doesn’t know what substance it’s calculating for and doesn’t care. Grape juice or gentamicin, the math is the math. Institutions author their own protocols. The engine validates them at build time, hashes them with SHA-256 for integrity, and interprets them at runtime with decimal arithmetic — no IEEE 754 floating point anywhere near the dosing math.

Every calculation produces a full transcript: the formula as written, every substituted value, every branch decision, every rounding step. Copy-ready output for the medical record. The clinician sees exactly how the number was derived and makes the clinical judgment. The tool doesn’t.

The architecture bet

Static SPA. No backend. No patient data touches a server because there is no server. Stateless by design — which keeps the tool outside HIPAA scope, outside 21 CFR Part 11 scope, outside EPCS scope. That’s not a loophole. That’s the architecture satisfying the regulatory requirements instead of the compliance department scrambling to paper over them after the fact.

Protocols are immutable once confirmed. Test vectors are required — the build fails without them. 136 tests in the suite. IEC 62304 is technically optional for non-device software, but we follow it voluntarily because the standard exists for a reason and the cost of adopting it is trivial compared to the cost of wishing you had.

The demo protocols are fake on purpose

The repo ships with three demo protocols that calculate fictional beverage servings and one intake form. Not real medications. Not placeholder doses. Deliberately fictional — because the point is that institutions must author, validate, and take responsibility for their own protocols. The engine is the infrastructure. The clinical knowledge lives in the protocol files, owned by the people who understand the medicine.

Where it stands

Feature-complete: engine, parser, UI, build pipeline. Published to GitHub under AGPL v3. Waiting on a friend to circle back for clinic-specific protocol adaptation — the part where it stops being a demo and starts being useful in a room with actual patients.

The regulatory guidance report we wrote during development might have standalone value. Turns out there isn’t a great single document that maps FDA CDS criteria, IEC 62304 practices, and pharmacy board requirements onto the specific architecture of a stateless clinical calculator. Now there is.