If you make a medical device that currently works on its own, a monitor, a diagnostic unit, a homecare instrument, and you're now being asked to make it "connected," this piece is for you. That request usually comes from a hospital partner, a distributor, or your own product roadmap, and it's rarely a small ask. Adding remote monitoring medical devices capability means rethinking your hardware, your data flow, and in most cases, your regulatory filing. This guide walks through exactly what changes: how to decide between retrofitting your existing device or redesigning it, which connectivity option actually fits your use case, what happens to your device data once it leaves the unit, and where Indian compliance requirements come into the picture. No fluff, no generic RPM market talk. Just what a Pune-based OEM engineering team needs to plan this properly.

The Problem Pune OEMs Are Actually Facing

Here's what's really happening. A hospital or care network that's been buying your device for years now wants the readings to show up on a dashboard, not just on the device's own screen. Some insurers are starting to ask for continuous data instead of periodic visit-based readings. Distributors are telling you that competitors have already added app connectivity, and your device is starting to look dated next to them.

None of this is about chasing a buzzword. It's a practical shift in how healthcare buyers evaluate a device before they purchase it.

Pune sits in a strong position to respond to this. The city has a dense base of medical device OEM Pune manufacturers, diagnostics companies, and homecare equipment makers, alongside a mature IT and electronics ecosystem that most other manufacturing hubs in India don't have side by side. That combination matters, because adding remote monitoring isn't purely a hardware problem or purely a software problem. It needs both, and Pune OEMs are unusually well placed to source that expertise locally instead of managing it across cities. The real question isn't whether to add this capability. It's how to do it without breaking what already works in your device, your certifications, and your existing customer base.

The Real Decision: Retrofit vs. Redesign

Before touching connectivity protocols or cloud architecture, you need to settle this question first, because it decides your budget, your timeline, and your regulatory exposure.

• Retrofitting means adding an external module. This is generally faster to bring to market, but it is not a way to sidestep regulatory review. Under CDSCO's framework, any add-on that captures, transmits, or processes clinical data is treated as its own compliance question, whether that's as software embedded in your device (SiMD) or standalone software (SaMD), and it needs to be assessed on those terms before you assume it's the lighter-touch option. This is a common route for medical device retrofitting IoT projects on devices already mid-lifecycle that just need a data layer bolted on.

• Redesigning means building connectivity into the device itself: new PCB, embedded firmware changes, possibly a new enclosure. This gives you a cleaner, more integrated product and lower long-term unit cost at scale, but it usually means treating it as a new device variant from a regulatory standpoint, with a longer development and testing cycle.

The deciding factors that matter most: how much runway is left on your current product's lifecycle, whether the connectivity module you're adding qualifies as SiMD or SaMD under CDSCO's software guidance and what that pathway requires, and whether your budget supports a longer redesign cycle versus a shorter retrofit. If your device is early in its lifecycle and you expect to sell it for years, redesign tends to pay off. If it's a mature product nearing its next revision anyway, retrofitting buys you time without gambling the whole product line.

Choosing the Connectivity Layer: BLE, Wi-Fi, or Cellular

This is where a lot of otherwise good projects go sideways, because teams pick a connectivity option based on what's familiar rather than what the device actually needs.

1. BLE (Bluetooth Low Energy): The default for battery-powered, patient-worn, or homecare devices where power consumption is the top constraint. Building BLE medical device connectivity is cheap and well-supported, and certification is relatively straightforward, but it needs a paired smartphone or gateway to reach the internet; it doesn't connect directly.

2. Wi-Fi: Works when the device is stationary, think hospital-ward monitors or diagnostic units that stay plugged in near a router. It draws more power than BLE, depends on the facility's network being reliable, and in many Indian hospitals means working through enterprise Wi-Fi authentication requirements that home Wi-Fi setups don't have.

3. Cellular (NB-IoT or LTE-M): The right call for devices that need to work independent of the patient's home network, such as a device that travels with the patient, or one deployed where Wi-Fi can't be guaranteed. It's the most expensive option upfront, both in module cost and certification effort, but it removes dependency on someone else's network setup.

For a homecare device, BLE paired with a smartphone app is usually the practical starting point. You avoid cellular certification overhead while still getting reliable, low-power data transfer. If you need a partner experienced across all three, working with an IoT medical device development company that has actually built and certified connectivity modules, and worked through the SiMD/SaMD classification process with a regulatory consultant, saves months of trial and error and rework.

Building the Data Pipeline: Device to Dashboard

Once the device is transmitting data, that data needs somewhere to go and something to do once it arrives. The typical flow looks like this: sensor reading, local processing on the device or gateway, secure transmission to the cloud, storage and analysis, then a dashboard for the clinician or patient.

The part teams underestimate is interoperability. If your device data needs to land inside a hospital's existing electronic health record system, you're likely working with HL7 or FHIR standards for that handoff, and specifically FHIR R4 APIs where ABDM compliance is in scope, since that's the version India's digital health interoperability guidelines are built around. That integration work is not trivial, especially with data formats that vary hospital to hospital. Plan for this early rather than treating it as a bolt-on at the end.

The cloud layer itself doesn't need to be exotic. What it needs is reliable ingestion, encryption in transit and at rest, secure device authentication, and signed over-the-air firmware updates, plus a cloud dashboard for medical devices that's actually usable by a clinician glancing at it between patients, not a data dump. This is the core of what genuine IoT product transformation looks like for a device manufacturer. It's not just adding a sensor, it's building the entire chain that makes that sensor's data useful to someone. Getting remote patient monitoring integration right at this stage saves a lot of rework later.

Connectivity and Compliance: What Pune OEMs Need to Know

This is the part most guides on this topic skip entirely, and it's the one that matters most if you're manufacturing in India.

The base law here is India's Medical Device Rules, 2017, administered by CDSCO. That's still the governing regulation. What changed recently is that CDSCO issued draft guidance in October 2025 that clarifies, specifically for software, how connectivity should be treated under those same 2017 rules. In simple terms: once your device starts capturing, transmitting, or processing clinical data, that connectivity is treated as either software embedded in your device (SiMD) or standalone software (SaMD). Which of those two applies, not a change to your device's original risk class, is what actually determines the testing, documentation, and approval pathway you'll need going forward.

This is exactly why regulatory input has to come in at the design stage, not after the connectivity is built. In practice, it also means your firmware and software development process needs to hold up against recognized standards like IEC 62304 for software lifecycle management and ISO 14971 for risk management, since these are the technical backbone auditors expect to see behind any SiMD or SaMD submission. CDSCO connected device compliance is worth reviewing with a regulatory consultant early, before the hardware is finalized, since retrofitting compliance after the fact is far more expensive than designing around it. For the underlying rules and classification framework, the CDSCO Medical Device Rules, 2017 is the primary reference to start from, with CDSCO's 2025 software guidance as the layer that applies specifically to your connectivity build.

Separately, once patient data is being collected and transmitted, two more frameworks come into play. The Digital Personal Data Protection Act and Rules, which are being rolled out in phases, govern consent and data handling generally. The Ayushman Bharat Digital Mission (ABDM) standards are the more specific reference point for how health data itself is expected to be structured and exchanged in India. Neither is optional groundwork. Both need to shape your architecture decisions from the start, not get bolted on before launch.

What This Actually Costs and Takes

There's no honest single figure here. It depends entirely on the path you choose. The main cost and time drivers are:

1. Connectivity module and its certification. BLE is generally the lowest-cost, cellular the highest.

2. Firmware development effort. Heavier for a redesign than a retrofit.

3. Cloud infrastructure and security build-out. Ingestion, storage, encryption, and dashboard development.

4. Regulatory review cycle. The biggest variable, especially depending on whether your connectivity module is treated as SiMD or SaMD and what that pathway requires.

A retrofit-based project generally moves faster than a full redesign with cellular connectivity and EHR integration. Get a realistic estimate from your hardware and regulatory teams before committing to a launch date publicly. Timelines here vary too much project to project to quote a fixed number responsibly.

Frequently Asked Questions

Do I need new regulatory approval if I add remote monitoring to an existing device?  
It depends on whether the added connectivity is classified as software in the device (SiMD) or standalone software (SaMD) under CDSCO's medical device software guidance, and what testing or approval that pathway requires. Check with a regulatory consultant before finalizing your design.

What's the fastest way to add connectivity to a legacy medical device?  
A BLE-based retrofit module paired with a companion app is typically the quickest to build, since it avoids redesigning the core device. That speed doesn't extend to regulatory review, though. Whatever you add still needs to be assessed under CDSCO's SiMD/SaMD framework before you can call it the faster path end-to-end.

Is BLE or cellular better for a homecare monitoring device?  
BLE is usually better for battery-powered homecare devices because of lower power draw and simpler certification. Cellular makes sense when the device can't rely on a paired smartphone or a home Wi-Fi network.

How long does it take to build a connected version of an existing device?  
It varies by scope. A retrofit is generally quicker to bring to market than a full redesign with new connectivity built into the device plus regulatory review, which takes considerably longer.

How This Comes Together in Practice

Adding remote monitoring to a device you already manufacture is a cross-disciplinary build. Hardware, firmware, cloud, and regulatory work happening in parallel, not in sequence. At Theta Technolabs, this kind of work typically runs on a stack built around Node.js for the backend and API layer connecting devices to the cloud, cloud infrastructure for secure data storage and dashboard delivery, and where appropriate, AI/ML to help structure and surface patterns in sensor data for clinical review. Any use of AI/ML for diagnostic or decision-support purposes is its own regulatory conversation under CDSCO's SaMD framework, and that's a discussion to have early with your regulatory team, not something to treat as a simple backend add-on. We also work on broader digital healthcare solutions alongside this kind of device connectivity work.

If you're an OEM in Pune working through this decision, retrofit or redesign, BLE or cellular, in-house build or outsourced partner, it helps to talk it through with a team that's built these systems before, not just written about them. As an AI development company Pune teams already work with, Theta Technolabs is reachable at sales@thetatechnolabs.com.