AI Customer Support for Remote Patient Monitoring Device Companies (2026)

AI customer support for remote patient monitoring (RPM) device companies works when the AI agent can look inside your device platform and logistics systems, not just your help centre. It can confirm when a blood pressure cuff last transmitted, walk a patient through re-pairing a scale, check whether a replacement device has shipped, and tell a care team why readings are missing. It should never interpret a reading or respond to a clinical alert: those go to clinicians, every time.

This guide is for support and operations leads at RPM companies that ship connected devices to patients and run the data platform their provider customers bill from. It covers the ticket types that dominate RPM support, the Medicare rules that make a sync failure a revenue problem for your customers, where the line sits between support and clinical work, HIPAA, and how to evaluate vendors.

Key takeaways

• Data gaps cost your customers money. CMS says remote physiologic monitoring requires data collection on 2 to 15 or 16+ days out of 30, depending on the code descriptor. A device that stops syncing for a week can drop a patient below the threshold for that period.

• Setup and device supply are where RPM breaks. HHS OIG found about 43% of Medicare enrollees who received RPM did not receive all 3 components; about 28% had no claim for education and setup and about 23% had none for a device.

• Decision rule for automation: if the answer comes from device, shipping, account or billing systems, an AI agent can resolve it. If it depends on what a reading means or how the patient feels, it escalates to a clinician.

• Device complaints can be regulatory events. FDA requires manufacturers to report when a device may have caused or contributed to a death or serious injury, so injury mentions must reach your complaint team, not sit in a support queue.

• HIPAA applies to the AI layer. Your vendor handles PHI, so expect a Business Associate Agreement and minimum-necessary data access.

Which AI customer support tools work for remote patient monitoring companies?

A handful of AI agent platforms serve healthcare support teams, and they differ mainly in how deeply they act inside your own systems.

• Lorikeet takes action in your backend systems through APIs and MCP servers inside workflows, and escalates with context when human judgment is needed. For an RPM company, that means checking a device's last transmission, triggering a replacement order or reading shipment status, with clinical topics routed to people.

• Sierra lists medical devices among the healthcare segments it serves, alongside payers, providers and pharmacy.

• Decagon describes its health and wellness offer as guiding patients through complex healthcare journeys with consistent touchpoints across every channel.

• Fin (now part of Salesforce) works with any helpdesk, including Salesforce and HubSpot, at $0.99 per outcome.

What do support tickets at an RPM device company actually look like?

Most RPM support tickets are about devices, data and logistics, not medicine. Many patients are Medicare enrollees setting up a connected device for the first time, often by phone or SMS. Provider customers (the practices and care teams who bill for RPM) contact you when readings are missing from their dashboard. The common categories and where each one lands:

Our guide to AI support use cases in telehealth covers the adjacent visit and prescription categories, and the sibling guide on AI customer support for chronic care management covers the care management programs RPM often runs alongside.

How does AI customer support for remote patient monitoring device companies handle pairing and sync failures?

It handles them by checking the device record first and only then troubleshooting, so the patient is never asked questions your platform already knows the answer to. A typical sync workflow looks like this:

1. Identify the patient and device. Verify identity, then look up the assigned device serial, model and the practice it reports to.

2. Read the device state. Pull last successful transmission, signal or gateway status and battery level from the device platform API.

3. Troubleshoot to the model. Give steps for that exact device (cellular cuff, Bluetooth scale paired to a hub, pulse oximeter), one at a time, and confirm a fresh transmission arrives before closing.

4. Replace when troubleshooting fails. If the documented steps are exhausted, create a replacement order through your logistics system and send tracking by SMS.

5. Tell the care team. Where your provider customers want it, post a note to their queue that the patient has had a data gap and a replacement is on the way.

Pattern detection matters as much as the single ticket. If ten patients on the same cellular carrier report sync failures in an hour, that is an incident, and the agent should route it to your operations team rather than resolve ten tickets one at a time. The same logic applies to new patients: setup questions are an onboarding problem, covered in more depth in our guide to AI for patient onboarding.

Why does the 16-day rule make data-sync tickets urgent?

Data-sync tickets are urgent because Medicare device supply billing depends on how many days of data a patient transmits in each 30-day period. CMS's Telehealth and Remote Monitoring booklet (December 2025) sets out the requirements for remote physiologic monitoring:

• Data must be collected on 2 to 15 or 16+ days out of 30, depending on the code descriptor.

• Only 1 practitioner can bill for remote monitoring per patient in a 30-day period.

• Patient consent is required at the time RPM services are provided.

• Data must be collected electronically and uploaded automatically to a secure location the billing practitioner can access.

• The device must meet the FDA definition of a medical device.

The HHS Office of Inspector General's 2024 report, Additional Oversight of Remote Patient Monitoring in Medicare Is Needed, explains why this matters at scale. It groups RPM into three components: education and setup (CPT 99453), device supply (CPT 99454) and treatment management (CPT 99091, 99457 or 99458). It found Medicare RPM payments of more than $300 million in 2022, up from $15 million in 2019, and that most commonly enrollees missed education and setup or the device itself, including not transmitting readings on at least 16 days in any month. OIG notes that it and CMS have raised concerns about fraud related to RPM. CMS's CY 2026 Physician Fee Schedule final rule also changed how rates are set for some remote monitoring services, so your customers are watching these codes closely.

For a support team, two rules follow. First, a sync ticket opened on day 20 of a period needs the same priority as an outage, because each lost day matters. Second, outreach must be about the care plan the clinician ordered, never about reaching a billing threshold. An AI agent can send a reminder that a reading has not arrived in three days; it should not tell a patient to take readings so a code can be billed. Write that rule into the workflow and test it.

What should support AI never handle at an RPM company?

Support AI should never handle clinical alerts, reading interpretation, symptoms or medication questions. RPM data exists so a clinician can act on it, and the support channel is the wrong place for that decision. Concretely, the agent should hand off immediately, with the conversation and device context attached, when:

• A patient or care team member asks whether a reading is high, low, normal or dangerous.

• A patient mentions symptoms, feeling unwell, or a change in their condition. Emergency language should trigger an instruction to call emergency services plus an immediate escalation, using your clinical team's approved wording.

• A clinical alert or threshold breach comes up in conversation. Alerts belong in the clinical workflow your provider customers run, not in a support ticket.

• A device may have harmed someone. FDA's Medical Device Reporting rules require manufacturers to report when they learn a device may have caused or contributed to a death or serious injury, and when a malfunction would be likely to do so if it recurred. A support conversation can be how you learn, so route these to your complaint handling team with the transcript.

This is not hypothetical for Lorikeet customers. The easykind story describes an AI agent trained to operate under strict guardrails: if a patient reports concerning side effects, it directs them to stop taking the medication, call emergency services, and escalates to a human agent. easykind is a health clinic rather than a device company, but the pattern carries straight across to RPM. Keeping the agent out of clinical decisions also keeps it clear of the software functions FDA's device software guidance focuses on.

How do you handle HIPAA when an AI agent reads device and patient data?

You handle it by treating the AI vendor as a business associate, signing a BAA, and limiting what data the agent can see. The HIPAA Privacy Rule's minimum necessary standard (45 CFR 164.502(b)) requires covered entities and business associates to make reasonable efforts to limit protected health information to the minimum necessary for the purpose. For RPM support, that usually means:

• The agent's tools return device status, shipment status and day counts, not raw clinical readings, unless a workflow truly needs them.

• Identity verification runs before any account-specific detail is shared, on every channel including SMS and voice.

• Every tool call and response is logged so you can show who accessed what and why.

• Training data and model access are covered in the contract, including whether the vendor trains models on your data.

Lorikeet's Trust page lists SOC 2 Type II, ISO 27001:2022, HIPAA and GDPR, says Lorikeet signs Business Associate Agreements for healthcare customers with PHI handled on a minimum-necessary basis and automatically redacted, and states customer data is never used to train AI models. For a deeper walkthrough of PHI handling in patient-facing AI, see AI customer service for telehealth and HIPAA.

How should an RPM company evaluate AI support vendors?

Evaluate on whether the agent can act in your systems and whether it escalates clinical topics every time, then on price. A practical checklist:

1. Action, not answers. Ask the vendor to show the agent reading a device's last transmission and creating a replacement order through your APIs, in a sandbox, before you sign.

2. Deterministic escalation. Clinical keywords, symptom descriptions and injury reports should trigger handoff by rule, not by the model's judgement on the day.

3. Testing before launch. Replay real historical tickets, including edge cases like a patient describing chest pain inside a pairing question, and review results before going live. Lorikeet runs simulations from real and synthetic tickets in bulk for this.

4. Channels your patients use. Many RPM patients would rather call or text than open a chat window. Confirm voice and SMS run on the same workflows as chat, and look at after-hours coverage; our guide to after-hours patient messaging compares options.

5. Compliance paperwork. BAA, SOC 2 report, data residency, and a clear answer on model training.

6. Pricing that matches outcomes. Per-seat pricing rewards headcount; per-resolution pricing ties cost to tickets actually closed.

For reference, Lorikeet's public pricing is $2,100/mo (Start) or $5,100/mo (Scale), paid annually, plus $0.99 or $0.90 per resolved chat, email or SMS ticket and $1.50 or $1.20 per voice resolution (3 minute average). Escalations to a person are not charged, which matters in RPM because a large share of clinical-adjacent tickets should escalate. There is a 30-day free trial.

What still needs a human?

Even with good tooling, several parts of RPM support stay with people:

• Clinical judgement. Every question about a reading, a symptom or an alert goes to a licensed clinician at the provider or on your clinical team.

• Billing eligibility decisions. The agent can report days of data on file; whether a code is billed is the billing practitioner's decision.

• Complaint and adverse event review. Someone trained in your complaint process decides whether an event is reportable.

• Consent conversations with hesitation. If a patient is unsure about monitoring, a person should talk it through.

• Compliance sign-off. Your privacy and regulatory leads approve the escalation rules, wording and data access before launch, and review them when CMS or FDA guidance changes.

The easykind story shows what the split looks like in practice: email response times fell 92%, from 24 hours to roughly two, while concerning cases still went straight to people. Eucalyptus, a digital health provider, reports that patients get a response from Lorikeet within 90 seconds. If you want to test the device and logistics workflows against your own tickets, you can start a free Lorikeet trial.