What language models do, and what they never do
Every feature below is optional, default off, and gated by a clinic administrator and a clinician. Nothing here is shipped yet; status for each is noted. For an introduction aimed at clinicians and administrators, see the main AI features page.
A model may surface candidates for a human to screen; a model never produces a value that ends up in something we sign, submit, or attest to.
The test to apply: does the model's output end up in a regulatory submission, a quality-measure population, a claim, a case report form, or a signed receipt? If yes, the feature is forbidden, however good the model is and however carefully a human reviews it afterwards. Review does not make a model's output reproducible — and the whole premise of blueHealthcare is that a signed value remains checkable 18 months later, by someone who has never seen it before, using only the source record and the code.
This rule is not US regulation; it is clinical-safety reasoning. What varies by country is whether patient data may leave the building (the jurisdiction pack's business). What does not vary is whether a model may decide.
Default off at every level. A clinic's main administrator turns each feature on. Features that can see patient data also require approval by a named clinical reviewer — the clinic chooses who approves, with one floor: at least one approver must be an active clinician. A health worker who is not an administrator cannot enable a feature for themselves or their clinic.
A four-step lifecycle: the administrator turns a feature on; the clinic's medical director or named clinician approves it; the feature is trained (if it needs training for that clinic); and it moves to use. Nothing is available until all four steps are complete. A clinic that never turns any feature on loses nothing — the software works exactly as it does today.
An environment variable would be decoration, not a toggle. The activation record is a receipted clinical ledger entry, so every approval is auditable and can be revoked.
Each feature is a separate toggle under one master switch. Enabling any one requires the same activation: administrator on, clinician approval (if the feature uses patient data), training (if needed). The status column names what exists: BUILDING = lanes are active; DESIGNED = the design is complete and falsifiers written; PROPOSED = the idea is named and scoped, design pending. Two previously proposed features were withdrawn 2026-09-13 — see below.
| Feature | What it does | Uses patient data | Status |
|---|---|---|---|
| Terminology code search | A clinician asks for diagnoses or procedures matching a phrase, and the model ranks real terminology codes (SNOMED, ICD) by relevance. The clinician chooses which code to record; the model's suggestion reaches nothing signed. | No | DESIGNED |
| Local-to-standard code mapping | When a clinic onboards, it has local procedure, medication, and lab codes. The model maps each to SNOMED or ICD and shows the clinic the mapping, so a clinic administrator and its terminology expert can review and correct before codes go live. Runs once per clinic at setup. | No | DESIGNED |
| Coding candidates (payer-review only) | Where blueChart and blueClaims' deterministic revenue-coding rule has no hit, the model suggests a code; the auditor or payer reviewer screens it and decides whether to use it. Never reaches a claim without human acceptance. | Yes | DESIGNED |
| Trial patient matching | For a clinical trial, the model reads a patient's record and returns candidates matching the inclusion and exclusion criteria the trial defines. A research coordinator screens the candidates and decides whether to enroll the patient. Named in A1.1 as a permitted surface. | Yes | DESIGNED |
| Span extraction (assurance products) | In blueChart and blueClaims, where a deterministic gate exists to decide what reaches a reviewer, the model finds the sentence spans that support the verdict. A human still decides the verdict; the model finds the evidence. | Yes | DESIGNED |
Two previously proposed features were withdrawn 2026-09-13, on clinical advice, and will not be built as designed:
- Note-to-list reconciliation. Withdrawn because Manead Khin's absolute medication-list rule (Amendment A1.2, above) forbids a model from assembling or summarizing a medication list under any circumstance, even from already-structured data — and because this feature's own design scope named allergy and discharge reconciliation, which her 2026-09-13 ruling also added to the never-list.
- Message summary for clinician. Withdrawn as in tension with the same day's never-list entry for triage/acuity assignment — judging what in an incoming message needs summarizing is itself a triage decision.
Both remain named as closed-enum members in platform/assist/features.py (AssistFeature.NOTE_RECONCILIATION, AssistFeature.MESSAGE_SUMMARY) pending the code-level removal that will follow this decision; neither was ever built, enabled, or used with any clinic's data.
Status: NOT APPROVED FOR USE WITH PATIENTS YET. This is designed, not built — no drafting code exists in the repository. The design is published so that health departments, clinicians and counsel can review it before it is built. When a country's health department, clinicians and legal counsel have approved it locally, a clinic may turn it on. MOBLUEHQ provides the framework; the local approval is the clinic's work.
What it does: A health worker (not a clinician) enters a patient's vitals, symptoms, and history into a structured intake. The model turns that and any existing structured record data into a draft note, which the health worker reviews and signs. It bridges the gap between a clinic with no clinician on site for days and the need to send a patient to a referral hospital with signed documentation.
What it cannot do: No model-drafted assessment, plan, medication instructions, or examination findings. The design permits the model to draft only sentences that quote data the worker entered or the record already holds, checked against the source. The test: every sentence must anchor to something in the structured record or to the worker's own entries for that visit. If not, the note refuses to sign.
How it is marked: The note carries, inside its own text, a banner stating it was drafted by a model, from data and the worker's own entries, signed as responsible party (never author), and that no clinician has reviewed it unless a linked review exists. The banner survives printing, fax, and packaging to a referral hospital — a referral note carries it out of the system, so the receiving hospital knows what it is. The marking also appears in the receipt and patient record, always together in five places, so someone reading any path through the patient's record sees it.
How it is overseen: A named clinical reviewer samples signed drafted notes, weighted toward the fast signatures with no changes, and records a separate signed review. The administrator can disable the feature at any site based on the sample findings.
This feature exists outside A1.1 (Amendment A1.1 in the licensing section forbids models in submitted fields). It is recorded as a named exception to that rule, with conditions attached, not as an amendment to the rule itself.
These are forbidden regardless of how the model is configured or where it runs:
- Order decision support. A model never recommends whether to place an order, to approve it, or to change it. The clinician decides.
- Critical-value evaluation. When a lab value is critical (too high or too low), a model never decides the action. A named person does.
- Pharmacist verification and the medication administration record. A model never verifies a medication is safe to give, never approves a dose, never signs the MAR.
- Discharge/disposition recommendations. A model never recommends whether or where a patient is discharged. Added 2026-09-13 (Manead) — adjacent to the MAR item but distinct enough to name separately.
- Triage/acuity assignment. A model never assigns or recommends how urgently a patient should be seen. Added 2026-09-13 (Manead).
- Allergy/interaction suggestions. A model never suggests whether an allergy or a drug interaction is clinically significant. Added 2026-09-13 (Manead).
- Patient identity matching. A model never decides whether two records are the same patient. Wrong-patient events are too harmful and a model's error too confident.
- Inbox priority or any worklist ordering. A model never decides the order in which a clinician sees tasks, messages, or patients. That is a silent decision.
- Note, report, message, or portal text. A model never writes narrative that reaches a record, a patient message, a referral letter, or anything sent outside the clinic.
- Quality-measure populations. A model never decides who is in a quality measure. The denominator and numerator must be reproducible deterministically.
- Claim fields or revenue coding. A model never writes a claim field directly — it may surface candidates for a payer reviewer only, and never for claim submission.
- Authorization, care-team, consent, or receipt fields. A model never decides who may access a record, who cares for a patient, whether consent is given, or what a receipt attests.
- Header-source-of-truth fields — code status, isolation. A model never proposes, summarizes, or touches these. Added 2026-09-13 (Manead), from the earlier design work on the record header.
- Medication lists, assembled or summarized by a model — absolute, no exception. Forbidden even from already-structured data: "a model-compiled medication list is exactly the failure mode that caused real medication errors in EHR copy-paste long before AI existed — compiling, de-duplicating, or reformatting a list is itself a judgment call" (Manead, 2026-09-13). A model may only be quoted for a single medication exactly as a clinician typed it, one at a time.
- Early-warning scoring. A model never computes an early-warning score. Scores are arithmetic on flowsheet values and must be deterministic. We build those without a model.
- Anything patient-facing and generative. No patient ever reads model-generated text.
The five items above marked "Added 2026-09-13 (Manead)" and the absolute medication-list prohibition are rulings from Manead Khin, our clinical authority, recorded in docs/MANEAD_INVARIANTS.md Amendment A1.2. Nothing already on this list has been loosened.
These are deterministic features, built without any language model:
- Early-warning scores. Arithmetic on flowsheet values (SOFA, qSOFA, NEWS, MET). No model involved. Better: reproducible, auditable, and fast.
- Duplicate-record detection. Ordinary probabilistic matching on demographics and record keys. A model would add wrong-patient risk with no gain.
- Order sets and care protocols. Templates defined by the clinic's own clinicians, not learned by a model. Better: clinicians own the logic, changes are auditable, and every site can see every line.
- Structured intake. A versioned, content-addressed questionnaire plus a pure, total renderer: the same answers and the same questionnaire version always produce byte-identical note text. Fail-closed completeness with typed reasons; free text is reproduced exactly as the worker typed it and attributed to them, never blended into templated prose; the finalized note is a real
DocumentReferencewhose provenance names the questionnaire hash, id and version, the entering worker, and an explicitstructured-intake-no-modelmarker. This is what the drafting tool was mostly for, without any of the drafting tool's conditions. Built 2026-09-13 —platform/intake/, 40 tests.
Three choices, all optional:
- A local model on the clinic's own hardware. The model runs on the clinic's server, on the clinic's network. Patient data stays on the machine. No Internet call, ever. The software refuses if the model is unavailable.
- A contracted provider. The clinic approves a contract with a model provider (e.g., a cloud service or a nonprofit) and MOBLUEHQ records the provider's identity and terms. Patient data leaves the building only if the clinic has signed that approval. The software fails closed: if the clinic revokes approval, the feature stops. If the provider identity is not pinned, the feature stops. If there is no approval on file, the feature refuses to run.
- Off. The feature is not available. The software works with no degradation.
No fallback. If a clinic chooses local and the local model fails, the feature does not silently try a cloud provider. It stops and tells the clinician why. If a clinic sets up a contract and the provider is offline, the feature stops. Patient data never leaves the building unless a clinic explicitly approved that path.
Two open questions, pending external review:
- Clinical validation. The clinical reviewer in each country (typically the health ministry or a hospital board) will evaluate whether these features help or harm. The answer varies by country, by clinic, and by the conditions MOBLUEHQ attaches. We provide the toggles; you decide what to turn on.
- Legal and licensing. Vendoring the components from other clinical products (blueChart and blueClaims) brings proprietary headers and legal questions. The licence is proposed and under counsel review. Nothing ships until those questions are answered.
Until these are resolved, the features are available for testing with synthetic data only, never with real patients.
None of this is shipped. The designs are complete. Some lanes are building. Falsifiers are written. When a feature reaches BUILDING status, it is under test with recorded adversarial outputs and synthetic fixtures only. No real patient data will ever be used until a country's health authority and legal counsel have approved it.
For a clinic administrator or clinician overview of these AI features, visit the main blueHealthcare section.