RPM and RTM billing engine development
We build the billing engine inside remote patient monitoring programs: a day counter for every 30-day device period, a minute ledger for every calendar month, the 2026 codes 99445 and 99470 alongside 99453, 99454, 99457, 99458 and 99091, remote therapeutic monitoring on 98975 to 98986, clean concurrency with CCM, and a claim export to your RCM system or clearinghouse as an 837P. Every billed line carries the readings, minutes and interactive contact that justify it.
Scope your RPM billing engineFor RPM companies, provider groups and monitoring platforms that bill Medicare and commercial payers for remote monitoring. Updated September 26, 2026.
Unique days with transmitted data in each 30-day device period
Minutes per calendar month, with the interactive contact flagged
99454 or 99445, 99470 or 99457 plus 99458, never both sides of a pair
837P to your clearinghouse, then 999, 277CA and 835 matched back
Illustrative workflow · scope tailored to your environment
The short answer
RPM billing software turns device readings and care team time into billable remote patient monitoring claims. It counts the days each patient transmitted data in every 30-day period (16 or more days for 99454, 2 to 15 days for 99445 from January 1, 2026), totals treatment management minutes per calendar month (10 minutes for 99470, 20 for 99457, each further 20 for 99458), checks that a live interactive communication happened, applies the rules that stop RPM and RTM from being billed together or one minute from counting toward both RPM and CCM, and sends claim-ready lines to billing with the evidence attached. We build it as an engine inside your RPM platform or as a service beside it.
Read our RPM CPT code and reimbursement guide for 2026Start with the real problem
Programs monitor patients well and still leave months unbilled or billed wrong. Day counts are taken from the calendar month when the device codes run on a 30-day period. A patient with 12 reading days is written off because the platform predates 99445. Nine minutes of work is ignored when 99470 now pays for ten. A care manager's call counts toward both RPM and CCM. Two practitioners bill the same device period. Each of these is a rule, and a rule belongs in software that applies it the same way every month, with the evidence stored beside the claim line.
What we build
Most programs need the engine plus two or three of these. We scope them around the codes you bill today and the ones you plan to add.
A rolling 30-day period per patient and device, counting unique days with transmitted physiologic data and deciding between the 16-day and the 2 to 15 day device codes.
Remote patient monitoring softwareTimers and manual entries by patient, staff role, activity and calendar month, with the interactive communication (call, video, audio-only or secure message exchange) recorded as its own event.
CCM, RPM and RTM billing togetherThe same engine for therapy programs that monitor musculoskeletal, respiratory or cognitive behavioral therapy data, with rules that keep a patient in RPM or RTM for a period, never both.
Medical device integrationOne minute ledger shared by every program a patient is enrolled in, so RPM runs alongside chronic care management without a minute counting twice.
Chronic care management softwareApproved lines leave as charges for your practice management system or as an 837P for your clearinghouse, and every acknowledgment and payment comes back to the line that created it.
X12 EDI integration servicesFor every billed patient month: consent, the ordering practitioner, device and FDA status, reading days, minutes by person, the interactive contact and the rule version that selected the code.
RCM software developmentYour starting point
Your platform collects readings and runs care team workflows, and customers now ask for billing. We build the engine as a module: day counts, minute ledger, code selection per tenant, and exports each customer's billing team can take into its own PM system.
Billers pull device reports and time logs into a spreadsheet and decide codes by hand. We move that logic into a rules engine that runs daily, shows who is on track for 16 days or 20 minutes, and produces the claim file at period end.
Your engine was written for 99454 and 99457 only. We add 99445 and 99470, the 2-day minimum for 99453, the RTM 2 to 15 day codes, and regression tests that prove old months still bill the way they did.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Record the ordering practitioner, the established patient relationship, the condition being monitored and consent before the first reading counts. Link each patient to one billing practitioner per 30-day period.
Take readings from cellular hubs, Bluetooth apps and vendor clouds, deduplicate them, map them to the patient and device, and keep the transmission date that the day count uses.
Count unique days with data per device period, not per calendar month, and show each patient's running total so care teams can reach out before a period closes short.
Track treatment management time by person, role and program, capture the interactive communication as its own record, and separate practitioner review time for 99091.
Versioned rules with effective dates for RPM, RTM, CCM and PCM codes, including mutually exclusive pairs, one practitioner per period and payer-specific variations for commercial plans.
Send approved lines to your practice management or RCM system, or build the 837P directly with rendering and billing provider, place of service, diagnosis pointers and units, then match 999, 277CA and 835 responses back.
Per-claim evidence packets, program reports by code, practitioner and payer, and an exceptions queue for months that almost qualified.
Compare your options
All three can bill a compliant program. The difference is who owns the rules, the data and the margin.
| Custom RPM billing engine | RPM vendor platform | Outsourced RPM billing service | |
|---|---|---|---|
| Best for | RPM companies and platforms where billing is part of the product | Single practices starting a program | Practices without billing staff |
| Codes covered | RPM, RTM, CCM, PCM and APCM on one ledger, updated on your schedule | RPM and often CCM, on the vendor's release cycle | Whatever the service bills for you |
| Rules ownership | You own and version every rule | Vendor-maintained rules | The service's internal rules |
| Evidence | Stored with each claim line in your database | In the vendor platform | In the service's systems |
| Claim path | Your PM system, RCM system or clearinghouse via 837P | Vendor export or vendor-submitted claims | The service submits |
| Cost shape | Build cost, then hosting and support | Per-enrolled-patient fees | Percentage of collections or per-claim fees |
Platforms that sell RPM to many practices usually build the engine; single practices usually buy.
Expertise is in the decisions
99453, 99454, 99445 and the RTM device codes run on 30-day periods that start with the first reading. 99470, 99457, 99458 and the RTM management codes run on calendar months. The engine keeps both clocks per patient and never mixes them.
From January 1, 2026, a period with 16 or more reading days bills 99454 and a period with 2 to 15 days bills 99445. Only one device code bills per period, and a period with fewer than 2 days bills neither.
99470 pays for the first 10 minutes of treatment management in a month and 99457 for the first 20, so a month bills one or the other. 99458 adds each further 20 minutes after 99457. Each needs a live interactive communication with the patient or caregiver during the month.
Medicare allows RPM alongside CCM, PCM, TCM and BHI for the same patient, with each minute counted toward one service. RPM and RTM cannot be billed for the same patient in the same period, and only one practitioner bills RPM per 30-day period.
We encode CMS and payer rules with effective dates, and your compliance or billing lead signs off each rule and each change before it reaches a claim.
Which patients enroll, what devices they use and how alerts are handled are clinical decisions. The billing engine records them and bills what was done.
Timeline
The schedule depends on the number of device sources, programs and billing destinations more than on screens.
Map enrollment, device sources, time capture and the current claim path with your billing lead.
Day counts, minute ledger, code selection and claim export for RPM on one payer mix.
RTM codes, the shared minute ledger with CCM, and direct 837P with remittance matching.
More tenants, payers and reporting, with audit packets on demand.
Delivered work
Client names are withheld; each is a real engagement. Our open-source X12 work is public on GitHub.
Signed notes become claims checked against payer rules, a claims engine talks to the clearinghouse, denials land in a queue with the payer's reason attached, and an append-only ledger keeps every dollar traceable.
Eligibility checked through the clearinghouse before each visit and every claim run through CPT, modifier and NCCI checks before submission.
Blood pressure, pulse and oxygen readings captured from connected devices into a durable patient record that stays correct offline and reconciles when the network returns.
A test clearinghouse for 270/271, 278, 837, 999 and 277CA, 835 and 276/277, which we use to exercise claim exports and remittance matching before a real clearinghouse connection.
From discussion to delivery
Codes, payers, device sources, time capture and claim path agreed in writing.
Every billing rule written as a test case with your billing lead before code is written.
Working software every two weeks, tested against real device payloads and 837P validators.
One full billing period run beside your current process, reconciled line by line, then cutover.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↓It is the part of a remote patient monitoring platform that decides what can be billed each month. It counts reading days per 30-day device period, totals treatment management minutes per calendar month, checks for the interactive communication, applies concurrency rules with RTM and CCM, selects the codes and sends claim-ready lines to billing with the evidence stored alongside.
99453 for setup and patient education, 99454 for device supply with 16 to 30 days of data, 99445 for device supply with 2 to 15 days of data (new in 2026), 99470 for the first 10 minutes of treatment management (new in 2026), 99457 for the first 20 minutes, 99458 for each additional 20 minutes, and 99091 for 30 minutes of physician or qualified health professional data review.
99445 is the device supply code for a 30-day period in which the patient transmitted data on 2 to 15 days. It took effect on January 1, 2026 and pays at the same rate as 99454. The patient must be enrolled in RPM with a device that meets the FDA definition of a medical device, and 99445 and 99454 cannot both be billed for the same period.
99454 requires data on at least 16 days in a 30-day period. Before 2026 a period with fewer days could not bill a device code at all. Since January 1, 2026, periods with 2 to 15 days bill 99445 instead, so the software must count unique days per period and pick the right code.
Every activity is logged against a patient, staff member, role, program and calendar month, with a timer or a manual entry and a note. The interactive communication is recorded as its own event. At month end, 10 to 19 minutes bills 99470, 20 minutes bills 99457 and each further 20 minutes bills 99458.
Yes. Medicare allows RPM alongside CCM, PCM, TCM and BHI, as long as each minute counts toward one service. Our engines keep one time ledger with the program on every entry, so the export cannot count a minute twice.
No. A patient is billed for remote physiologic monitoring or remote therapeutic monitoring in a period, not both. The engine enforces this per patient and period and flags conflicts before export.
98975 for setup, 98976, 98977 and 98978 for respiratory, musculoskeletal and cognitive behavioral therapy device supply with 16 or more days, 98984, 98985 and 98986 for the same systems with 2 to 15 days (new in 2026), 98980 and 98981 for 20-minute treatment management blocks, and 98979 for the first 10 minutes (new in 2026).
We send approved lines to your practice management or RCM system as charges (HL7 DFT, FHIR ChargeItem or a flat file), or build the X12 837P directly for your clearinghouse. The 999, 277CA and 835 responses are matched back to each claim line so billed, accepted and paid are tracked separately.
For each billed patient month: consent, the ordering practitioner, the device and its FDA status, the dates of every reading, minutes by person and activity, the interactive communication, and the rule version that selected each code. We store this as an immutable record that can be exported as a packet for an audit or additional documentation request.
Cost depends on the number of device sources, programs (RPM, RTM, CCM), payers with custom rules, tenants and billing destinations. We give a fixed-scope estimate after discovery, broken down by module and integration, so you can phase the build.
Yes. We sign BAAs, we are ISO 27001:2022 certified, and we build HIPAA Security Rule safeguards into the engine: role-based access, audit logs of every view and change, and encryption in transit and at rest.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
