# Get trends graphs

Canonical page: https://docs.ovok.com/api/slim/trends/get-trends-graphs

`GET /v1/slim/trends/graphs`

Returns a resident's heart rate and respiratory rate over a date range, grouped by graph type and device, with threshold and baseline values and summary statistics. Use it to draw the trend charts. For live readings from the last day, use `GET /v1/slim/trends/realtime`.

**Auth:** bearer token. The caller must be a practitioner, an admin or a System Owner, and needs `Organization:read`, `Device:read`, `Patient:read` and `DocumentReference:read`.
**Scope:** the caller's project (from the token). Observations are read with your token, so Medplum's access policy limits what you see.

## Behaviour

- `graphType` is a comma-separated list of `heartRate` and `respiratoryRate`. Repeated entries are ignored. `startDate` must not be after `endDate`.
- Days are cut at the project's time zone (default `Europe/Berlin`). The chart for a day starts at 09:00 local time, so a night stays in one day.
- A range of two or more days is an over-day chart: one point per day, at 09:00 local time, starting the day after `startDate`. Each point is the day's mean from the pre-computed statistics, with batch readings filling nights that have none.
- A range of one day or less is an in-day chart: 30-second points across the 24 hours that start at 09:00 local time on `startDate`. `endDate` only decides which kind of chart you get. In-day points come from batch readings only.
- Before a night's recording is picked, both charts drop the readings and sleep statistics that end outside the resident's use periods of their device, as `GET /v1/slim/sleep/statistics` does. So a previous resident's night that ended before the device was handed over, but reached Ovok after it and was stored under this resident, is not charted. A resident with no device use history keeps all of them.
- Once a resident has any use period, this also drops the readings of a device with no period of theirs, and those from before a device's earliest period. A device assigned before use periods were recorded gets its first one on its next edit in Ovok, starting at the Device's last write before that edit, so its readings from before then are not charted. Each device whose readings in a request all drop is counted in the `sleep.device_use_device_dropped` metric and logged at most once a minute.
- The use periods are read on every uncached call. When Medplum answers that read with an error, the route answers `502` rather than chart a night it cannot check; when the request itself fails, the route fails with Medplum's status, or `500`.
- When a night (the calendar day its recordings end on, in the project's time zone) has several sleep recordings left, both charts show only the readings of the one whose sleep statistics were written last (latest `meta.lastUpdated`): its heart and respiratory rate statistics, matched by the recording's exact period, and its batch readings, matched by their start (below). That is the rule `GET /v1/slim/sleep/statistics` uses. A night with no sleep statistics goes by its heart and respiratory rate statistics' write times. A night with one recording left, a night with batch readings only, and a night none of whose readings belongs to the chosen recording are charted with all the readings left. Readings with no end time cannot be put on a night, so neither rule applies to them: they are always charted.
- Sleep statistics are read over the chart's range, which ends at 09:00 local time on its last day, so a recording that starts later that day is not weighed.
- A batch block is matched by its start, because Sleepiz ends one up to about ten minutes before its recording: it belongs to the recording that starts at the same instant and ends at or after it, at most 15 minutes later, the earliest such end when two recordings share the start. A batch block that starts at any other time belongs to no recording, so on a night with several recordings it is dropped: a chosen recording whose only heart rate reading is a batch block that starts after the recording shows no heart rate for that night, while its respiratory rate still shows.
- Every bucket is returned. A bucket without a reading has `data: null`. `pointTimestamp` and `pointTimestampRange` show which readings filled it.
- `maxThreshold`, `minThreshold`, `maxBaseLine` and `minBaseLine` are the values that applied at that time. They are left out when none apply, and when the threshold lookup fails the chart still returns without them.
- When a heart or breathing rate limit changed inside the range (a nurse's edit or a home-wide save), each point carries the limit in force at its own time, as Signals recorded it, so the lines step where the limit changed. Points after the last change carry the limits the limits screen shows. If Signals' change history cannot be read, every point carries the current limits.
- Devices are keyed `<manufacturer>-<device id>`. A resident who changed device has one entry per device.
- A graph type with no data in the range comes back as `{}`. When nothing at all can be charted, both `heartRate` and `respiratoryRate` are `{}`.
- Results are cached for up to 60 seconds. A write to the resident's data invalidates the cache sooner.

## Example

```bash
curl -X GET 'https://api.sandbox.ovok.com/v1/slim/trends/graphs?patientId=c3499c27-2973-0a7f-807e-fb8676a92dcb&startDate=2026-09-01T00:00:00Z&endDate=2026-09-30T00:00:00Z&graphType=heartRate,respiratoryRate' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk'
```

```json
{
  "heartRate": {
    "Sleepiz-5f0c...": {
      "dataPoints": [
        {
          "timestamp": "2026-09-02T07:00:00.000Z",
          "timestampMs": 1788332400000,
          "data": 72,
          "maxThreshold": 100,
          "minThreshold": 60,
          "pointTimestamp": "2026-09-02T05:41:00.000Z"
        }
      ],
      "stats": { "average": 72, "max": 72, "min": 72, "total": 1 }
    }
  },
  "respiratoryRate": {}
}
```