Engineering

Modelling concurrent cyclical medication regimens as a deterministic engine

Jane McKay — Founder & Principal Engineer, Forgeyard Digital · 28 July 2026

Jane McKay — Founder & Principal Engineer, Forgeyard Digital

Every reminder app can tell you to take a pill at 8am. Almost none of them can represent a real hormone replacement therapy prescription. That gap is not a missing feature. It is a missing model — and closing it is a genuinely hard engineering problem that I think deserves a proper write-up.

The problem nobody models

A representative HRT regimen looks like this:

• Oestrogen, by one of two routes — and the route defines the clock. Either a gel applied daily — dosed in pumps, where the pump count changes frequently during titration as the patient and her clinician search for the right dose — or transdermal patches replaced twice a week — not "every 3.5 days," but on a rotating pair of weekdays the patient anchors to (Sunday/Wednesday, say), which drifts when a replacement is late and must re-anchor rather than accumulate error. Same hormone, two scheduling semantics, and prescriptions switch between them.
• Progesterone, taken for a set number of days in each cycle — day 15 to day 26 of a 28-day cycle, for example. And in some cases a clinician will advise anchoring the window to the actual period, which arrives when it arrives. This is not common, and it is emphatically not something a woman should improvise herself — it is a prescribed pattern. But when it is prescribed, the anchor is an observed biological event, not a rule you can write down in advance, and the software must model it exactly as the clinician specified it.
• Sometimes testosterone — prescribed off-label for women in the UK, which most have to fight for and many can only obtain through private GPs and menopause clinics rather than the NHS. From the engine's point of view that means the third medication is optional, heterogeneous and titration-varied: there is no canonical regimen to hard-code.

Two or three medications on different clocks, one of them with two alternative delivery routes carrying different rules — all running concurrently against one shared human life that includes missed doses, holidays, timezone crossings, dose changes mid-cycle, and prescriptions that change shape entirely.

The naive implementation — a bag of repeating local notifications — collapses on contact with every one of these. Repeating alarms have no notion of state: they cannot express "the patch that should have been changed yesterday still needs changing, and the next change stays on schedule" — which is a different rule from the gel route's "a missed application is simply missed" — and switching a prescription from gel to patches is a change of scheduling semantics, not just of label text. They cannot express a clinician-prescribed progesterone window anchored to an event that hasn't happened yet: when the doctor has advised following the actual period, next month's schedule is a function of an observation you haven't made. A paper calendar fails for the same reason a repeating reminder does — both demand the future be written down before the body has voted. The engine's job is to represent that prescription faithfully, not to invent it. And they fail silently across timezones, where "8am" is a civil time bound to a location that no longer exists on the wall clock — or exists twice.

If your scheduling model cannot represent the prescription, no amount of UI polish fixes it. The app is wrong at the type level.

Schedules are data; the engine is a function

The design that holds is the one boring systems engineers have been using in finance for decades: separate the declarative specification from the computed state, and make the computation a pure function.

In HRTMe's engine:

1. The regimen is a declarative spec. Each medication is described by its delivery route, its recurrence structure (daily / weekday-anchored rotation / cycle-windowed), its anchors, and its route-specific miss semantics. Nothing in the spec is a timestamp of a future event. The spec is what the prescription says, not what the phone should do.

1. History is an event log — doses and observations. Taken, skipped, late, patch removed, period started — immutable facts with civil-time context. Where a clinician has prescribed a period-anchored pattern, the period-start event re-anchors the progesterone window: the schedule follows the prescription, and the prescription follows the body.

1. The schedule is computed, never stored. A pure function of (spec, history, now) → due and upcoming doses. Recomputation is idempotent: given the same inputs, the engine produces the same answer on the phone, on the watch, after a reinstall, or in a unit test. There is no hidden mutable schedule to drift out of sync with reality — which is also what keeps iOS and watchOS consistent: the same computation over the same facts yields the same answer on both devices.

This factoring is what makes the hard cases tractable, because every hard case becomes an explicit rule rather than an emergent bug:

• Missed doses are policy, per route. A patch overdue by a day generates a catch-up obligation and preserves the forward anchor; a missed gel application generates nothing forward-looking. Route switches (gel ⇄ patches) are spec transitions that swap the rule set cleanly. These are clinical semantics, encoded as engine rules, validated with practising NHS clinicians — not guessed at in a notification handler.
• Mid-cycle prescription changes are spec transitions. The engine computes the changeover from the transition date without corrupting history — the event log is untouched by definition, because specs and events never mix.
• Titration is a stream of small spec transitions. The gel's pump count changes; each event still records the quantity actually applied on that date. When the clinician asks "what were you on when the symptoms changed?", the answer is in the ledger, dose by dose — the exact correlation a paper diary loses and a repeating reminder never captures.
• Timezones and DST resolve at the last moment. Doses are specified in civil time and materialised into instants only when the engine computes against now in the current zone — through a single injectable clock, so there are no scattered wall-clock reads to disagree with each other. The 8am dose is at 8am in Lisbon and 8am in London.

None of this is exotic. It is event sourcing, pure derivation, and explicit policy — the same architecture I spent years applying to financial systems, where "the schedule drifted from the ledger" is a firing offence. The insight is only that a medication regimen is a small financial system: a contract (the prescription), a ledger (the dose log), and a valuation function (what is due now). Treat it with that seriousness and the edge cases stop being edge cases.

Testing it like it matters

A deterministic core earns you the only test suite worth having: exhaustive, fast, and brutal.

The test suites enumerate the cases that break naive implementations: divergent anchors after late patch chains; cross-medication mismatches; windows spanning a cycle adjustment; spec changes landing inside a miss. Because time enters through one injectable clock, integration suites literally time-travel the application — jumping it across days, zones and transitions and asserting the schedule stays correct — instead of mocking dates piecemeal and hoping.

Above the core: snapshot tests pin the UI so regressions are caught by machines rather than by a woman standing in her bathroom wondering why the app disagrees with her prescription. CI runs the lot on every change. Dose logic is treated as safety-critical, because for the person relying on it, it is.

And the discipline scales beyond one product: I have since architected and built an entire AI software factory — specification, implementation, adversarial review and QA as separately gated, autonomously executed stages — engineering that sits at the bleeding edge of how software will be built. But that is a different article.

Why this matters beyond HRT

Cyclical, concurrent, policy-laden scheduling is everywhere in health: tapering courses, alternating-day dosing, chemotherapy cycles, paediatric weight-band adjustments. The industry keeps shipping repeating alarms at these problems because the market for each is "too small" to deserve real engineering.

I build for those markets on purpose. The people in them don't need a friendlier alarm. They need software whose model is at least as sophisticated as their prescription — engineered, tested, and boring in all the right ways.

Jane McKay is Founder & Principal Engineer at Forgeyard Digital, an independent UK studio building health software for underserved populations. HRTMe, built on this engine, is trusted by thousands of perimenopausal and menopausal women.