This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you are building for chronic disease — hypertension, heart failure, diabetes, COPD — your product lives or dies on details that look like billing trivia but are actually architecture. A platform that lets patients type their blood pressure into a form will never collect a cent of RPM reimbursement, because Medicare requires the data to come automatically off a real medical device. A program that forgets to capture consent, or that double-enrolls a patient under two practices in the same month, generates clawbacks instead of revenue. This guide is for the founder, product manager, or clinical lead deciding what to build first, and it translates the 2026 Medicare rules, the FDA device line, and the HIPAA stream into product decisions you can hand to engineers and auditors.

Two products that look like one

Start by separating the two things, because almost every confused chronic-care build comes from treating them as a single feature.

Chronic care management, called CCM, is a care-coordination service. Medicare pays a practice to manage a patient who has two or more chronic conditions — conditions expected to last at least 12 months — that put the patient at significant risk of decline. The work is human: a nurse or care coordinator maintains a comprehensive care plan, helps with medication refills, coordinates between specialists, runs a monthly check-in, and keeps a 24/7 line open. Notice what is missing from that description: a device. CCM is billed on time spent coordinating care, and a patient can be enrolled in CCM with nothing more than a phone.

Remote patient monitoring, called RPM (and sometimes "remote physiologic monitoring," the same thing), is a device service. Medicare pays for a connected medical device — a blood-pressure cuff, a weight scale, a pulse oximeter, a glucose meter — that automatically records a patient's vital signs and transmits them to the care team, plus the staff time spent reviewing those readings and managing the patient. RPM is the longitudinal data product: instead of a once-a-month snapshot, the care team watches a continuous stream and intervenes when a number drifts.

The two stack. A patient with heart failure and diabetes can be enrolled in CCM for the care coordination and RPM for the daily weight and glucose readings, and a practice can bill both in the same month (Medicare permits concurrent billing of CCM and RPM when the time counted toward each is not double-counted). That is exactly why founders blur them — in a mature product they run on the same patient, the same dashboard, the same care team. But they are governed by different rules, and you cannot design either correctly until you hold them apart.

CCM as device-free care coordination beside RPM as device-streamed monitoring, with the billing codes for each Figure 1. CCM and RPM are two reimbursable programs, not one. CCM pays for coordination time and needs no device; RPM pays for a connected medical device plus the time to act on its data. They stack on the same patient.

The billing codes are the product spec

Here is the idea that reorganizes everything: in chronic care, the Medicare billing codes are your requirements document. Each code names a threshold the product must measure, a piece of evidence it must capture, and a workflow it must enforce. Build to the codes and you have a compliant product; build to a feature wishlist and you will discover at your first audit that you cannot prove a single claim.

Let us walk the codes, with the 2026 Medicare rates so the math is concrete. (Reimbursement values are national approximations from the CY2026 Physician Fee Schedule; actual payment varies by locality and is updated yearly — treat every dollar figure as a planning range.)

The RPM codes (from the CY2026 Physician Fee Schedule Final Rule):

  • 99453 — initial setup and patient education on the device. Billed once per episode. ~$22.
  • 99454 — device supply with daily recordings or alerts, 16–30 days in a 30-day period. ~$47 per 30 days. This is the workhorse, and the 16-day rule is the single most important number in RPM.
  • 99445 — new for 2026 — device supply for 2–15 days in a 30-day period, ~$47. CMS added this code so a shorter "data burst" — after a procedure, during a medication change — is billable when the patient does not hit 16 days. It is not additive with 99454: you bill one or the other, never both.
  • 99457 — treatment management, the first 20 minutes of clinical staff or provider time in a month, and it requires at least one live, interactive conversation with the patient or caregiver. ~$52.
  • 99470 — new for 2026 — treatment management, the first 10 minutes, also requiring a live interactive conversation. ~$26. Not additive with 99457 — pick the single code that matches the time you actually spent.
  • 99458 — each additional 20 minutes of treatment management. ~$41. This is how a high-touch month stacks.

Two of those rules are pure architecture. First, the 16-day rule: code 99454 is only billable if the device recorded data on at least 16 unique calendar days within the 30-day window. Your product must count adherence days per patient, surface a "12 of 16" progress indicator to the care team, and nudge patients who are falling behind — adherence is not a nicety, it is the revenue gate. Second, the live-interaction requirement on 99457/99470: the platform must log a real two-way conversation each month, with a timestamp, or the treatment-management time is unbillable no matter how many readings the staff reviewed.

The CCM codes (from the Medicare Chronic Care Management MLN booklet, MLN909188):

  • 99490 — first 20 minutes of clinical staff time per month, under general supervision of the billing clinician. ~$62.
  • 99439 — each additional 20 minutes of clinical staff time, billable up to twice a month. ~$50 each.
  • 99491 — first 30 minutes when the billing clinician personally does the work (clinical-staff time does not count toward it). ~$86.
  • 99437 — each additional 30 minutes of that personal physician time.
  • 99487 / 99489 — complex CCM, for patients needing more intensive coordination and moderate-to-high decision-making.

CCM's rules are about evidence, not devices: a documented patient consent, a comprehensive care plan stored in the record, and a defensible time log. The product must track who spent which minutes, on what, for which patient, and prove the 20-minute (or 30-minute) threshold was crossed before it lets a claim go out.

Now the worked example, out loud, because the panel economics are the whole reason this category exists. Take one patient enrolled in both programs in a routine month:

RPM:  99454 (device supply, 16+ days)         ~$47
    + 99457 (first 20 min, live interaction)  ~$52
CCM:  99490 (first 20 min coordination)       ~$62
                                              ------
Per patient, per month                        ~$161

Multiply by a panel. A care team managing 500 enrolled patients at roughly that blended rate is a program in the neighborhood of:

500 patients × ~$161/month  ≈  $80,500 / month
                            ≈  $966,000 / year

That is gross, before device cost, staff cost, and the ~20% patient copay (RPM and CCM are Medicare Part B services, so the patient owes coinsurance — typically around $8/month for CCM — which your billing flow must disclose at consent). But it explains why chronic care is the most durable recurring-revenue model in telehealth: the codes pay every month the patient stays adherent. The product's job is to keep them adherent and to prove, claim by claim, that every threshold was met.

Map of 2026 RPM and CCM billing codes with thresholds, the 16-day rule, and approximate Medicare rates Figure 2. The 2026 code map. Each code is a threshold the product must measure and a piece of evidence it must capture. The 16-day device rule and the monthly live-interaction rule are the two that are pure engineering.

The device gate: what Medicare and the FDA will actually count

This is where naive RPM builds die. A patient typing their morning blood pressure into a text field feels like remote monitoring. Medicare does not pay for it, and the reason is a hard rule worth memorizing.

To bill RPM, the data must come from a device that meets the FDA's definition of a medical device, and it must be transmitted automatically — the patient cannot key it in. Manually entered readings are denied. CMS built RPM on the FDA device definition (from section 201(h) of the Federal Food, Drug, and Cosmetic Act) precisely to anchor reimbursement to instruments that produce reliable, tamper-resistant clinical data. So your sourcing decision is also a compliance decision: a $15 consumer cuff that only shows a number on its own screen cannot anchor a claim; a cleared cuff that pushes readings over cellular or Bluetooth can.

That pulls in a second line you have to respect: the difference between a general-wellness product and a regulated medical device. The FDA refreshed both its "General Wellness: Policy for Low-Risk Devices" guidance and its Clinical Decision Support Software guidance in January 2026, and the boundary matters to you twice. A fitness tracker that reports steps and sleep is a general-wellness product and is not a medical device; a cleared blood-pressure monitor making a measurement used to manage hypertension is. Wearable consumer hardware sits in a gray zone — advanced metrics like blood-oxygen or blood-pressure trends may stay in the wellness lane only as long as they make no diagnostic or disease-management claim. The moment your product uses that data to manage a diagnosed condition, you are relying on it as clinical data, and the device behind it needs to be the regulated kind.

The line returns a third time, on your own software. If your platform only displays and stores readings, it is plumbing. If it starts interpreting them — flagging a value as dangerous, predicting deterioration, recommending a medication change — you are approaching the regulatory boundary between decision support (generally permitted, under conditions) and a diagnostic function (which can make your software a regulated medical device, "Software as a Medical Device," or SaMD). The safe pattern is to keep your analytics as transparent support for a licensed clinician who makes the call, and to treat any feature that outputs a conclusion directly to the patient, or that a clinician cannot independently review, as one that needs a regulatory look. We cover that boundary in depth in the companion articles on RPM anomaly detection and the compliance and safety layer for clinical AI; the rule of thumb here is simply: display is plumbing, interpretation is a device question.

Decision tree: FDA-defined auto-transmitting devices are RPM-billable; wellness wearables and manual entry are not Figure 3. The device gate. Reimbursable RPM data comes only from an FDA-defined medical device that transmits automatically. Consumer wellness data and manual entry are not billable, and analytics that interpret rather than display raise a separate device question.

The architecture: from a cuff in a kitchen to a billable record

With the rules fixed, the build becomes a data-flow problem: get a reliable reading off a device in someone's home, carry it safely across the internet, land it in a record a clinician can act on and a biller can defend, and do it for thousands of patients at once.

The device and its radio. Home monitoring devices talk over one of two links. Bluetooth Low Energy (BLE) pairs the device to the patient's phone, and an app relays readings to your cloud — cheap, but it depends on the patient owning a smartphone, keeping the app installed, and keeping Bluetooth on. For a chronic-care population that skews older, that fragility is the enemy of the 16-day rule. The alternative is a cellular device with an embedded modem (using low-power wide-area links such as LTE-M or NB-IoT) that transmits on its own, with no phone and no app. Cellular devices cost more per unit and carry a data-plan fee, but they convert far better on adherence — the patient takes a reading and it simply arrives. For the patients RPM serves best, "no phone required" is often the single highest-leverage design decision you will make.

Ingestion and normalization. Readings arrive from many device makers in many shapes. A clean platform terminates that variety at an ingestion layer that normalizes everything into a consistent internal model, then maps it onto a healthcare standard so the rest of your stack — and the EHR — can read it. The relevant standards: device-level interoperability profiles like IEEE 11073 and the Continua Guidelines describe how a vital sign should be structured at the source, and HL7 FHIR carries it onward — a reading becomes a FHIR Observation, tied to a Device and a Patient resource. Speak FHIR at the boundary and EHR write-back stops being a custom project per vendor. (For the standards themselves, see the HL7 FHIR and EHR integration article — this section covers the clinical wiring, not the spec internals.)

The record and the care surface. Normalized readings land in a longitudinal store and surface on a care-team dashboard: trends per patient, adherence-day counters tied to the 16-day rule, and a worklist of patients whose numbers crossed a threshold. The same store feeds the EHR so the patient's chart shows the monitoring, and feeds the billing engine so a claim can prove its thresholds. Every one of these hops carries Protected Health Information — health data tied to an identifiable person, "PHI" — which brings us to the boundary.

RPM data flow: home device over Bluetooth or cellular to a FHIR record, EHR, dashboard, and billing inside the HIPAA boundary Figure 4. The RPM data flow. A reading leaves an FDA-defined device over Bluetooth or cellular, is normalized to FHIR, and lands in the record, the EHR, the care dashboard, and the billing engine. Everything inside the boundary is PHI and every vendor that touches it needs a signed BAA.

Compliance: the stream is PHI, and the device vendor is in your boundary

A blood-pressure reading tagged to a named patient is PHI from the instant the cuff captures it. That single fact sets the whole compliance frame, and RPM has a wrinkle that a video-only telehealth product does not: the data is continuous, and it originates on hardware and networks you did not build.

The first rule is the one founders skip: every vendor that can see the PHI needs a signed Business Associate Agreement — the contract, called a BAA, in which a vendor handling patient data on your behalf legally commits to protecting it (45 CFR §164.502(e)). For RPM that list is longer than people expect. The device manufacturer that ships readings through its cloud, the cellular-connectivity provider whose modem carries the data, the platform that stores it — each one is inside your boundary and each one needs a BAA. "The device is encrypted" is not the same as "the device vendor is covered." Encryption is necessary and not sufficient; a perfectly encrypted reading flowing through a vendor with no BAA is still a HIPAA gap.

Inside the boundary, the familiar safeguards apply, sharpened by the always-on nature of the data. Encryption in transit and at rest (45 CFR §164.312) covers the link from the device and the store the readings sit in. Access controls and audit logging record which staff member viewed which patient's stream and when — the continuous data makes the audit trail larger, not optional. And the minimum-necessary principle (45 CFR §164.502(b)) governs who on the care team sees what.

Analytics deserve their own line, because this is where chronic-care products quietly leak PHI. If you want to study population trends, run quality metrics, or train a model, the readings must either stay inside the boundary under a BAA or be properly de-identified first (the HIPAA de-identification standard, 45 CFR §164.514(b)). Piping a raw, patient-tagged vitals stream into a general analytics tool with no BAA is one of the most common — and most invisible — violations in this category.

One more duty is specific to monitoring and easy to miss: bias and measurement validity. Some sensors do not perform equally across all patients. Pulse oximeters, for example, have been shown to overestimate blood-oxygen levels in patients with darker skin, and a 2024 federal rule under Section 1557 of the Affordable Care Act (45 CFR §92.210) requires covered entities to identify and mitigate the risk of discrimination when patient-care decision-support tools use such measurements. For an RPM product, that means knowing the limits of your sensors and designing thresholds and escalation so a known measurement bias does not become a care gap. It is both an ethics duty and, now, a compliance one.

Turning a data stream into safe care: alerts, baselines, and the human in the loop

A monitoring product that streams numbers but does not safely act on them is worse than no product — it creates the appearance of oversight without the substance. Two design realities decide whether your platform is safe.

The first is alert fatigue. A naive threshold ("alert if systolic > 140") fires constantly across a real population, and a care team that drowns in false alarms stops reading any of them. Studies of clinical alarms have long found that the overwhelming majority are not clinically actionable, and the same trap waits in RPM. The fix is to move from fixed thresholds to personalized baselines — what is normal for this patient — and to triage alerts by severity before a human ever sees them, so the care team's worklist shows the readings that actually need a person. The engineering of that detection layer is its own subject, covered in the RPM anomaly detection article; the product principle here is that an alert without a triage owner is a liability, not a feature.

The second reality is that the reimbursement rules quietly enforce safety. Remember that RPM's treatment-management codes (99457, 99470, 99458) require a live, interactive conversation each month. CMS did not write that to be annoying — it encodes the expectation that monitoring is coupled to human management. The continuous stream is the input; a clinician reviewing it, talking to the patient, and adjusting the plan is the billable, safe output. Design the care workflow so that every monitored patient has a named owner, a clear escalation path when a number is dangerous, and a logged monthly touchpoint. That workflow is simultaneously your clinical-safety design and your claim evidence.

The evidence that this works is real, which is worth saying plainly to a skeptical buyer. In a large retrospective hypertension cohort, RPM was associated with meaningful blood-pressure reductions — average systolic drops in the range of roughly 12 mmHg in uncontrolled patients, larger in stage-2 patients — after at least 90 days on the program. Heart-failure programs pairing RPM with telemedicine have reported 30-day readmission reductions on the order of 50% at individual health systems. These are observational results, not randomized trials, and they vary by population and program design — but the direction is consistent, and it is the clinical story your product is there to deliver.

A common-mistake gallery

Chronic care has a recognizable set of failures, and every one of them is designed-out rather than fixed later.

  • Billing manually entered data. A patient types their weight, the claim goes out under 99454, and it is denied — the data must transmit automatically from an FDA-defined device. Build the device path; never offer a "just type it in" shortcut that looks billable.
  • No BAA with the device or connectivity vendor. The platform is HIPAA-careful but the cellular carrier moving the readings was never papered. The whole chain needs BAAs, not just your own servers.
  • Ignoring the 16-day rule until billing. The product collects readings but never counts adherence days, so the care team learns at month-end that half the panel missed the threshold. Surface the day counter continuously and nudge early.
  • Treating a wellness wearable as an RPM device. Consumer step-and-sleep data is not billable RPM data and may not be a medical device at all. Keep wellness signals and reimbursable clinical readings in separate lanes.
  • An alert stream with no triage owner. Thresholds fire, nobody is accountable for the queue, and a dangerous reading sits unread. Assign every monitored patient a named owner and an escalation path before launch.
  • Skipping or losing consent. CCM and RPM both require recorded patient consent, including the cost-sharing disclosure. Capture it in the enrollment flow and store it where an auditor can find it.
  • Double-enrollment. Only one practitioner can bill CCM for a patient in a given month; a patient enrolled under two practices generates a denial and a clawback. Enforce the one-practitioner lock in the data model.

Where Fora Soft fits in

Fora Soft has built real-time video, streaming, conferencing, and connected-device software since 2005, and chronic-care platforms sit at the intersection of two things we do: ingesting and normalizing live data streams, and wrapping them in a HIPAA-aware boundary. The compliance-first way we approach an RPM build is to start from the requirement — the 16-day adherence counter, the automatic-transmission device path, the BAA chain across every vendor that touches the stream, the consent and time-log evidence a claim must prove — and then build the capability on top of it. That ordering is the difference between a chronic-care product that generates recurring reimbursement and one that generates clawbacks.

What to read next

Call to action

References

  1. Centers for Medicare & Medicaid Services. CY 2026 Medicare Physician Fee Schedule Final Rule. Federal Register, doc. 2025-19787, published 2025-11-05. (Tier 1 — RPM codes 99453/99454/99457/99458, new 99445 and 99470, the 16-day rule, automatic-transmission and FDA-device requirements, live-interactive-communication policy.) https://www.federalregister.gov/documents/2025/11/05/2025-19787/
  2. Centers for Medicare & Medicaid Services. Chronic Care Management Services. MLN Booklet MLN909188, June 2025. (Tier 1 — CCM codes 99490/99439/99491/99437/99487/99489, the two-chronic-conditions threshold, consent's four required elements, care-plan and time-log requirements, cost-sharing.) https://www.cms.gov/files/document/chroniccaremanagement.pdf
  3. U.S. Food & Drug Administration. General Wellness: Policy for Low-Risk Devices. Updated guidance, January 6, 2026. (Tier 1 — the general-wellness-vs-medical-device boundary.) https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices
  4. U.S. Food & Drug Administration. Clinical Decision Support Software. Updated guidance, January 6, 2026, docket FDA-2017-D-6569. (Tier 1 — the decision-support-vs-device line for interpretive analytics.) https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
  5. Federal Food, Drug, and Cosmetic Act, §201(h) — definition of "device." (Tier 1 — the medical-device definition CMS anchors RPM on.) https://www.govinfo.gov/
  6. 45 CFR §164.502(e) and §164.514(b) — Business Associate Agreements and the de-identification standard, HIPAA Privacy Rule. (Tier 1.) https://www.ecfr.gov/current/title-45/part-164
  7. 45 CFR §164.312 — technical safeguards (encryption, access control, audit controls), HIPAA Security Rule. (Tier 1.) https://www.ecfr.gov/current/title-45/part-164/subpart-C
  8. 45 CFR §92.210 — nondiscrimination in the use of patient-care decision-support tools, Section 1557 of the ACA, 2024 final rule. (Tier 1 — the measurement-bias duty, pulse-oximetry example.) https://www.ecfr.gov/current/title-45/part-92
  9. "Remote Patient Monitoring Is Associated with Improved Outcomes in Hypertension: A Large, Retrospective, Cohort Analysis." Healthcare (MDPI), 2024; PMC11353537. (Tier 5 — systolic-BP reduction figures.) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC11353537/
  10. "Remote Monitoring Program Cuts Heart Failure Readmissions in Half." AJMC, 2024. (Tier 5 — 30-day readmission reduction.) https://www.ajmc.com/view/remote-monitoring-program-cuts-heart-failure-readmissions-in-half
  11. "The State of Remote Patient Monitoring for Chronic Disease Management in the United States." Journal of Medical Internet Research, 2025; e70422. (Tier 5 — RPM adoption and program context.) https://www.jmir.org/2025/1/e70422
  12. HL7 FHIR R4 — Observation, Device, and Patient resources; IEEE 11073 / Continua Guidelines for personal health device data. (Tier 3 — interoperability standards.) https://hl7.org/fhir/R4/