OpenMedCheck: An Open-Source Prescription Checker That Uses Local Gemma to Read Medical Records for ER Doctors

The Blind Spot in Emergency Prescription Safety: Critical Information Buried in Free Text

Prescriptions in the emergency department are often written under time pressure, and the clues that actually determine whether a drug is appropriate frequently exist only in free text: an uncoded line in today's progress note saying "suspected acute coronary syndrome (ACS)," or a line in the past medical history reading "upper GI bleeding from duodenal ulcer in 2021." Traditional prescription review modules mainly check drug pairings based on coded data and cannot read this text; and the alerts they fire are often overridden by doctors outright. According to a 2025 systematic review, drug interaction alerts produced no significant improvement in patient-important outcomes. The author of the open-source project OpenMedCheck draws a different conclusion: the problem is not too many alerts, but that alerts lack patient context.

Drug-drug interaction (DDI) alerts and "alert fatigue": Prompts automatically fired by clinical decision support (CDS) systems based on drug-pairing rules, intended to intercept potentially harmful combinations. In real deployments, however, the positive predictive value of such alerts tends to be low, and doctors over time develop "habitual override"—closing them without reading the content. The "no significant improvement" cited in the 2025 systematic review refers precisely to this phenomenon: more alerts do not equal better patient outcomes, and may even backfire by drowning out critical alerts. This also explains why OpenMedCheck takes "reducing ineffective alerts and filling in patient context" rather than "adding more checks" as its design starting point.

The gap between ICD coding and free text: Diagnoses and past medical history in hospital information systems are usually stored as standard codes such as ICD-10, which facilitates statistics and rule matching; but in emergency settings, doctors often describe undiagnosed suspicions in natural language in progress notes (e.g., "suspected ACS"), and this content is only coded after discharge or a confirmed diagnosis—introducing time lag or permanent gaps. Review modules based on coded data therefore inherently cannot see "what is currently being suspected," which is the technical root of the article's claim that they "cannot read this text."

One Input, One Decision Card

OpenMedCheck's interaction design is highly restrained: input a proposed order and the patient record, and output a decision card with status NO_ISSUE, WARNING, or BLOCKED, accompanied by the reason, the doctor's own words as evidence, and—when the rule table permits—a re-validated alternative. When there is no conflict, it shows only a single line, "No issue found by these checks," and gets out of the way.

The project illustrates its value with two synthetic patients. Bed 3 is a chest pain patient whose record notes daily aspirin use, whose today's progress note reads "suspected ACS, ECG and troponin pending," and for whom the proposed drug is the NSAID analgesic dexketoprofen. Because the information is not yet coded, a pure rule-based judgment yields NO_ISSUE; once Gemma reads the progress note, the card turns red BLOCKED, quotes the doctor's own words, and offers a re-checked alternative, acetaminophen. Bed 5 is a wrist sprain patient whose visit today looks routine, but whose past medical history conceals a record of upper GI bleeding; the rules likewise miss it, and Gemma finds the line and issues an amber WARNING.

Three-Layer Architecture: The Model Only Reads, Code Validates, Rules Decide

OpenMedCheck's technical core is a clear three-part division of labor, which is also the precondition for running Gemma 4 E4B on a laptop GPU with 8GB of VRAM.

Layer One: Gemma Reads Free Text

Gemma runs locally via Ollama, reads the reason for visit, past medical history, and today's progress note, answers a fixed set of questions, and outputs strict JSON. Every answer must include verbatim quotes from the text.

Layer Two: Ordinary Code Validates the Answers

A non-AI program verifies each model answer one by one: Do these words actually appear in the original text? Do they point to what the model claims ("mild" is not "myocardial infarction")? Are they negated ("ACS ruled out"), attributed to a relative ("father had MI"), or an old event treated as current? Any answer that fails validation is discarded, preventing misreadings from becoming alerts.

Layer Three: The Rule Table Makes the Final Decision

Twenty-five if-then rules written from drug labels and published guidelines re-run over the record and the validated facts, with each rule annotated with its source and review status. Clinical experts reviewed 23 of them; two past-history rules were added later and marked unreviewed.

The guarantee of the whole design is "only escalate, never downgrade": Gemma's opinion can only make the card stricter, never looser; a BLOCKED from the rules is final; doses come only from the rule table, never from the model; and if the model crashes, times out, or gives anomalous answers twice in a row, the app still answers with pure rules—in which case a clean result shows "Free-text note not checked," because a check that failed to read the progress note must not look like it passed.

Grounding and citation validation: Having a large model attach source citations to its conclusions is a common way to reduce hallucination, known as "grounding." But merely requiring the model to "quote verbatim" is not enough—the model can still cite text that genuinely exists while assigning it the wrong meaning (the article's "mild is not MI" is one such case). OpenMedCheck's second layer is essentially a deterministic string and semantic consistency checker: first verify the quoted fragment actually appears in the original, then check for negation words ("ruled out"), subject attribution ("father has"), and temporal reference (old event vs. current event). This "model proposes, code adjudicates" pattern is a typical engineering practice for constraining unreliable generative components within verifiable boundaries.

If-then rule tables and auditability: A rule table is the translation of indications and contraindications from drug labels and clinical guidelines into deterministic logic of the form "if the patient satisfies condition X, then order Y has status Z." Unlike a model, a rule table can annotate each rule with its source literature and review status (e.g., "reviewed by clinical expert" or "unreviewed"), thereby supporting version pinning and re-testing. For systems that may fall under medical device software (SaMD) regulation, this traceability is often a prerequisite for compliance.

Why It Must Be Open Weights

For OpenMedCheck, an open model is not the cheaper choice but the only viable one. Emergency progress notes are special-category health data under GDPR Article 9, and many hospitals will not send every order and record to a third-party model API. With open weights, Gemma runs on the hospital's own GPU, the app binds only to 127.0.0.1, the only outbound call is to the local model, and patient context is not logged, stored, or cached.

The author compared three Gemma variants on the same machine using 76 synthetic cases: Gemma 4 E4B reached 97%, Gemma 3 4B reached 78% with 5 false positives, and Gemma 4 12B reached 80% with 32 call timeouts. Switching models requires changing a single configuration item. In addition, hospitals can pin, audit, and re-test the exact model they run, alongside a pharmacist-readable rule table—important for a system that may in the future be regulated as medical device software.

GDPR Article 9 and special-category data: Article 9 of the EU General Data Protection Regulation classifies "data concerning health" as special-category personal data, processing of which is prohibited in principle unless exceptions such as explicit consent or medical purposes are met, with additional restrictions on cross-border transfers. Sending every emergency order and progress note to a third-party cloud API means the data leaves the hospital's control and requires complex legal bases and data processing agreements, which many hospitals simply choose not to do. Local deployment of open-weight models is therefore not about saving money but about sidestepping the compliance obstacle of data egress.

Open weights vs. open source: Open weights means the model parameters can be downloaded and run locally, but the training data and training code are not necessarily public; this differs from a fully open-source software license. For hospitals, the key value of open weights is the ability to pin an exact version, audit its behavior on their own hardware, and re-run regression tests after model updates, without relying on silent vendor upgrades.

Results and Caveats That Must Be Retained

On an open set of 76 synthetic emergency cases, adding Gemma's reading of progress notes raised agreement with expected outcomes from 72% with pure rules to 97%, reduced missed detections from 21 of 42 to 1, produced 0 false positives among 34 cases that should have stayed quiet, and had a median model-step latency of 1.87 seconds.

The author explicitly lists limitations: the cases, prompts, and checker were built together, so this is a development set rather than clinical validation; and these numbers predate the addition of the past-history step, which has not yet been measured. Presenting these caveats honestly is part of the project's credibility.

The difference between a development set and clinical validation: The high agreement on the 76 synthetic cases is a "development set" result—the cases, prompts, and validator were constructed together by the same team, and the model and rules may inadvertently have adapted to the characteristics of these samples, making optimistic bias hard to avoid. Clinical validation typically requires evaluation on real patient data, prospectively or on external datasets, reporting sensitivity, specificity, and impact on clinical outcomes. The author's proactive flagging of this is a responsible way of clearly distinguishing a development demo from clinical evidence, and it signals to readers that the 97% should not be directly extrapolated to real-world performance.

Design Lessons Learned from Failure

Early prompts let Gemma judge conflicts itself, and it kept associating "NSAID and ACS" with any prescribed drug, including acetaminophen. The fix was to stop making the model do what the code already knows: Gemma does what it is good at—reading messy text and quoting it—while the rules make decisions.

Who Would Pay for This

The buyer is not the emergency physician but the people in the hospital responsible for medication safety: pharmacy and medication safety teams, and clinical informatics teams. They bear the cost of medication errors and ineffective alerts, yet cannot extend the check logic inside vendor prescription modules. EHR and clinical decision support vendors could also embed it as an open, auditable component. The business model is open core: the engine stays open source, and hospitals pay for a maintained, updated rule table with citations, integration with record systems (HL7 FHIR, CDS Hooks), and support and regulatory pathways. The author frankly admits this hypothesis has not yet been validated with buyers.

The project uses the Apache-2.0 license, Python 3.12, FastAPI, Ollama, and Pydantic, with roughly 1,080 automated tests. It must be emphasized again: this is a concept demo, for synthetic patients only, not a medical device, and must not be used with any real patient.

One-line Summary

OpenMedCheck uses Gemma to read emergency free text, code to validate, and rules to decide, filling in the patient context missing from prescription review.

Paragraph Summary

OpenMedCheck addresses the blind spot in emergency prescription review: key clinical clues (such as suspected ACS or prior upper GI bleeding) often exist as free text in progress notes and past history, which traditional coded-data-based review cannot see, and alerts are frequently overridden by doctors. The project uses a three-layer architecture: Gemma locally reads text and outputs structured answers with verbatim citations, ordinary code validates each citation's authenticity, negation, and subject attribution, and a deterministic rule table makes the final decision, with the model able to escalate alerts but never downgrade them. On 76 synthetic cases, agreement rose from 72% with pure rules to 97%, missed detections fell from 21 to 1, with zero false positives. Open weights are a hard requirement under GDPR compliance, and the model runs on an 8GB laptop GPU. The project is an Apache-2.0 concept demo, not a medical device.