TL;DR
Most “how to start CCM” advice leads with billing codes and software backwards. The real sequence is: size the eligible population realistically (15-20% enrollment, not 100%, and pulled systematically from the EHR, not manual chart review), decide the staffing model (in-house vs outsourced vs hybrid), design the enrollment workflow, then pick software, then pilot before scaling. Skipping straight to software or a full-population launch is the most common reason programs underperform their revenue projections later, usually tracing to documentation burden, billing logic living outside the clinical workflow, or shallow EHR integration.
Most CCM Launch Advice Gets the Order Wrong
Most “how to start a CCM program” content leads with billing codes and software features. That’s not where the actual decisions start. The sequence that determines whether a program succeeds runs through population sizing, staffing model, and workflow design first, with software and billing as the execution layer that follows those decisions, not the starting point.
Step One: Size the Real Opportunity, Not the Theoretical One
Before anything else, quantify how many patients in your population are genuinely eligible (two or more chronic conditions, 12-month duration) and apply a realistic enrollment assumption, 15-20% of eligible patients even in a well-run program, not the full eligible count. Population targeting for a care-management program is a real methodology, not guesswork; AHRQ’s own guidance on selecting and targeting populations is worth reviewing before defaulting to whatever definition happens to be easiest to query. And the sizing step needs to run through the EHR systematically, not a manual chart review, because manual identification consistently underestimates the true qualifying population, leaving real eligible patients undiscovered before the program even launches. A hospital that assumes 100% of eligible patients will enroll is building a business case that will disappoint everyone six months in.
Step Two: Decide the Staffing Model
CCM can run nurse-led in-house, fully outsourced to a care-management vendor, or as a hybrid where technology handles identification and documentation while staff (in-house or contracted) handle the actual patient conversations. Each model has real cost and control trade-offs: in-house gives full control over patient relationships and care continuity at higher fixed staffing cost; outsourced reduces staffing burden but hands off the direct patient relationship; hybrid tries to capture both, with more coordination overhead between the technology layer and whoever’s actually making the calls.
Step Three: Design the Enrollment Workflow Before Building or Buying Software
Decide how patients get identified (EHR query criteria), who does outreach, how consent gets captured and documented, and how the qualifying initiating visit gets sequenced before CCM billing starts. This workflow design should happen before selecting software, not after, because a platform chosen without a clear workflow in mind often turns out to be a poor fit once the real operational sequence becomes clear.
Step Four: Choose the Software, Now That You Know What It Needs to Do
With population size, staffing model, and workflow decided, the build-vs-buy and platform-selection decision becomes much more concrete. A single-specialty practice with straightforward workflow needs may do fine with an off-the-shelf platform. An organization running CCM alongside RPM, PCM, or BHI concurrently, or spanning multiple EHRs, is more likely to need custom-built depth; the fuller build-vs-buy decision is its own analysis, not something to re-derive here.
Step Five: Launch Small, Then Scale
Most successful CCM launches start with a pilot cohort, one department, one physician panel, or a few hundred patients, rather than a full-population rollout on day one. This surfaces workflow gaps (a consent script that doesn’t land well with patients, a time-logging step coordinators skip under pressure) at a scale where they’re cheap to fix, before they’re baked into a program running against your entire eligible population. One gap that a pilot should specifically surface, and that most launch plans skip entirely: patient churn. A launch plan built around initial enrollment numbers alone, with no plan for the share of enrolled patients who’ll disenroll or go quiet within the first few months, is measuring the wrong thing. A pilot cohort is exactly where that churn rate should get measured for the first time, before it’s baked into a revenue projection built on a full-population rollout.
See How We Help Launch Successful CCM Programs
What a Realistic Timeline Looks Like
Population sizing and staffing model decisions typically take two to four weeks if the underlying EHR data is accessible. Workflow design and software selection or build scoping add another four to eight weeks, more for a custom build than an off-the-shelf selection. A pilot cohort running for 60 to 90 days before full-scale rollout is a reasonable, unrushed timeline; compressing this to hit an arbitrary launch date is one of the more common reasons early-stage CCM programs underperform their revenue projections. Where that underperformance actually traces to, once a program is past launch, tends to be one of three specific things: a documentation burden that quietly eats coordinator capacity, billing logic that lives in a separate system from the clinical workflow instead of inside it, and EHR integration that’s shallow enough to connect but not deep enough to actually reduce the manual work. A timeline that skips the workflow-design step to launch faster is the timeline most likely to hit exactly these three problems six months in.
How Mindbowser Approaches This
We work through this sequence with organizations launching a CCM program: real population sizing against EHR data, staffing model trade-off analysis, workflow design before any platform decision, and a pilot-first rollout plan. Where a custom platform is the right call given the population’s complexity, we build it around the workflow that’s already been designed, not the other way around.
Conclusion
The correct build order is population sizing → staffing model → workflow design → software selection → pilot → scale. Most published advice starts at software/billing, which is the wrong end. Realistic enrollment is 15–20% of eligible patients, even in a well-run program, not the full eligible count. Manual chart review underestimates the eligible population, so sizing needs to run through the EHR systematically. Workflow design (identification, outreach, consent capture, initiating-visit sequencing) has to happen before software gets picked, or the platform ends up a poor fit.
The staffing trade-off remains clear: in-house = full control, higher fixed cost; outsourced = lower staffing burden, no direct patient relationship; hybrid = both, more coordination overhead. Pilot first (one department, one panel, a few hundred patients), and it’s where patient churn should get measured for the first time, before it’s baked into a revenue projection. A realistic timeline is 2–4 weeks (population/staffing) + 4–8 weeks (workflow/software scoping) + 60–90 day pilot before full rollout. Finally, watch for the three named causes of post-launch underperformance: documentation burden eating coordinator time, billing logic living separately from clinical workflow, and EHR integration too shallow to reduce manual work.
A realistic timeline runs population sizing and staffing decisions (2-4 weeks), workflow design and software selection or build scoping (4-8 weeks), and a 60-90 day pilot before full rollout. Compressing this timeline is a common cause of underperforming early results.
After. Choosing a platform before deciding how patients will be identified, enrolled, and staffed frequently results in a mismatch discovered only after the platform is already in use.
15-20% of the technically eligible population, even in a well-run program. Business cases built on higher assumptions tend to disappoint within the first several months.
No. A pilot cohort (one department, one panel, a few hundred patients) surfaces workflow problems cheaply before they’re built into a program running at full scale.
Most trace to one of three causes once they’re past launch: a documentation burden that eats coordinator capacity, billing logic living separately from the clinical workflow instead of inside it, and EHR integration too shallow to actually reduce manual work. Patient churn compounds all three, since a program that isn’t measuring disenrollment is measuring an incomplete picture from the start.









BLOGS
NEWSROOM
CASE STUDIES
WEBINARS
PODCASTS
ASSET HUB
EVENT CALENDAR 


















