OpenMedCheck：替急症室醫生細讀病歷的 AI 處方助手

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

Not for clinical use — synthetic patients. Not a medical device. OpenMedCheck is a concept demonstrator. Every patient in this post is invented.

What I Built

OpenMedCheck is an open-source prescribing check for emergency-department doctors. One proposed medication order goes in, together with the patient's record. One decision card comes out: NO_ISSUE, WARNING or BLOCKED, with the reason, the doctor's own words as evidence and, where the rule table allows one, a re-checked alternative. When nothing conflicts it says one line, "No issue found by these checks", and gets out of the way.

The problem it solves. In the ED, orders are written under time pressure, and the fact that makes a drug a bad idea is often only in free text:

a suspicion in today's note, written before anything is coded ("Suspected ACS"), or
one line in a long past medical history ("Upper GI bleed from a duodenal ulcer in 2021").

Prescribing modules mostly check drug pairs against coded data. They don't read the note. And the alerts they do raise are often overridden: a 2025 systematic review of drug-drug interaction alerts found no significant improvement in patient-important outcomes. We think the problem isn't too many alerts in general. It's alerts without the patient's context.

Two synthetic patients show the idea:

Bed 3: a 64-year-old man with chest pain, daily aspirin in the record, and "Suspected ACS; ECG and troponin pending" in today's note. The order is dexketoprofen, an anti-inflammatory (NSAID). Nothing is coded yet, so the rules alone say NO_ISSUE. Once Gemma reads the note, the card turns red (BLOCKED), quotes the doctor's words, and offers paracetamol 1 g every 8 hours, already re-checked. One click applies it: "No issue found by these checks".
Bed 5: a 66-year-old man with a wrist sprain after a bicycle fall; ibuprofen is ordered. Today's visit looks routine. But between the knee arthroscopy and the cataract surgery, his past medical history says "Upper GI bleed from a duodenal ulcer in 2021". Rules alone: NO_ISSUE. Once Gemma finds the line: amber (WARNING), the line highlighted where it was written, and paracetamol offered instead.

Who would pay. Not the ED doctor. The buyer is whoever owns medication safety in a hospital: pharmacy and medication-safety teams and clinical-informatics teams. They carry the cost of medication errors and of alerts that don't help, and they can't extend the checks inside their vendor's prescribing module. EHR and decision-support vendors could also embed it as an open, inspectable component.

The model is open core. The engine stays open source. A hospital would pay for:

a maintained, cited rule table, kept current as drug labels and guidelines change;
integration with its record system (HL7 FHIR, CDS Hooks);
support and the regulatory path.

This is a hypothesis I haven't tested with buyers yet.

Demo

Code

Apache-2.0. Python 3.12, FastAPI, Ollama, Pydantic; about 1,080 automated tests.

How I Built It

Gemma 4 E4B, open weights, running locally through Ollama, on an 8 GB laptop GPU. The whole design rests on one split, with three parts that each have one job:

Gemma reads. It reads the free text (the reason for consult, the past medical history, today's note) and answers a fixed set of questions in strict JSON. Is there a suspected ACS? Which medicines does the text say the patient takes? Which past events are recorded? Every answer must include the exact words from the text.
Code checks. A plain program, with no AI, verifies each answer:
- Are those words really in the text?
- Do they name what Gemma claims ("mild" is not "MI")?
- Are they denied ("ACS ruled out"), a relative's ("Father had an MI"), or an old event presented as current?

Anything that fails is dropped. This is what keeps a misread from becoming an alert.

Rules decide. A fixed table of 25 if-then rules, written from drug labels (Spanish SmPCs) and published guidance, re-runs on the record plus the verified facts. Example: NSAID + suspected ACS + antiplatelet → BLOCKED. Every rule cites its source and carries a review mark. A clinical specialist reviewed 23 of the 25; the two past-history rules came later and are marked not reviewed.

The guarantee is escalate-only:

Gemma's own opinion can make a card stricter, never softer. A rules BLOCKED is final.
For the conflicts the rules decide, Gemma's opinion counts only if a rule of that kind fired.
Doses come only from the rule table, never from the model. An unreviewed dose shows as "Dose: consult SmPC".
If the model is down, slow or answers badly twice, the app still answers with the rules alone. A clean result then says "Free-text note not checked", because a check that couldn't read the note must not look like a pass.

Does it work? On an open set of 76 synthetic ED cases, Gemma reading the note lifted the match with the expected outcome from 72% (rules only) to 97%. Misses fell from 21 of 42 to 1, with 0 false alarms on the 34 cases that should stay silent. The median model step was 1.87 s. Caveats:

The cases, prompt and checker were built together, so this is a development set, not a clinical validation.
These figures predate the past-history step, which isn't measured yet. [HUMAN: replace with the prompt v8 run on all 89 cases, or keep this sentence.]

One lesson shaped the design. Early prompts asked Gemma to judge the conflict itself, and it kept attaching "NSAID with ACS" to whatever drug was ordered, including paracetamol. The fix was to stop asking the model what the code already knows. Gemma does what it's good at, reading messy text and quoting it, and the rules decide.

Process. I worked spec-first with Claude Code as the coding agent:

I explored the idea and wrote a spec with numbered requirements and acceptance criteria.
Each task was implemented test-first, with tests named after the criteria.
AI reviewers checked the safety invariant and the clinical wording on every change.

Full explanation: How OpenMedCheck decides.

Why Does Open Innovation Matter?

Here the open model isn't a cheaper option. It's the only option that works.

The data can't leave the building. An ED note is special-category health data under GDPR (Art. 9), and many hospitals won't send every order and note to a third-party model API. With open weights, Gemma runs on the hospital's own GPU (a 6.6 GB download). The app binds to 127.0.0.1; its only outbound call is to the local model; and nothing from the patient context is logged, stored or cached. A closed API would need a data-processing agreement and an outbound connection before the first test.
It runs on a laptop. Everything in this post ran on one laptop with an 8 GB GPU. A demo, a hospital pilot and a vendor evaluation can all start without cloud credits.
I could compare models freely. Because the weights are open, I ran the same 76 cases through three Gemma variants on the same machine. Gemma 4 E4B gave 97%. Gemma 3 4B gave 78% with 5 false alarms. Gemma 4 12B gave 80%, with 32 of 76 calls timing out on 8 GB. Swapping models is one setting (OPENMEDCHECK_MODEL); fine-tuning on a hospital's own note style is a possible next step.
It can be audited. A hospital can pin, inspect and re-test the exact model it runs, next to a rule table a pharmacist can read. That matters for something that may one day be regulated as medical-device software.
No per-call fee. Inference runs on hardware the hospital already owns, so cost doesn't grow with every order checked.

My Agent Session

I built this spec-first with Claude Code. The two sessions below show how the idea was shaped and specified before any code was written.

1. Ideation: from a rough idea to a zero-egress Gemma 4 prescribing check, with research, competitors and a go/no-go verdict.

2. Spec-driven planning: requirements with acceptance criteria, the escalate-only design and the task plan.

Prize Categories

Best Use of Gemma: Gemma 4 E4B runs locally through Ollama and reads the note and the patient's history. Its quoted findings drive the cited rules, under an escalate-only guarantee.