# ePCR Wearable Patient Telemetry and Consent

## Overview

Patients increasingly arrive with clinically relevant information already on their own devices: recent heart-rate changes, oxygen trends, glucose readings, sleep disruption, or activity collapse before the event. In some cases that information can materially improve triage, but only if it can be pulled quickly, lawfully, and in a way the patient understands and agrees to.

The Wearable Patient Telemetry module gives crews a consent-led way to bring patient-generated data into the encounter. A short-lived consent journey lets the patient approve the specific data types being shared, after which the encounter can display recent telemetry alongside the rest of the clinical record. This turns consumer-device data into a structured clinical context tool without treating it as automatically available.

```mermaid
flowchart TD
    A[Active Encounter] --> B[Patient Consent Request]
    B --> C[Short-Lived Approval Journey]
    C --> D[Scoped Telemetry Retrieval]
    D --> E[Recent Trends and Anomalies]
    E --> F[Encounter Telemetry View]
    F --> G[Clinical Review and Handover]
    C --> H[Consent Audit Trail]
    H --> G
```

**Last Reviewed:** 2026-04-22
**Last Updated:** 2026-04-22

## Key Features

- **Consent-First Workflow**: Require explicit patient approval before any wearable or patient-generated data is brought into the encounter.

- **Short-Lived Consent Token Journey**: Make consent easy to complete in the moment using a time-limited patient flow rather than a long account setup process.

- **Scoped Data Sharing**: Let services request only the categories that matter to the case, such as heart rate, oxygen saturation, blood glucose, activity, or sleep.

- **Provider-Agnostic Patient Data Pull**: Support a range of consumer health and wearable sources behind one clinical workflow so services are not tied to a single device ecosystem.

- **Encounter-Linked Telemetry View**: Present the pulled time series as part of the patient context for the active encounter rather than as a separate wellness dashboard.

- **Anomaly-Aware Context**: Highlight unusual trends so crews and receiving clinicians can quickly see why the wearable context may matter to the case.

- **Legal Evidence of Consent**: Preserve when consent was granted, for what scope, and in relation to which encounter.

## Use Cases

- **Diabetic Emergency**: A patient with a continuous glucose device shares recent glucose trends so the crew can understand what led into the event rather than relying only on a single point-in-time reading.

- **Collapse or Syncope Call**: Recent heart-rate or activity changes from the patient's wearable help the crew interpret the timeline of the episode.

- **Respiratory Concern**: Oxygen or respiratory trends from the patient's own device provide added context while deciding whether the patient can safely remain at home or needs conveyance.

- **Elderly or Vulnerable Patient Review**: A patient with limited recall shares recent activity and sleep disruption to help the crew assess whether there has been a gradual decline before the acute call.

- **Hospital or Specialist Follow-On Review**: A receiving clinician or approved partner app uses the same encounter-linked telemetry context when reviewing the case after handover.

## Integration

- **Electronic Patient Care Report Clinical Workspace**: Wearable context becomes part of the live encounter rather than an external reference the crew has to interpret separately.

- **Patient Consent and Governance Workflow**: The wearable pull complements the wider patient consent model by recording exactly what was shared and why.

- **SMART-on-FHIR and Clinical App Ecosystem**: Where connected applications are used, the wearable context can become part of the richer patient picture available to downstream review tools.

- **Clinical Decision Support and Review**: Telemetry can support pathway decisions, handover quality, and retrospective clinical audit without requiring a second collection step.

## Open Standards

- **OAuth 2.0**: patient approval to external health-data providers follows the standard delegated authorisation model used across consumer health ecosystems.

- **QR Code (ISO/IEC 18004)**: the short-lived patient consent handoff can be delivered through a standard QR scan journey.

- **HTTPS / TLS**: patient-generated data and consent confirmation move over standard secure web transport.

- **JSON**: telemetry windows and consent scope are represented in a structured format that can be consumed by adjacent clinical services.

- **ISO 8601**: telemetry timestamps and consent grant windows remain machine-readable across systems and review workflows.