Remote patient monitoring
Remote Patient Monitoring on FHIR
Remote monitoring puts a steady stream of device readings against a roster of patients and asks the care team to act on the ones that matter. Fire Arrow gives the data flow a FHIR shape: Observations from the devices, Subscriptions for the alerts, Tasks for the actions, and access rules that scope the cohort to the team responsible for it.
What you can build
- Device data lands in standard FHIR resources
Observation for the readings, Device for the source, Patient for the subject. No bespoke schema for monitoring data.
- Alerts run through Subscriptions
Threshold-driven alerts emit notifications through REST hook, queue, or WebSocket channels. The care team's worklist is a Task search.
- Cohort scoping is the same access model as the rest of the deployment
LegitimateInterest and CareTeam validators scope the team's view to its panel without parallel access logic.
How it works
- 1 Device pushes readings
The device or the gateway authenticates as a Device service identity and writes Observations linked to the Patient.
- 2 Subscription evaluates thresholds
Server-side Subscription matches Observations whose values cross the configured threshold and emits a notification.
- 3 Notification creates a Task
Downstream handler creates a Task referencing the Observation, the Patient, and the responsible CareTeam.
- 4 Care team works the worklist
Nurses see the Tasks for their CareTeam, act on them, and record outcomes back to the Patient record.
What you get out of the box
Who this is for
Care management teams, RPM platform engineers, and clinical leads operating monitoring programs for chronic conditions, post-acute discharge, or post-surgical follow-up.
Clinical applicability
A heart failure clinic monitors weight, blood pressure, and symptom check-ins from a panel of 400 patients. Out-of-range readings trigger Subscriptions that create Tasks for the care team. The clinic's nurses see only the patients on their team's panel.
From device to FHIR
RPM device data fits Observation cleanly: code, value, effective time, performer (the Device), subject (the Patient). The Device resource describes the source for traceability and recall handling. The ingestion path is a write against the patient compartment from a Device service identity.
Aggregation (daily averages, weekly trends) is typically derived rather than stored as primary data. Either compute on read or write summary Observations alongside the raw ones, depending on the analytics pattern the program uses.
Alerting that does not become its own database
The temptation in RPM is to build a parallel rule engine that watches every reading and decides what to do. The FHIR-native pattern is to express the threshold as a Subscription and let the server emit a notification when an Observation matches.
The notification handler creates a Task. Tasks are searchable by CareTeam, status, owner, and priority, which is exactly the shape a worklist needs. The care team's UI is a Task search; no separate alerting database to keep in sync.
Cohort scoping for the care team
The care team owning the panel is a CareTeam resource with the assigned Patients in its scope. The team's nurses have a role with a CareTeam validator that scopes their reads and writes to the Patients on their team.
When a patient transfers to a different team, the CareTeam membership changes. The access scope follows automatically; no separate access-list to maintain.
Related docs
FAQ
How do I handle high-volume device data?
FHIR Observation handles high write rates well in HAPI JPA on Postgres. For very high cadences (continuous glucose monitoring, ECG streams) consider summary Observations as the primary clinical view with the full waveform stored alongside.
Can patients see their own readings?
Yes. The Patient role has read access to their own Observations through the PatientCompartment validator. The same data the care team monitors is visible to the patient through their app.
What about manufacturer post-market surveillance?
The Device resource carries the manufacturer and model. Recalls and surveillance queries can be answered with searches on Device.manufacturer or Device.model.
How are alerts acknowledged?
Tasks have a status field. The care team marks Tasks as accepted, in-progress, or completed. The audit log records the transition and the responsible identity.
