Skip to main content

Update threshold

MethodPath
PUT/v1/slim/threshold

Authentication · Access policies

Replaces the home's threshold configuration: the alert limits every resident follows unless they have limits of their own.

Deprecated. Use PUT /v2/slim/threshold. This v1 route stays available until every client has moved.

Auth: Bearer token. The caller must be a practitioner, an admin, a super admin, or hold the "System Owner" access policy. The access policy must grant PlanDefinition:update (admins and super admins skip this check). Scope: The caller's project (from the token).

Behaviour​

  • The body replaces the stored settings; fields you omit take their schema defaults. The home's limit ranges and optional vitals, which v1 cannot send, are kept as stored.
  • Units: durationOfOutOfBed is in seconds, sleepDuration in hours.
  • enabled: false switches a metric fully off: its absolute and relative bands are stored off too, whatever their own enabled says, and the residents following the home hold no Signals limit for it (a resident with limits of their own keeps them). Out of bed keeps its relative band, which only tightens its limit while it is on.
  • To switch a metric back on, send its band's enabled: true as well. A switch-off stores the band's flag false, so a body that sets only the metric's enabled: true reads back enabled: true but arms nothing: the residents following the home get no limit for it.
  • meanHeartRate and meanRespiratoryRate relative bands cannot be enabled for the home: a resident without a baseline of their own would get no alarm from them. Set baseline limits per resident. One sent under enabled: false is stored off.
  • Heart-rate, respiratory-rate and vital limits are evaluated by Signals. A save that changes one is all or nothing, as PUT /v2/slim/threshold describes: it answers once Signals holds the changed limits for every resident following the home, or puts everything back and answers an error with saved: false and unconfirmedResidents (409 another save, a tenant move or a resident's own limits got in the way; 422 more than 1,000 followers; 502 out of time, or Signals did not take them; 500 the undo failed too). Nothing is stored then; send the save again. A 504 from the gateway can come while a failed save is still being put back: read the limits before sending it again.
  • Any other save is stored and passed on to residents in the background.
  • A change-history entry is written for a save that stands.
  • The response is the saved configuration.

Example​

curl -X PUT 'https://api.sandbox.ovok.com/v1/slim/threshold' \
  -H "Authorization: Bearer ${OVOK_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{
    "status": "active",
    "settings": {
      "heartRate": { "mode": "organization", "enabled": true, "absolute": { "enabled": true, "min": 40, "max": 120 } }
    }
  }'

Successful response​

200 — Threshold updated successfully.

Errors​

StatusMeaning
400Your session has no project, or Medplum refused the write.
401Bearer token is missing, invalid or expired.
403You are not a practitioner, admin or System Owner, or you lack PlanDefinition:update.
409Another save of this home's limits is running (a save the gateway timed out may still be undoing), the home is moving to another Signals tenant, or a resident's or the home's own limits were saved while this one ran. Nothing was changed; read the limits, then send the save again.
422The body fails validation, it enables a relative band on meanHeartRate or meanRespiratoryRate (home-wide bands are absolute only), or more than 1,000 residents follow the limits it changes.
502The home's stored thresholds could not be read, the save ran out of time, or Signals did not take the changed heart-rate, respiratory-rate or vital limits for every resident following the home. Nothing was changed; send the save again.
504The gateway's 29 s ran out while a failed save was still being put back (a home with many residents). Read the limits before sending the save again: until that is done, another save answers 409.