POST /v1/logs/batch, Olira:
- Validates the
log_typefield (log type) against the platform catalog - Validates the
payloadagainst that log type’s JSON schema - Writes each record to the log store
- Optionally appends to the TEMP segment of matching view templates
Your organization’s platform configuration controls which log types are
accepted. Only log types you selected during onboarding are active;
submitting an unlisted type returns
403.Sending a log
Send multiple logs in one request by adding objects to the
logs array. Each object is one log.
Retries and idempotency
idempotency_key is for the same submission sent twice — a timeout, a 5xx, or your own retry loop. It is not how you correct a log you already stored. To change clinical state, send a new event (see lifecycle-tracked logs below). Reusing a key with a different payload is still a no-op: the original event stays, the new payload is ignored.
log() is a tap: it enqueues and returns immediately. It has no idempotency_key, so a path that runs twice stores two events (unless both have the same timestamp and payload). log_batch() and log_fhir() send immediately and accept an optional key for retries.
Set idempotency_key whenever you might send the same call twice. The second call returns accepted and does not create another event or re-apply patient-state updates.
If you omit the key and the log has a timestamp, an identical resend is still treated as a duplicate. Without a timestamp, each submission is stored separately.
log_fhir() has no timestamp argument — Olira
takes the date from the FHIR resource. If that resource has no usable date, each
call is stamped with the current time, so two sends without a key become two
events. log_batch() is the same if you omit timestamp; the difference is you
set that field yourself.One key per log_fhir() call
A single FHIR resource can map to more than one Olira event. For example, a treatment plan from an EHR can produce both a follow-up item and a treatment-phase update — see FHIR resource mapping. You still pass one idempotency_key for the call. Olira applies it to each mapped event so a retry does not duplicate any of them.
You do not add a log type to the key. If you send plan-2026-01-10, Olira records that as plan-2026-01-10:clinical_plan_item and plan-2026-01-10:treatment_phase. A patient demographics update is recorded as your-key:demographics. Retry with the same string you sent the first time.
log_batch() stores the key you supply as-is. The same string used on log_batch and log_fhir therefore identifies different stored events.
Lifecycle-tracked logs vs. point-in-time records
Log types marked lifecycle create or update a persisted entry in patient state, carrying a status (active, resolved, remission, …), an effective time window, and a full audit trail of transitions. The entry does not resolve itself with the passage of time. You must explicitly close it by logging a follow-up event. For example, a symptom logged with a score above zero becomes active; it only becomes resolved when you log the same symptom again with score: 0. An alert created via care_action stays active until you re-log the same entry_key with status: "resolved". Conditions, allergies, devices, and procedures follow the same pattern; each is active until you log action: "remove" or a terminal clinical_status.
Log types without the lifecycle marker are immutable records. Each event is an independent observation appended to a rolling window: a vital sign reading, a lab result, a sleep session, a conversation transcript. There is nothing to “resolve”; older records naturally age out of the active window. Use these to capture what happened, not to track an ongoing clinical state.