Skip to main content
DoneThat

AI Adoption GuideHealthcareFollowup

Remote patient monitoring with escalation

ML monitors wearable and connected device data post-discharge, detects deterioration patterns, and alerts the care team for intervention, using tools like Biofourmis or Current Health.

Healthcare processAccessIntakeAssessDiagnoseTreatDischargeBillFollowup

By Don, DoneThat’s AI coach · updated

What the RPM nurse should receive

The usable output of remote patient monitoring after discharge is a short alert that names three things: the reading, the timestamp on the device clock, and the protocol threshold that reading crossed. If the wearable or connected-device stream stays inside the loaded protocol, the worklist stays empty.

A model can sit on that stream and flag a deterioration pattern. The model does not replace the nurse, diagnose, or invent a floor because a dashboard looks quiet. The nurse still routes a clinician, and the clinician still decides whether to call the patient, change the plan, or send them in.

RPM platforms in this class (Biofourmis, Current Health, Epic RPM modules, Philips-class home monitors) all assume a device feed and a rule set. Treat them as plumbing for the same nursing job: match tonight's numbers to the service line's written thresholds, then escalate with a cite or stay silent.

This job is adjacent to early warning score automation, which usually runs on inpatient vitals already in the chart. Do not copy an inpatient cutoff onto a home cuff unless the RPM order says to.

Load the device stream and the protocol before you watch

Do not open a color-coded tile and guess.

First, the device stream: which sensors are transmitting, at what interval, and in which units. A Bluetooth scale, a pulse oximeter, a blood-pressure cuff, and a wearable heart-rate band are not one feed. If the oximeter dropped at 21:00, you do not have overnight oxygen. A red tile on a disconnected sensor is not a deterioration pattern. It is a missing reading. Do not escalate it as hypoxia.

Confirm the packet belongs to this patient, this device serial, and this episode.

Second, the protocol: the service line's written floors, ceilings, and time windows for this diagnosis and this discharge. Heart-failure weight gain is not the same rule as post-surgical oxygen. You load the threshold the protocol already names. You do not type a number because a vendor default looked reasonable, and you do not borrow a floor from another pathway because this tile is blank.

If the protocol is not in the record, stop. Call the covering clinician or the RPM lead and get the rule in writing before you watch. Inventing a threshold so the dashboard can turn colors is a failure mode. The next nurse cannot defend a number nobody agreed to.

Once both objects are loaded, map each sensor to the clause it can fire: weight to daily gain, SpO2 to the overnight floor, systolic pressure to the hypo/hypertension window. A model that "detects deterioration" is only useful if it can point at one of those clauses. If it cannot, you are looking at a score. Do not let it paint the board.

Cite the reading, the time, and the threshold

When the stream crosses a loaded clause, the alert text should read like a nurse-to-nurse handoff, not a diagnosis.

Illustrative example (not a measured program result): a patient discharged after decompensated heart failure goes home with a Bluetooth scale and a pulse oximeter on the cardiology RPM pathway. At 02:14 the oximeter reports SpO2 88%. The overnight oxygen floor is whatever that pathway's RPM order already states. The alert says: SpO2 88% at 02:14, below the overnight oxygen floor on this RPM order, last valid reading 94% at 22:07. It does not say the patient is in respiratory failure, send them to the ED, or estimate how often this happens on the census.

The cite has to be copy-pasteable into the EHR note and the phone call: reading and unit, device clock time (not "overnight"), protocol clause and the threshold as written, plus a prior sample only if it is a real packet.

Do not let the model interpolate a missing stretch. If 00:00 through 02:00 has no packets, you do not have a two-hour decline. You have a hole. Say so on the call.

A related but different hunt is adverse event signal detection, which mines notes and labs for harm. Do not dump that hunt onto the overnight RPM board.

Ordinary streams stay off the worklist

If every reading in the window sits inside the loaded clauses, produce nothing. Do not paint a green badge that still demands a click. Do not write "patient stable" as an automated chart note unless the protocol requires a scheduled check-in. Stability is the absence of a cited breach, not a second queue.

RPM nurses burn out on dual queues: true threshold breaches mixed with "review this" tiles that contain no number. That is how a red tile with no reading gets treated like an emergency. Disconnected, battery-dead, and "patient did not wear it" are device problems. Route them to device support, not clinical escalation.

A model that scores every night so the board never looks idle is the wrong tool for this job. The quality outcome is an empty list on ordinary streams, and a cited alert when a clause fires.

This is also why RPM escalation is not the same task as readmission risk scoring. A risk score can stay on the chart for the whole episode. An RPM alert should appear when a threshold is crossed and then clear, or remain only while the breach is current.

Failures that look like monitoring

A red tile with no reading. Color without a cite is not an alert. Open the packet log. If there is no sample, you cannot name a value, a time, or a threshold. Fix connectivity, replace the battery, or document non-use. Do not call the on-call intern with "the monitor is red."

Treating the alert as a diagnosis. "Deterioration pattern detected" is not pulmonary edema, not infection, not anxiety. The model can group a falling SpO2 with a rising overnight heart rate. The nurse still phones with the numbers. The clinician still interviews the patient. If the alert text already says "likely decompensation," strip that sentence before you call. You are handing off measurements against a protocol, not an impression.

Inventing a threshold. Vendor defaults, a number remembered from ICU, or a floor copied from another service are not this patient's protocol. If the RPM order is silent on overnight SpO2, you do not pick a floor so the engine can run. You get the order completed. Biofourmis, Current Health, Epic, and Philips-class monitors will all fire on whatever rule you type. The software being willing is not the same as the service line agreeing.

Do not use RPM as a stand-in for care plan adherence monitoring. Missed weigh-ins are adherence. A weigh-in that crosses the gain clause is physiology. Keep those queues separate.

The clinician still has to respond

The loop is not closed when the tile turns red. The nurse reviews the cite, confirms the packets are real, then contacts the covering clinician with the three-part alert and the last known symptom check. The clinician decides among a same-night call, a same-day clinic slot, a medication change, or an ED send. The model does not pick among those.

After the response, write what was done against the same cite: who was called, at what clock time, and what instruction went to the patient. If the clinician declined to act, record that too. A dismissed alert with no note is how the next shift re-escalates the same 02:14 SpO2.

If the stream returns inside the clause, clear the tile. If the patient is readmitted, stop the home stream's escalation path so two teams are not acting on the same oxygen number.

Load the feed and the written protocol. Fire only with a reading, a timestamp, and a threshold. Stay empty when the night is ordinary. Put a clinician on the call.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first