Sources and review notes
These links support definition-level research and do not establish the regulatory status, safety, or suitability of any product.
CMS describes Medicare remote patient monitoring as collection of physiologic data through a connected medical device that automatically transmits data to a provider, with separate setup and education, device supply and data transmission, and treatment-management components. The CMS page is specific to Medicare coverage and billing and should not be generalized into a clinical definition, a requirement for every remote-monitoring program, or a reimbursement guarantee from another payer. HHS patient guidance says users should receive setup instructions, know how often and how to measure, understand what an alert means and whom to contact after hours, obtain technical help, and recognize that RPM devices are not emergency tools. FDA policy is function-specific: some software functions meet the medical-device definition and others do not, so a mobile app, dashboard, algorithm, or connection to a sensor should not be assigned a regulatory status based only on its label or platform. NIST SP 1800-30 treats RPM as an interconnected ecosystem involving the healthcare delivery organization, platform providers, patients, devices, networks and cloud services, with distributed responsibility for confidentiality, integrity, availability, privacy and service resilience. HHS privacy guidance recommends explaining remote-technology privacy and security risks and protections to patients in plain language; these materials do not certify a vendor or replace organization-specific legal, clinical, billing or device review. A program should define its intended use, eligible population, ordering and enrollment criteria, consent, device and software versions, measurement protocol, units, expected frequency, clinical review hours, threshold and trend logic, alert severity, response and escalation clocks, emergency instructions, documentation, discontinuation and device-return process, and accountable clinical, technical and operational owners before launch. Device assignment should link a verified patient, device identifier and configuration, while preserving calibration and maintenance status, shipment and activation, training completion, connectivity and battery state, firmware and app changes, replacement, loss and decommissioning. Data controls should retain the source reading, device and patient identifiers, acquisition and receipt times, time zone, unit, quality flags, manual versus automatic entry, edits, duplicates, missingness, late arrival, transformations, derived features, alert version, notification and acknowledgement, reviewer action, patient contact, escalation and outcome. Teams should test incorrect patient-device pairing, implausible values, unit and clock errors, intermittent connectivity, delayed and replayed data, duplicate readings, device drift or replacement, manual transcription, caregiver use, low digital literacy, language and accessibility needs, travel, daylight-saving changes, source and interface outages, alert storms, unstaffed hours and emergency scenarios. AI-generated trends, summaries or alerts require local validation against representative devices and patients, visible uncertainty and source data, qualified review, override and correction controls, version monitoring, and checks for false negatives, false positives, automation bias and performance differences across relevant populations. Security review should map device, home network, mobile app, patient identity, platform, API, EHR, vendor support and cloud trust boundaries; cover authentication, least privilege, encryption, keys, logging, updates, vulnerability response, data minimization, retention and deletion, backup, downtime, incident notification and safe degraded operation; and specify each party's responsibility. Metrics should distinguish enrollment, activation and training, days with usable readings, missing and rejected data, alerts per patient, alert precision and recall where adjudication is available, acknowledgement and response time, escalation, patient contact, adherence, staff burden, technical support, device loss, outages, documented clinical action, discontinuation, safety events and results by device, site and relevant patient strata. Billing metrics should be reported separately from clinical and operational outcomes. A connected device, FDA status, transmitted reading, alert, billed code, engagement rate or dashboard trend does not by itself prove medical necessity, clinical benefit, safety, privacy, compliance or reimbursement.
