TL;DR
Every RPM vendor claims “HIPAA-compliant.” Fewer than half can explain what that means for device data in transit, at rest, and inside the EHR. RPM creates unique HIPAA challenges: PHI generated in a patient’s home, transmitted over cellular or Bluetooth, processed through cloud platforms, and stored across multiple systems. This checklist covers the seven compliance domains your organization must address before launching or scaling any RPM program: device data encryption, transmission security, cloud storage, BAA coverage, access controls, audit logging, and FDA cybersecurity alignment.
I train healthcare teams on HIPAA compliance, and the question I get most often about RPM is the same one every time: “Is this HIPAA-compliant?”
The answer is never yes or no. It is: “Which part?” The device? The transmission? The cloud platform? The EHR integration? The care manager’s access? The patient’s app? Each layer has its own HIPAA requirements, and a failure at any single layer exposes the entire program.
RPM introduces a compliance surface area that traditional in-clinic care does not have. The PHI is generated in a patient’s home. It travels over a cellular network or Bluetooth connection the patient controls. It passes through a vendor’s cloud platform. It lands in your EHR. At every hop, the data must be encrypted, access-controlled, and audit-logged. Miss one hop and you have a HIPAA exposure.
This checklist is what I walk through with every organization before they launch an RPM program. It is not theoretical. Every item has been a finding in a real compliance review.
Domain 1: Device-Level Data Security
The RPM device is where PHI originates. Blood pressure readings, glucose values, SpO2 levels, weight, ECG data: all are PHI the moment they are generated in association with a patient.
Checklist items:
- [ ] Device stores minimal PHI locally. The device should transmit readings immediately and not retain patient-identifiable data on the device itself. If the device caches data (common when connectivity is intermittent), cached data must be encrypted at rest
- [ ] Device uses encrypted local storage. If the device has onboard memory (most BLE and cellular devices do), stored data must use AES-256 encryption or equivalent
- [ ] Device cannot be used to access other patient data. The device assigned to Patient A should not be able to display or transmit data from Patient B. Sounds obvious. Some multi-patient hub devices fail this test
- [ ] Device decommissioning protocol exists. When a device is returned or reassigned, all patient data must be wiped. Document the wipe process. A cellular BP cuff returned from Patient A and shipped to Patient B with Patient A’s readings still in cache is a HIPAA violation
The FDA issued cybersecurity guidance for medical devices that applies to RPM-connected devices. The guidance requires manufacturers to address cybersecurity risks throughout the device lifecycle, including post-market vulnerability management. If your RPM devices connect to the internet (cellular devices do), they fall under this guidance.
Visual Brief #1: Device security checklist card. Four items with checkbox format, each with a one-line requirement and a one-line “what goes wrong” example. Title: “RPM Device Security Checklist.” File name: rpm-hipaa-device-security-checklist.png. Alt text: “Four-item checklist for RPM device-level HIPAA security covering minimal local PHI storage, AES-256 encryption, patient data isolation, and device decommissioning protocols.” Sizes: 1200×500 blog.
Domain 2: Data Transmission Security
Data in transit is the highest-risk phase for RPM PHI. The reading leaves the device and travels through networks the organization does not control.
Checklist items:
- [ ] All data transmissions use TLS 1.2 or higher. This is the minimum encryption standard for PHI in transit. TLS 1.0 and 1.1 are deprecated and should not be accepted. Verify with the device vendor and the platform vendor
- [ ] Cellular transmissions are encrypted end-to-end. Cellular RPM devices (Tenovi, BodyTrace, Omron cellular) transmit over carrier networks. The device-to-cloud connection must be encrypted independently of the carrier’s network encryption. Do not rely on carrier encryption alone
- [ ] BLE transmissions use Bluetooth 4.2+ with LE Secure Connections. Bluetooth Low Energy prior to version 4.2 has known pairing vulnerabilities. Devices using older BLE versions should not be deployed for PHI transmission
- [ ] WiFi-connected devices require WPA3 or WPA2 with strong passphrase. Home WiFi networks are not enterprise networks. If RPM devices connect via patient’s home WiFi, the platform must not depend on WiFi-level encryption as the only protection. Application-layer encryption (TLS) must be present regardless
- [ ] No PHI transmitted via SMS or unencrypted email. Alert notifications that include patient vitals sent via standard SMS or unencrypted email violate HIPAA. Notifications must go through the secure RPM platform or use encrypted messaging
The practical issue I encounter most frequently: care managers receiving RPM alert emails that contain patient names and vital signs in the email body. Standard email is not encrypted in transit by default. Either the alert notification contains no PHI (just “Patient ID 4721 requires review”) or it travels through an encrypted channel.
Visual Brief #2: Transmission security checklist. Five items with protocol specifications. Title: “RPM Data Transmission Security.” File name: rpm-hipaa-transmission-security.png. Alt text: “Five-item checklist for RPM data transmission HIPAA security covering TLS 1.2 minimum, cellular end-to-end encryption, Bluetooth 4.2+ requirement, WiFi WPA3, and no PHI via SMS or unencrypted email.” Sizes: 1200×500 blog.
Domain 3: Cloud Platform and Storage
RPM data lands in a cloud platform before it reaches the EHR. This intermediate storage layer has its own HIPAA requirements.
Checklist items:
- [ ] Cloud platform is hosted on a HIPAA-eligible infrastructure. AWS, Azure, and GCP all offer HIPAA-eligible services, but the organization must configure them correctly. A HIPAA-eligible cloud is not automatically HIPAA-compliant. The configuration is your responsibility
- [ ] Data at rest is encrypted with AES-256. All RPM data stored in the cloud platform (databases, object storage, backups) must be encrypted at rest. This includes log files that may contain PHI
- [ ] Data retention policy is documented and enforced. HIPAA requires that PHI be retained for a minimum of 6 years (for compliance documentation). Your RPM platform should have a defined retention period and automated deletion after that period. Keeping data indefinitely is a liability, not a benefit
- [ ] Data backup and disaster recovery are tested. Backups must be encrypted. Recovery procedures must be tested at least annually. A backup that cannot be restored is not a backup
- [ ] Multi-tenancy isolation is verified. If your RPM platform serves multiple organizations (common with SaaS RPM vendors), verify that your patient data is logically or physically isolated from other tenants. Ask the vendor: “Can another customer’s administrator accidentally access our data?” If the answer is anything other than a clear no, investigate further
- [ ] Cloud vendor provides a HIPAA-specific shared responsibility model. AWS, Azure, and GCP publish these documents. They define what the cloud provider secures (physical infrastructure, hypervisor) and what you secure (data, access controls, application logic). Read it. Most compliance failures occur in the customer-responsibility zone
Domain 4: Business Associate Agreements (BAAs)
Every entity that touches RPM PHI must be covered by a BAA. This is the compliance item most frequently incomplete in RPM programs.
Checklist items:
- [ ] BAA signed with RPM platform vendor. The vendor hosting your RPM dashboard, processing device data, and displaying patient information is a business associate. No BAA = HIPAA violation regardless of their technical security
- [ ] BAA signed with device vendor (if they access PHI). If the device vendor’s cloud (Dexcom Clarity, Abbott LibreView, Tenovi cloud) stores identifiable patient data, they need a BAA. Some device vendors claim their systems are “de-identified” at the device level. Verify this claim. If the vendor can associate readings with a patient identity, it is PHI
- [ ] BAA signed with cloud infrastructure provider. AWS, Azure, and GCP all sign BAAs. You must initiate this. It does not happen automatically when you create an account
- [ ] BAA signed with any third-party analytics or AI service. If your RPM platform sends patient data to a third-party AI service for alert triage or trend analysis, that service needs a BAA. This includes AI/ML APIs that process vitals data
- [ ] BAA chain is documented. Map every entity that touches patient data from device to EHR. Every entity in the chain must have a BAA. This map should be reviewed annually and updated when vendors change
The most common gap I find: the RPM platform vendor has a BAA, but the device manufacturer’s cloud does not. The device sends data to the manufacturer’s servers before forwarding to the RPM platform. That intermediate hop is an uncovered business associate relationship.
Visual Brief #3: BAA chain diagram. Flow: Patient Device → Device Vendor Cloud → RPM Platform → AI/Analytics Service → Cloud Infrastructure → EHR. Each node has a “BAA required” checkbox. Title: “RPM BAA Chain: Every Entity That Touches PHI.” File name: rpm-hipaa-baa-chain.png. Alt text: “Diagram showing the RPM data flow from patient device through device vendor cloud, RPM platform, AI analytics, cloud infrastructure, and EHR, with BAA requirements at each entity in the chain.” Sizes: 1200×400 blog, 1080×1080 social.
Domain 5: Access Controls and Authentication
Who can see RPM patient data, and how is their access verified?
Checklist items:
- [ ] Role-based access control (RBAC) is implemented. Care managers see their assigned patients. Physicians see their panel. Administrators see aggregate data. No user should have access to all patient data unless their role requires it
- [ ] Multi-factor authentication (MFA) is required for all clinical users. Password-only access to a platform containing PHI is insufficient. MFA (app-based, hardware token, or SMS as a minimum) must be enforced
- [ ] Session timeout is configured. Clinical dashboards left open on unattended workstations expose PHI. Auto-lock after 15 minutes of inactivity is the standard. Some organizations use 10 minutes for higher-security environments
- [ ] Patient-facing app access uses biometric or MFA. If patients access their own RPM data through an app, the app must use biometric login (fingerprint, face) or MFA. Password-only access for patient apps is acceptable under HIPAA (the patient is accessing their own data) but biometric is recommended
- [ ] Remote access policy covers care managers working from home. RPM care managers frequently work from home or hybrid. Their access to the RPM platform from personal devices or home networks must be covered by the organization’s remote access policy: VPN or zero-trust access, encrypted connection, device management
Domain 6: Audit Logging and Monitoring
HIPAA requires audit trails for all access to PHI. RPM generates high-volume data access events that must be logged.
Checklist items:
- [ ] All access to patient RPM data is logged. Every time a care manager views a patient’s readings, the event is recorded: who accessed, what patient, what data, when, from where
- [ ] Logs are immutable. Audit logs must not be editable. Append-only log storage (such as AWS CloudTrail or Azure Monitor immutable logs) prevents tampering
- [ ] Log retention meets HIPAA minimum (6 years). Audit logs must be retained for at least 6 years. Storage costs for RPM audit logs can be significant at scale (288 CGM readings/day per patient, each access logged). Plan storage costs into the program budget
- [ ] Automated alerts for suspicious access patterns. Unusual access patterns (a user viewing 50 patients in 10 minutes, access from an unusual location, access outside normal working hours) should trigger automated alerts to the compliance team
- [ ] Regular audit log reviews are scheduled. Monthly review of access logs for anomalies. Quarterly review by compliance team. Annual review as part of HIPAA risk assessment
Domain 7: FDA Cybersecurity for Connected RPM Devices
The FDA’s premarket cybersecurity guidance for medical devices, updated in 2023 and enforced through 2025-2026, applies to RPM devices that connect to networks.
Checklist items:
- [ ] Verify device manufacturer meets FDA cybersecurity guidance. Ask the vendor: do they have a Software Bill of Materials (SBOM)? Do they have a vulnerability disclosure policy? Do they provide security patches for known vulnerabilities? The FDA now requires these for premarket submissions of connected devices
- [ ] Device firmware updates are managed. Connected RPM devices need firmware updates for security patches. Who manages these updates? If the patient has a device in their home with a known vulnerability and no update mechanism, that is both an FDA and HIPAA exposure
- [ ] End-of-life devices are tracked and replaced. When a device manufacturer stops supporting a device (no more security patches), that device becomes a liability. Track device model versions across your deployed fleet and replace end-of-life devices proactively
- [ ] Network segmentation applies to hub-based devices. If RPM devices connect through a home hub that is also on the patient’s WiFi network, the hub should be on a segmented network or use its own cellular connection. A hub on the same network as the patient’s smart TV and laptop inherits the security posture of every other device on that network
The intersection of FDA cybersecurity and HIPAA is where most RPM compliance programs have their biggest blind spot. The FDA governs the device. HIPAA governs the data. Both apply simultaneously to a connected RPM device transmitting PHI.
PHISecure is our accelerator for this exact intersection: a pre-built HIPAA-compliant data handling layer that covers encryption at rest and in transit, access controls, audit logging, and BAA-ready architecture for RPM platforms. It addresses the infrastructure layer so the clinical team can focus on the program, not the plumbing.
Visual Brief #4: Seven-domain compliance overview. Seven boxes in a grid: Device Security, Transmission Security, Cloud Storage, BAAs, Access Controls, Audit Logging, FDA Cybersecurity. Each box has a count of checklist items. Center badge: “All 7 domains must pass before RPM program launch.” Title: “RPM HIPAA Compliance: The 7-Domain Checklist.” File name: rpm-hipaa-seven-domain-overview.png. Alt text: “Overview grid of seven HIPAA compliance domains for RPM programs with checklist item counts per domain including device security, transmission, cloud storage, BAAs, access controls, audit logging, and FDA cybersecurity.” Sizes: 1200×700 blog, 1080×1080 social.
How to Use This Checklist
Three steps to make this operational.
Step 1: Assign ownership. Each of the seven domains needs a named owner. Device security: IT or biomedical engineering. Transmission: IT infrastructure. Cloud: platform vendor (with your validation). BAAs: legal or compliance. Access controls: IT security. Audit logging: compliance. FDA cybersecurity: IT + vendor. If any domain has no owner, it has no accountability.
Step 2: Complete the checklist before launch. Every item with a checkbox must be verified, not assumed. “Our vendor says they’re HIPAA-compliant” is not verification. Request documentation: SOC 2 Type II reports, HITRUST certification (if available), BAA templates, encryption specifications, audit log configurations. If the vendor cannot provide documentation, that is a finding.
Step 3: Schedule annual review. HIPAA requires an annual risk assessment. RPM programs should be included in that assessment with this checklist as the framework. Vendors change. Devices update. Staff turnover affects access controls. The checklist is not a one-time exercise.
For organizations building custom RPM platforms, PHISecure provides the infrastructure layer (encryption, access controls, audit logging, BAA-ready architecture) so the compliance checklist items in Domains 1-3 and 5-6 are addressed at the platform level. The organization still owns Domain 4 (BAAs) and Domain 7 (FDA device cybersecurity) regardless of platform choice.
Request an Assessment to evaluate your RPM program’s HIPAA compliance posture across all seven domains.
The Compliance Conversation Nobody Wants to Have
Every RFP for RPM services includes a HIPAA compliance section. Every vendor checks the box. The gap between “we’re HIPAA-compliant” and “here is exactly how our encryption works at every hop from device to EHR” is where the real risk lives.
I have reviewed RPM platform security architectures where the vendor’s marketing said “HIPAA-compliant” and the technical documentation revealed: TLS 1.0 still in use on one API endpoint, no BAA with the device manufacturer’s cloud relay, audit logs retained for 90 days instead of 6 years, and no documented device decommissioning process. Each of those is a HIPAA violation. The vendor was not lying about being compliant. They were incomplete about what compliance actually requires for RPM.
The RPM compliance surface area is larger than traditional telehealth or EHR compliance because the data originates on a device in the patient’s home, traverses networks you do not control, and passes through multiple vendor systems before reaching your EHR. Every hop is a potential exposure. This checklist maps every hop.
If your compliance team has not reviewed your RPM data flow from device to EHR with this level of specificity, the conversation is overdue. The cost of a compliance review is measured in hours. The cost of an OCR enforcement action is measured in millions.
Request an Assessment to audit your RPM HIPAA compliance against this checklist.
RPM devices that generate, store, or transmit PHI must meet HIPAA security requirements. This means encrypted local storage, encrypted data transmission (TLS 1.2+), and a device decommissioning protocol that wipes patient data before reassignment. The device manufacturer is a business associate if they access or store identifiable patient data. A BAA is required. The FDA’s cybersecurity guidance also applies to network-connected medical devices used in RPM.
HIPAA does not mandate a specific encryption algorithm but references NIST standards. The accepted standard is AES-256 for data at rest and TLS 1.2 or higher for data in transit. RPM data encrypted with AES-256 at rest and transmitted over TLS 1.2+ meets the HIPAA encryption safe harbor, meaning that if encrypted data is breached, it is not considered a reportable breach under HIPAA.
Yes. Any entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity is a business associate under HIPAA. RPM platform vendors, device manufacturer clouds that store patient data, cloud infrastructure providers (AWS, Azure, GCP), and third-party AI/analytics services that process patient vitals all require BAAs. The most common gap is missing BAAs with device vendor cloud relay services.
HIPAA requires documentation related to policies and procedures to be retained for 6 years from the date of creation or last effective date. Audit logs documenting access to PHI should be retained for at least 6 years. For RPM programs generating high-volume access events (288 CGM readings per day per patient, each potentially triggering an access log), plan cloud storage costs for 6+ years of log retention into the program budget.
The FDA regulates the cybersecurity of connected medical devices, including RPM devices that transmit patient data over networks. The FDA’s premarket cybersecurity guidance (updated 2023) requires manufacturers to include a Software Bill of Materials (SBOM), vulnerability disclosure policies, and security patch mechanisms for connected devices. Post-market, manufacturers must monitor for and address cybersecurity vulnerabilities. This applies alongside HIPAA: the FDA governs the device security, HIPAA governs the data security, and both apply simultaneously.
The HHS Office for Civil Rights (OCR) enforces HIPAA. Penalties range from $100 to $50,000 per violation (per record), with annual maximums up to $1.5 million per violation category. Breaches affecting 500 or more individuals must be reported to OCR within 60 days and posted on the HHS breach portal. Encrypted data breached under AES-256/TLS 1.2+ qualifies for the encryption safe harbor and is not a reportable breach. This is the strongest practical argument for encrypting RPM data at every layer.
RPM patient consent covers the clinical program (enrollment, device use, data collection). HIPAA authorization is a separate requirement if PHI is being used or disclosed for purposes beyond treatment, payment, or healthcare operations. Standard RPM programs (monitoring for treatment, billing for payment) generally fall within the TPO exception and do not require separate HIPAA authorization. However, if RPM data is used for research, marketing, or shared with third parties beyond the treatment team, HIPAA authorization is required. Consult your compliance officer for your specific use case.
