BLOGS 
NEWSROOM 
CASE STUDIES 
WEBINARS 
PODCASTS 
ASSET HUB 
EVENT CALENDAR 
TL;DR
- Chronic care management technology stopped being a solved problem the moment HRS acquired Rimidi in 2026 to become a full CCM solution provider, not just an RPM vendor with a bolted-on feature.
- That acquisition points to three structural shifts most platforms haven’t caught up to: documenting patient complexity for APCM billing (not just tracking minutes), detecting concurrency conflicts across CCM, RPM, PCM, and BHI automatically (not relying on staff to catch them), and building genuinely EHR-native workflows to FHIR CarePlan resources and the CMS ACCESS Model’s requirements (not a generic integration layer).
- Established vendors are strong on patient engagement and device connectivity, but that strength doesn’t automatically cover these three gaps. Evaluating a CCM platform in 2026 means asking about all three directly, because the technology bar is rising faster than most buyers’ mental model of the category.
Where CCM Technology Actually Stands in 2026
Chronic care management technology has been treated as a solved problem for years: a portal, a time tracker, a billing export. That framing is outdated, and the market itself is telling you so. Health Recovery Solutions, an established remote patient monitoring platform with real industry recognition from KLAS, Frost & Sullivan, and Avia, acquired Rimidi in 2026 specifically to become a full chronic care management solution provider, not just an RPM vendor with a CCM feature bolted on. That’s a real acquisition, not a positioning claim, and it signals the category is consolidating around a broader definition of what CCM technology needs to cover.
Shift One: From Time Tracking to Complexity Documentation
APCM’s complexity-based billing model, alongside traditional time-based CCM, means a platform now needs to document patient complexity with real specificity (social determinants of health, behavioral health flags, condition interactions), not just log minutes against a stopwatch. A platform built purely around time-tracking has no natural place to capture this, because it was never designed to.
Shift Two: From Single-Program to Multi-Program Awareness
Most chronically ill Medicare patients qualify for more than one care-management program at once (CCM, RPM, PCM, BHI), and the billing rules for what can run concurrently are specific and easy to violate without realizing it. Technology built around a single program in isolation cannot detect a concurrency conflict with a program it doesn’t track. This is a structural gap in most platforms, not a minor feature request, and it’s part of why a consolidation like HRS acquiring a chronic-disease-specific platform makes strategic sense: the winning platforms are the ones that can manage the whole stack, not one program at a time.
Shift Three: From Generic Integration to EHR-Native Workflows
The platforms winning real technical credibility right now are the ones building to a specific EHR’s actual data surfaces (FHIR CarePlan resources inside Epic, structured PowerForms inside Cerner) rather than a lowest-common-denominator API layer that works everywhere and integrates deeply nowhere. The CMS ACCESS Model reinforces this directly: participants are required to use FHIR-based APIs for eligibility, consent, claims-sharing, and care coordination, tied to CMS’s Health Tech Ecosystem pledge, not a generic data export. A platform that can’t meet that bar structurally can’t support an ACCESS-aligned organization at all, regardless of how good its CCM features are otherwise.
Where the Established Vendors Are, Honestly
Established CCM/RPM platforms have real strengths in patient-facing engagement and device integration for remote monitoring, and the HRS-Rimidi consolidation shows real momentum toward closing the chronic-disease-management gap specifically. Where the market gap still sits, even after that kind of consolidation, is in the three shifts above taken together: complexity-based documentation for APCM, cross-program concurrency management, and genuinely EHR-native (not just EHR-connected) architecture. A platform strong on device connectivity and patient engagement isn’t automatically strong on the regulatory and architectural shifts reshaping how CCM technology needs to work going forward, and a single acquisition doesn’t automatically close all three gaps at once.
Why This Consolidation Pattern Will Likely Continue
The HRS-Rimidi acquisition is unlikely to be the last move of its kind. Point solutions built around a single program, RPM-only, CCM-only, behavioral-health-only, are structurally at a disadvantage against a patient population that increasingly qualifies for several programs at once, and against a regulatory environment (APCM, ACCESS) that rewards platforms able to prove complexity and coordinate across programs rather than bill one activity type well. Vendors that can’t build multi-program depth organically have two paths: acquire it, the way HRS just did, or watch a buyer’s evaluation process surface the gap during procurement. Either way, the technology bar for “adequate CCM platform” is rising faster than most buyers’ mental model of the category has caught up to.
What This Means for a Buying Decision Today
A platform evaluation in 2026 should include questions the standard feature checklist doesn’t ask: can this platform document APCM-level complexity, not just CCM minutes? Does it detect a concurrency conflict across CCM, RPM, PCM, and BHI automatically, or rely on staff to catch it manually? Is the EHR integration built to your specific EHR’s real data model, or a generic layer that technically connects but doesn’t write natively into the chart? Is the platform’s FHIR API infrastructure actually ready for something like the ACCESS Model’s requirements, or is that still aspirational?
How Mindbowser Approaches This
We build CCM technology around where the category is actually heading, not where it’s been. That means complexity-aware documentation that supports both time-based CCM and APCM billing, automated concurrency checking across CCM, RPM, PCM, and BHI, and EHR-native architecture built to Epic, Cerner, and athenahealth’s actual data surfaces rather than a generic abstraction layer. CarePlan AI and RPMCheck AI are two of the accelerators that make this practical to build quickly rather than from scratch.
Conclusion
The HRS-Rimidi acquisition isn’t an isolated data point, it’s a signal that the category’s definition of “adequate CCM platform” has moved. Complexity-based documentation for APCM, cross-program concurrency management, and EHR-native architecture aren’t edge-case features anymore; they’re the three places where point solutions built around a single program are structurally exposed. Vendors will keep closing that gap one of two ways: acquiring the capability, the way HRS just did, or having the gap surface mid-procurement when a buyer asks the right questions.
Either path confirms the same thing: the checklist most teams are still evaluating against is outdated. A platform’s real position in 2026 comes down to whether it can document complexity, catch concurrency conflicts, and integrate natively into the EHR it’s actually deployed in, not how polished its patient portal looks in a demo.
Cross-program concurrency management, most platforms track CCM in isolation and can’t automatically detect a billing conflict with RPM, PCM, or BHI running on the same patient.
Not entirely different, but it does require capturing patient complexity (social determinants, behavioral health flags, condition interactions) with more structured specificity than time-based CCM billing alone requires.
Whether the platform writes directly into your EHR’s native data structures (FHIR CarePlan resources, Epic SmartForms, Cerner PowerForms) versus connecting through a generic API layer that shows data without integrating into your actual clinical workflow, and whether that infrastructure is ready for FHIR-based requirements like the ACCESS Model’s.
