A CCM platform is the software a practice or care management team uses to run chronic care management each month: finding eligible patients, recording consent, keeping the electronic care plan, logging staff time and producing the billing data for each patient month.
This guide is about building that software. It covers the modules a platform needs, how consent and care plans should be modelled, how a time ledger turns minutes into codes, how billing data reaches the EHR, and where new platforms break at their first month-end close.
What is a CCM platform?
Building chronic care management software?
Agnotic builds care management and virtual care platforms for the client, including consent capture, care plans, time ledgers and EHR billing exports.
A CCM platform is software that runs a Medicare chronic care management program between visits. It enrolls eligible patients, records their consent, holds a patient-centered electronic care plan, logs care team minutes by activity and staff member, and turns each patient month into billing data the practice can submit under the billing practitioner.
The platform does not decide what to bill. The practice's billing and compliance team sets the rules; the software applies them the same way every month and keeps the evidence behind each code.
Most platforms sit beside the EHR rather than inside it. Care managers work a queue in the platform, while the chart, the problem list and the claim stay in the EHR, so the integration design matters as much as the screens.
Which modules does a CCM platform need?
A working CCM platform needs seven modules, and billing is only one of them. This list doubles as a scope checklist for a first release.
- Eligibility registry: Pulls problem lists and recent visits from the EHR, flags patients with two or more qualifying chronic conditions, and records who confirmed eligibility.
- Consent record: Stores what the patient was told, how they agreed, who recorded it and when, plus any later withdrawal.
- Care plan: A structured, versioned plan with problems, goals, interventions and medications, shared with the patient.
- Care manager worklist: Shows who is due for outreach this month, who is short of a time threshold, and who has open tasks.
- Time ledger: Records each activity with staff member, role, start and stop time, and the care plan item it served.
- Month-end close: Applies the code rules, holds patients with gaps for review, and locks the month after sign-off.
- EHR exchange: Reads clinical data in, and writes notes, care plan updates and charges back through the interfaces the site allows.
Teams that build the time ledger first often rebuild the data model later, because time entries have nothing to attach to until consent and the care plan exist as records.
How should consent capture work?
Consent capture should create a structured record before any billable time is logged, and the platform should block time entry until it exists. The CMS chronic care management booklet (MLN909188) says the patient must be told about the service, that cost sharing may apply and that they can stop at any time, and that the consent must be documented in the medical record.
Consent can be verbal, so the platform cannot depend on a signature. It needs an approved script, a field for who obtained consent and by what method, and the date.
- Disclosure items: Which points were explained, checked against the practice's approved script version.
- Method: In person, by phone or through a portal message, with the staff member who recorded it.
- Billing practitioner: The practitioner who will bill, so the registry can check that no other practice is already running CCM for the patient.
- Withdrawal: Date and reason when the patient stops, which ends time logging from that date.
Keep the consent record and the script version together. When an auditor asks what the patient was told, the answer should take one lookup, not a search through call notes.
Designing the care plan record
The care plan should be a structured, versioned record, not a free-text note. A useful plan holds the problem list, the expected outcome for each problem, measurable goals, planned interventions, medications, and the other clinicians and community services involved.
Give each element its own field rather than one large text box. Empty fields show care managers what is missing at a glance, and structured goals let the worklist surface patients whose targets have not been reviewed recently.
Keep the plan readable by the patient as well as the care team. Goals written in plain language, such as walking for twenty minutes most days, make outreach calls easier than goals written only as clinical codes.
In HL7 FHIR terms, the plan maps to a CarePlan that references Condition resources for problems, Goal resources for targets, and Tasks or request resources for interventions. Even when the platform keeps its own schema, holding that mapping makes later exchange with the EHR much simpler.
Version every change with its author and reason. Complex CCM depends on a substantial revision of the care plan, so the platform must show when a substantial revision happened and who made it.
The patient also gets a copy of the plan. A portal view or a printable version generated from the same record avoids a second document that drifts away from the first.
How does the time ledger turn minutes into codes?
The time ledger turns minutes into codes by totalling qualifying time per patient per calendar month, split by who did the work, and then applying the code thresholds the practice has configured.
- 99490 and 99439: Clinical staff time directed by the physician or other qualified health professional, 20 minutes for the first code and each additional 20 minutes for the add-on.
- 99491 and 99437: Time the physician or qualified health professional spends personally, 30 minutes for the first code and each additional 30 minutes.
- 99487 and 99489: Complex CCM, 60 minutes of clinical staff time for the first code and each additional 30 minutes, with the complexity conditions met.
- Related code sets: Principal care management for a single high-risk condition and Advanced Primary Care Management are configured as separate rule sets with their own thresholds and conflicts.
The split by role is why a single minutes field fails. Staff minutes and practitioner minutes count toward different codes, and the same minute cannot count twice.
Concurrent services need the same care. The CY 2024 Physician Fee Schedule final rule restates that remote physiologic monitoring or remote therapeutic monitoring, but not both, can be billed with CCM for the same patient when time and effort are not counted twice. A platform that also runs RPM must tag every minute to one service.
Close the month in two passes: a draft run late in the month that lists patients near a threshold while there is still time to reach them, and a final run after the month ends that locks the entries. Any later edit should reopen the month with a recorded reason.
Billing exports and EHR write-back
The platform should hand billing data to the EHR or billing system rather than submit claims itself, unless the client is set up to submit claims. The claim goes out under the billing practitioner, so the practice's own charge review should see it first.
- Charge feed: An HL7 v2 DFT^P03 message, or a file the billing team imports, carrying patient, code, date of service, billing practitioner and minutes.
- Monthly summary note: A signed note in the chart listing the activities and time behind each code, filed through the EHR's document interface or write API.
- Care plan sync: The current plan filed as a document or, where the EHR supports it, as structured CarePlan data.
- Audit export: For each patient month, the consent record, time entries, notes and the code billed, ready for a compliance review.
Plan reads and writes separately. Standard FHIR read access feeds the eligibility registry well, but filing notes and charges usually needs the EHR vendor's write APIs or HL7 v2 interfaces, and each site decides which of those it will enable.
Where CCM software breaks at the first month-end
New CCM platforms tend to break at the first month-end close, when the data model meets real billing rules. Test these failure points with sample patient months before go-live.
- Time with no activity: Minutes logged without a linked care plan item or note cannot be defended in an audit.
- Wrong role on entries: Practitioner and staff time mixed together, so codes are chosen from the wrong family.
- Consent after time: Entries dated before the consent record. The platform should block them, not flag them later.
- Two billers: A specialist and a primary care practice both enroll the patient. The registry needs a field for the agreed billing practitioner and a check before outreach starts.
- Month boundaries in the wrong zone: Calls late on the last day of the month land in the next month when timestamps are stored without a time zone.
- Closed months edited silently: Corrections after the close change totals that were already billed.
- Double-counted RPM time: The same call logged to CCM and to RPM treatment management.
Most of these cost less to prevent with validation rules at entry than to find in a month-end report.
How Agnotic can help
A CCM program depends on software that keeps consent, care plans and minutes consistent every month. Agnotic Technologies builds CCM platforms for practices, care management companies and digital health teams, with the eligibility registry, consent records, versioned care plans, a role-aware time ledger and the month-end close.
Agnotic also builds the EHR side: problem lists and visits read in through FHIR, and summary notes, care plans and charges written back through the interfaces each site approves. Your billing team sets the rules, and the platform applies them.
Build your CCM platform with Agnotic
Explore telemedicine and care platform development, or browse more remote care guides.
Related reading on Agnotic
Continue with CCM billing, CCM outsourcing, PCM billing codes, care pathways and running an RPM program.
