{"id":23003,"date":"2026-05-25T12:37:10","date_gmt":"2026-05-25T12:37:10","guid":{"rendered":"https:\/\/engineerbabu.com\/blog\/?p=23003"},"modified":"2026-10-29T12:09:24","modified_gmt":"2026-10-29T12:09:24","slug":"remote-patient-monitoring-software-development","status":"publish","type":"post","link":"https:\/\/engineerbabu.com\/blog\/remote-patient-monitoring-software-development\/","title":{"rendered":"Remote Patient Monitoring Software Development: Billing, Devices, Architecture and Cost"},"content":{"rendered":"<p><b>TL;DR<\/b><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Remote patient monitoring software development is a billing problem first. CMS documentation rules shape your data model more than any clinical feature does.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">The <a href=\"https:\/\/www.cgm.com\/usa_en\/articles\/articles\/2026-medicare-rpm-code-changes-what-your-practice-is-leaving-on-the-table.html\" target=\"_blank\" rel=\"noopener\">2026 fee schedule added CPT 99445 and 99470<\/a>, so platforms built on the old 16-day and 20-minute thresholds are now leaving revenue on the table.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Device integration and EHR approval drive the timeline, not feature count. Epic production access alone takes 8 to 16 weeks.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">EngineerBabu built Somnoware for ResMed&#8217;s connected sleep therapy network and reuses that device abstraction layer, alert model and billing engine on new RPM builds.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Most RPM platforms that fail do not fail technically. They fail at billing, usually eight months after launch, when the denials have already stacked up.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Remote patient monitoring software development means building the system that collects physiologic data from FDA-cleared devices, moves it securely to clinicians, and produces the documentation CMS requires to pay for it. Three layers have to work together: device connectivity, time-series data infrastructure, and billing compliance.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Most teams build the first two well. They discover the third after the first claims come back denied. That ordering explains why RPM products fail commercially while working perfectly as software. A platform can stream vitals flawlessly and still be unbillable, because nobody counted transmission days correctly or logged clinical time against the right code.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This guide covers the full build for the US market, assuming you intend to bill Medicare.<\/span><\/p>\n<h2><b>What counts as RPM, and what does not<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Four product categories get called RPM. Only some are billable, and the regulatory requirements differ sharply across them.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Chronic disease RPM<\/b><span style=\"font-weight: 400;\"> is the core market. Continuous monitoring for hypertension, diabetes, heart failure, COPD and obesity, using blood pressure monitors, glucometers, pulse oximeters, scales and spirometers. This category has the clearest regulatory framework and the most established payer coverage.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Post-acute and transitional care RPM<\/b><span style=\"font-weight: 400;\"> monitors patients moving from hospital to home. Shorter windows of 30 to 90 days, tighter clinical response protocols, and billing that is often bundled into discharge rather than standalone CPT codes.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Specialty RPM<\/b><span style=\"font-weight: 400;\"> covers disease-specific programs such as oncology symptom management, maternal-fetal monitoring and post-transplant care. Billing may follow standard RPM codes or specialty frameworks depending on the use case.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Consumer health monitoring is not RPM.<\/b><span style=\"font-weight: 400;\"> Aggregating Apple Watch or Fitbit data without a physician order, clinical staff monitoring or CPT billing falls outside the CMS definition. It may be a good product. It is not a Medicare-billable service, and positioning it as one carries real regulatory risk.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Get precise about your category before scoping. The device list, billing architecture and clinical workflow all change with it.<\/span><\/p>\n<h2><b>The 2026 CPT code architecture<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">This is the section most RPM products get wrong. Not because the codes are complex, but because implementing them correctly requires your data model, documentation workflow and claim logic to be built around each code&#8217;s specific requirements.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">CMS expanded the code set in the CY2026 Physician Fee Schedule. The old model paid at only two thresholds, which left shorter monitoring periods and briefer clinical interactions uncompensated. Two new codes closed those gaps.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Code<\/b><\/td>\n<td><b>Covers<\/b><\/td>\n<td><b>Threshold<\/b><\/td>\n<td><b>Frequency<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">99453<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Device setup and patient education<\/span><\/td>\n<td><span style=\"font-weight: 400;\">First transmission, not delivery<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Once per device per episode<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">99454<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Device supply and transmission<\/span><\/td>\n<td><span style=\"font-weight: 400;\">16+ transmission days in 30 days<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Monthly<\/span><\/td>\n<\/tr>\n<tr>\n<td><b>99445<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Device supply and transmission<\/span><\/td>\n<td><b>2 to 15 transmission days<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Monthly, new in 2026<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">99457<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Treatment management, first 20 minutes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">20+ minutes with interactive communication<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Monthly<\/span><\/td>\n<\/tr>\n<tr>\n<td><b>99470<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Treatment management, shorter interval<\/span><\/td>\n<td><b>10 to 20 minutes with interactive communication<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Monthly, new in 2026<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">99458<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Each additional 20 minutes<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Beyond the first 20<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Typically twice monthly max<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">99091<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Physician data interpretation<\/span><\/td>\n<td><span style=\"font-weight: 400;\">30 minutes QHP time<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Monthly, not alongside 99457<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Published 2026 rate estimates for the new codes vary between roughly $26 and $47 for 99445, so confirm every figure against the current CMS Physician Fee Schedule before modeling revenue.<\/span><\/p>\n<h3><b>The four rules that shape your schema<\/b><\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>99453 fires on first transmission.<\/b><span style=\"font-weight: 400;\"> Not device delivery, not setup. Your system must store enrollment date, delivery date and first transmission date as three separate fields.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Transmission days are calendar days with at least one qualifying reading.<\/b><span style=\"font-weight: 400;\"> Not days the device was powered on, not days the patient opened the app, not Bluetooth pairing events. Track transmission at the reading level or the 16-day calculation will be wrong.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>99445 and 99454 are mutually exclusive in a month.<\/b><span style=\"font-weight: 400;\"> Your billing engine selects one at month end rather than accumulating both.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Clinical time needs minute-level precision.<\/b><span style=\"font-weight: 400;\"> With 99470 sitting between 10 and 20 minutes and 99457 starting at 20, a total-time note no longer picks the right code. Documentation must show the date, duration and nature of each individual interaction, plus the staff member&#8217;s name and credentials.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Across RPM products EngineerBabu has shipped, platforms with a correctly implemented billing engine captured an average of 94% of eligible CPT revenue in year one. Platforms relying on manual workflows or repurposed billing modules captured 61%.<\/span><\/p>\n<h2><b>Six things teams get wrong before they build<\/b><\/h2>\n<ul>\n<li aria-level=\"1\">\n<h3><b>The dashboard is treated as the product<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The dashboard is the interface. The revenue layer is the care management workflow that produces billable 99457 and 99470 time: the task queue, the interaction timer, the documentation template and the attestation flow.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Device support is left open-ended<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">&#8220;We support any device&#8221; is not scope. Every manufacturer has a different protocol, API architecture and data format. Scope your integrations explicitly in discovery.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Automated alerts are mistaken for clinical time<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The management codes require interactive communication with the patient or caregiver. Alerts and notifications do not count. Every RPM product needs a clinical operations layer, in-house, outsourced or built in as a managed service.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Payer strategy stops at &#8220;Medicare covers RPM.&#8221;<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Medicare Advantage plans set their own policies. Medicaid varies by state. Commercial payers often require prior authorization. Know your payer mix before architecting the billing engine.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>BAAs are treated as paperwork<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">You are the HIPAA business associate for data your platform receives. Any manufacturer whose cloud holds identified patient data is one too. Confirm BAA availability before you build the integration, not after.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Payer rules are deferred to &#8220;later.&#8221;<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">They are architectural constraints on your data model, documentation and claim logic. Build the billing engine as a configurable rules engine so adding a payer is a configuration change, not a sprint.<\/span><\/p>\n<h2><b>The regulatory stack<\/b><\/h2>\n<ul>\n<li aria-level=\"1\">\n<h3><b>HIPAA is the baseline<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">All physiologic data moving through the platform is ePHI, so the Privacy, Security and Breach Notification Rules apply.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Cellular carriers are generally not business associates because they transmit without accessing content, though confirm that for your architecture. Standard<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/healthcare-data-security-best-practices\/\"> <span style=\"font-weight: 400;\">healthcare data security best practices<\/span><\/a><span style=\"font-weight: 400;\"> apply across the stack.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>CMS sets eligibility<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Services must be ordered by a physician or qualified professional before monitoring begins. Consent must be obtained and documented beforehand, and verbal consent is acceptable.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The device must be medical-grade and transmit automatically. A glucometer requiring the patient to type in a reading does not qualify. The monitoring period is a calendar month, not a rolling 30 days from enrollment.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>FDA rules may reach your software<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Devices used in clinical RPM are typically Class II with 510(k) clearance. Your platform is usually not a device if it only transmits and displays. If your alert logic performs clinical decision support, such as predicting a cardiac event from reading patterns, the<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/samd-development-for-us-startups\/\"> <span style=\"font-weight: 400;\">SaMD development<\/span><\/a><span style=\"font-weight: 400;\"> classification question applies and should be settled early.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>State law adds a layer<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">RPM is generally treated as telehealth. Coverage parity laws exist in most states but parity does not mean every payer reimburses. State Medicaid programs set their own determinations.<\/span><\/p>\n<h2><b>The architecture decision that sets your budget<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Before any stack choice, answer one question. How fresh does the data need to be? That requirement drives infrastructure, cost and timeline more than anything else.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>15 to 30 minute windows<\/b><span style=\"font-weight: 400;\"> suit chronic condition trending and medication adherence. A REST API with periodic sync handles it.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>30 to 60 second alerting<\/b><span style=\"font-weight: 400;\"> is required for arrhythmia, hypertension management and post-surgical monitoring. This needs real-time streaming, with WebSockets or MQTT for device transport, Kafka or Kinesis for ingestion, and stream processing for rule evaluation.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Sub-10 second response<\/b><span style=\"font-weight: 400;\"> applies to ICU-adjacent and early warning systems, which pushes processing to the device or a local gateway.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A periodic-sync MVP typically costs 30 to 40% less and ships 6 to 8 weeks earlier than the real-time equivalent. Retrofitting streaming onto a polling architecture has forced backend rebuilds of roughly 40% on projects we have reviewed. Pick the lowest tier your clinical protocol genuinely tolerates.<\/span><\/p>\n<h2><b>Device integration for Remote Patient Monitoring Software Development<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Device integration is where RPM builds break most often. There is no universal RPM device API.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>What the landscape actually looks like<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Withings offers a REST API with OAuth 2.0 and a BAA under its Health Institutions program, making it the most developer-friendly blood pressure integration available.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Omron Connect is less friendly, though its cellular models transmit without phone pairing, which helps adherence in elderly populations. A&amp;D Medical runs cellular-first with proprietary cloud transmission.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">On glucose, Dexcom has one of the cleanest APIs in the market with a BAA available for clinical partners, while Abbott&#8217;s LibreView is harder to work with. For pulse oximetry, Masimo and Nonin are the medical-grade options.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The same constraints govern<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/wearable-device-integration-in-healthcare\/\"> <span style=\"font-weight: 400;\">wearable device integration in healthcare<\/span><\/a><span style=\"font-weight: 400;\"> generally.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Cellular or Bluetooth<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Cellular devices transmit straight to the manufacturer cloud with no pairing, no app install and no phone dependency. Adherence is higher and support tickets are lower, at $20 to $50 more per unit. For Medicare-target programs with elderly patients, this is usually the right call.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Bluetooth devices cost less but introduce pairing friction, which is the single largest source of patient support requests in RPM programs.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Build the framework before the second integration<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Point-to-point integrations become a maintenance problem fast. Build an adapter framework instead: one standardized internal reading model, one adapter per manufacturer, plus polling and webhook handling, device status monitoring and reading validation. Adding a device then takes days rather than weeks.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Budget a dedicated 3 to 4 week sprint for the framework and first device, run on its own rather than alongside feature work.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Device fleet management<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">For programs that supply hardware, you need inventory tracking, device-to-patient assignment by serial number, shipping and return integration, reconditioning workflow and transmission monitoring. A device that stops transmitting means missed threshold days, which means lost revenue. Return rates run 8 to 15% per year on blood pressure monitors.<\/span><\/p>\n<h2><b>Data architecture for time-series ePHI<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Remote patient monitoring software development data is time-series data at volume, and the patterns that work for clinical notes fail here.<\/span><\/p>\n<p><b>Store readings at the reading level<\/b><span style=\"font-weight: 400;\"> with patient ID, device ID, device type, reading timestamp, transmission timestamp, values, unit, status, transmission method and data source. The two timestamps are separate fields and both must be retained. An auditor reviewing a 99454 claim will ask when each reading was taken and when it was transmitted. A model storing only transmission time cannot answer the first question.<\/span><\/p>\n<p><b>Use a time-series database.<\/b><span style=\"font-weight: 400;\"> PostgreSQL with TimescaleDB handles most platforms under 50,000 patients and scales to tens of millions of readings. InfluxDB or Amazon Timestream suit higher volumes. A generic relational readings table degrades badly on exactly the queries RPM needs.<\/span><\/p>\n<p><b>Configure alert thresholds at three levels:<\/b><span style=\"font-weight: 400;\"> platform defaults, practice overrides and patient overrides. Store them so historical queries work, because &#8220;what was this patient&#8217;s threshold on that date&#8221; matters in audits. Log every alert with event, timestamp, channel, recipient and acknowledgment.<\/span><\/p>\n<p><b>Run a nightly threshold calculation service<\/b><span style=\"font-weight: 400;\"> that counts transmission days per patient per device per month, sums documented interaction time, and flags patients drifting below a billing threshold while there is still time to act.<\/span><\/p>\n<p><b>Retain for seven years<\/b><span style=\"font-weight: 400;\">, the longer of HIPAA&#8217;s six-year rule and Medicare&#8217;s audit lookback. Archive to cold storage after two years to control cost, which is straightforward once<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/hipaa-compliant-cloud-storage-healthcare-apps\/\"> <span style=\"font-weight: 400;\">HIPAA compliant cloud storage<\/span><\/a><span style=\"font-weight: 400;\"> is configured correctly.<\/span><\/p>\n<h2><b>The clinical workflow that produces billable time<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Revenue is generated or lost here. A solid integration and a clean dashboard produce nothing if clinical staff cannot deliver and document the required minutes each month.<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>The daily review<\/b><span style=\"font-weight: 400;\"> starts with a prioritized panel: critical alerts first, then patients at risk of missing the transmission threshold, then those short on interaction time with the month running out, then patients silent for 48 hours, then trend-based alerts.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>The interaction<\/b><span style=\"font-weight: 400;\"> runs on an embedded timer that starts when the chart opens and stops when the call ends. It records start time, end time, duration, staff name and credentials, and the documentation content. That timer record is the evidence behind the claim.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>The attestation<\/b><span style=\"font-weight: 400;\"> closes the month. The supervising physician or qualified professional reviews the documentation and attests that services were delivered. This is the first document an auditor requests.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>The panel view<\/b><span style=\"font-weight: 400;\"> is the care manager&#8217;s workspace. It must show every patient&#8217;s transmission count, interaction time, last reading, alert status and billing state, sortable and clickable straight into the interaction flow.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The patient-side scope sits alongside this, and the full<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/10-must-have-features-of-an-rpm-app\/\"> <span style=\"font-weight: 400;\">must-have features of an RPM app<\/span><\/a><span style=\"font-weight: 400;\"> go deeper on engagement than workflow planning covers.<\/span><\/p>\n<h2><b>EHR integration, where programs stall<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">EHR integration is the most common late-stage failure in remote patient monitoring software development. Teams treat it as an API task and discover it is a vendor approval process.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The modern standard is HL7 FHIR R4 with SMART on FHIR for authentication. Epic and Cerner both expose FHIR APIs, but access is heavily sandboxed and<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/epic-fhir-integration-guide-usa\/\"> <span style=\"font-weight: 400;\">Epic FHIR integration<\/span><\/a><span style=\"font-weight: 400;\"> approval alone runs 8 to 16 weeks.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Mapping the Observation and Device resources correctly needs real clinical informatics knowledge. Legacy paths such as HL7 v2 over MLLP and Mirth Connect middleware are still common and harder to work with.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Practices will not adopt a platform that forces double entry. You need demographics pull, order sync, note push and medication list access.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Common targets are Epic and Oracle Health in large systems, with Athenahealth, eClinicalWorks, NextGen and Tebra across independent practices. Teams building their own record layer face a different problem set under<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/custom-ehr-software-development\/\"> <span style=\"font-weight: 400;\">custom EHR software development<\/span><\/a><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Three rules keep this from wrecking the launch date. Name the target EHR on day one. Join its sandbox program immediately, since approval queues run in parallel with engineering. Then run integration as a separate workstream with a 12 to 16 week runway.<\/span><\/p>\n<h2><b>Build, buy, or build on top<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Not every Remote patient monitoring software development should be built from scratch. Mature white-label platforms include Current Health, Biofourmis, Health Recovery Solutions and TytoCare.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Build custom<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">When you need a device or protocol the platforms do not support, you are solving for a specific disease state, you need to own data for research or licensing, or the technology itself is the differentiator.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Buy or white-label<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">When your differentiation is the clinical program, you must be in market within six months, patient volume does not justify custom infrastructure, or you are a health system rather than a health-tech company.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Build on top<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">When neither fits. Build your clinical workflow layer against an FDA-cleared platform&#8217;s APIs. You inherit their clearance and device library while owning the experience. This path is underused and is often correct for provider organizations.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The honest test is whether a buyer would choose you for your software or your care model.<\/span><\/p>\n<h2><b>What remote patient monitoring software development costs<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Two cost models circulate, and both are right because they describe different products.<\/span><\/p>\n<h3><b>Module-scoped build, focused population<\/b><\/h3>\n<table>\n<tbody>\n<tr>\n<td><b>Module<\/b><\/td>\n<td><b>Range<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Device integration, 10 device types<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$10,000 \u2013 $20,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Time-series database and pipeline<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$6,000 \u2013 $12,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Real-time alert engine<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$8,000 \u2013 $15,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Alert fatigue prevention, ML baselines<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$8,000 \u2013 $15,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">CMS billing compliance engine<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$10,000 \u2013 $18,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Claims generation and clearinghouse<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$6,000 \u2013 $12,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Patient app, iOS and Android<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$10,000 \u2013 $18,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Provider dashboard and coordinator tools<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$8,000 \u2013 $15,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">EHR integration, FHIR R4<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$6,000 \u2013 $12,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">HIPAA infrastructure, IoT security, VAPT<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$8,000 \u2013 $15,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><b>Total<\/b><\/td>\n<td><b>$80,000 \u2013 $152,000<\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><b>Program-scoped build, by complexity<\/b><\/h3>\n<table>\n<tbody>\n<tr>\n<td><b>Tier<\/b><\/td>\n<td><b>Scope<\/b><\/td>\n<td><b>Timeline<\/b><\/td>\n<td><b>Cost<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Lean MVP<\/span><\/td>\n<td><span style=\"font-weight: 400;\">One condition, 2 device types, one EHR integration<\/span><\/td>\n<td><span style=\"font-weight: 400;\">14 \u2013 18 weeks<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$110,000 \u2013 $175,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Full platform<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Multi-condition, 4+ devices, multi-payer billing, fleet management<\/span><\/td>\n<td><span style=\"font-weight: 400;\">20 \u2013 28 weeks<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$185,000 \u2013 $290,000<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">AI-native<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Predictive alerts, trend analysis, care gap detection<\/span><\/td>\n<td><span style=\"font-weight: 400;\">22 \u2013 30 weeks<\/span><\/td>\n<td><span style=\"font-weight: 400;\">$210,000 \u2013 $330,000<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><b>Costs outside engineering.<\/b><span style=\"font-weight: 400;\"> SOC 2 Type II audit runs $45,000 to $95,000, with compliance tooling at $12,000 to $36,000 annually and penetration testing at $8,000 to $22,000.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Cellular blood pressure monitors cost $45 to $85 per unit, medical-grade pulse oximeters $150 to $300, and reconditioning $8 to $20 per returned device. Clearinghouse connections run $0.10 to $0.30 per claim, and an RCM partner takes 4 to 8% of collections.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A care manager costs $55,000 to $80,000 annually and sustains roughly 200 patients.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Weighed against<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/remote-patient-monitoring-roi-usa\/\"> <span style=\"font-weight: 400;\">remote patient monitoring software development ROI<\/span><\/a><span style=\"font-weight: 400;\"> at realistic enrollment, the billing engine pays for itself fastest.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For pre-Series A teams, a single condition, two device types, Medicare FFS only and outsourced clinical operations brings engineering to $120,000 to $165,000. Validate first, add complexity at Series A, which is the same logic behind<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/mvp-development-for-healthcare-startups\/\"> <span style=\"font-weight: 400;\">MVP development for healthcare startups<\/span><\/a><span style=\"font-weight: 400;\"> in other regulated categories.<\/span><\/p>\n<h2><b>The 14-week build, phase by phase<\/b><\/h2>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Weeks 1 to 3: compliance scoping and architecture<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Confirm the target condition and device list. Produce an ePHI data classification map down to the reading level. Run BAA analysis for every manufacturer API. Confirm EHR scope and payer strategy.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Map each CPT code&#8217;s documentation requirements to data model requirements, then design the billing engine around them. Provision HIPAA-eligible infrastructure with encryption at rest, TLS 1.2 or higher, audit logging and a CI\/CD pipeline with static analysis. Skipping this phase is what produces the rebuilds described earlier.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Weeks 4 to 7: devices, enrollment and thresholds<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Build the device adapter framework first, then the highest-priority integration against it. Add reading validation and device status monitoring. Build physician order creation and storage, patient enrollment with timestamped consent capture, and device assignment by serial number.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Then build the threshold calculation service covering transmission days per device per month and cumulative interaction time per patient. Surface that status live on the clinical dashboard so staff can act before a billing window closes.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Weeks 8 to 11: alerts, clinical workflow and billing<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Build threshold configuration at platform, practice and patient levels, with multi-channel delivery and acknowledgment tracking. Build the interaction timer and documentation template capturing date, duration, nature, actions and credentials, plus the attestation workflow.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Then build claim generation for each code, clearinghouse integration, remittance processing and denial management. Add the second device integration and the EHR connection, tested in sandbox. This phase carries the most billing risk, so budget QA time inside it.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Weeks 12 to 14: QA, review and launch<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Test every billing edge case explicitly: exactly 16 transmission days, 15 days, interaction time landing between thresholds, and readings arriving in the final week of a month. Run a third-party penetration test.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Have a healthcare billing specialist review the engine against the current fee schedule, since this is domain review rather than engineering review. Remediate critical findings, connect the SOC 2 platform, deliver the handover pack, then onboard the first practice and ship devices.<\/span><\/p>\n<h2><b>Where AI earns its place<\/b><\/h2>\n<p><b>Predictive deterioration alerts<\/b><span style=\"font-weight: 400;\"> identify patients whose reading patterns suggest decline before any single reading crosses a threshold. A blood pressure trending up 3 mmHg daily for a week may still be under the critical line while heading over it within 72 hours. These models run nightly on active patients, with predictions stored separately from threshold alerts.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Validation is not optional. One deployment we reviewed launched at a 34% false positive rate, staff stopped trusting the alerts entirely, and retraining with six more months of outcome data brought it to 11%. Only then did admissions in that panel drop 18%.<\/span><\/p>\n<p><b>Automated monthly summaries<\/b><span style=\"font-weight: 400;\"> cut the physician attestation burden by presenting averages, trends, threshold events and interaction history instead of raw readings.<\/span><\/p>\n<p><b>NLP on recorded interactions<\/b><span style=\"font-weight: 400;\"> drafts documentation and saves 3 to 5 minutes per call, which matters at 200-patient caseloads. Recordings are ePHI, so the transcription and model providers both need BAAs, and the wider rules for<\/span><a href=\"https:\/\/engineerbabu.com\/blog\/hipaa-compliant-ai-in-healthcare\/\"> <span style=\"font-weight: 400;\">HIPAA compliant AI in healthcare<\/span><\/a><span style=\"font-weight: 400;\"> apply to every inference step.<\/span><\/p>\n<p><b>Care gap detection<\/b><span style=\"font-weight: 400;\"> flags patients whose declining engagement predicts dropout, before they miss a threshold.<\/span><\/p>\n<h2><b>The payer landscape<\/b><\/h2>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Medicare fee-for-service<\/b><span style=\"font-weight: 400;\"> is the cleanest path. Coverage criteria, codes and rates are published annually, billing runs through the practice NPI, and no prior authorization is required. A fully compliant month generates roughly $130 to $145 per patient in gross revenue.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Medicare Advantage<\/b><span style=\"font-weight: 400;\"> plans set their own policies, so your engine needs plan-specific rules rather than traditional Medicare logic.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Medicaid<\/b><span style=\"font-weight: 400;\"> varies by state on covered codes, eligible conditions and rates.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Commercial payers<\/b><span style=\"font-weight: 400;\"> are the least uniform, frequently require prior authorization, and sometimes require contracted vendor status. Billing before authorization produces procedural denials that cannot be appealed on merit.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Across RPM products we have shipped, first-year collection rates ran 84% on Medicare FFS, 71% on Medicare Advantage and 62% on commercial. Architect for the payer mix you will actually face.<\/span><\/p>\n<h2><b>What the Somnoware build taught us<\/b><\/h2>\n<p><a href=\"http:\/\/engineerbabu.com\"><span style=\"font-weight: 400;\">EngineerBabu<\/span><\/a><span style=\"font-weight: 400;\"> built Somnoware, an RPM platform for ResMed&#8217;s connected CPAP and BiPAP network, which ResMed later acquired.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The problems it solved are the ones every RPM platform hits. Device protocols had to be normalized across hardware that reported differently. Alerts had to stay clinically useful without burying coordinators.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Compliance tracking had to survive billing scrutiny. Three components carry into current work: the device abstraction layer, the alert fatigue model built on per-patient baselines, and the billing engine. That is why new builds start at module integration rather than architecture.<\/span><\/p>\n<h2><b>When an offshore partner is the wrong call<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">An India-based engineering partner is wrong for your build if your escalation protocols require real-time clinical design decisions throughout the US business day,<\/span><\/p>\n<p><span style=\"font-weight: 400;\">if you are building custom hardware rather than integrating commercial devices, or if a health system customer contractually requires development inside the continental US.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For most teams building software that integrates with commercial devices and bills through existing payer channels, none of those apply.<\/span><\/p>\n<h2><b>Remote Patient Monitoring Software Development: Readiness Scorecard<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Score each row 0 for absent, 1 for partial, 2 for complete. Items marked 2x are billing-critical and double-weighted.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>#<\/b><\/td>\n<td><b>Criterion<\/b><\/td>\n<td><b>Weight<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">1<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Reading and transmission timestamps stored separately<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">2<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Transmission days counted from qualifying readings, not device activity<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">3<\/span><\/td>\n<td><span style=\"font-weight: 400;\">99453 triggered by first transmission, not delivery<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">4<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Interaction-level documentation with date, duration, nature, credentials<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">5<\/span><\/td>\n<td><span style=\"font-weight: 400;\">99445 and 99470 supported alongside 99454 and 99457<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">6<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Physician order workflow built and stored<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">7<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Timestamped consent with staff name and method<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">8<\/span><\/td>\n<td><span style=\"font-weight: 400;\">BAA confirmed with every manufacturer API in use<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">9<\/span><\/td>\n<td><span style=\"font-weight: 400;\">EHR integration for the target practice system<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">10<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Denial management with code capture and resubmission tracking<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">11<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Device adapter framework rather than point-to-point builds<\/span><\/td>\n<td><span style=\"font-weight: 400;\">1x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">12<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Time-series database for reading storage<\/span><\/td>\n<td><span style=\"font-weight: 400;\">1x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">13<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Payer rules engine, configurable rather than hardcoded<\/span><\/td>\n<td><span style=\"font-weight: 400;\">1x<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">14<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Seven-year retention implemented<\/span><\/td>\n<td><span style=\"font-weight: 400;\">1x<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Maximum score is 48. Above 38 means you are ready to bill and sell into practices. Between 28 and 38, remediate the double-weighted gaps first. Below 28, do not submit claims with real patients until the gaps close.<\/span><\/p>\n<h2><b>Final thoughts<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Remote patient monitoring software development rewards teams who design around reimbursement first and features second.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The billing engine is not a back-office module added at the end. It is the schema constraint shaping your reading table, your interaction log and your alerting logic from the first commit.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Decide your data freshness tier, confirm which codes your clinical protocol can realistically support under the 2026 rules, and name your target EHR before engineering starts. Those three answers determine most of your budget.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Teams scoping a full build can start with our<\/span><a href=\"https:\/\/engineerbabu.com\/remote-patient-monitoring-software-development-usa\"> <span style=\"font-weight: 400;\">remote patient monitoring software development in the USA<\/span><\/a><span style=\"font-weight: 400;\"> practice, or scope the wider<\/span><a href=\"https:\/\/engineerbabu.com\/industries\/healthcare-software-development\"> <span style=\"font-weight: 400;\">healthcare software development<\/span><\/a><span style=\"font-weight: 400;\"> program around it.<\/span><\/p>\n<h2><b>FAQs about Remote Patient Monitoring Software Development<\/b><\/h2>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Can RPM and chronic care management be billed in the same month?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Yes. RPM and CCM are separately billable when the time counted toward each does not overlap. Each needs its own documented minutes and its own interaction log.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>What is the difference between RPM and RTM?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">RPM covers physiologic data such as blood pressure and glucose. RTM covers therapeutic data such as medication adherence, pain levels and respiratory system status, and uses the 98975 to 98978 code family.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Who can perform the clinical time billed under 99457?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Clinical staff, physicians or other qualified professionals working under general supervision. The supervising provider need not be present for each interaction but must review and attest to the service.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Do patients pay a copay for remote patient monitoring?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Yes. RPM is subject to standard Medicare Part B cost sharing, typically 20% after the deductible. Patients must be informed of their cost responsibility before enrollment begins.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Can FQHCs and RHCs bill for RPM in 2026?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Yes. CMS confirmed that federally qualified health centers and rural health clinics can bill the new shorter-duration device supply code in 2026, expanding RPM access in underserved areas.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>What happens to billing when a patient is hospitalized mid-month?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Transmission days accrued before admission still count toward the supply code. Clinical management time during an inpatient stay is generally not separately billable under RPM.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>How many devices can be billed for one patient?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Device supply codes are billable per device type when each independently meets its transmission threshold. A patient using a blood pressure monitor and a glucometer can support two separate claims.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>What causes most RPM claim denials?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Insufficient transmission days, missing interactive communication records, absent consent documentation, and clinical time logged without timestamps. Nearly all denials trace to documentation gaps rather than clinical problems.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Can one platform serve multiple provider organizations?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Yes, with tenant isolation at the data layer, per-organization billing configuration and separate audit trails. Multi-tenancy retrofitted later costs substantially more than multi-tenancy designed in.<\/span><\/p>\n<ul>\n<li aria-level=\"1\">\n<h3><b>Does a patient need an established relationship with the ordering provider?<\/b><\/h3>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Yes. CMS requires an existing patient relationship before RPM begins, established through a prior evaluation and management visit or an equivalent qualifying encounter with the ordering provider.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>TL;DR Remote patient monitoring software development is a billing problem first. CMS documentation rules shape your data model more than any clinical feature does. The 2026 fee schedule added CPT 99445 and 99470, so platforms built on the old 16-day and 20-minute thresholds are now leaving revenue on the table. Device integration and EHR approval [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":24647,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1246],"tags":[],"class_list":["post-23003","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-healthtech"],"_links":{"self":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/23003","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/comments?post=23003"}],"version-history":[{"count":4,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/23003\/revisions"}],"predecessor-version":[{"id":24648,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/posts\/23003\/revisions\/24648"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/media\/24647"}],"wp:attachment":[{"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/media?parent=23003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/categories?post=23003"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/engineerbabu.com\/blog\/wp-json\/wp\/v2\/tags?post=23003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}