Building systems around Home Medicines Reviews

HMR-OS is software I’m building to support my own Home Medicines Review work — the study side, the report side, and the pipeline that connects a referral to a finished report. This post is what it actually does, what it doesn’t touch, and where the human sign-off gate sits. If you’re a pharmacist wondering whether AI belongs anywhere near HMR work, this is the honest version, not the sales version.

What is a Home Medicines Review, for anyone outside pharmacy?

It’s a Medicare-funded service where a GP refers a patient to an accredited pharmacist, who reviews the patient’s full medication list — usually with a home visit — and writes up a report with recommendations back to the GP. It exists to catch the kind of problems that build up quietly: interactions, duplication, medicines nobody’s taking anymore, doses that made sense a year ago and don’t now. The Australian Department of Health’s HMR program page has the official scope if you want it straight from the source.

The part that matters for this post: it’s clinical work, it ends in a document a GP acts on, and the pharmacist’s name is on the recommendations. Nothing about that changes because software is involved.

What does HMR-OS actually support?

Three things, and I’m deliberately not trying to make it more than that yet. There’s the study side — the reference material and workflow I use to stay sharp on interactions, guidelines, and the review process itself. There’s the report side, turning a medication list and interview notes into a structured draft that follows the shape a GP expects. And there’s the pipeline, which tracks a referral through its stages, from intake to scheduling to the report going out to invoicing, so nothing sits forgotten in an inbox.

None of those three pieces write a clinical opinion on their own. They organise the work and produce a draft. What goes out under my name is still mine.

Where does the AI actually help?

Mostly at the parts that are mechanical, not the parts that are clinical. Turning a messy medication list and a set of interview notes into the right report structure is a formatting and drafting problem — AI is genuinely useful there, because it’s fast at imposing structure on unstructured notes. Tracking where a referral sits in the pipeline, flagging one that’s stalled, generating the invoice once a report ships — also mechanical, also a good fit.

What it doesn’t do is decide whether a drug interaction is clinically significant for this patient, or whether a dose looks wrong given their renal function, or whether a recommendation is worth making. Those are judgment calls that come from training and clinical reasoning, not from pattern-matching a report template. HMR-OS drafts around that judgment; it doesn’t supply it.

Where does the sign-off gate sit, and does it ever move?

Every report HMR-OS produces is a draft until I review it, edit it, and sign it. That’s not a formality I could relax as the tooling gets better — it’s a fixed rule I hold across every piece of health-data work I do: nothing identifiable goes near the model, and the sign-off before a report reaches a GP is mine — credentialled for it, specifically.

I’m building the compliance and clinical-judgment parts of this slower than the rest on purpose. A wrong invoice is annoying. A wrong clinical recommendation, or a compliance record that doesn’t hold up, is a different category of problem. So that part of the system gets more scrutiny and moves at a more conservative pace than the scheduling or invoicing pieces, which is exactly backwards from how a “move fast” build would prioritise — and exactly right for this kind of work.

Does using de-identified data limit what the tooling can do?

Yes, and I think that’s the correct trade. Working only with de-identified information means the drafting tools never see a name, a Medicare number, or anything else that ties a report back to a real person — which also means they can’t do things that would require that identity, like auto-populating a claim form with a patient’s real details. I’d rather the tool be less convenient than have real patient data anywhere near a system I don’t fully control end to end.

This is the same rule I apply to every piece of healthcare-adjacent AI work I do, not something specific to this build. If a workflow can’t function without real patient data passing through an AI tool, the workflow doesn’t ship as-is.

What’s actually working right now, and what isn’t?

The report drafting is the furthest along — it takes structured input and produces something close to the shape I need, which I then edit properly before anything goes out. The pipeline tracking is functional for my own referral volume but hasn’t been tested against a busier practice than mine. The study side is the least built out; it’s closer to a personal reference tool than a finished feature.

I’m not going to pretend this is further along than it is. It’s a working system I use on my own HMR work, built in the open, with the clinical and compliance parts moving deliberately slower than everything else.

Who is this useful for right now?

Honestly, mostly me. It’s built around how I run my own HMR workload, not as a general product yet. If you do HMR or MMR work and the idea of a pipeline-plus-drafting tool with a hard de-identification rule is interesting, that’s the direction it’s heading — but I’d rather say that plainly than oversell a v0.

See what else I’ve built with this same set of rules at /work.