The Healthcare Vocabulary for Agentic AI — Five Terms the Core Twenty Do Not Cover

The three-part core vocabulary — Foundations, Coordinate, Govern and Run — closed each intro with the same honest note. The twenty terms are the common vocabulary. Verticals extend it. Healthcare is the second vertical extension, because the Sirehs series gave cmdev enough deep implementation ground to make the extension real rather than synthetic.

The five terms below are what an agent team building for a Nigerian primary-care platform, a pan-African telehealth provider, or a European hospital under the AI Act's high-risk classification actually needs on top of the twenty. Each is a load-bearing primitive that decides whether the agent can be trusted with a clinical decision, a prescription, or a patient record — and whether the regulator, the clinical council, and the patient's family will trust it in that order.

The Clinical Decision Support Boundary

The agent is a support tool. The doctor is the clinical authority. The pharmacist is the safety layer. That order does not change because the agent is well-trained or because the model version is new.

• What it is — the hard line the agent does not cross. It transcribes the consultation. It drafts a clinical note for the doctor's signature. It surfaces a triage suggestion the doctor may consider. It does not diagnose. It does not prescribe. It does not decide what to dispense.
• Reach for it on every healthcare agent that touches clinical workflow. Reach for it especially on any product that markets itself as "AI-native" — the boundary is what the regulator will ask about.
• Trade-offs — the boundary constrains the agent's autonomy meaningfully. That constraint is the point. An agent that can prescribe is an agent whose vendor needs a medical licence that no AI vendor in the world currently holds.
• Cost and effort — the boundary is a design decision that costs almost nothing to enforce and everything to skip. Design it in from the first product-scoping meeting; do not attempt to add it after the first regulatory conversation.

Pharmacist-in-the-Loop

The core Human-in-the-Loop term becomes something more specific in healthcare. The pharmacist is not the fallback reviewer; the pharmacist is the load-bearing safety primitive.

• What it is — every prescription passes a NAFDAC-registered superintendent pharmacist for review before dispensing, regardless of how confident the doctor was or how clean the agent's note was. The pharmacist sees the prescription, the patient's drug history, the active medications, the relevant allergies, and any AI-flagged interactions.
• Reach for it on every agent that reaches a dispensing surface. The Sirehs architecture treats this as the load-bearing safety primitive; every healthcare agent should.
• Trade-offs — the pharmacist queue is a real bottleneck if the operational design is wrong. Treat it as a tier in the SLA (target under-five-minute response during operating hours), not as a manual checkpoint. The pharmacist is the safety layer; the queue design is what stops the safety layer from becoming the unit-economics blocker.
• Cost and effort — the technical implementation is a queue with mobile-first UI. The organisational implementation is the pharmacist contract, the SLA, and the escalation path. Design both from day one; the queue is not optional.

Data Residency at Consent

NDPA Section 41–43 governs cross-border transfer of personal data. In healthcare, personal data is clinical data, and cross-border transfer is not a one-time infrastructure decision — it is a consent flow the patient sees.

• What it is — a granular consent flow at patient enrolment (and re-consent at each escalation) that says what data can cross a jurisdictional boundary, under what conditions, for what purpose, and for how long. The default answer is that data stays in-country; the escalation path requires explicit consent.
• Reach for it on every healthcare agent whose stack has any cross-border component — Zoom Healthcare in the US, Bedrock-Frankfurt for the frontier tier, Google Cloud in the EU. Each cross-border hop is a consent surface.
• Trade-offs — a granular consent flow is more UX work than a single tick-box at enrolment. It is also what survives an NDPC audit and what earns patient trust. The Sirehs architecture treats consent as multi-language (Yoruba, Igbo, Hausa, English, Pidgin) and per-purpose, not as a one-time click.
• Cost and effort — a proper consent flow is a two-to-four-week UX and legal joint project. The audit surface it creates pays back on the first NDPC inspection.

FHIR-Portable State

The patient record cannot be a bespoke schema, because bespoke schemas are the reason patients have to repeat their medical history at every new hospital.

• What it is — the clinical record is stored in a schema that is FHIR R4-portable from the first row written. The database can be Postgres, the storage layer can be in-country, the encryption can be HSM-backed — but the schema shape is FHIR R4 native, and the export path is a standard FHIR bundle.
• Reach for it on every healthcare agent whose product will exist longer than one implementation. Interoperability is a future problem, and the schema decision that makes it possible has to be made before the first record is stored.
• Trade-offs — FHIR R4 is verbose. A hand-rolled schema is shorter, faster to iterate on, and locks you out of the ecosystem. The verbosity is the price of interoperability; pay it.
• Cost and effort — moderate schema-design cost up front. Zero cost when the day comes that you need to hand the patient's record to a referring hospital, an HMO integration, or the state health information exchange that eventually consolidates.

The Clinical-Corpus Eval

The core evals term says the eval is only as good as the dataset. In healthcare, the dataset must be curated by clinicians, red-teamed in the languages the patients actually use, and signed off by a licensed physician on the record.

• What it is — a curated corpus of Nigerian primary-care scenarios (or the equivalent for the vertical's jurisdiction) with expected agent behaviours, red-team prompts in the patient languages the agent will encounter, and pass-fail thresholds signed off by a licensed physician on the clinical advisory board.
• Reach for it before the first patient sees the agent. This is the gate that decides whether the local-LLM tier is safe to hand a Yoruba-speaking market woman on a Tuesday morning, and whether the escalation to a frontier model handles the same case any better.
• Trade-offs — building a clinical corpus is not a two-week engineering task. It is a joint project with a physician, a pharmacist, and a data-protection officer, and the corpus has to be re-curated every quarter as the vertical evolves.
• Cost and effort — the initial corpus is a quarter of clinical time plus a quarter of engineering. Ongoing curation is a rolling commitment. Under-invest, and the agent behaves competently on the demos and unpredictably on the real cases.

If your healthcare team is about to hand the first agent to the first patient, and the Wednesday standup scene in Part 1 becomes a Tuesday morning at Oja Oba, which of the five terms above is the one whose absence would keep you from letting the agent see her?

Companion content

• Building the Agent — Part 1: Foundations — the seven foundation terms
• Coordinating the Agent — Part 2 — the six coordination terms and the delegation chain
• Governing the Agent — Part 3 — the seven govern-and-run terms
• The Doctor at the Market Square: A Hybrid Telehealth Micro-Clinic Architecture — the healthcare-adjacent kiosk architecture
• When the Clinic Comes to Oja Oba: The Sire Mobile Unit Operating Model — the operating model these terms sit inside

How to engage

If your healthcare team is building an AI-augmented clinical workflow and you want a vendor-neutral read on which of the five terms above are essential in the first release and which can wait, talk to us at creativeminds.dev/contact.