Medicare Care Program Stacking Rules: Which Bills Together

What Never Stacks, What Only Looks Like It, and the Reason That Predicts the Next Rule

The same practitioner cannot bill CCM and PCM for one patient in one calendar month. A different practitioner can, and that distinction is worth more than it sounds.

CMS answers this one directly. A primary care practitioner may offer chronic care management while a specialist offers principal care management for the same patient in the same month, provided the conditions being managed are different and each program carries its own care plan. The PCM care plan need only be disease-specific. CMS’s own framing of the question is whether the two can be billed for the same practice in a multispecialty group with a PCP and a specialist, and the answer is yes.

So this is a rule about who is billing, not about whether the patient qualifies. Read it as an eligibility exclusion and a specialist declines an enrollment that was available all along.

Three exclusions matter most, and only one of them is flat.

CCM and PCM, same practitioner. Not an eligibility conflict. The restriction reaches the practitioner, and the second-practitioner route is expressly open, per the CMS chronic care management FAQs citing the CY2020 Physician Fee Schedule final rule at 84 FR 62697. CMS adds a related rule inside CCM itself: non-complex and complex CCM cannot both be reported for the same patient in the same calendar month, so 99491 and 99437 do not run alongside 99487, 99489, 99490 or 99439. That one is a genuine intra-program exclusion, and keeping the two straight is a standing requirement of any chronic care management software that enrolls patients on more than one pathway.

CCM and APCM. APCM replaces CCM’s billing structure for a given patient rather than running beside it. APCM pays a monthly amount tiered by patient complexity instead of accumulating billable minutes, which is the whole design intent, and running both would reintroduce the time-threshold model APCM was built to remove.

RPM and RTM. Same billing category, as covered above.

One of those three is a flat never. The other two turn on who is billing, and the same practitioner is the party the rule reaches in both. All three are plausible mistakes for a team working from memory, and they concentrate at a predictable moment: the transition. A patient moving from CCM onto APCM mid-quarter, or out of a TCM window into ongoing PCM, is where the check that ran at enrollment and never ran again produces a claim nobody re-examined.

RTM: The Program Missing From Every Page on This Search

Remote therapeutic monitoring is the program most likely to be absent from whatever reference a practice is using. It is absent from every page currently ranking for this question, which makes it the combination least likely to have been checked before it was billed.

RTM monitors non-physiologic data: musculoskeletal and respiratory system status, treatment adherence, and treatment response. It does not require an established patient relationship, which makes it available for post-surgical referrals on day one. It can run alongside CCM, TCM, BHI/CoCM, and PCM. It cannot run alongside RPM, because both sit in the same CMS billing category: remote monitoring services. That is the decision rule, not the data type. If a team is reasoning from “RPM and RTM monitor different signals so they must stack,” they will get that cell wrong every time.

The remote patient monitoring billing guide covers the RPM code set and rates. The RTM versus RPM guide compares the two programs and advises which to build first.

FQHCs and RHCs: Same Patient, Different Answer

The stacking answer changes by setting, and this is the rule least likely to appear on a vendor page.

Federally qualified health centers (FQHCs) and rural health clinics (RHCs) can bill CCM and TCM for the same patient during the same period. CMS states it as its own line in MLN909188, separate from the general concurrency rules, because it is a setting-specific permission rather than a variation of one.

There is a second FQHC and RHC change worth stating in the present tense, because it is often still written as upcoming. Since July 1, 2025, the individual care management codes are required and G0511, the general care management code these settings previously billed, is no longer reimbursable. The transition window opened January 1, 2025, and flexibility during it applied at facility level, not patient level. That deadline has passed. FQHCs and RHCs now bill the standard CCM, PCM, BHI and APCM codes, with add-on codes available for additional time.

The ACCESS Model Override

This is not a stacking rule. It is an override, and it is 1 month old at the time of writing, which means most published tables have not caught up to it.

The CMS ACCESS Model, Advancing Chronic Care with Effective, Scalable Solutions, began its first cohort on July 5, 2026. It is a 10-year voluntary model that pays for technology-enabled chronic care in traditional fee-for-service (FFS) Medicare on outcome attainment rather than on billed services.

The consequence for everything above is blunt. ACCESS participants and their affiliated entities may not submit Medicare FFS claims for aligned beneficiaries during active care periods. Not “these programs conflict.” CCM, PCM, TCM, BHI, RPM and RTM stop being billable for that patient by that participant, for the duration.

Two details decide how far the exclusion reaches. Affiliation is defined broadly: any 5% or greater ownership interest, operational or managerial control relationships, and Medicare reassignment relationships, per Jones Day’s March 2026 analysis of the model. And the exclusion attaches to the participant, not to the patient, so a different provider with no affiliation can still bill fee-for-service for the same beneficiary.

On the payment side, the model pays $90 to $420 per aligned beneficiary per year, with 50% distributed in equal monthly installments and 50% withheld until year end, recoverable in full if at least half of a participant’s beneficiaries meet the clinical outcome target. It opened with 4 clinical tracks covering common chronic conditions.

For an organization weighing participation, this is the number that matters more than any single code rate: joining ACCESS for part of a panel changes the revenue model for every other program on this table, for that subset of patients only, which means the panel now has 2 billing regimes running side by side and a flag deciding which patient falls under which.

Why This Matrix Is Not Complete, and Cannot Be

Every stacking table published anywhere, including this one, is incomplete, and CMS says so in the same document that supplies the rules.

MLN909188 closes its concurrency section by directing readers to consult CPT instructions for other codes that cannot be billed concurrently, and warns that further restrictions may apply under a CMS-sponsored model or demonstration. It adds that CMS will not duplicate payments for the same or similar services already paid under a demonstration initiative.

Two consequences follow, and neither is a hedge.

Restrictions live outside the pairwise grid. CCM cannot be billed during the same service period as G0181 or G0182, the home health and hospice care supervision codes, or alongside certain end-stage renal disease services in the 90951 to 90970 range. Complex CCM cannot be reported in the same calendar month as prolonged evaluation and management services. None of those are program-to-program pairings, so a 7 by 7 grid structurally cannot show them.

And the table has a shelf life. The Physician Fee Schedule is proposed in summer and finalized in November, and code families, thresholds and rates move with it. A stacking reference that carries no version stamp is telling you something about how it is maintained.

Before billing a combination this page does not list, the sequence is: check the CPT instructions for both codes, check whether the patient is aligned to any CMS model or demonstration, and check whether either code family changed in the most recent final rule.

Why a Single Reimbursement Number Is Always Wrong

Published reimbursement figures for these programs disagree with each other, often by 20% to 30% on the same code, and the disagreement is not a matter of one source being wrong.

Take TCM. Vendor pages currently ranking for transitional care management quote roughly $205 and $278 for 99495 and 99496. Others quote $176.50 and $236.77. Fee schedule aggregators list roughly $220 and $298.60 for CY2026 non-facility, and roughly $166.34 for 99496 in a facility setting. Every one of those can be defensible and none of them is usable, because in each case the year and the place of service have been collapsed into a single number and then presented as the rate.

A Medicare rate is only meaningful with 3 things attached: the year, whether the setting is facility or non-facility, and the acknowledgment that the published figure is a national average that varies by locality. The 2026 conversion factor rose between 3.26% for non-qualifying-participant clinicians and 3.77% for qualifying participants, so even a correctly-specified 2025 figure is already off.

For that reason this page does not publish a rate table. The CMS Physician Fee Schedule Look-Up Tool returns the number for a specific code, year, setting and locality, and it is the only source that should ever settle a reimbursement question. A vendor blog, including this one, is not.

What legitimate stacking is worth per patient is a separate question with a real answer, and it is worked through in detail in the revenue math for stacked programs rather than repeated here. For the single-program version of the same arithmetic, the Medicare CCM reimbursement guide carries it code by code.

Where the Software Breaks: One Time Field, 7 Programs

Everything above is the rule set. If you are the one building the software that has to enforce it, the next two sections are yours.

The failure I see most often is a single care management time field. One patient record, one accumulating counter, and a report at month end. It is the obvious data model, it satisfies the people asking for a time total, and it cannot survive the rule this page opened with.

What makes it dangerous is that nothing about it looks broken. The total reconciles. The claim goes out. Denials do not spike, because a payer cannot see attribution from a claim line either. The gap only becomes visible when someone asks which minutes justified which code on which date, and at that point the honest answer is that the system never stored it. The work happened. The evidence did not.

There is a second failure that costs money in the other direction, and it is the mirror image. Your customers are almost certainly under-enrolling. A patient who qualifies for a second program nobody enrolled them in is invisible by definition, and the discharge-month CCM permission at the top of this page is the clearest example: it never generates an error, only an absence. Software that only prevents wrong claims is doing half the job.

The third is timing. Eligibility gets checked at enrollment, once, and then the patient moves. They start a monitoring program, they get discharged, they cross onto APCM. Each of those transitions changes which combinations are legal, and a check that ran in March has nothing to say about it in September. And as of this year there is a fourth state to carry: whether the patient is aligned to an ACCESS participant at all, which retroactively invalidates fee-for-service claims that were correct under every other rule.

What a Stacking Engine Actually Has to Do

Five requirements, each traceable to a rule above rather than to a feature list.

1. Per-program time ledgers with per-activity attribution. Not one counter with a category label. Each logged activity belongs to exactly one program, and the system can reconstruct that assignment later. This is the direct expression of the no-double-counting rule.
2. Eligibility evaluated at enrollment and again at every transition. Discharge, program change, monitoring start or stop, complexity change. A one-time check cannot catch errors that only exist at transitions.
3. A rules layer versioned by CMS year. The Physician Fee Schedule moves every November. Rules encoded as conditionals inside application logic have to be found and rewritten each cycle; rules held as versioned data can be updated and, more usefully, replayed against a prior year when a claim from that year is questioned.
4. An ACCESS alignment flag that suppresses fee-for-service claims. Patient-level, participant-aware, and able to distinguish an affiliated entity from an unaffiliated one, because the exclusion follows affiliation rather than the patient.
5. An audit trail built for reconstruction. The question is never “what was the total.” It is “which minutes, to which code, on which date, documented by whom.”

Worth being straight about where this sits in a build. Getting clinical and encounter data out of the electronic health record and into a workflow layer is well-travelled ground, and ConnectHealth, our integration platform, covers that part with pre-built connectivity. The stacking engine on top of it is not that. It is a versioned policy engine with per-patient state, and no packaged component covers it, so it is a custom build. Anyone offering to demonstrate concurrent-billing enforcement out of the box is describing a roadmap.

That is also why the useful first conversation is about your program mix and your data model rather than about a product. If your platform enrolls patients into more than one Medicare care program, the questions worth answering are whether your time model can survive a records request, and whether you can name the patients who qualify for a program they are not in.

Where the engine gets built depends on what already exists. Teams extending a working single-program system usually add the rules layer beside it, which is the path most custom chronic care management software work takes. Teams coordinating across departments that each own a program are solving a different problem first, closer to continuity of care, where the stacking rules become one component of a wider coordination layer rather than the whole build.