AI features

What Blue does, what Blue never does, and who decides

Blue is the optional AI assistance inside blueHealthcare. It is off everywhere until a clinic turns it on, one feature at a time. This page is the whole of it — what we are building, what we refuse outright, and what we withdrew after clinical review. See the technical details and architecture.

Off by defaultOne feature at a timeA named human decides

EnablementYour administrator, per feature, per clinic.

ApprovalA clinician you name, for anything reading patient data.

AuthorshipThe person who accepts is the author. Always.

The governing rule

No configuration of this software lets a model make a clinical decision. Not in any country, not with any toggle, not with review afterwards.

That is our own rule, and it does not change when a jurisdiction's rules change. The reason is not regulation: a signed value has to stay checkable years later by someone who was never in the room, from the source record and the code. Human review does not make a model's output reproducible.

Rules for AI in medicine are unsettled and differ sharply between countries, and we do not claim to know where they will land. Everything here is off by default, has to be switched on deliberately by named people at a single clinic, and can be switched off again. We are not telling any health system what it should permit.

If there is one doctor in a three-hundred-square-mile area and nobody to help them, we want to have asked how software could responsibly help. In a hospital with a full medical staff and a compliance department, the honest answer may be that all of it stays off — and the software loses nothing when it does.

Meet Blue

What Blue is

A name for the assistance, so a clinician who learns it in one tool recognises it in the next. Your clinic can rename it.

Blue offers candidates. A named person accepts, edits or rejects each one, and that acceptance is the recorded act.

What Blue is not

Not a colleague, not a chat window, not a voice. Blue has no opinions and never speaks in the first person.

Blue is never the author of anything signed. Its name appears in the record of what happened, never on a byline.

Blue at setup

Blue also helps a clinic get started — as a signed download, before any patient exists in the system.

A clinic installing blueHealthcare on its own machine, with no IT department and nobody experienced to ask, can run the same assistant to get set up. The install itself needs no model at all; the AI layer is one optional add-on that only answers setup questions, only from the manuals bundled with the download. Being built

Works with AI fully off

The install steps, the plain-language health checks, and the signed confirmation record all run with no model anywhere in the path. The AI layer is optional; the setup is not built around it.

The optional AI layer

Off until two people at the clinic turn it on. It answers only from the manuals bundled with the download, shows its source for every answer, and never reads patient data — none exists yet at setup.

Signed downloadA person confirms every stepRuns on your own machine

See how Blue helps at setup →

Candidate, and decision

Blue can propose. Only a named person can decide.

Authority transfers; text does not. The diagram deliberately uses no green for accepted and no red for rejected — both are ordinary, and the point is who decides, not which answer won.

What it looks like in use

Nothing is pre-selected and nothing is filled in for you. Each candidate names where it came from. Rejecting is exactly as easy as accepting.

Design mockup: blueHealthcare shell, Office area (master files), showing Blue's two suggested standard code candidates for a clinic's own lab code, each with Accept, Edit, Reject and a none-of-these option, none pre-selected. — Design mockup · not built
**Design mockup. This feature is not built.** Shown inside blueHealthcare's real shell (top bar, left rail, product tokens) with synthetic data, composed from the platform's own components — not a live feature, and not a real screenshot of a shipped screen. Accepting and rejecting carry the same weight on purpose. An interface where accepting is one click and rejecting is three has built a rubber stamp, whatever else it says.

Design mockup: the same terminology-mapping screen while Blue is still working, showing the Blue Flow B mark's Connect motion — fine signal paths briefly linking its four modules — next to the words 'Blue is mapping the fields…' — no candidates shown yet. — Design mockup — not built

What we are building

Nineteen features. Eighteen read no patient data at all.

Those eighteen need no clinician approver and no jurisdiction question — an administrator can switch them on alone. Every group below links to a detailed page with a synthetic walkthrough and a candidate-card mockup for each tool — what it helps with, who used it and how, what it never does, and its honest build status. Two are already being built; everything else is planned.

Configuration and terminology

Maps your own codes to the standardsProcedures, medications, lab tests and the test menu, reviewed by your people before go-live.

Finds the right code from a phraseYou type what you mean; Blue ranks real codes; you pick. Being built

See detailed examples and mockups →

Migration — the first week at every clinic

Maps a legacy export's columnsBlue proposes a rule, never a row value.

Describes an undocumented exportFor the clinic that has its data and no way to say what it is.

Transcribes a paper registerEvery row held for a person to clear, one at a time.

See detailed examples and mockups →

Interfaces

Explains an HL7 rejectionBeing wrong costs an afternoon, never a patient.

Proposes a field mappingAdmitted only with a test attached. A mapping that cannot be checked cannot be accepted.

See detailed examples and mockups →

Support — no IT staff, no vendor within a day's travel

Answers "how do I do this?"From our own manuals. Being built

Answers from the runbookCiting the page, over a bundle carrying no patient data.

Tutors a new user in a sandboxWhere there is nobody to ask.

See detailed examples and mockups →

Scheduling and operations

Drafts a schedule templateFrom "adult clinic Tuesday and Thursday mornings, twenty-minute slots".

Turns a rostering rule into a constraintThe solver stays the product; the roster stays explainable.

See detailed examples and mockups →

Compliance, grants and the back office

Assembles the accreditation packWhat a one-doctor clinic facing its first inspection needs.

Turns a reporting template into a specificationThe specification produces every number — never the model.

Extracts contract renewal and notice datesThe auto-renewed contract nobody read. Being built

Reads invoice lines into structureBlue extracts; arithmetic decides. Being built

See detailed examples and mockups →

Inside blueChart and blueClaims

Helps author coverage criteria, and back-tests themAdopted by edition, never by run — so a stranger can rerun it.

Generates a policy sidecar and checks it is groundedNo personal data.

See detailed examples and mockups →

The one that reads patient data, and one withdrawn

—

Sorting the incoming document tray withdrawnDeciding which patient a fax belongs to is patient-identity matching, which no toggle ever turns on. We had it on this list; it should never have been. Sorting by document kind, for a person who then attaches it themselves, is a different feature and is still open.

Turns a question into a record search reads recordsBlue writes only the query. Authorization still decides what comes back.

—

Problem candidates from a note heldThe problems half is being re-scoped, not shipped. The medication half does not survive in any form: Manead Khin, our clinical authority, ruled a model may never assemble or summarize a medication list — full stop, even from already-structured data. See "Withdrawn, and why" below.

See detailed examples and mockups →

44%

of every AI idea we could find is better without AI. We examined 36 parts of this software and wrote down 818 ideas, including the ones we refuse.

Better with no AI — 44%Everything else — 56%

Early-warning scores are arithmetic on the values you charted. Duplicate-record detection is ordinary matching. Order sets are your clinicians' own templates. A warning before a shelf goes empty is counting. A lapsed licence is a date comparison. In every one of those, deterministic is not the cautious choice — it is the better one: reproducible, auditable, fast, and it arrives with no toggle, no approval and no answer to a jurisdiction question.

What no toggle ever turns on

Permanent, regardless of configuration, country, or how good a model becomes.

NEVER 01Order decisionsOnly a clinician decides whether to place, approve, or change an order.

NEVER 02Critical valuesWhen a lab value is critical, a named person — never a model — decides what to do.

NEVER 03Discharge, disposition, triage and acuityOnly a clinician decides whether and where a patient is discharged, and only a clinician decides how urgently a patient needs to be seen.

NEVER 04Pharmacist workOnly a pharmacist verifies a medication is safe, approves a dose, and signs the medication administration record.

NEVER 05Medication listsA model never assembles, compiles, de-duplicates, or reformats a medication list — even from data your clinic already has in structured form. It may only be quoted, one medication at a time, exactly as a clinician typed it, for that clinician to add.

NEVER 06Allergies and interactionsOnly a clinician or pharmacist decides whether an allergy or interaction is clinically significant.

NEVER 07Code status and isolationThese header fields are set by a clinician and relied on exactly as set. A model never proposes, summarizes, or touches them.

NEVER 08Patient identityOnly a human decides whether two records are the same patient. The risk of error is too high.

NEVER 09Worklist orderOnly you decide the order in which you see patients, messages, and tasks. The system will not decide for you.

NEVER 10Narrative anyone readsA model never writes anything that reaches a patient, a referral letter, or your chart. No patient ever reads text a model generated.

NEVER 11Measures and claimsQuality measure populations must be checkable deterministically, without a model. A model never writes a claim field — it may suggest candidates for your payer reviewer, and that is the end of the line.

NEVER 12Access and consentA model never decides who may access a record, who cares for a patient, what consent means, or what a signed receipt attests.

Added 2026-09-13 by Manead Khin, our clinical authority: discharge/disposition recommendations, triage/acuity assignment, allergy/interaction suggestions, header-source-of-truth fields (code status, isolation), and the absolute prohibition on model-assembled medication lists. Nothing already on this list has been loosened.

Where Blue runs

Your clinic chooses one, per feature.

On your own hardware

A model inside your own network. Patient data never leaves the building. No internet call, ever.

Your contracted provider

Your own agreement and your own key. Data leaves only if you signed for that, and the provider's identity is pinned — a substitution stops the feature.

Off

The feature is not available, and your clinic loses nothing.

No fallback. If the path you chose is unavailable, the feature stops and tells you why. It will never quietly reach the internet instead. Where your patients' data goes is not something software may reconsider at runtime because something was slow.

Two ways it runs

Beside the record system you have, or as the record system you do not.

Both modes are equal. Neither is the advanced one.

What your patients see

A patient reading their own record can see where a model contributed — never the model's text, which reaches no patient, but the fact and the nature of it.

In the patient's own record

Part of this record was prepared with help from an AI tool that suggested information from your chart; your care team reviewed and confirmed it.

Suggested and confirmed — not drafted. The wording is our clinical adviser's, because the accurate frame matters more here than ours did.

Withdrawn, and why

We would rather show you this than quietly change a table.

Withdrawn after clinical review

Note-to-list reconciliation. Withdrawn because our clinical authority, Manead Khin, ruled that a model may never assemble or summarize a medication list — full stop, even from already-structured data — and because this feature's own documented scope named allergy and discharge reconciliation, which she added to the never-list the same day.

Message summary for clinician. Withdrawn because drafting a summary of a patient's message is in tension with her never-list entry for triage and acuity assignment — deciding what in a message is urgent enough to summarize is itself a triage judgment.

Superseded, not rejected

A tool that would draft a whole note from a model. Rejected on clinical advice. The structured questionnaire we built instead uses no model at all, works in every country today, and delivers most of the same benefit.

The structured questionnaire we built instead uses no model at all, works in every country today, and already delivers most of the same benefit. Paper capture, clinician translation and dictation each need a named exception from our clinical adviser. None is ours to grant.

Everything we've considered

Every AI idea we're considering, building, or have ruled out

This page shows what a clinic actually sees. A second page lists the full working catalogue behind it — the ideas being built, the ones still under discussion, the ones on hold, and the ones we turned down, each with a plain reason.

See every AI idea →