Opexia builds integrations between remote patient monitoring (RPM) vendors and the software your care-management team already runs: enrolled-patient sync, device data pulled through vendor APIs, readings matched to the right patient, and days-of-data and management-time tracking as configurable, effective-dated rules. The RPM work in our published engagement is an enrolled-patient export to an external RPM system; device ingestion and RPM billing rules would be new work, scoped for your program.
If several of these sound familiar, the systems need to be connected:
A patient is enrolled in the RPM vendor's portal but missing from your care-management roster, or the other way round.
Device data arrives under a name, device ID or MRN that doesn't line up with your records.
Someone exports readings each month to work out which patients reached the transmission days their code requires.
RPM management time sits apart from CCM and PCM time, so nobody can check that minutes aren't counted twice.
Your tracking assumes one threshold, but the 2026 code set added 2–15 day and 10-minute codes, and changes for 2027 are proposed.
Most RPM programs run on at least two systems: the vendor's platform, which receives device readings, and the system your care team works in, which holds the roster, the care programs and the time log. When the two drift apart, patients are enrolled in one and missing from the other, readings arrive for people nobody can match, and month-end counts of transmission days and management minutes are rebuilt by hand. We build the layer between them. Enrolled patients are synced with the vendor on a schedule, and mismatches are reported rather than silently dropped. Readings are pulled through the vendor's API where one is offered, matched to patients on identifiers agreed with you, and stored with their source and timestamp. Transmission days per 30-day period and management minutes per calendar month are counted against rules that carry start and end dates, because CMS changed the RPM code set for 2026 and has proposed further changes for 2027. Out-of-range readings are routed to the assigned coordinator's queue, using thresholds your clinicians set. The integration is built to HIPAA requirements (encryption, audit logging, role-based access); the RPM vendor stays your device and data provider.
This is one specific service within Custom CCM, PCM & RPM Operations Software.
| Approach | How current the data is | Patient matching | Ongoing effort | Suits |
|---|---|---|---|---|
| Manual export and import | As current as the last time someone ran it. | Done by eye or with spreadsheet lookups. | Staff time every cycle. | Small programs, or a stopgap while an integration is built. |
| Vendor portal only | Current inside the portal; absent from your own system. | Handled by the vendor within its own records. | Low, until you need RPM data beside CCM and PCM time. | Programs that run RPM separately from other care management. |
| Scheduled file exchange | Updated on each scheduled transfer. | Automated by script, with a report of rows that don't match. | Low once running; file formats need monitoring. | Vendors that offer exports or secure file transfer but no API. |
| API integration | As frequent as the vendor's API and your contract allow. | Automated, with a review queue for unmatched readings. | Low once running; vendor API changes need maintenance. | Vendors with a documented API and programs that need timely data. |
We confirm which of these your vendor supports before scoping. Many integrations start with a scheduled file exchange and move to an API later.
CMS's remote monitoring booklet says RPM data must be collected on 2–15 or 16 or more days out of 30, depending on the code; only one practitioner can bill remote monitoring per patient in a 30-day period; RPM and RTM can't be billed together; and RPM can be billed alongside CCM or PCM for the same patient if time and effort aren't counted twice. Source: CMS MLN901705, Telehealth & Remote Patient Monitoring (December 2025).
Final, effective January 1, 2026
CMS adopted CPT 99445 for device supply with 2 to 15 days of data in a 30-day period, beside 99454 for 16 to 30 days, and 99470 for the first 10 minutes of treatment management, beside 99457 for the first 20. The codes in each pair are not additive; 99458 covers additional 20-minute increments after 99457.
PROPOSED
CMS's CY 2027 proposed rule would pay for RPM and RTM from January 1, 2027 only when the clinical staff are directly employed by the billing practitioner or practice. CCM, PCM and APCM are not included. It is not a final rule; an integration that records each staff member's employer by date can adapt either way.
Engineering and operations context, not legal or billing advice. Last reviewed 2026-09-28.
Useful before a first call:
Common questions about rpm integration development for care-management teams
Yes, one, and we describe it exactly: an integration from a US CCM/PCM organization's platform to an external RPM system, exporting enrolled-patient data so care programs stay in sync. We did not build that RPM system, its device connections or RPM billing logic; for your program, those would be scoped as new work.
Any vendor that offers an API, scheduled exports or secure file transfer, and allows that access under your contract with them. We confirm the interface, the identifiers it carries and any vendor approval steps before writing a scope. If a vendor offers none of these, we tell you so rather than work around it.
Thresholds live in configuration with start and end dates, not in code. The 2026 code set added CPT 99445 for 2 to 15 days of data and 99470 for the first 10 minutes of management. If CMS finalizes further changes for 2027, you add a new rule version instead of rewriting the integration.
If finalized, it adds one requirement: knowing who employed each staff member on each date. CMS-1848-P would limit RPM and RTM payment to clinical staff directly employed by the billing practice from January 1, 2027. It is proposed, not final, and it does not include CCM, PCM or APCM.
Yes. We sign a Business Associate Agreement (BAA) before any PHI access: no one on our team sees protected health information until it is executed. Device readings are PHI, so this comes before any integration touches production data. We can sign your organization's BAA or provide ours, and the signed agreement governs.
Cost depends on scope, so we don't quote a generic range. Book a free 30-minute consultation: we review your requirements and workflow, then send a written scope and quote tied to what you actually need. Cost depends mostly on what your vendor's interface offers and how many systems are involved.
You do. You own the source code on final payment, including the sync, matching and threshold rules, and your patient data stays yours throughout. Your contract with the RPM vendor is unaffected: we build against the access that contract already gives you, and you can maintain the integration yourselves later.
Our team works from Pakistan with overlap into US business hours. Access to PHI, including device readings, is governed by the signed BAA, limited by role-based access so each person sees only what their role needs, and recorded in audit logs. During builds we use de-identified or synthetic data wherever possible.
Deep-dive technical guides related to rpm integration development for care-management teams
Calculate how much you're spending on manual processes and how fast custom software pays for itself.
Calculate SavingsDownload a practical checklist of HIPAA Security Rule safeguards to review before you launch.
Get ChecklistRead the published CCM/PCM engagement: Excel to a multi-tenant platform serving 8,000+ patients.
Read the Case StudySchedule a technical consultation to discuss your specific requirements, timeline, and budget. No sales pitch—just engineering.
Or explore the engineering glossary to learn more about healthcare software terminology.
'/%3e%3cpath%20d='M534.104%20592.554C517.522%20607.15%20492.036%20605.65%20479.37%20587.55C432.827%20521.038%20409.925%20440.343%20415.135%20358.545C420.344%20276.748%20453.298%20199.61%20507.904%20139.54C522.764%20123.194%20548.234%20124.939%20562.83%20141.521L608.023%20192.862C622.619%20209.444%20620.638%20234.536%20607.101%20251.994C581.387%20285.156%20565.941%20325.498%20563.237%20367.978C560.53%20410.458%20570.733%20452.433%20592.032%20488.59C603.245%20507.624%20602.027%20532.765%20585.445%20547.361L534.104%20592.554Z'%20fill='url(%23paint1_linear_154_257)'/%3e%3cpath%20d='M404.368%20499.661L455.381%20493.203L438.013%20356L387%20362.458L404.368%20499.661Z'%20fill='white'/%3e%3cpath%20d='M349%20408.709L355.956%20459.657L492.983%20440.947L486.026%20390L349%20408.709Z'%20fill='white'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_154_257'%20x1='170'%20y1='492.5'%20x2='449'%20y2='508.5'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%236648E0'/%3e%3cstop%20offset='1'%20stop-color='%23413AC9'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_154_257'%20x1='429'%20y1='384'%20x2='549.5'%20y2='380.5'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%235B51FF'/%3e%3cstop%20offset='1'%20stop-color='%233428E6'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)