How to evaluate a care management platform for ACOs and MSOs

By Gautamdev Chowdary, co-founder and CTO, Zynix AI · Updated October 9, 2026

Key takeaways

Evaluate a care management platform for ACOs and MSOs on six things: one patient record from claims, ADT feeds and every practice’s EHR; risk flags a clinician can check; care plans with an owner for each step; outreach inside rules clinicians approve; CMS rules for TCM, CCM and AWV; and security documents. Then check implementation needs, terms and references.

Ask every vendor to show the work on synthetic or de-identified data, and share no PHI before a BAA is signed.
Interfaces differ by EHR version and configuration, so get a written integration plan for each practice before you compare prices.
Clinicians make the clinical decisions, and CMS requires the TCM interactive contact to be made by the billing practitioner or clinical staff under their direction.
Ask for the SOC 2 Type II audit report itself and a BAA you can review, not a badge on a website.
Give every vendor the same demo script, so their answers can be compared.

Vendor roundups rank products. A ranking doesn’t tell an ACO or MSO much, because the right platform depends on who is attributed to you, how many EHRs your practices run and which program you need to get right first.

This guide doesn’t rank or compare vendors. It is written for teams that will run care management across multiple EHRs, claims feeds and hospital ADT notifications. For each area you get the questions to ask, what a good answer includes and the red flags, then a demo script, a master checklist and a simple scoring rubric to use with every vendor.

Start with the platform type and your first workflow

Most options for this work fall into a few types, and each covers a different part of it. Knowing the type tells you which questions matter most.

Platform type	What it often centers on	What to check
EHR-native care management modules	Care management tools inside an EHR, for the practices and staff who use it	How practices on other EHRs, outside claims data and hospital ADT notifications are handled
Population health analytics suites	Claims, attribution, registries and quality reporting	Who does the work after the list is built, and where that work is tracked
Point outreach and answering tools	Calls, texts, reminders or after-hours answering	How they connect to the patient record, the care plan and clinical escalation
Combined platforms (data, prediction, care plans and outreach together)	Several of these functions in one product (Zynix describes its own platform this way)	The depth of each part, not only the breadth of the feature list
Outsourced care management services	Staff who run calls and programs for you under contract	Whose protocols they follow, how their work reaches your record, and what you keep if you leave
Building on your own data warehouse	Your own team’s data, reporting and workflow tools	Who maintains the feeds, the patient matching and the workflow layer, and who staffs the outreach

Then pick one first workflow and evaluate every vendor against it. Good candidates are transitional care management (TCM) for patients discharged from connected hospitals, annual wellness visits (AWV) or chronic care management (CCM). One workflow shown end to end tells you more than any feature list.

How to run the evaluation: who checks what

Name a small evaluation team, send every vendor the same questions in writing before demos, and run security review alongside the demos rather than after you pick. Each person on the team owns part of the checklist.

Care management lead: workflow fit, staffing and what the team would stop doing.
Clinical lead: escalation rules, scripts and who makes each clinical decision.
Data or IT lead: claims and ADT feeds, and the integration plan for each practice’s EHR.
Compliance or privacy officer: the BAA, the SOC 2 Type II audit report and the consent approach for calls and texts.
Finance: pricing against your attribution and practice count.

Ask for written answers to the questions in this guide before the first demo. Give every vendor the same scripted scenario (see the demo script near the end of this guide), so you compare like with like. Use synthetic or properly de-identified data for demos; if any sample includes PHI, sign a BAA first. Finish with reference calls, then score each vendor with the rubric at the end.

Data onboarding: claims, ADT and EHR feeds

A care management platform is only as good as the patient record it works from, so test data onboarding first. Ask which sources it takes, how often each one arrives, and how records are matched and checked before anyone works a list.

Medicare claims data for ACOs comes with its own rules, and each rule turns into a question for the vendor.

Source or rule	What CMS says	What to ask the vendor
CCLF files	Available monthly, and can be downloaded weekly on request. CMS lists CCLF for the Shared Savings Program, ACO REACH and Kidney Care Choices, among other models.	Which cadence do you load, and how soon do new files reach worklists?
BCDA	In v3, the Beneficiary Claims Data API updates adjudicated Part A and Part B claims weekly, Part D claims six times a week and partially adjudicated claims four to five times a week, for those programs among others. CMS suggests cross-referencing BCDA with CCLF to identify discrepancies. The v1 and v2 endpoints will be disabled on July 30, 2027.	Do you use BCDA v3 today, and how do you reconcile BCDA with CCLF?
Data access	For Shared Savings Program ACOs, the regulation requires a signed data use agreement (DUA) and a formal data request (42 CFR 425.704).	Who on our side signs and requests, and what do you need from us?
MBI changes	A beneficiary’s Medicare Beneficiary Identifier (MBI) can change over time. The CCLF9 cross-reference file links current and previous MBIs.	How do MBI changes and duplicate records flow into patient matching?
Claims run-out	Shared Savings Program and ACO REACH ACOs receive CCLFs for a three-month claims run-out period after each performance year.	How does run-out data change reports and work already closed?
Opt-outs and substance use data	Shared Savings Program beneficiaries can decline claims data sharing (42 CFR 425.708). CMS’s CCLF documentation says Shared Savings Program, ACO REACH and Kidney Care Choices beneficiaries are always opted out of substance abuse data sharing, so expect those claims or codes to be missing from the files.	How do opt-outs and missing claims show up in worklists and risk flags?

Plan for the program calendar too. CMS says its LEAD Model, the successor to ACO REACH, launches after REACH concludes at the end of 2026 and runs from January 1, 2027, through December 31, 2036. Ask how the vendor will take in LEAD data.

Hospital ADT notifications are the other half. Under CMS’s Conditions of Participation, a hospital whose electronic system conforms to the rule’s content exchange standard must make a reasonable effort to send admission, discharge and transfer notifications to the patient’s established primary care practitioner or practice group, among others. Hospitals may work through an intermediary such as a health information exchange (HIE), may group notifications for daily delivery if the recipient prefers, and may send HL7 messages, C-CDA summary care records or use a FHIR-based API. ADT coverage is decided hospital by hospital, so ask for the list.

Data onboarding questions

Which claims sources do you take: CCLF, BCDA (and which version), payer claims extracts, member rosters and eligibility files? Some arrive as X12 transactions, many as custom flat files.
Which hospitals send ADT notifications today, and does each one come direct or through an HIE or other intermediary?
How long after an ADT notification arrives does a task reach a named owner, and what happens to discharges on a Friday night or a weekend?
What do you read from each practice’s EHR: problem list, medications, last visit, scheduling?
How are patients matched across sources (name, date of birth, MBI or MRN, address), and how are duplicates resolved?
How do quarterly attribution changes flow into worklists?
How are matched records checked with our team before any worklist goes live?

What a good answer includes: a source-by-source list with how often each feed refreshes, a named owner for each feed, the hospitals sending ADT listed by name, and a validation step where your team reviews matched records before outreach starts.

Red flags: “we take any file” with no mapping or validation plan; no answer on MBI changes or claims run-out; ADT coverage claimed without naming the hospitals.

If you run several payer contracts

Many MSOs and ACOs also hold Medicare Advantage or commercial contracts, each with its own roster, attribution and measures. If you do, add these questions:

How do each contract’s roster, attribution and program rules stay separate while staff work one worklist?
How are payer gap lists reconciled against claims and EHR data before anyone is contacted?
Can we report each contract on its own denominators?

Care management across multiple EHRs: every practice is its own integration

In an ACO or MSO, each practice’s EHR, version and configuration is a separate integration. Ask for the plan practice by practice, not a page of logos.

Interfaces vary by EHR version and configuration, so two practices on the same EHR can still need different work. That is why each EHR connection should be confirmed by version and configuration during scoping. What the care team needs on top of all those connections is one patient record and one worklist across practices, filtered by practice.

Illustrative example: an MSO runs one TCM program across independent practices. One practice uses eClinicalWorks and the next uses athenahealth. Discharges for both should land in the same worklist, the follow-up visit should be booked at the patient’s own practice, and the network office should see the work for both in one place. This is the everyday case for MSOs and IPAs running one program across independent practices, so ask each vendor to walk through it, including who sets up each connection.

Multi-EHR questions

For each practice: which EHR, which version, which interface method and what data do you read?
Who owns each step: our IT team, the EHR vendor or your integration team?
What, if anything, is filed into each EHR, by whom and in what form? Ask the vendor to name the EHRs and the document types.
How does scheduling work when the visit should be booked at the patient’s own practice?
What happens when a practice upgrades or changes its EHR?

What a good answer includes: a written integration matrix (practice, EHR, version, method, data read, owner), a validation step for each connection, and one worklist across practices that you can filter by practice.

Red flags: “we integrate with every EHR” with no version-level detail; claims that results are filed into your EHRs with no EHR or document type named; a separate login and worklist for each practice.

Risk and gap identification: can a clinician see why?

Ask what each model predicts, from which data, how each flag is explained and what it sets in motion. A score without reasons is hard for a clinician to trust or to check.

A prediction is useful only if it changes what someone does next, so each one should map to a defined step, such as a post-discharge care plan or a review for chronic care management. Operational steps, like a care-plan task or a call to book a visit, can start from a prediction inside programs and scripts your clinical leadership approved. Clinical action stays with a clinician who has reviewed the drivers. Mortality predictions need particular care: they should only prompt a clinician-led serious-illness conversation, never an automated action.

Two public frameworks help structure the questions. ONC’s HTI-1 rule lists source attributes meant to help organizations judge whether a predictive tool is fair, appropriate, valid, effective and safe (FAVES), and NIST’s voluntary AI Risk Management Framework organizes the work into four functions: govern, map, measure and manage. Both are useful buyer frameworks for any predictive tool, whether or not HTI-1’s developer requirements apply to the vendor.

Questions about predictions

What does each model predict (for example readmission, mortality, disease progression or utilization), and what next step does each prediction start?
When is each prediction made (at admission, at discharge, monthly), and how long until a flag reaches an owner?
Which drivers are shown for each patient, and can a clinician see the data behind them?
Which steps start automatically from a prediction, which wait for a clinician, and who set that rule?
How was the model validated, and how will you check it on our population, including how it performs across patient groups and over time?
Who can dismiss a flag, and how are false positives recorded?
How are care gaps checked against claims, clinical and lab data before outreach, so patients who already had the service aren’t contacted?
Where does risk adjustment documentation work fit, and does the treating clinician assess and document every condition at a visit?

What a good answer includes: named predictions, the drivers behind every flag, a plan to check the model on your own patients, clinician review before any clinical action, and operational steps a prediction starts (a care-plan task, an outreach call to book a visit) that run only inside the programs, scripts and escalation rules your clinical leadership approved.

Red flags: a score with no drivers; accuracy claims that can’t be reproduced on your data; predictions that change the clinical content of a care plan or prompt clinical action with no clinician review; outreach that runs outside approved programs and scripts.

Care plans: does every step have an owner?

A list is not a program. The platform should open a care plan with sequenced steps, an owner and a deadline for each step, escalation by rule when a step is missed, and close the plan only when the work is documented.

Without that, follow-up tends to live in spreadsheets, inboxes and memory, and nobody can say which discharges are still open. Ask to see a care plan for the workflow you picked, from the trigger to the documented close.

Care plan questions

Which plan templates exist (TCM, CCM, AWV, gap closure), and who configures the steps, owners, timing and escalation rules?
What happens when a step is missed or a patient can’t be reached?
Who can change the clinical content of a plan?
Do staff work in the tools they already use, or in a separate application?
What closes a plan or a gap: a documented visit or result, or a call attempt?
Can we see every open plan by practice, owner and due date?

What a good answer includes: templates your team configures and owns, escalation by rule to a named role, and closure only on a documented visit or result.

Red flags: plans that close on outreach alone; tasks with no owner; escalation that is only an email.

Outreach: voice and text agents, consent and after-hours

Automated outreach helps only inside rules your clinical team approves, with clinical questions handed to a person. Ask who writes the rules, how a patient reaches a human, and what happens with symptoms, emergencies and opt-outs.

Outreach questions

Who writes and approves scripts, outreach hours and escalation thresholds?
Does the agent say it is automated, and how does a patient reach a person?
How does the agent verify it is speaking with the patient or an authorized caregiver before discussing health information?
What is left in a voicemail or a text, and what is held back?
How are consent, contact preferences and opt-outs recorded and honored? Have your counsel review your consent approach for calls and texts.
How are symptom questions routed to the on-call clinician, and are callers who describe an emergency told to call 911?
How are after-hours calls handled, and what reaches the care team the next morning?
Which languages are supported? Ask for the list.
What happens when a patient doesn’t answer: how many attempts, on which channels, and when does a staff member take over?
Is what the patient said recorded for the care team to read?

What a good answer includes: scripts and hours your clinical leadership approves, identity checks before any health information is discussed, symptom questions routed to a clinician by rule, a documented opt-out process, and a record of each conversation for the care team.

Red flags: agents described as triaging, giving clinical advice or changing care plans; no documented opt-out handling; no record of what the patient said.

Human review and clinical governance: who decides what

Write down who owns each decision before go-live. Software can identify, rank, route, remind, book and draft inside rules your team sets; clinicians make the clinical decisions.

Decision	Who should own it
Which programs to run and who is eligible	Program and clinical leadership
Which predictions open a plan or start outreach	Clinical leadership, by rule
Scripts, outreach hours and escalation thresholds	Clinical leadership approves them
A patient’s symptom or clinical question	A licensed clinician, reached by rule
The TCM interactive contact	The billing practitioner or clinical staff under their direction (CMS)
Clinical action on a prediction	A clinician, after reviewing the drivers
Clinical notes drafted by software	The physician, who approves the note before it is filed or billed
Time counted toward CCM billing	The billing practitioner, after review
The closure rule	Set by the care team: a plan or gap closes only when the visit or result is documented

Ask the vendor to show where each of these decisions happens in the product and who can change the rule.

What a good answer includes: each decision shown in the product, with the role that owns it and the person allowed to change the rule.

Red flags: clinical rules set by the vendor; no named owner for escalations; marketing that says the software decides.

CMS program fit: TCM, CCM and AWV

Check the platform against the CMS rules for each program your practices bill. A workflow that misses a rule can cost the practice the claim.

TCM: the 30-day timeline

When	CMS rule	What the platform must support
Day of discharge	The 30-day TCM period starts on the day of discharge.	A plan opened from the discharge, with an owner
Within 2 business days	You, or clinical staff under your direction, contact the patient or caregiver by phone, email or face to face. The interactive contact is performed by clinical staff who can address status and needs beyond scheduling. If 2 or more separate, timely attempts fail, you may still report the service when the other requirements are met; document the attempts in the patient’s medical record and keep trying.	A contact task for clinical staff, a deadline that counts business days, and an attempt log
Within 7 or 14 calendar days	Face-to-face visit within 7 days (99496, high medical decision making) or 14 days (99495, at least moderate).	Booking inside the window, at the patient’s own practice
On or before the visit	Medication reconciliation and management.	A medication reconciliation task tied to the visit
End of the 30-day period	The TCM service period ends.	A plan that closes only when the visit is documented

At a minimum, CMS says to document the discharge date, the date of the first interactive contact, the face-to-face visit date and the level of medical decision making in the patient’s medical record. That raises a sharp question for every vendor: CMS says to document contact attempts in the patient’s medical record, so where does your attempt log live, and how does it reach the record the practice bills from?

If a central ACO or MSO care team does part of this work for practices that bill, check the supervision rules with compliance. CMS’s TCM booklet says auxiliary personnel may provide non-face-to-face TCM services under the general supervision of the physician or NPP, subject to applicable state law, scope of practice and the Medicare Physician Fee Schedule incident to rules. Confirm how the central team’s work is directed, documented and billed by the practice.

CCM and AWV

Program	CMS rule (summary)	What the platform must support
CCM (for example CPT 99490)	Two or more chronic conditions expected to last at least 12 months, or until death, that place the patient at significant risk. An initiating visit first, for new patients or patients not seen in the previous year (an E/M visit, AWV or IPPE where CCM is discussed). Written or verbal consent documented before billing, covering availability, cost-sharing, one billing practitioner per calendar month and the right to stop. An electronic comprehensive care plan, available promptly within and outside the practice. 24/7 access for urgent needs. Time-based codes such as 99490 (clinical staff, first 20 minutes).	Consent captured by staff, a care plan record, and time tracked per calendar month for the billing practitioner to review
AWV (HCPCS G0438, G0439)	G0438 for the first visit and G0439 for later ones, billable once in a 12-month period and not within 12 months of an initial preventive physical exam (IPPE, G0402). Includes a health risk assessment (HRA) that you or the patient can update before or during the visit. Advance care planning is optional, at the patient’s discretion.	An eligibility check against claims, HRA collection before the visit, and booking

Red flags: a workflow that counts an automated call as the TCM interactive contact (plan for clinical staff, as CMS defines them, to make it under the billing practitioner’s direction; we recommend licensed clinical staff); CCM time billed without practitioner review; AWV outreach to patients who already had one in the past 12 months.

Reporting: what you can see and prove

Reporting should show work and outcomes by practice and program, on denominators that follow attribution, and count a closure only when it is documented.

Attribution moves. For Shared Savings Program ACOs under preliminary prospective assignment, CMS updates assignment quarterly and says the beneficiaries on the quarterly lists may change each quarter, so a worklist or measure built once and left alone drifts.

Reporting questions

Can we report by practice, program, measure, payer contract and owner?
How do attribution changes affect denominators and open worklists?
Can we see spending and utilization by practice against our benchmark here, or does that stay in another tool?
Can we export row-level data to our own BI tools?
How do you propose to measure value against our own baseline?

What a good answer includes: row-level export, denominators that follow quarterly assignment, and closures counted only on documented visits or results.

Red flags: dashboards you can’t export; contacts made reported as outcomes; ROI claims not tied to your baseline.

Security and compliance evidence

Ask for documents, not badges: the SOC 2 Type II audit report, a business associate agreement (BAA) you can review, and written answers on HIPAA Security Rule safeguards and data use.

A SOC 2 audit report covers a service organization’s controls relevant to security, availability, processing integrity, confidentiality or privacy, and AICPA notes that customers often request one. Under 45 CFR 164.504(e), a BAA must set the permitted uses of protected health information (PHI), require safeguards, including the HIPAA Security Rule safeguards for electronic PHI (45 CFR Part 164, Subpart C), require breach reporting and flow the same terms to subcontractors.

Security questions

Can we read the full SOC 2 Type II audit report: the systems in scope, the period covered, any exceptions and any carved-out subservice organizations?
Will you share the BAA before contract, and which subcontractors handle PHI?
Is our data used to train models, and can we opt out?
Where is the data hosted?
Do you support single sign-on, and how often are user access reviews done?
Can we see the subprocessor list?
Are agent and user actions logged, and can we see the log?
What is your HITRUST status?

What a good answer includes: documents you can keep (the report itself, a BAA draft and written answers to each question above).

Red flags: badges or seals offered in place of the report; a summary letter instead of the full report; refusal to share a BAA before contract.

Implementation dependencies and scoping

Implementation depends on your data sources and scope, so judge vendors on how clearly they list what they need from you, not on a promised go-live date.

A signed DUA and CCLF or BCDA access
Payer claims, roster and eligibility files for your other contracts
The hospitals that send ADT notifications, and whether they send them direct or through an intermediary
Each practice’s EHR, version and interface owner
Scheduling access at each practice
Scripts, hours and escalation rules approved by clinical leadership
A signed BAA
Validation of matched patient records with your team before worklists go live
One first workflow, with more programs added one at a time

What a good answer includes: a written dependency list with an owner on each side, and no go-live date until the data sources are scoped.

Red flags: a fixed go-live promise before data sources are scoped; no named owner on your side; integration work priced per practice with no ceiling disclosed.

Commercial terms and pricing

Get the pricing model and contract terms in writing, priced against your own attribution and practice count.

Pricing and contract questions

Is pricing per attributed life or member per month, per practice, per module or per workflow?
What is included: integrations, interface changes, support and training?
How does the price change when attribution or the number of practices changes?
What are the contract term, renewal and termination terms?
How is our data returned and deleted when the contract ends?
If we start with a pilot, are its scope and success measures agreed in writing up front?

What a good answer includes: a written pricing basis tied to your attribution and practice count, a list of what is included, and exit terms that cover returning and deleting your data.

Red flags: per-practice integration fees that aren’t disclosed; outcome-based pricing with no agreed baseline; no exit terms for your data.

References: talk to an organization like yours

Ask for a reference that matches your EHR mix, your first program and your size, and ask what they had to change.

Reference call questions

What broke during onboarding, and how was it fixed?
How much staff time did onboarding take on your side?
How do escalations work on a weekend?
What did the care team stop doing once the platform was running?

What a good answer includes: a reference in your segment, with a similar EHR mix and first program, who will talk about what went wrong as well as what worked.

Red flags: references only from a different segment; outcome numbers that can’t be traced to a baseline.

Run one demo script with every vendor

Give every vendor the same scenario and ask them to run it live, step by step. Identical scripts make the answers comparable, and they stop each vendor from showing only its strongest path.

Illustrative example: a patient attributed to a practice on athenahealth is discharged from a connected hospital on a Friday afternoon. Ask the vendor to show, in order:

The ADT notification arriving, the patient matched and the care plan opening.
Who owns the contact task, and how the 2-business-day deadline counts the weekend.
The first attempt, and what happens when nobody answers: logged attempts, the next channel and the point where staff take over.
The interactive contact made by clinical staff, and where it is documented.
The patient mentioning a new symptom, and how it reaches the on-call clinician by rule.
The follow-up visit booked at the patient’s own practice inside the 7- or 14-day window.
The medication reconciliation task.
The plan closing only when the visit is documented, and what the practice sees in the record it bills from.

Run the script on synthetic patients and score what you saw, not what you were told.

The master checklist

Use this table in every demo. Ask the vendor to show each row, and keep the answers.

Area	Ask the vendor to show	A good answer includes	Red flag
Data onboarding	Your claims, ADT and EHR sources mapped, with refresh frequency	A named owner per feed and validation before go-live	“We take any file”
Identity and attribution	How patients are matched and how attribution changes flow through	MBI changes, duplicates, quarterly changes and separate payer contracts handled	No answer on MBI changes or run-out
Multi-EHR	The integration plan for each practice	A matrix by EHR, version, method, data and owner	“Every EHR” with no version detail
Risk and gaps	The drivers behind a flag, on synthetic or de-identified data	Drivers, checks on your population, clinician review before clinical action	A score with no reasons
Care plans	One plan from trigger to documented close	Owners, deadlines and escalation by rule	Plans that close on a call attempt
Outreach	A sample call or text and its handoff	Approved scripts, identity checks, routing by rule, opt-out handling	Agents that give clinical advice
Clinical governance	Where each decision is made in the product	Clinicians own clinical decisions, and clinical staff make the TCM contact	Clinical rules set by the vendor
CMS program fit	TCM, CCM and AWV rules in the workflow	Attempt logs, consent capture, eligibility checks	An automated call counted as the TCM contact
Reporting	Reports by practice, program, contract and owner	Denominators that follow attribution, and export	Contacts made reported as outcomes
Security and compliance	The SOC 2 Type II audit report and a BAA	Documents you can keep	A badge in place of the report
Implementation	What they need from you, and from whom	A dependency list, not a promised date	A go-live date before scoping
Commercial	Pricing against your attribution and practice count	A written pricing basis and exit terms	Undisclosed per-practice fees
References	An organization like yours	The same segment, EHR mix and program	Only references from another segment

A simple scoring rubric

Score each area from 0 to 2, count the areas your first workflow depends on twice, and treat four items as must-pass.

0: no answer, or “on the roadmap”.
1: described in a deck or on a call.
2: shown on synthetic or de-identified data, or in a document you keep.

For TCM across many practices, the areas to count twice are usually data onboarding, multi-EHR, care plans and clinical governance.

Must-pass, whatever the score:

A BAA you can review.
The SOC 2 Type II audit report, or a clear written status.
Clinical decisions and the TCM interactive contact stay with your licensed clinical staff.
A per-practice integration plan.

If two vendors score close, ask each to run the demo script again end to end, from the patient record to the documented close.

Where Zynix fits

Zynix is the AI operating layer for value-based healthcare, built as four pillars: Population Intelligence, Predictive Risk, Embedded Care Management Platform and AI Patient Engagement. Here is how the platform maps to several areas of the checklist above.

Data and multi-EHR: Population Intelligence resolves claims, EHR, ADT, lab and pharmacy data into one record per patient. Zynix connects to 30+ EHR systems across 300+ connected instances (Zynix, September 2026). Interfaces vary by EHR version and configuration, so each connection is confirmed during scoping.
Risk: Predictive Risk predicts readmission, mortality, disease progression and utilization, and lists the drivers behind each prediction. A prediction starts a care-plan task or outreach within the programs and rules your team sets, and clinicians make the clinical decisions. A mortality flag goes to your clinical team as a prompt, never an automated decision, and nothing happens for the patient until a clinician has reviewed it.
Care plans and governance: the Embedded Care Management Platform runs TCM, CCM, AWV and gap-closure plans that your team configures, with owners, deadlines and escalation by rule. A plan closes only when each step is documented, and ZynScribe notes stay drafts until a physician reviews and approves them.
Outreach: AI Patient Engagement runs voice and text outreach within the rules and hours your team sets. Symptom questions go to the on-call clinician by rule, callers describing an emergency are told to call 911, and clinical staff make the TCM interactive contact.
Security: Zynix is SOC 2 Type II audited (report available on request), with HIPAA-aligned safeguards, BAA available, and HITRUST CSF certification in progress.

Frequently asked questions

What should an ACO or MSO look for in a care management platform?

Start with six areas: one patient record from claims, hospital ADT notifications and each practice’s EHR; risk flags that show their drivers; care plans with an owner for every step; outreach inside rules your clinicians approve; CMS rules for TCM, CCM and AWV; and security documents. Then treat four items as must-pass: a BAA you can review, the SOC 2 Type II audit report, clinical decisions kept with your clinicians, and a written integration plan for each practice.

How do you evaluate a care management platform that has to work across multiple EHRs?

Ask for an integration matrix for each practice, listing the EHR, version, interface method, data read and who owns each step, because interfaces vary by EHR version and configuration. Then ask how matched patient records are validated before worklists go live, whether staff work from one worklist across practices, and exactly what, if anything, is filed into each EHR and by whom.

Can an AI agent make the TCM interactive contact?

Plan on no. CMS’s TCM booklet says the interactive contact must be performed by clinical staff who can address patient status and needs beyond scheduling follow-up care. It defines clinical staff as someone supervised by a physician or other qualified health care professional and allowed by law, regulation and facility policy to perform or assist in the service. Automation can still reach the patient, book the visit and route questions to the right person.

What security documents should we ask a care management vendor for?

Ask for the full SOC 2 Type II audit report, not a summary, and read its scope, period and exceptions. Ask for a BAA you can review before contract; under 45 CFR 164.504(e) it must set the permitted uses of PHI, require safeguards and breach reporting, and bind subcontractors. Also get written answers on Security Rule safeguards, use of your data for model training, hosting, subprocessors and access controls.

Should we use our EHR’s built-in care management module instead?

It can fit when most of your practices share one EHR and the program needs little data from outside it. Check how the module handles practices on other EHRs, Medicare and payer claims files, ADT notifications from hospitals that don’t use that EHR, and who runs the outreach. Score it with the same checklist and demo script as any other option, so the comparison is fair.

Source notes

CMS (Medicare Learning Network): Transitional Care Management Services (MLN908628, August 2025). https://www.cms.gov/files/document/mln908628-transitional-care-management-services.pdf

CMS (Medicare Learning Network): Chronic Care Management Services (MLN909188, June 2025). https://www.cms.gov/files/document/chroniccaremanagement.pdf

CMS: Annual Wellness Visit. https://www.cms.gov/medicare/coverage/preventive-services/medicare-wellness-visits/annual-wellness-visit

CMS (Beneficiary Claims Data API): Comparison of BCDA and CCLF Files. https://bcda.cms.gov/bcda-data/comparison-bcda-cclf-files.html

CMS: Beneficiary Claims Data API (BCDA). https://bcda.cms.gov/

CMS (ACO Operational System): Claim and Claim Line Feed (CCLF) Information Packet, Version 43 (May 2026). https://www.cms.gov/files/document/cclf-information-packet.pdf

CMS (Medicare Shared Savings Program): Shared Savings and Losses, Assignment and Quality Performance Standard Methodology Specifications, Version 14 (April 2026). https://www.cms.gov/files/document/medicare-shared-savings-program-shared-savings-losses-assignment-methodology-specifications-version.pdf-0

eCFR: 42 CFR 425.704, Beneficiary-identifiable claims data. https://www.ecfr.gov/current/title-42/part-425/section-425.704

eCFR: 42 CFR 425.708, Beneficiaries may decline claims data sharing. https://www.ecfr.gov/current/title-42/part-425/section-425.708

CMS (Innovation Center): LEAD (Long-term Enhanced ACO Design) Model. https://www.cms.gov/priorities/innovation/innovation-models/lead

CMS: Admission, Discharge, and Transfer Patient Event Notification Conditions of Participation (CoP) FAQ. https://www.cms.gov/initiatives/burden-reduction/overview/interoperability/frequently-asked-questions/admission-discharge-transfer-patient-event-notification-conditions-participation-cop-42-cfr-482-24d

ONC (HealthIT.gov): HTI-1 Final Rule: Decision Support Interventions (DSI) fact sheet (December 2023). https://healthit.gov/wp-content/uploads/2023/12/HTI-1_DSI_fact-sheet_508.pdf

NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

AICPA & CIMA: Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (the SOC 2 audit guide). https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy

eCFR: 45 CFR 164.504, Uses and disclosures: Organizational requirements. https://www.ecfr.gov/current/title-45/part-164/section-164.504

eCFR: 45 CFR Part 164, Subpart C, Security Standards for the Protection of Electronic Protected Health Information. https://www.ecfr.gov/current/title-45/part-164/subpart-C

About the author

Gautamdev Chowdary is co-founder and CTO of Zynix AI, where he leads engineering for the Zynix platform, its AI agents and ZynixLLM.

Evaluating care management platforms?

See one of your workflows run on sample data, from the patient record to the care plan and outreach, with clinicians making every clinical decision.

Book a 30-min walkthrough →