> ## Documentation Index
> Fetch the complete documentation index at: https://docs.olira.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Patient state

> How Olira models a patient as structured modules over time: stable profile, event-driven modules, memory bank, and rendered views.

Patient state is the platform's unified picture of a person: slow-changing baseline facts, rolling activity-driven signal, categorized memory, and generated **views**. Everything enters through **logs**. There is no parallel path that silently patches state, so every update is auditable and tied to something that happened.

We split state into **modules** with different lifecycles instead of one giant document. That keeps agent and workflow **context bounded**. Each module carries **timestamps and validity** so it is clear **as of when** a fact or signal applies; agents can tell what is current versus historical instead of relying on one undated document where recency is ambiguous. Organizations enable only the regions their log types actually feed. See the [log types catalog](/reference/log-types/symptom-reports) for how catalog entries map into modules.

<Note>
  Organization-level platform configuration decides which module types exist
  for your patients and which view templates are active. The mechanical split
  among stable, rolling, memory, and rendered views stays the same across
  organizations.
</Note>

## State modules

Patient state is grouped into four families with different update rhythms and roles. The Console explores them through observability and patient detail; engineers map log types and templates onto these regions in configuration. The module keys listed below are examples of what exists today, not a fixed set: the catalog grows as the platform adds new data domains, and your organization's configuration determines which modules are active.

### Stable profile

Baseline clinical and administrative facts that change relatively slowly: identity, conditions, medications, care relationships, coverage, and similar "current truth" that should stay valid until something explicitly updates it.

Example module keys (category `stable_data`): `demographics`, `condition_diagnosis`, `medications`, `treatment_phase`, `user_preferences`, `emergency_contact`, `care_team`, `insurance`, `social`, `pharmacy`, `procedures`, `allergies`, `immunizations`, `devices`, `family_history`.

### Event-driven modules

Time-varying signal derived from logs: symptoms, labs, vitals, device-derived measures, engagement, conversations, and other streams that reflect what is happening with the patient now and recently. Shape and churn differ by domain, but the idea is the same: rolling clinical and product context, not a permanent archive in one blob.

Example module keys (category `event_state`): `behavioral_state`, `symptoms`, `adherence`, `physical_activity`, `engagement`, `heart`, `sleep`, `lab_results`, `vitals`, `clinical_context`, `questionnaires`, `conversations`, `glucose`, `alerts_and_tasks`.

### Memory bank

Holds **unstructured insights** distilled from chats and similar sources. These are short, categorized memories the platform uses for continuity across sessions. Like other regions, memory is part of patient state, not a bolt-on store, and each insight keeps provenance back to what produced it.

### Views

Timestamped, template-driven outputs per **view category**: the rendered layers agents and APIs read; examples include medication, symptoms, and care context. They are built from stable, event-driven, and memory content on a schedule. [Views & templates](/read-data/views-and-templates) separates **templates**, how a category is defined, from **views**, the patient-specific result at a point in time.

To inspect the field-level models behind each module and watch your patient state fill in as you send more log types, open a patient's state in the [Console](/console/patients).

## Time, weekly signal & longer horizons

**Stable** modules answer "what do we believe right now?" For historical reads you typically take a single cut at a chosen timestamp.

**Event-driven modules** and the **memory bank** are intentionally **high-churn**: the live material holds on the order of **about a week** of relevant signal that rolls forward as new logs are processed, not an unbounded archive in one row. That keeps payloads sized for models and makes recency honest.

When a view or job needs **more than a week**, the platform **assembles a window**: it merges versioned module snapshots across week-aligned slices inside the interval you care about, deduplicating and letting fresher data win. You get a truthful picture of how that rolling surface evolved over the range, without pretending one static row describes the whole period.

<Note>
  **Views** work differently: generation starts from the **current view
  snapshot** for the run's timestamp, plus upstream modules; prior wording
  inside a block is carried through that block's last result, not by
  replay-merging every old snapshot document.
</Note>

## Next steps

<Columns cols={2}>
  <Card title="Views & templates" icon="table-columns" href="/read-data/views-and-templates">
    How blocks are built, cadence, confidence metrics, and provenance.
  </Card>

  <Card title="Accessing patient state" icon="plug" href="/read-data/accessing-patient-state">
    Read state via MCP, the Python SDK, or REST from your workflows.
  </Card>
</Columns>