Submit a reading by patient refIdCopy Anchor Link

• Sandbox: available
• Staging: available
• Production: unknown

The patient is patientRefId in the body, else subject.reference (Patient/<refId>).

The body is a FHIR R4 Observation: code, value[x] (valueQuantity, valueInteger, valueString, valueBoolean, valueDateTime, valueCodeableConcept) or dataAbsentReason, and a combined device sample's vitals as component[] (each code, value[x], optional dataAbsentReason). The clinical time is effectiveDateTime, effectiveInstant or effectivePeriod.start, else issued, else the server's receipt; device is {reference, display}; the first identifier's value is stored as v1's refId. Other FHIR elements (meta, extension, performer, interpretation, referenceRange, …) are accepted and ignored. v1's observedAt (it wins over effective[x]), refId, string dataAbsentReason and device.id still work. A node with dataAbsentReason and no value is judged as carrying no value. valueSampledData is judged by its latest sample and stored whole. A valueDateTime, on the reading or a component, is judged and aggregated as epoch ms (valueNumber) and listed as sent.

History is never judged. A reading whose category has a coding the tenant names as history (its historyCategories; the default pack's: batch-data, statistics, presence-batch, derived) is stored and deduplicated like any other, answered with no alerts, and never judged nor read by the rules.

The caller must be one of the patient's submitters, admins included: a known patient it is not attached to is a 403, an unknown one a 404 with type PATIENT_NOT_FOUND.

Idempotent. A reading is named by its first identifier (system|value), else by its clinical time, code, device and refId. A resend of one stored within the last hour is a 409 DUPLICATE_READING whose data.observationId is the stored reading, and is neither stored nor evaluated again. A reading with neither an identifier nor a clinical time is not deduplicated.

Concurrent requests are batched server-side. With Prefer: respond-sync evaluation finishes first and the reply adds alertIds, alerts ([{id, code}]), resolvedAlertIds and ruleCoverage; without it mode is async and alerts are delivered by webhook.

Through ovokCopy Anchor Link

• Who can call it: Submitter apps, and users whose access policy grants the capabilities.
• Capabilities, all required: signals_observations:create. Project admins have every capability; client applications get no admin bypass.
• If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), every patient the body names must be one you can update. A patient is named by its Signals id, or by its Medplum Patient id where Signals takes a refId; ovok asks Signals which patient a Signals id is.
• Each reading counts its patient as monitored for billing.

RequestCopy Anchor Link

BodyCopy Anchor Link

Required. Schema V1ObservationByRefDto.

ResponsesCopy Anchor Link

ExampleCopy Anchor Link

curl --request POST 'https://api.sandbox.ovok.com/v1/signals/api/observation' \
  --user "${OVOK_CLIENT_ID}:${OVOK_CLIENT_SECRET}" \
  --header 'Content-Type: application/json' \
  --data @body.json