HealthTech IoT Remote Patient Monitoring Platform Contracts

A remote patient monitoring (RPM) platform is not a SaaS product that happens to sit in a hospital. It is a product stack that combines hardware, firmware, cloud software, clinical algorithms, and real-time alerting in a chain where a single broken link can cause measurable patient harm. Contracts for this stack carry obligations that a standard Master Services Agreement built for enterprise software will not address and, in some cases, will actively misallocate. India’s regulatory environment for this space changed materially through 2025 and into 2026: the Central Drugs Standard Control Organisation (CDSCO) issued final Medical Device Software (MDSW) guidance, the Digital Personal Data Protection (DPDP) Rules 2025 were notified in November 2025, and the GST 2.0 reforms effective September 2025 altered the tax treatment of mixed health-technology supplies. Any RPM platform contract signed today needs to reflect these positions. This article walks through the six contract layers where RPM deals are genuinely different from standard software transactions and tells you the clause positions that hold in practice.

What makes an RPM platform contract legally different from a SaaS MSA?

An RPM platform contract differs from a standard SaaS MSA in three material ways: the product is a regulated medical device (or software in a medical device) under the Medical Devices Rules 2017 and CDSCO MDSW guidance (October 2025), which means contractual warranties and representations carry regulatory consequences, not just commercial ones; health data flowing through the platform is personal data under the DPDP Act 2023 with specific processor contracting obligations; and clinical liability for delayed alerts or device failure is not cleanly excludable by a limitation of liability clause the way software downtime typically is. Standard SaaS templates address none of these three correctly.

How CDSCO medical device software classification reshapes your contract

The CDSCO finalised its Medical Device Software (MDSW) guidance in mid-2026, building on the draft issued on 21 October 2025. The guidance draws the distinction between Software in a Medical Device (SiMD, embedded in hardware) and Software as a Medical Device (SaMD, standalone software performing a medical purpose). For an IoT RPM platform, the classification depends on what the software claims to do.

A platform that continuously monitors heart rate and flags abnormal readings to a clinician for review sits in Class B or Class C under the Medical Devices Rules 2017 (S.O. 648(E), 11 February 2020). A platform that autonomously generates clinical decisions, diagnoses arrhythmia, or recommends medication changes sits at Class C or higher. Class C software is licensed by the Central Licensing Authority at CDSCO. Class A and B are licensed by state licensing authorities. This classification determines who holds the manufacturing or import licence, and that party must be identified in the contract.

Why this changes your contract:

The entity that holds the CDSCO licence for the medical device software bears post-market surveillance obligations under Rule 30A of the Medical Devices Rules 2017. If the platform company holds the licence and the hospital deploys it, the contract must allocate obligations correctly: the platform company remains responsible for maintaining the device master file, reporting adverse events, and implementing software updates that address safety-related defects. The hospital cannot contractually accept these obligations from the platform company because the hospital is not the licence holder.

This creates a clause structure that is the inverse of normal SaaS: the platform company cannot cap its obligations to provide safety-critical updates with a simple “no commitment to specific enhancements” clause. A safety-related software update mandated by CDSCO post-market surveillance requirements is not optional. The contract must therefore distinguish between feature enhancements (no obligation unless agreed in a SOW) and safety-related updates (mandatory, at platform company’s cost, with a defined deployment timeline).

Table: CDSCO software classification and contract implications

One practical point: the CDSCO MDSW guidance introduces an Algorithm Change Protocol (ACP) for AI and machine learning-based tools. This allows software updates to AI algorithms without constant re-licensing, provided changes stay within the approved ACP scope. The contract must confirm which party owns and maintains the ACP, what change-management approval is required before deployment, and how algorithm updates are communicated to hospital end-users who are relying on the outputs clinically.

Does the CDSCO classification affect who can be named as a party in hospital procurement?

Yes. Government hospital procurement under GFR 2017 and state procurement rules often requires the supplier to hold the relevant regulatory licence. If the platform company holds a CDSCO Class C licence for its software and the government hospital’s tender terms require the supplier to be the licence holder, a channel-sales structure (where a distributor fronts the contract) creates a mismatch. This is a live structuring issue for founders selling into ABDM-integrated government health systems. The contract counterparty, the licence holder, and the entity receiving payment must align.

DPDP Act 2023 and DPDP Rules 2025: what the contract must do

In an RPM platform arrangement, the hospital or healthcare provider is the Data Fiduciary under the Digital Personal Data Protection Act 2023 (it determines the purpose and means of processing patient data). The platform company is the Data Processor. The DPDP Rules 2025, notified on 14 November 2025, require the Fiduciary to bind processors through written agreements limiting processing to the fiduciary’s instructions. The general architecture for those agreements, including DPA minimum content, sub-processor disclosure, and DPDP penalty exposure, is covered in depth in Treelife’s guide to drafting AI usage clauses in B2B tech contracts. What an RPM platform contract requires beyond that general framework are four health-data-specific obligations.

Four RPM-specific DPDP obligations:

First, the breach notification cascade. The DPDP Rules 2025 require breach notification to the Data Protection Board of India by the Data Fiduciary within 72 hours. Because the hospital holds this obligation and the breach may originate at the platform layer, the contract must require the platform company to notify the hospital within 24 hours of discovering any breach affecting patient data. Any clause giving the platform company the full 72 hours leaves the hospital with zero time to meet its regulatory deadline.

Second, the CDSCO data retention carve-out in the deletion clause. On termination, the platform company must delete patient personal data within 30 days (60 days maximum). However, CDSCO post-market surveillance obligations under Rule 30A of the Medical Devices Rules 2017 require the platform company to retain adverse event records and device performance logs for a defined period regardless of contract termination. The deletion clause must carve out data required for regulatory compliance from the general deletion obligation, with the categories and retention period specified precisely.

Third, sub-processor mapping for health data. Cloud infrastructure providers, analytics vendors, and AI model providers that touch patient data are sub-processors. Each must be listed by name in a sub-processor schedule. Given that patient health data is among the most sensitive personal data categories, any sub-processor change must trigger 30-day advance notice to the hospital, not the 7-to-14-day window sometimes used in standard SaaS DPAs.

Fourth, the cross-border transfer position. MeitY has not yet published the final permitted-country list under Section 16 of the DPDP Act 2023. Any contract clause permitting unrestricted offshore data transfer by the platform company operates in an unsettled legal position. Build a contractual mechanism requiring compliance with the whitelist within 60 days of its notification, and confirm with any overseas cloud provider that their India-data handling terms can be updated accordingly.

Why the SLA for an RPM platform is fundamentally different

Standard SaaS SLAs measure uptime as a binary: the platform is accessible or it is not. An RPM platform SLA must be layered across multiple components with clinically appropriate response times, because the consequence of downtime is not a delayed email, it is a missed critical alert.

The six components an RPM SLA must address:

1. Device connectivity uptime: The IoT device (wearable sensor, bedside monitor, pulse oximeter) must transmit data within a defined latency window. A 99.9% uptime target for cloud software means nothing if the device firmware drops transmission every 15 minutes. The SLA must separately address device-layer availability.
2. Data transmission latency: For cardiac monitoring, glucose monitoring, or fall detection, the delay between a physiological event and the alert reaching the clinician dashboard is clinically material. The SLA should specify maximum transmission latency (e.g., critical alerts within 60 seconds of detection at the device layer).
3. Alert generation and delivery: The platform’s alerting engine must differentiate between critical alerts (e.g., SpO2 below threshold) and informational notifications (e.g., weekly trend summary). SLA credits for failure to deliver a critical alert must be disproportionately large relative to other SLA metrics.
4. Dashboard availability: The clinician-facing dashboard must meet availability targets separately from the backend data pipeline. A backend running at 99.95% does not help a clinician who cannot log in at 2 AM during an ICU shift.
5. Escalation pathways: What happens when the primary alert delivery fails? The SLA must specify redundant escalation channels (SMS, voice call, backup dashboard notification) and the maximum acceptable escalation delay.
6. Device replacement or repair timelines: If a deployed IoT device fails, the SLA must commit to replacement within a defined number of business hours. For a patient with a chronic condition being monitored at home, a 5-day hardware replacement cycle is clinically unacceptable.

A word on service credits: Standard SaaS service credits (a 5% monthly fee credit for downtime below 99.9%) are an inadequate remedy in an RPM context where a missed critical alert could trigger patient harm and consequential claims against the hospital. The hospital’s procurement team will understand this and will push for the right to terminate for cause with a penalty, not just a credit, if the platform misses clinical SLA thresholds. The platform company should negotiate a tiered regime: service credits for availability failures below a threshold, with a right to cure, and termination for repeated or sustained clinical SLA failures, while ensuring the clinical SLA thresholds are technically achievable under real-world connectivity conditions.

Clinical liability: the clause that must be negotiated, not deleted

Every standard SaaS MSA contains a mutual limitation of liability clause capping total liability at 12 months of fees paid. For an RPM platform, this clause will be the most contested point in the negotiation with any sophisticated hospital counterpart, and for good reason.

The liability question has three distinct sources in an RPM deployment:

Device liability: If a sensor device malfunctions and transmits incorrect data (a false-normal reading that masks a deteriorating condition), the harm flows from the device layer. Under the Consumer Protection Act 2019, if the device is sold (not leased) to the hospital or the patient, product liability provisions under Chapter VI apply. The platform company, if it manufactures or imports the device, is the “product seller” and bears strict liability for defects that cause harm. This is not excludable by contract between the platform company and the hospital; it exists as a statutory right for the patient.

Software-clinical decision support liability: If the platform’s algorithm generates an alert that a clinician acts on and the alert was a false positive, or fails to generate an alert for a true positive, liability is contested across the platform company and the treating clinician. The CDSCO MDSW guidance makes clear that the platform company, as the MDSW licence holder, is responsible for the algorithm’s performance within its stated specifications. The contract must therefore clearly define the Indications for Use (IFU), the validated performance parameters of the algorithm (sensitivity, specificity, the population it was validated on), and include an express warranty that the platform’s outputs meet those specifications.

Operational liability: If the hospital fails to act on a correctly delivered alert, the liability rests with the clinical team, not the platform company. The contract must include a “clinical decisions remain with the treating clinician” clause that is both legally accurate and does not read as an attempt to dodge all accountability. Courts will look at the totality of the arrangement; a blanket “platform is not responsible for clinical outcomes” clause that sits alongside marketing claims of “AI-powered autonomous monitoring” will be read against the platform company.

Practical clause position: The platform company should accept uncapped liability for death or personal injury caused by a defect in the device or a material breach of the MDSW specifications (this is non-negotiable in any case because product liability is statutory). It should cap liability for all other claims at 24 to 36 months of fees paid (higher than a standard 12-month cap, reflecting the clinical context). It should exclude liability for consequential loss arising from the hospital’s failure to act on correctly delivered alerts, and should back that exclusion with a robust audit log that time-stamps every alert, its delivery, and the recipient’s acknowledgment.

Table: liability allocation framework for an RPM platform contract

How does GST apply to an RPM platform supply?

The GST treatment of an RPM platform contract is one of the most practically important and least clearly resolved issues in HealthTech contracting in India. The answer depends on how the supply is structured and what clinical claims are attached to it.

Core healthcare services provided by clinical establishments are exempt from GST under Entry 46 and Entry 74 of Notification No. 12/2017 – Central Tax (Rate), dated 28 June 2017. Post the GST 2.0 reforms effective 22 September 2025, pathology tests, ambulance services, and telemedicine provided as part of healthcare by a clinical establishment remain exempt.

The platform company is not a clinical establishment. It is a technology service provider. The platform fee charged to the hospital for software access, IoT device rental, data analytics, and dashboard services attracts GST at 18% as an information technology and communication service unless the supply qualifies as a composite supply where the dominant element is an exempt healthcare service.

Three scenarios and their GST treatment:

Scenario 1: Platform company charges a single bundled fee for “RPM-as-a-service” that includes devices, software, and clinical monitoring services (where the platform company also employs the clinical monitoring nurses or paramedics). If the clinical monitoring element is the principal supply and the technology is ancillary, there is an argument for composite supply treatment with the clinical element dominating. This position is aggressive and will attract GST scrutiny. Seek an advance ruling before structuring this way.

Scenario 2: Platform company charges separately for (a) device lease or supply and (b) software subscription. Device supply on lease may attract GST at the applicable device rate. Software subscription at 18%. Hospital clients may prefer this structure because the hospital’s healthcare services remain exempt and the input technology cost is transparent.

Scenario 3: Platform company white-labels its technology to a hospital network which then delivers RPM services directly to patients. The hospital’s patient-facing service is exempt. The technology fee from hospital to platform company is taxable at 18%. The hospital cannot claim input tax credit on this cost because it flows into exempt supplies. This is the most common structure and creates a dead-weight cost for the hospital that founders should factor into their pricing.

For founders: the contract must specify whether fees are inclusive or exclusive of applicable taxes, which party bears the GST cost, and whether the platform company will provide documentary evidence of its GST registration and proper invoicing. Hospitals are large, audited entities; their finance teams will not sign contracts with GST ambiguity.

What hospital procurement teams will ask for that founders miss

Hospitals, particularly multi-specialty chains, corporate hospital groups, and government health systems, run structured vendor risk assessment processes. An RPM platform founder who has not prepared the following will lose procurement rounds or face extended delays:

Security and data protection audit rights. Hospital IT security teams will ask for ISO 27001 certification or equivalent, a right to audit the platform company’s information security controls annually, penetration test reports dated within the last 12 months, and a software bill of materials for open-source components. The contract should acknowledge audit rights while limiting the frequency (one per year plus after any material breach) and requiring the hospital to bear its own costs of the audit.

Business continuity and disaster recovery. Hospitals will ask: what happens to patient monitoring data if the platform company becomes insolvent, is acquired, or suffers a prolonged infrastructure outage? The contract should address data escrow (patient monitoring records held in a format accessible independently of the platform’s proprietary software), a 90-day wind-down period on termination with continued data access, and the obligation on the platform company to provide a data export in a portable standard format.

ABDM interoperability. Hospitals participating in the Ayushman Bharat Digital Mission (ABDM) are expected to integrate with the Health Data Management Policy framework. An RPM platform that does not support ABDM Health ID linking, or whose data outputs do not conform to FHIR (Fast Healthcare Interoperability Resources) standards, will face rejection in government hospital procurement. The contract should include a roadmap commitment with a specific date if ABDM integration is pending, rather than a vague “best efforts” clause.

Government hospital and GeM procurement. RPM platforms selling to government hospitals face an additional layer: procurement under the General Financial Rules 2017 and, increasingly, through the Government e-Marketplace (GeM). GeM registration requires product listing under the correct HSN/SAC code, which for an IoT RPM platform is a live classification question (device versus software versus service). Tender documents for ABDM-connected government hospitals typically require the supplier to be the CDSCO licence holder, which means a channel-sales or reseller structure often cannot front the contract. The platform company must be named as the primary supplier, with CDSCO licence, GeM registration, and MSME certification (if applicable) in place before the tender close date. Missing any of these disqualifies the bid regardless of technical merit.

Clinical governance and training obligations. Who trains the hospital’s clinical staff to use the alert system? Who determines the alert thresholds (normal range settings for the patient population)? If the hospital missets alert thresholds and a patient is harmed, the platform company will argue the hospital bears the liability. If the platform company’s onboarding process did not document the threshold-setting decision and confirm the hospital’s clinical team made it, this argument weakens. The contract must include a clinical onboarding protocol with written acceptance of alert threshold settings by the hospital’s clinical lead.

Table: hospital procurement checklist and platform company preparation

Common mistakes that cost RPM founders time and money

Mistake 1: Using a generic SaaS MSA with a healthcare addendum.

A generic SaaS MSA treats software uptime as the primary performance metric. It limits liability to the SaaS fee paid, excludes indirect loss broadly, and says nothing about device performance, clinical SLA layers, CDSCO obligations, or DPDP processor contracting. Adding a “healthcare addendum” to a generic MSA after the fact creates a patched document with internal contradictions. The limitation of liability in the base MSA will conflict with the uncapped device liability in the addendum. Start with a purpose-built RPM platform agreement structure.

Mistake 2: Missing the regulatory warranty.

Most platform companies include a representation that their software complies with applicable law. For an MDSW-classified product, this is insufficient. The contract must include a specific representation that the platform holds the current, valid CDSCO licence for the software’s risk class, that the software has been manufactured in compliance with MDR 2017 Rule 7 essential principles, and that the algorithm performs within the validated specifications described in the technical file. If the platform loses its CDSCO licence during the contract term, this should be an event of default by the platform company, not a force majeure event.

Mistake 3: Treating alert threshold configuration as a product feature, not a clinical decision.

Alert thresholds determine what triggers an alert and what does not. A SpO2 threshold set at 92% versus 95% will generate different alert volumes and miss different patient events. Who sets these thresholds is a clinical governance decision that creates liability. Platform companies that allow hospitals to configure thresholds freely through an admin console without requiring clinical sign-off are transferring liability while creating the impression that the technology controls the decision. The contract and the onboarding process must document that threshold configuration is a clinical decision made and signed off by the hospital’s medical team.

Mistake 4: Ignoring IP ownership in algorithm training data.

RPM platforms improve their algorithms using patient data from deployed hospitals. If the contract is silent on IP in the aggregated, de-identified training data, the hospital will later claim it has rights to algorithms trained on its patients’ data. The platform company should include an express clause: the hospital grants a licence to the platform company to use de-identified, aggregated device output data for algorithm improvement, with the obligation that no data used in training can be re-identified and that the improved algorithm benefits all platform customers.

Mistake 5: Standard termination clauses in a clinical deployment.

Standard SaaS MSAs allow either party to terminate for convenience on 30 or 60 days’ notice. In an RPM deployment where patients are actively being monitored, a 30-day termination creates a clinical continuity crisis. The contract must require a minimum 6-month wind-down period on termination for convenience, continued monitoring service during wind-down, and a clear data handover plan so the hospital can migrate to a replacement platform or to manual monitoring protocols.

Frequently asked questions

Q: Does an IoT wearable device used in remote patient monitoring need CDSCO registration in India?
A: Yes, if the device is used for medical purposes such as monitoring vital signs for clinical decision-making, it qualifies as a medical device under the Drugs and Cosmetics Act 1940 read with the Medical Devices Rules 2017 (S.O. 648(E), 11 February 2020) and requires CDSCO registration. A general fitness tracker that makes no medical claims may fall outside the definition, but any device marketed or contracted for clinical use in a hospital setting should be treated as a regulated medical device.

Q: Who is the data fiduciary under the DPDP Act 2023 in an RPM platform arrangement: the hospital or the platform company?
A: The hospital (or the clinical establishment) is generally the Data Fiduciary because it determines why and how patient data is collected. The platform company is the Data Processor, processing data on the hospital’s behalf under contractual instructions. The hospital bears primary DPDP compliance obligations, including breach notification to the Data Protection Board. The platform company must be contracted as a processor with obligations mirroring the fiduciary’s requirements.

Q: What is the standard engagement structure when a Treelife team reviews an RPM platform contract?
A: We typically run a five-session engagement over three to four weeks: (1) regulatory classification mapping (CDSCO class, ABDM obligations, GST treatment), (2) contract architecture review (identifying which documents govern which obligations), (3) clause-by-clause redline of the MSA and DPA, (4) SLA design workshop with the client’s technical and clinical teams, (5) final version review and execution readiness. Timelines depend on the counterparty’s procurement process.

Q: How long does CDSCO licensing take for medical device software?
A: For Class B software, state licensing authority timelines typically run 60 to 90 days after submission of a complete application. For Class C software, the CDSCO Central Licensing Authority process runs 90 to 120 days or longer depending on the complexity of the technical file and whether clarifications are sought. These timelines are indicative; verify current processing times with a regulatory consultant at the time of filing.

Q: Can the platform company include a non-compete restriction on the hospital counterpart?
A: Under Section 27 of the Indian Contract Act 1872, an agreement in restraint of trade is void. A non-compete clause that prevents the hospital from contracting with a competing RPM platform is unenforceable. Confidentiality obligations covering the platform’s proprietary technology are enforceable. Exclusivity in a specific use case or ward (e.g., cardiac ICU exclusivity) is commercially negotiable but must be framed as a commercial commitment, not a restraint of trade.

Q: Is the platform company’s fee from hospitals subject to GST, or is it exempt as a healthcare supply?
A: The platform company’s technology services fee to the hospital is taxable at 18% as an IT service. It is not a healthcare service by a clinical establishment under Entry 46 or 74 of Notification No. 12/2017 – CT(R). If the platform company also provides clinical monitoring services (employing paramedics who monitor alerts), the GST treatment of the bundled supply is unsettled and should be the subject of a GST advance ruling before contracting at scale.

Q: What is the right limitation of liability cap for a HealthTech RPM platform MSA?
A: There is no single right answer, but the starting position for negotiation is: uncapped liability for death or personal injury caused by a defect in the device or a material breach of the algorithm’s validated specifications; 24 to 36 months of fees paid for all other direct claims; mutual exclusion of indirect and consequential loss (with a carve-out for DPDP regulatory penalties attributable to the platform’s breach). Hospitals with strong procurement leverage will push for higher caps or uncapped liability for clinical outcomes. The platform company’s product liability insurance policy will determine how much exposure is commercially tolerable.

Q: What happens to patient monitoring data if the platform company shuts down or is acquired?
A: The contract should require the platform company to provide a structured data export in FHIR-compliant format within 30 days of a termination event, with a 90-day continued read-only data access period for the hospital. If the platform company is acquired, the MSA should require the acquirer to assume all data processor obligations and give the hospital a right to terminate without penalty if the acquirer is a direct competitor.

Q: Does the contract need to address ABDM Health ID integration?
A: For a platform selling to hospitals participating in the Ayushman Bharat Digital Mission, ABDM compliance is effectively a procurement requirement. The contract should include a representation that the platform supports ABDM Health ID linking and FHIR-compliant data sharing, or, if integration is pending, a milestone-based roadmap clause with a longstop date and a right for the hospital to terminate at no penalty if the milestone is missed.

Q: Can the platform company use patient monitoring data to train and improve its AI algorithm?
A: Yes, with the correct contractual and technical safeguards. The contract must grant the platform company a licence to use de-identified, aggregated device output data for algorithm improvement. The platform company must confirm through a technical attestation in the DPA that the anonymisation is irreversible (meeting DPDP standards for exemption from the Act’s personal data obligations) and that no patient can be re-identified from the training dataset.

Q: What indemnities should the platform company give to the hospital?
A: The minimum indemnity package for an RPM platform company should cover: (1) third-party IP infringement claims relating to the platform’s own software; (2) DPDP regulatory penalties imposed on the hospital as Data Fiduciary to the extent directly attributable to the platform company’s breach of its data processor obligations; (3) claims from patients arising from defects in the device hardware or from the algorithm operating outside its stated validated specifications.

Q: What stamp duty applies to an RPM platform MSA in India?
A: Stamp duty is state-specific. Most Indian states treat an MSA as a general agreement stamped at ₹100 to ₹500. Maharashtra and Karnataka apply higher rates on agreements with specified consideration. Stamp duty does not affect the validity of the agreement between parties but is required if the document is produced as evidence in court. Where a platform MSA specifies high annual contract values, apply the MSA’s place of execution state rates and verify with a local law expert.

Q: How should the contract address algorithm updates and version changes?
A: The CDSCO MDSW guidance (October 2025) introduces an Algorithm Change Protocol (ACP) for AI and ML-based tools. Algorithm changes that fall within the approved ACP scope do not require fresh CDSCO approval but must be documented. Changes outside ACP scope require a new regulatory submission. The contract must: (a) confirm which party owns and maintains the ACP; (b) require advance written notice to the hospital before any algorithm update that changes the sensitivity or specificity of alerts; (c) give the hospital a defined period (e.g., 30 days) to accept or raise concerns before the update is deployed in their environment; and (d) maintain a version history with change logs available to the hospital on request.

About the Author

Share

• Link copied to clipboard!
  https://treelife.in/legal/healthtech-iot-remote-patient-monitoring-platform-contracts/
  
• 
• 
• 
• 

Treelife

Treelife Team | support@treelife.in

We are a legal and finance firm with a deep focus on the startup ecosystem. We offer a wide range of services, including Virtual CFO, Legal Support, Tax & Regulatory, and Global Expansion assistance.

Our goal at Treelife is to provide you with peace of mind and ease in business.