How to Manage Vendor Risk and HIPAA Compliance in Remote Therapeutic Monitoring Programs

How to Manage Vendor Risk and HIPAA Compliance in Remote Therapeutic Monitoring Programs

Kevin Henry

HIPAA

Published Updated

9 minutes read
Share this article
How to Manage Vendor Risk and HIPAA Compliance in Remote Therapeutic Monitoring Programs

Which vendors and services create HIPAA risk in an RTM program?

Map every service that touches remote therapeutic monitoring (RTM) data, not just the device or platform you purchase. Depending on how your program is organized, vendors may include device makers, app and platform providers, cloud-hosting companies, data analytics services, patient-support teams, integration vendors, and subcontractors.

Identify what each party does with protected health information (PHI): collects it, transmits it, stores it, analyzes it, or accesses it while troubleshooting. A software provider that hosts or accesses patient information for a covered entity generally acts as a business associate; simply selling software without access to PHI does not, by itself, create that relationship. See HHS guidance on software vendors and business associate status.

Also map the flow of data from the patient’s device through the platform to your clinical records and care team. Document where data is stored, who can access it, how it is shared, and what happens when a vendor relationship ends. This inventory helps you see where vendor access, weak integrations, or unclear responsibilities could expose PHI.

How do business associate agreements apply to RTM vendors?

If a vendor creates, receives, maintains, or transmits PHI on behalf of your covered entity—or performs those activities for a business associate—it may be a business associate and generally requires a HIPAA business associate agreement (BAA). This can include a cloud provider that stores encrypted ePHI, even if the provider cannot decrypt or view it. The narrow conduit exception generally covers transmission-only services with temporary storage incidental to transmission, not persistent storage or other services involving PHI. See HHS’s business associate guidance and HHS’s conduit exception guidance.

A BAA should define permitted uses and disclosures, require appropriate safeguards, address reporting of security incidents and breaches, support applicable patient rights, and set out what happens to PHI at termination. It should also require subcontractor compliance when subcontractors handle PHI. Review the HHS summary of required BAA provisions when developing or reviewing contract language.

Use the BAA alongside service-level and security terms that clarify responsibilities for access, incident coordination, backups, data return or deletion, and service availability. A signed BAA is an important contractual safeguard, but it does not by itself establish that either party has met every HIPAA requirement.

What security safeguards should vendors implement for RTM data?

The HIPAA Security Rule requires covered entities and business associates to protect ePHI with reasonable and appropriate administrative, physical, and technical safeguards. It does not prescribe one security product or identical controls for every organization. Review the HHS summary of the Security Rule for the applicable safeguard categories.

  • Access controls and audit logs: Ask how the vendor limits access to authorized users, assigns user identities, verifies identity, and records and reviews activity involving ePHI.
  • Data protection: Evaluate safeguards for transmission, storage, integrity, backups, and secure deletion, including how the vendor responds to lost devices or compromised accounts.
  • Administrative and physical safeguards: Review workforce access procedures, security training, incident procedures, system and facility protections, and contingency planning.
  • Subcontractor compliance: Identify subcontractors that may handle PHI and confirm that appropriate written safeguards and contractual obligations flow down to them.

Encryption can reduce exposure, but HHS explains that encryption alone does not satisfy every Security Rule obligation. Ask for evidence that helps you evaluate the vendor’s practices, such as relevant policies, control descriptions, independent assessment results, and incident procedures; consider the evidence in the context of your own program’s risks.

How can you assess and monitor RTM vendor risk?

Include each RTM vendor and relevant subcontractor in your Security Rule risk analysis. Assess the confidentiality, integrity, and availability risks for all ePHI your organization creates, receives, maintains, or transmits, including information held by vendors. HHS describes risk analysis as an ongoing process that should be revisited as systems, vendors, and threats change. See HHS guidance on Security Rule risk analysis.

Before onboarding a vendor, document the data involved, business purpose, access required, storage locations, data flows, subcontractors, and how the service will connect to your systems. Review the BAA and security terms, confirm who is responsible for each safeguard, and assess how the vendor will support patient access requests, incidents, and program termination.

After onboarding, review vendor risk periodically and when a material change occurs, such as a new integration, subcontractor, data use, or security incident. Track unresolved issues and agreed remediation dates, check that access remains appropriate, and reassess whether the vendor still needs the PHI it receives. The Security Rule requires ongoing risk management and evaluation; HHS does not set one universal schedule for every organization.

Ready to assess your HIPAA security risks?

Join thousands of organizations that use Accountable to identify and fix their security gaps.

Take the Free Risk Assessment

Explain the RTM program to patients in clear terms: what information the device or platform collects, how the care team uses it, which service providers may handle it, and how patients can ask questions or request access. Keep program participation or treatment consent distinct from HIPAA permissions. HIPAA generally permits covered entities to use or disclose PHI for treatment, payment, and health care operations without a separate HIPAA authorization, while other uses may require authorization or another basis. See HHS guidance on treatment, payment, and health care operations.

Do not assume HIPAA creates one universal consent requirement for every RTM service. Determine whether consent or other patient notices are required by applicable state law, payer rules, or the terms of your specific program, and document the process you use.

Limit vendor access and disclosures to what is appropriate for each role and purpose. The minimum necessary standard applies to many uses and disclosures, but it does not apply to disclosures to or requests by a health care provider for treatment. For details, see HHS’s minimum necessary guidance.

Covered entities remain responsible for responding to patient access requests for PHI in a designated record set, including information maintained by a business associate on their behalf. Make sure your BAA and workflows let you retrieve that information in time to meet the applicable response deadline. See HHS guidance on access to PHI held by business associates.

What should an incident response plan cover for vendor breaches?

Set out how your team and vendor will identify, report, assess, contain, and investigate suspected incidents involving RTM data. The BAA should establish the vendor’s reporting obligations; operational procedures should specify who to contact, what information to preserve, and how the parties will coordinate. Require prompt notice under your contract so you have time to investigate and meet any applicable obligations.

Under the HIPAA Breach Notification Rule, a business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery. The covered entity is responsible for required notifications to affected individuals and HHS, though it may delegate individual notices to the business associate. A contract can require faster vendor reporting than the federal outer deadline. See the HHS Breach Notification Rule guidance.

Your response plan should include a process to determine whether an event is a reportable breach, identify affected individuals and data, document decisions, mitigate harm, and coordinate required notices. Test the plan with relevant vendors so each party understands its role before an incident occurs.

What are the limits of HIPAA compliance for RTM vendors?

HIPAA does not apply to every company that makes a connected device, app, or health-data service. A vendor’s status depends on its role and relationship to a covered entity or business associate, including whether it handles PHI on their behalf. A consumer-facing health app or device service may fall outside HIPAA when it is not acting as a business associate, but other requirements may apply.

For certain health apps and related services not covered by HIPAA, the Federal Trade Commission’s Health Breach Notification Rule may apply. The FTC explains that the Rule covers certain personal health record vendors, related entities, and service providers, and can require breach notices. See the FTC’s Health Breach Notification Rule overview.

Do not treat a vendor’s marketing claims, a signed BAA, or a security assessment as a guarantee that your RTM program is compliant. Your organization still needs to assess its own risks, configure and use the service appropriately, manage its workforce and access, and meet its obligations under applicable privacy and security rules.

In short, manage RTM vendor risk by mapping data flows, determining which vendors are business associates, documenting responsibilities in appropriate agreements, evaluating safeguards, monitoring changes, and preparing for patient requests and incidents. HIPAA compliance is a shared operational effort, not a status conferred by a contract or product claim.

FAQs.

Does an RTM device vendor need a business associate agreement?

It depends on the vendor’s role. If it creates, receives, maintains, or transmits PHI on behalf of a covered entity or business associate, a BAA is generally required. Merely selling a device or software without access to PHI does not, by itself, create a business associate relationship.

What HIPAA safeguards should an RTM platform provide?

Evaluate whether the platform supports appropriate administrative, physical, and technical safeguards, including authorized access, identity verification, audit controls, transmission security, data integrity, incident procedures, and contingency planning. The specific measures should be assessed in light of your organization’s Security Rule risk analysis.

Who is responsible for reporting an RTM vendor data breach?

A business associate must notify the covered entity after discovering a breach of unsecured PHI. The covered entity is responsible for required notices to affected individuals and HHS, although it may delegate individual notifications to the business associate. The BAA should explain how the parties will coordinate.

Does HIPAA apply to every remote therapeutic monitoring vendor?

No. HIPAA applies based on an organization’s covered-entity or business-associate role, not simply because it handles health-related information. Some consumer-facing apps or device services may not be HIPAA business associates, but other laws, including the FTC’s Health Breach Notification Rule, may apply.

Share this article

Ready to assess your HIPAA security risks?

Join thousands of organizations that use Accountable to identify and fix their security gaps.

Take the Free Risk Assessment

Related Articles