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

# Hospital Integration

> Integrate Stealthera data into HIS, EMR, and monitoring dashboards

This guide is for teams connecting Stealthera to a hospital information system (HIS), electronic medical record (EMR), or a monitoring dashboard.

## Integration model

Stealthera is a **pull-based** API. Your platform calls the endpoints on a schedule and stores or displays the results. Stealthera handles all device communication and data normalization — you only consume the REST endpoints.

```text theme={null}
Stealthera API  ──poll──▶  Your HIS / EMR / Dashboard
```

## Recommended endpoints

Prefer the grouped endpoints so you fetch related metrics in a single call rather than one request per metric.

| Need                                             | Endpoint                                 |
| ------------------------------------------------ | ---------------------------------------- |
| Live device list + status                        | `GET /api/health-data`                   |
| Vitals (HR, BP, SpO₂, temp)                      | `GET /api/device/{deviceId}/vitals`      |
| Wellness (overview, sleep, heart health, stress) | `GET /api/device/{deviceId}/wellness`    |
| ECG records                                      | `GET /api/device/{deviceId}/diagnostics` |
| Location + alarms                                | `GET /api/device/{deviceId}/safety`      |
| SOS events + call logs                           | `GET /api/device/{deviceId}/sos`         |
| All alarms across devices                        | `GET /api/alarms`                        |

## Polling cadence

Sampling and upload intervals are configurable per deployment. As a starting point:

| Data                             | Suggested poll interval                       |
| -------------------------------- | --------------------------------------------- |
| Device list / status             | 1–5 minutes                                   |
| Vitals, wellness                 | 5–15 minutes                                  |
| Alarms, SOS                      | 30–60 seconds (for emergency response)        |
| ECG, metabolic, body composition | On demand or hourly (measured intermittently) |

<Note>
  The `updateTime` / `lastSeen` field tells you when a device last reported. If it stops advancing, the device is offline or out of coverage — surface this in your dashboard.
</Note>

## Device-to-patient mapping

Each device is identified by its `deviceId` (the watch IMEI). In this version, map `deviceId` to a patient record **on your side** and keep the assignment history in your system, so historical readings stay attributed to the correct patient. A `nickname` field is available as a human-readable label.

<Info>
  A built-in patient registry and assignment-history workflow is planned for a future version. Until then, treat `deviceId` as the stable key.
</Info>

## Handling alarms and SOS

For emergency response, poll `GET /api/alarms` (or the per-device `GET /api/device/{deviceId}/safety`) on a short interval and route events by `type`. Critical types include `Fall`, `SOS`, `Heart rate warning`, `Blood pressure warning`, and `Blood oxygen warning`. SOS events from `GET /api/device/{deviceId}/sos` include the location and any associated call logs.

## Timestamps and empty states

* All timestamps are India Standard Time (UTC+05:30), formatted `YYYY-MM-DD HH:mm:ss`.
* A metric with no data for the requested day returns an empty array (`[]`) for list fields and `null` for summary values, with a `200` status. Empty states are not errors — see [Error Codes](/guides/error-codes).