Concepts

AnyBio routes, surfaces, holds, ranks and records. It does not decide for a clinician and it does not diagnose. Each concept below names the object in the API, what it is for, and the routes that touch it.

Patient

A patient is an xuser: a person in your organization, identified by your own external identifier and attached to a project. Patients are created with POST /api/v1/xusers and read with GET /api/v1/xusers/{xuser_id}. A patient's phone number is a contact point (PUT /api/v1/xusers/{xuser_id}/phone), and SMS consent is recorded per address, not per person. Every other object in this section hangs off a patient: episodes, observations, hand-offs, consent evidence. Patient data is scoped to one organization and one environment; a sandbox key never reads a production patient.

Episode

An episode is a bounded window of a patient's time that holds what happened in it: the observations linked to it, the timeline events, the attention level. A program opens one at enrollment; detection-based profiles open one when a condition holds. Episodes are read with GET /api/v1/episodes (filter by xuser_id, episode_profile_id, status, attention_gte) and GET /api/v1/episodes/{id}. GET /api/v1/episodes/{id}/attention returns the attention breakdown, GET /api/v1/episodes/{id}/fhir returns the episode as a FHIR bundle, and POST /api/v1/episodes/{id}/close ends it. An observation is routed to an episode only when the episode is active and its program declares the observation's signal in required_signals.

Program

A program is an episode profile: the authored document that says what a cohort's episodes require, watch for, and do. Its spec carries required_signals, detection, thresholds, attention_config, agents, disclosure, exports, sdk, an optional symptom_protocol and an optional billing_period. Programs are created with POST /api/v1/episode-profiles, activated with POST /api/v1/episode-profiles/{id}/activate, and patients are enrolled with POST /api/v1/episode-profiles/{slug}/enroll. Only an active program accepts enrollment. Saving a program also materializes the rules its spec declares (schedule triggers and the symptom trigger) as policy rows, so the authored document and the rules that run cannot disagree.

Rule

A rule is a policy: a trigger, a condition, and a list of actions. Triggers are observation_create, event_create, episode_start, episode_update, schedule, inactivity and manual. The condition is an expression over the reading (systolic >= 160 OR diastolic >= 100), state, baselines and named thresholds. Actions raise or clear attention, set a floor, emit an event, run an agent, send a gated notification, create an observation, or start a symptom interview. Rules are scoped to the environment, a project, or one program; each has a cooldown_seconds per episode and an optional max_executions_per_episode. They are managed at /api/v1/policies, dry-run with POST /api/v1/policies/{policy_id}/test, and every evaluation is recorded at GET /api/v1/policies/{policy_id}/executions. The full schema is in the policy reference.

Attention

Attention is a number from 0 to 100 that ranks episodes for a care team. It is never set directly; it is computed from a ledger of contributions, each with points, a reason, the signals involved and a half-life. Contributions decay, converging signals multiply, and a floor keeps attention from falling below a value until a person acknowledges it. The bands are Routine, Elevated, Concerning, Urgent and Critical, with thresholds the program can configure. Rules add contributions (contribute_attention), the symptom agent adds one when an interview surfaces something, and a resolved hand-off clears the one it raised. A clinician lowers the floor with POST /api/v1/episodes/{id}/attention/acknowledge. The formula and defaults are in the policy reference.

Hold

A hold is the loop refusing to proceed on its own. There are two. The gate hold is a patient-facing message the communication gate withheld: its decision record has release_status: held_for_review, and only a signed-in person can release or reject it (POST /api/v1/compliance/checks/{check_id}/release, .../reject). The automation hold is a care hand-off whose automation_resumed_at is empty: while it stands, automated care SMS to that patient is withheld and a person owns the conversation. A hold is not a failure state; it is the record that a person is now required.

Hand-off

A hand-off is a durable follow-up owned by a person. It is created when automation cannot continue for a patient (a message budget exhausted, a messaging policy missing, automation paused by a protocol rule, a delivery outcome unknown) and moves queued to claimed to resolved. It carries a queue label, routing to primary and backup staff, a due time and an escalation time, contact attempts with outcomes, and a disposition. Every change appends an event and bumps a version; a stale actor gets a 409. The routes are under /api/v1/care-handoffs and are staff-session only. See care hand-offs.

Record

A record is what the loop leaves behind so a reviewer can see what happened without asking anyone. Rules leave policy_executions with the context they evaluated and the actions they ran. The gate leaves a communication_compliance_check per message with the decision, the rationale, the detected claims, the original content and any rewritten content. Hand-offs leave care_handoff_events. Attention leaves contributions and acknowledgments. Symptom answers become observations. Audit queries are under /api/v1/audit (Admin scope). Records are read back through the same API and can be exported; see export.

The verbs

We say a rule routes a reading, the agent surfaces a finding, the gate holds a message, attention ranks an episode, and the system records a decision. A person reviews, releases, claims, resolves and acknowledges. The software does not triage, escalate on its own judgement, decide, or diagnose, and nothing here is autonomous: every path that reaches a patient is gated and every path that needs judgement ends at a person.