SOP and Process Flow

The demo shows the system working; this page shows the operating procedure it implements, written the way a clinic would adopt it. Every rule below is enforced in code and exercised by the test suite; the flow diagram is the same boundary the red-team log attacks. Green runs on its own. Coral waits for a person.

Purpose and scope

This procedure governs how inbound patient messages are triaged, answered, and escalated when an assistant drafts on the care team's behalf. It applies to every message that reaches the coordinator inbox. It does not change who is clinically responsible: clinical judgment belongs to the named provider, and nothing leaves the practice without a person approving it.

Roles

Assistant	Reads the thread, classifies the message, pulls only allowlisted fields, drafts, flags, and logs. Cannot send, cannot escalate clinically on its own authority, cannot answer clinical questions.
Care coordinator	Owns the inbox. Reviews every draft, edits or replaces it, approves every send, and makes the routing judgment calls the assistant holds for review.
Named provider	Receives clinical flags for their own patients. One clinician per thread.
On-call physician	Receives escalations when the patient has no assigned provider or the assigned provider is the escalation target. Escalation is internal; the patient is not told by the machine.

The flow

runs automatically terminates at a person decision audit, always

Procedure

1. Intake and identity

Identity comes from the thread, never from the message text. A message claiming to be someone else does not change whose thread it is.why: impersonation is the cheapest attack; the binding is structural
If the thread is not linked to a patient record, the assistant drafts a verification-only reply built from practice details, and looks nothing up.why: it must never confirm whether a named person is a patient

2. Screening and classification

Language attempting to instruct the system is treated as content, never as instruction: neutral acknowledgement, no data pulled, coordinator warned.
Every message is classified before any data is touched: urgent, clinical, or administrative (scheduling, billing, records).
Urgent: the practice's urgent auto-reply goes to the patient once, and the on-call escalation is internal. The machine never tells a patient they are having an emergency.
Clinical: the question is flagged to the named provider, one clinician per thread. The assistant answers only the administrative remainder, and never hedges an answer it is not sure of.

3. Data and drafting

Each message type has a field allowlist, and the assistant pulls only those fields, only for the thread's patient. A scheduling question cannot pull clinical notes.why: minimum necessary, enforced at the query, not the prose
Requests about another person resolve through the authorization record: a documented representative gets an answer within their scope and nothing beyond it; everyone else gets a refusal worded identically whether or not the person is a patient.
Drafts follow the message they answer, in the practice's voice, and propose concrete next steps.

4. The gate, the send, the record

Nothing sends without the coordinator. The draft can be approved, edited, or discarded for a fresh reply; the gate is the same in every path.
Every identity check, classification, field access, draft, approval, refusal and escalation is written to an append-only audit log as it happens.why: the record is the accountability, and it cannot be edited after the fact

What the assistant may never do

Send anything external on its own, including "obvious" replies.
Answer a clinical question, or state a number it is not certain of.
Confirm or deny that any named person is a patient.
Pull a field outside the message type's allowlist, or any field for a different patient.
Treat message text as instructions, whoever it claims to be from.
Tell a patient they are experiencing an emergency; it routes, a clinician decides.

Review cadence

The test suite is the standing review: it reruns every rule above on every change, and the generated report is the evidence. The procedure itself is reviewed when a rule fires wrongly in either direction, over-blocking or under-blocking, and both directions are test cases.

This SOP describes the demo system on this site, which runs on synthetic data for a fictional practice. It is a demonstration of operational design, not clinical or legal guidance, and adopting anything like it in a real practice is a decision for that practice's clinical and compliance owners.