Hi all,
I’d like to share a project I’ve been working on and get the community’s thoughts: open-pharma-dosing, an open-source, zero-dependency
library that converts clinical dosing frequency shorthand into structured data and FHIR R4 Timing resources.
The problem
Clinical systems routinely deal with dosing frequencies like “BD”, “TDS”, “PRN Q4H”, or “STAT” — but there’s no lightweight,
open-source library that:
- Maps these codes to structured timing metadata
- Converts them bidirectionally to/from FHIR R4 Timing and Dosage resources
- Generates concrete administration schedules
- Handles locale differences (e.g. “BD” in the UK vs “BID” in the US)
- Validates dosing instructions for clinical sense
Most teams end up writing this logic from scratch, often inconsistently.
Design decisions I’d like feedback on
- Embedded registry — All 33 codes are compiled into the binary as struct literals. No runtime file loading, no database dependency.
This keeps it fast and self-contained but means adding codes requires a code change. Is this the right trade-off for clinical software? - FHIR roundtrip fidelity — FromFhirTiming(ToFhirTiming(code)) == code holds for all 33 supported codes. This is tested and enforced.
Are there edge cases from real-world FHIR implementations that would break this? - Clinically sensible defaults — Default times are chosen for clinical reality, not mathematical spacing. For example, QDS (four times
daily) defaults to 06:00, 12:00, 18:00, 22:00 rather than every 6 hours from midnight. Would clinicians in your context expect
different defaults? - Locale model — Currently en-GB and en-US, with the architecture ready for fr, es, sw, ha, and yo (Swahili, Hausa, Yoruba are
intentional for deployment contexts in sub-Saharan Africa). What other locales would be useful? - Category taxonomy — Frequencies are classified into 7 categories: regular, interval, time_of_day, meal_relative, prn, one_off,
extended. Meal-relative codes (AC, PC, CC) are treated as modifiers that combine with a base frequency rather than standalone
frequencies. Does this model hold up against your clinical workflows?
Current state
- Canonical implementation: Go (zero dependencies, 42 tests passing)
- Planned ports: Dart/Flutter and Python with the same API surface
- License: Open source
- Repo: GitHub - Open-Nucleus/open-pharm-dosing: A zero-dependency library for structured medication dosing frequency encoding, parsing, and FHIR R4 Timing conversion.
What I’m looking for
- Clinical validation — Do the 33 codes and their default timings match what you see in practice? Are there common frequencies missing?
- FHIR interop experience — Has anyone dealt with dosing frequency mapping to FHIR Timing in production? What broke?
- Locale contributions — Especially interested in contributors who can validate dosing terminology in non-English clinical contexts
- Use case alignment — Would this be useful in your stack? What would need to change?
Happy to answer questions or walk through the code. Looking forward to the discussion. @pacharanero @eatyourpeas