The Centers for Medicare & Medicaid Services announced $10 billion in second-year Rural Health Transformation Program awards on November 9, 2026, with funding going to all 50 states.

The FY2027 awards are part of the program’s existing $50 billion, five-year investment. CMS says the latest allocation brings total awards to $20 billion across the first two years.

For providers, the next step is to identify how their state will implement its approved plan and where a hospital, clinic, workforce partner or technology project could participate.

A federal award to a state does not establish an individual provider’s eligibility or guarantee a direct payment.

What the Year 2 announcement includes

CMS published the FY2027 allocation for every state. Selected awards illustrate the variation:

State	FY2027 award
Texas	$281,976,026
Alaska	$272,653,149
California	$231,105,823
New York	$207,750,071
Florida	$203,828,071

These are state-level awards. Provider opportunities, selection processes and implementation schedules depend on the relevant state plan and funding arrangements. The complete allocation table is available in the CMS award announcement.

For the broader program structure, read our guide to the Rural Health Transformation Program and how providers can access opportunities.

How annual funding is divided

CMS describes two components:

• Baseline funding: Half of the annual $10 billion is distributed equally. With all 50 states participating, each receives $100 million.
• Workload funding: The remaining half follows the program’s methodology, including rural population and facility characteristics, state initiatives, specified policy actions and other technical factors.

The two components determine each state’s annual award.

What changes in the second year

CMS says subsequent awards are informed by progress implementing approved plans. All 50 states submitted annual reports.

For initiative-based funding, CMS assesses implementation checkpoints such as governance, approved project plans, launches, milestones, measurement methods and sustainability planning.

State awards can therefore rise, fall or remain similar from one year to the next. CMS also cautions that its published Year 1 obligation figures are a point-in-time snapshot and do not independently measure overall progress or determine Year 2 awards.

For providers preparing proposals, this makes a credible implementation plan especially useful. A strong description should explain what the organization can deliver, how progress will be documented and what happens after the initial funding period.

What providers should prepare now

The following checklist is US Health Insights’ operational analysis. It offers a preparation framework; the applicable state solicitation and award terms determine actual requirements.

1. Identify the state’s implementation pathway

Start with the state agency responsible for the program and its official procurement or funding pages.

Determine whether the relevant initiative will use a competitive application, procurement, partnership agreement or another selection process. Record the opportunity number, contact, eligibility criteria, deadlines and required documents.

A general program announcement should lead to a specific opportunity assessment before an organization commits substantial proposal resources.

2. Connect the project to a defined access problem

Describe the problem in operational terms.

For example, a project might address long specialty appointment waits, incomplete referrals, limited behavioral health access or difficulty retaining essential staff. Establish the local baseline and identify the population affected.

The proposal should explain how the planned work changes that baseline. A technology purchase or new position becomes more persuasive when its connection to patient access is clear.

3. Confirm partner responsibilities

Projects involving several organizations need an agreed division of work.

Before submission, establish who will lead, employ staff, purchase equipment, maintain technology, collect data and report results. Identify dependencies that could delay delivery.

Where information must move between partners, address data access, permissions, security and integration early. Our digital transformation in healthcare guide discusses these implementation considerations.

4. Build a complete operating budget

Estimate the resources needed to launch and maintain the project.

Depending on the proposed work, the budget may need to consider recruitment, training, integration, maintenance, cybersecurity, project management and evaluation.

Separate one-time expenses from recurring costs. Then identify which costs the solicitation allows, which require another funding source and which remain unresolved.

5. Choose a small set of useful measures

A project needs measures that show both delivery and results. The examples below are planning suggestions, not CMS-mandated metrics.

Project focus	Possible implementation measure	Possible access or service measure
Specialty access	Referral pathway activated and staff trained	Appointment wait time and completed referrals
Workforce development	Recruitment or training milestones completed	Vacancy duration and staff retention
Behavioral health	Referral agreements and service capacity established	Time to first appointment and follow-up completion
Chronic disease management	Outreach and monitoring workflows launched	Engagement and appropriate follow-up
Health information exchange	Connections tested and participating teams trained	Successful information retrieval during care

Specify who owns each measure, where the data come from and how frequently results will be reviewed.

6. Explain how the service will continue

A sustainability plan should identify the resources required after the initial project period.

Depending on the model, organizations may need to assess reimbursement, partner contributions, operating efficiencies or other continuing support. Assumptions should be documented and tested rather than presented as guaranteed revenue.

Keep funding dates separate

CMS states that states must obligate funds within the applicable budget period. Properly obligated funds generally remain available for expenditure through the following fiscal year, subject to program requirements. The program’s final expenditure limit is September 30, 2032.

Providers should therefore track several dates separately:

• The state application or procurement deadline.
• The project’s required start date.
• Contractual milestone and reporting dates.
• Obligation and expenditure deadlines specified in the agreement.

The final program-wide date should not be treated as a substitute for an earlier contractual deadline.

What the awards mean for provider planning

The Year 2 announcement gives providers a reason to revisit their state’s approved priorities and current opportunities.

A practical first step is a short readiness document covering the access problem, proposed work, partners, budget, measures and unresolved dependencies. That document can help leaders decide whether to apply, join a partnership or strengthen the project before a later opportunity.

Reporting basis: CMS’s November 9 announcement and Year 2 fact sheet. Provider preparation recommendations are US Health Insights’ analysis.

Humana and athenahealth announced an expansion of electronic prior authorization capabilities on November 3, 2026, bringing more of the process into athenaOne, athenahealth’s electronic health record platform.

The collaboration spans athenahealth’s nationwide network of more than 180,000 physicians and clinicians. It connects requirements discovery, documentation, electronic submission and health plan decisions within existing provider workflows. Company announcement

For provider organizations, the practical question is how much administrative work the integration removes—and which cases still require staff intervention. Preparation should focus on confirming availability, assigning responsibility for exceptions and measuring results against current workflows.

What the companies reported

According to athenahealth’s internal data for September 1–30, 2026, more than 6,000 providers processed nearly 35,000 electronic prior authorization transactions with Humana. More than 70% were completed without requests for additional information from practice staff.

That percentage measures documentation follow-up. The completed transactions include approvals, denials and determinations that authorization was unnecessary. It should therefore not be described as a 70% approval rate or evidence that care was approved automatically. Company announcement and methodology footnote

The figures offer an early operational signal. Practices evaluating the expansion should also examine turnaround times, staff effort, unresolved requests and the experience of patients waiting for care.

How the electronic workflow works

The companies describe an approach using FHIR-based interoperability standards, including Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support.

These components support different stages of the process:

Component	Role in the workflow
Coverage Requirements Discovery — CRD	Helps identify relevant coverage and authorization requirements.
Documentation Templates and Rules — DTR	Supports gathering the documentation required for a request.
Prior Authorization Support — PAS	Supports exchanging authorization requests and responses.

Humana uses athenaPayer to connect with clinicians across the athenaOne network. Company announcement

For background on these connections, see our guide to HL7 standards for healthcare data exchange.

Why the timing matters for 2027

The announcement comes as affected payers prepare for API requirements under the CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F.

CMS established API compliance dates generally beginning January 1, 2027, with exact timing depending on payer type. The rule covers specified Medicare Advantage, Medicaid, CHIP and federally facilitated Marketplace organizations. Its prior authorization API provisions concern medical items and services and exclude drugs. CMS final rule fact sheet

The Humana–athenahealth announcement is a company implementation development. Provider organizations should assess their applicable reporting requirements and payer arrangements separately when planning for 2027.

What providers should prepare for

The following checklist is US Health Insights’ operational analysis. It offers questions to use when assessing implementation; individual practices should confirm the answers with their payer and technology contacts.

1. Confirm which requests can use the workflow

Start with a written scope assessment. Ask which Humana products, services, locations and clinician groups are supported, whether activation is required, and how staff can identify an eligible request.

A network-wide announcement does not answer every practice-specific implementation question.

The assessment should also identify requests that must continue through another channel. Staff need clear instructions for those cases so that a partially supported workflow does not create duplicate submissions.

2. Map responsibility from order to decision

Document what happens after a clinician places an order:

• Who checks whether authorization is required?
• Who reviews documentation before submission?
• Who monitors requests for additional information?
• Who communicates the decision to scheduling staff and the patient?
• Who handles a denial or technical failure?

Embedding a request in the EHR can change where work appears. It still requires a named owner at each stage.

3. Review documentation quality

Electronic exchange depends on the information available in the record. Practices should check whether relevant diagnoses, clinical notes, prior treatment details and supporting results are complete and accessible.

A useful pilot would examine requests that still require follow-up. Determine whether the cause is missing clinical information, inconsistent documentation, an unsupported service or a technical problem.

This creates a more useful improvement plan than treating every delayed request as the same issue.

4. Create a clear exception process

Staff should know how to respond when a request cannot be completed electronically, information is missing or a response needs clinical review.

Assign an exception queue with defined ownership and escalation steps. Include a way to prevent duplicate requests and a process for communicating delays to patients.

An electronic submission confirmation should also be distinguishable from a final authorization decision in staff instructions.

5. Establish a baseline before measuring improvement

Capture current performance before expanding use. Otherwise, it will be difficult to determine whether changes reflect the integration, a different mix of services or unrelated staffing adjustments.

Measure	What to record	Why it helps
Staff effort	Staff touches and time spent per request	Shows whether administrative work decreases
Documentation follow-up	Requests requiring additional information	Identifies recurring information gaps
Decision time	Submission-to-decision time, separated by request type	Shows where delays persist
Exceptions	Technical failures, manual transfers and duplicate submissions	Reveals work outside the main workflow
Outcomes	Approvals, denials and authorization-not-required results separately	Prevents misleading combined success rates
Patient impact	Scheduling delays or cancellations linked to authorization	Connects process performance with access

These are suggested evaluation measures, not additional CMS requirements.

6. Train staff around the actual workflow

Training should cover where requests appear, how to interpret status messages, when to intervene and who owns unresolved cases.

Use representative scenarios during preparation: a complete request, missing documentation, a denial and an unavailable electronic route. Confirm that clinical, scheduling and revenue-cycle teams interpret each outcome consistently.

This approach fits the broader implementation principles discussed in our digital transformation in healthcare guide.

What healthcare leaders should take from the announcement

The expansion gives providers a timely reason to review how authorization work moves between their EHR, staff and health plans.

A practical starting point is a limited pilot with confirmed service eligibility, assigned exception handling and a documented baseline. Expansion decisions can then reflect observed staff workload, request completion and patient scheduling performance.

The goal is a workflow that helps teams understand what is required, submit complete information and act promptly on the resulting decision.

Here is the oldest complaint in value-based care, and every ACO executive has made it: you get punished for winning.

Save money against your benchmark, and the benchmark rebases downward. Next cycle you compete against your own best performance. Do it again and the target moves again. The organizations that transformed care most aggressively ended up with the least room left to earn. The industry calls it the ratchet, and it has quietly undermined every accountable care model CMS has built.

The Long-term Enhanced ACO Design (LEAD) Model is CMS’s answer.

LEAD runs for ten years with no traditional rebasing. It is the longest performance period the CMS Innovation Center has ever tested. An ACO that invests in care transformation in 2027 gets a decade to earn against that investment without the target sliding underneath it.

That single design decision is the story. Everything else in the model follows from it.

This guide covers what LEAD is, the benchmarking methodology that defines it, the two risk options, the prospective payment menu including a genuinely new capitation type, alignment rules and minimum thresholds, what changes from ACO REACH, quality measurement, the new benefit enhancements, and what different kinds of organizations should be doing now.

What is the LEAD Model?

The Long-term Enhanced ACO Design Model is a voluntary, ten-year Medicare accountable care model from the CMS Innovation Center, running January 1, 2027 through December 31, 2036. It is the successor to ACO REACH, which concludes at the end of 2026.

LEAD operates under Section 1115A authority and falls within CMS’s accountable care model category. As of CMS’s most recent page update, the model is in the Announced stage with participants not yet published.

Full name	Long-term Enhanced ACO Design
Performance period	January 1, 2027 to December 31, 2036
Length	10 years, the longest CMS has tested
Predecessor	ACO REACH (ends December 31, 2026)
Participation	Voluntary
Risk options	Global Risk and Professional Risk
Rebasing	No traditional rebasing during the period
Quality at risk	3% of benchmark
Authority	Section 1115A of the Social Security Act

The Problem CMS Is Trying to Solve

CMS is explicit about the diagnosis: many providers have never joined an ACO, or joined and dropped out, because of financial and administrative obstacles.

Earlier accountable care models were not built for smaller, more rural, or independent practices, or for organizations serving high-needs patients. The capital requirements, the alignment minimums, the cash flow timing, and the benchmark mechanics all favored large, well-resourced, already-efficient systems.

LEAD’s stated aims are to widen the door: bring in more small, rural, and independent providers and Community Health Centers, strengthen prevention and care coordination for patients with high needs, and give patients a more active role in their own care.

CMS anticipates LEAD participants will include current ACO REACH participants and other ACOs, Medicare fee-for-service providers who have never been in an ACO, and organizations serving underserved populations including those with high proportions of dually eligible individuals, federally qualified health centers, and rural health clinics.

The Ten-Year Benchmark: LEAD’s Defining Feature

LEAD’s benchmarking methodology builds on both ACO REACH and the Shared Savings Program. Five components matter.

No Traditional Rebasing

The ten-year performance period runs without traditional rebasing, which CMS frames directly as giving ACOs time to invest in care transformation and see returns over the long term.

This changes the investment math fundamentally. A care management build, a data infrastructure project, or a clinical hiring plan that takes three years to pay back is nearly impossible to justify against a benchmark that resets before the payback lands. Over a decade, it becomes a straightforward business case.

Annual Updates With Guardrails

Benchmarks update annually using a blend of a prospective trend factor plus observed national and regional spending, with guardrails applied to the prospective trend factor to mitigate large forecasting misses.

The design goal is stated plainly: more predictable year-to-year benchmark growth, while leaving room for efficient ACOs to beat the trend and generate durable savings.

A Realistic Starting Point for High-Spending Organizations

This provision deserves attention because it reverses a long-standing barrier.

ACOs whose aligned beneficiaries have higher historical Medicare costs than other beneficiaries in the same region are not immediately measured against a benchmark that incorporates regional spending. Instead, high-spending ACOs get a benchmark based purely on their own aligned beneficiaries’ historical spending, plus additional payment support.

Under models that blend in regional spending from day one, an organization serving a high-cost population starts underwater and often never surfaces. LEAD gives those organizations a viable pathway to improve efficiency over time rather than an impossible starting line.

Credit for Prior Performance

The inverse case is also handled. ACOs whose aligned beneficiaries have lower historical spending than their regional peers are eligible for a positive regional efficiency adjustment.

And critically for anyone already in a model: ACOs that generated savings in ACO REACH or the Shared Savings Program may receive either a regional efficiency adjustment or a prior savings adjustment, whichever is higher. Both reflect the ACO’s own risk profile.

If you have been doing this work and generating savings, that history follows you into LEAD rather than being erased.

The Regional Rate Book Endgame

Over the ten years, as spending levels converge within a region, LEAD is designed to move toward a more standardized regional rate book, reducing reliance on historical spending and promoting greater equity across participants.

Read the five components together and the arc is clear: start organizations where they actually are, give them a decade of stable targets, credit past performance, and converge toward regional rates once the gaps have closed.

Risk Options: Global vs. Professional

LEAD offers two voluntary risk-sharing arrangements.

	Global Risk	Professional Risk
Savings	Up to 100%	Up to 50%
Losses	Up to 100%	Up to 50%
Capitation options	PCC or Total Care Capitation	PCC required
Fit	Organizations with capital, experience, and a specialty network	Organizations building toward full risk

Both are measured relative to the ACO’s established performance year benchmark.

Prospective Payment Options

This is where LEAD is most operationally different from its predecessors, and where the cash flow story lives. LEAD provides monthly prospective payments to support enhanced care investments.

Primary Care Capitation

Primary Care Capitation (PCC) is a monthly capitated payment for primary care services delivered by the ACO’s Participant and Preferred Providers. It has two components:

• Base PCC covers the cost of delivering primary care to aligned beneficiaries.
• Enhanced PCC (EPCC) provides upfront cash flow to invest in infrastructure, staffing, workflow changes, and other improvements. EPCC must be paid back to CMS in full at the end of the performance year.

Think of EPCC as a working capital facility rather than revenue. It solves the timing problem that kills undercapitalized ACOs, but it comes back.

ACOs in the Professional Risk Option are required to select PCC. ACOs in Global Risk choose between PCC and Total Care Capitation.

Total Care Capitation

Total Care Capitation (TCC) is available only in the Global Risk Option and covers all Medicare Parts A and B services delivered by the ACO’s Participant and Preferred Providers, including both primary and specialty care.

Non-Primary Care Capitation: The New One

NPCC is a new payment option in LEAD and worth understanding carefully.

ACOs that select PCC may also select Non-Primary Care Capitation, a monthly capitated payment covering non-primary care services provided by enrolled Participant and Preferred Providers, such as specialists and post-acute care facilities.

The distinguishing feature: NPCC is a true capitated payment and is not reconciled against fee-for-service billing. That makes it structurally different from the Advanced Payment Option below, and it gives ACOs a real instrument for building risk-bearing relationships with specialists without waiting on FFS reconciliation.

Advanced Payment Option

APO is also optional for ACOs electing PCC. It provides an upfront monthly payment for non-primary care services from enrolled Participant and Preferred Providers, but APO is reconciled against actual fee-for-service billing throughout the performance year.

APO is cash flow timing. NPCC is risk transfer. Choosing between them is a strategic decision, not an administrative one.

Add-On Capitation Payments

ACOs with higher-than-average spending compared to their region are eligible for an additional capitated payment calculated as a percent of the ACO’s benchmark.

Two features make this significant:

• It is not reconciled at the end of the performance year.
• It is not included in performance year expenditures when calculating shared savings or losses.

This is an upfront benchmark adjustment intended to fund investment in primary care and other services that will let the ACO reduce Medicare expenditures over time. For a high-cost organization, it is real, unrecovered capital.

CMS also describes a separate non-reconciled add-on payment for rural health care providers, specifically to help build the infrastructure needed to operate as an ACO. For organizations also tracking Rural Health Transformation Program funds, these are two distinct capital sources aimed at overlapping problems.

Who Can Participate: Alignment and Minimums

How Beneficiaries Are Aligned

LEAD ACOs receive beneficiary alignment two ways:

• Claims-based alignment, using beneficiaries’ claims history and utilization patterns
• Voluntary alignment, where beneficiaries actively choose an ACO by naming a provider affiliated with it as their primary provider or other source of care. Voluntary alignment can happen in a care setting or in the patient’s home when a pre-existing relationship with an affiliated provider exists.

ACOs then select one of two alignment approaches:

• Prospective alignment. Alignment is set before each performance year begins, with no updates during the year.
• Hybrid alignment. Alignment updates during the performance year. Voluntary alignment refreshes monthly. Claims-based alignment is set prospectively, but ACOs adding new Participant TINs mid-year get one mid-performance-year claims-based update for those TINs. Beneficiaries can only be added mid-year, never dropped.

Minimum Beneficiary Thresholds

The thresholds are tiered, and the tiering is the clearest evidence of CMS’s intent to widen participation.

Participant type	Performance Year 1 minimum	Base Year requirement
Standard	5,000 aligned beneficiaries	3,000 aligned in at least one Base Year
Newly Entering ACOs	1,000 beneficiaries	600 claims-based in at least one Base Year
High Needs concentration (>40% of aligned beneficiaries meet High Needs criteria)	800 beneficiaries	500 claims-based in at least one Base Year

CMS notes that minimums for Newly Entering ACOs and ACOs with large High Needs populations will grow slowly over the course of the model, so the lowered thresholds are an on-ramp rather than a permanent accommodation.

An 800-beneficiary floor for organizations specializing in complex care is a meaningful change. It recognizes what CMS states directly: organizations that specialize in caring for High Needs beneficiaries typically have smaller patient panels.

What Changes From ACO REACH

If you are in ACO REACH today, these are the structural differences that will reshape your strategy.

High Needs Becomes a Beneficiary Policy, Not an ACO Type

This is the biggest change, and it is easy to underestimate.

LEAD does not include a distinct High Needs ACO type. Instead, High Needs policies apply to all beneficiaries meeting the High Needs criteria, across all ACOs.

The consequences cut two ways:

• ACOs that do not specialize in complex care receive more accurate benchmarks and risk adjustment for the High Needs beneficiaries they do serve. Previously, serving those patients inside a standard ACO was financially unattractive.
• Organizations that specialize in complex populations can now serve their entire eligible Medicare fee-for-service population within LEAD, not only beneficiaries meeting High Needs criteria. The previous structure forced specialization at the organizational level.

Mechanically, the High Needs beneficiary category gets its own historical benchmark calculation with a separate trend factor and its own risk adjustment methodology. Concurrent risk adjustment, first implemented for High Needs beneficiaries in ACO REACH, applies to all High Needs beneficiaries in LEAD.

CMS’s reasoning is worth noting: High Needs individuals often experience more rapid changes in health status than the average Medicare beneficiary, and a concurrent methodology that incorporates diagnoses documented during the performance year reflects those shifts more accurately than a purely prospective approach. If your risk adjustment operation is built around prospective capture and annual HCC recapture cycles, concurrent methodology for part of your population is a different operating rhythm.

Side by Side

	ACO REACH	LEAD
Period	Ends December 31, 2026	2027 to 2036, ten years
Rebasing	Periodic	No traditional rebasing
High Needs	Separate ACO type	Beneficiary-level policy across all ACOs
Risk options	Global and Professional	Global and Professional
Non-primary capitation	Advanced Payment Option	APO plus new, unreconciled NPCC
Specialist risk	Limited support	CARA episode-based arrangements
Medicaid	Not integrated	Two-state planning phase

Quality Measurement

LEAD uses a deliberately small measure set, which CMS frames as reducing provider burden while keeping criteria clear and achievable.

The set comprises four claims-based measures, one patient experience measure, and two electronic clinical quality measures, with the eCQMs phased in across the first half of the model.

Measures CMS names include:

• All-cause unplanned admissions for older adults with multiple chronic conditions (claims-based)
• Days at home for patients with complex, chronic conditions (claims-based)
• Timely follow-up after acute events for certain chronic conditions (claims-based)
• Patient experience via the CAHPS survey
• Diabetes care, glycemic status assessment greater than 9% (eCQM), reporting optional for performance years 2027 and 2028
• Blood pressure control (eCQM), reporting optional for performance years 2027 and 2028

Three more mechanics matter:

• 3% of benchmark is at risk for quality, earned back based on performance. Payments are not withheld during the year. At financial settlement, only the portion not earned back is applied when calculating shared savings or losses. That is a materially friendlier cash flow posture than withholding.
• A Continuous Improvement / Sustained Exceptional Performance (CI/SEP) component and a High Performers Pool, carried over from ACO REACH, reward ACOs achieving statistically significant year-over-year improvement and high overall performance.
• ACOs can earn additional quality points by submitting a Prevention Quality Plan describing a prevention intervention they are implementing.

Notice the shape of the measure set: unplanned admissions, days at home, timely follow-up, diabetes control, blood pressure. This is a chronic disease management scorecard. Organizations with mature chronic care management operations are already producing the behavior these measures reward.

Benefit Enhancements and Beneficiary Engagement Incentives

LEAD adds new Medicare waivers and patient incentives. Participation in any of them is optional, and acceptance into LEAD is not contingent on adopting any of them. ACOs that do adopt must submit an implementation plan to CMS for each, including how they will cover the cost.

New Benefit Enhancements

• Medical Nutrition Therapy expansion. CMS would expand the conditions for which beneficiaries can receive covered MNT beyond diabetes and renal disease, for beneficiaries in LEAD ACOs taking full risk. This opens nutrition therapy to other diet-sensitive chronic conditions.
• Part D Premium Buydown. Available by 2029, qualifying ACOs could partially or fully offset a beneficiary’s Part D premium for a given performance year, reducing cost-related barriers to accessing drugs.

New Beneficiary Engagement Incentives

• Chronic Disease Prevention Reward. ACOs can offer healthy food products as beneficiaries engage in healthy living activities and participate in evidence-based chronic disease programs.
• Substance Access BEI. ACOs and their providers may consult with aligned patients about the possible benefits of hemp products. This one carries specific conditions: it is funded entirely at the participant’s expense, CMS does not cover the cost, it is available only in states where the eligible hemp products are legal, and CMS will apply strict program integrity safeguards. The same BEI is being made available to ACO REACH participants in performance year 2026 and to the Enhancing Oncology Model starting in performance period 6.

CARA: Episode Risk With Specialists

The CMS Administered Risk Arrangements (CARA) initiative is a voluntary, modular digital data-sharing and payment component of total cost of care models, initially tested within LEAD among ACOs maintaining two-sided risk.

CARA exists to lower the barrier to ACOs building real financial and clinical relationships with Preferred Providers and downstream specialists without driving consolidation. That last phrase is doing deliberate work: CMS is offering an alternative to acquiring specialists in order to align them.

CARA works by:

1. Sharing episode data with ACOs and the Preferred Providers they enter episode-based risk arrangements (EBRAs) with
2. Providing common contracting frameworks, including export of episode information into contracting templates
3. Allowing configurable episode design
4. Making payment to ACOs and Preferred Providers based on their EBRAs

CARA will also feature an episode-based falls prevention program. CMS has signaled potential scaling to other total cost of care contexts based on demonstrated success and market uptake.

For specialty groups that have watched total cost of care models from the sidelines, CARA is the most concrete on-ramp CMS has built.

Medicaid Integration

LEAD includes an initial planning phase running March 2026 through December 2027, during which CMS will identify two states interested in developing a framework for ACO-Medicaid partnership arrangements.

The framework is meant to define how ACOs and Medicaid organizations share data and coordinate care for dually eligible beneficiaries in Original Medicare, including preventing avoidable hospitalizations and helping patients stay engaged in their communities. Pending successful completion of the planning period, ACOs in the selected states would have the opportunity to enter partnership arrangements with Medicaid organizations.

If you operate in a state that pursues this, it is a material strategic variable. Watch for which two states CMS selects.

What to Do Now

If You Are in ACO REACH

Your model ends December 31, 2026. LEAD begins the next day.

• Quantify your prior savings adjustment position. ACOs that generated savings in REACH or MSSP may receive a regional efficiency adjustment or a prior savings adjustment, whichever is higher. Know which applies to you and roughly what it is worth.
• Re-plan around the loss of the High Needs ACO type. If you run a High Needs REACH ACO, LEAD lets you serve your full eligible Medicare FFS population, which is an expansion opportunity and a different operating model.
• Reassess your risk option. Global versus Professional, and within Global, PCC versus TCC.
• Evaluate NPCC seriously. Unreconciled capitation for specialty and post-acute services is a new instrument and changes what specialist arrangements are possible.

If You Have Never Been in an ACO

CMS built the on-ramp for you specifically.

• Newly Entering ACOs need 1,000 beneficiaries in PY1, not 5,000.
• Rural providers get a non-reconciled add-on payment explicitly for building the infrastructure to operate as an ACO.
• EPCC provides upfront cash flow, though remember it is repaid in full at year end.
• Start with the Request for Applications and the Application Checklist on the CMS LEAD page.

If You Serve Complex or Dually Eligible Populations

• The 800-beneficiary minimum applies if more than 40% of your aligned population meets High Needs criteria.
• Concurrent risk adjustment for High Needs beneficiaries changes your documentation rhythm from an annual capture cycle to continuous performance-year capture.
• Watch the Medicaid integration state selection.

On Timing

CMS has stated it expects future opportunities to apply, though details are not yet published and participation parameters may change based on early model years. A non-binding Letter of Interest process was offered for organizations interested in later cohorts.

Because application windows and cohort timing have moved, confirm current application status directly on the CMS LEAD Model page rather than relying on any secondary source, including this one.

Frequently Asked Questions

What is the LEAD Model? The Long-term Enhanced ACO Design Model is a voluntary ten-year Medicare accountable care model from the CMS Innovation Center, running January 1, 2027 through December 31, 2036. It succeeds ACO REACH and is built around long-term benchmark stability without traditional rebasing.

What does LEAD stand for? Long-term Enhanced ACO Design.

When does the LEAD Model start and end? January 1, 2027 through December 31, 2036. It is the longest performance period CMS has tested.

Is LEAD replacing ACO REACH? Yes. ACO REACH concludes December 31, 2026, and LEAD launches immediately after as its successor, building on both ACO REACH and the Shared Savings Program.

What are the LEAD Model risk options? Global Risk, with up to 100% of savings and liability for up to 100% of losses, and Professional Risk, with up to 50% of savings and up to 50% of losses. Both are measured against the ACO’s established performance year benchmark.

How many beneficiaries does an ACO need for LEAD? 5,000 aligned beneficiaries in Performance Year 1 for standard participants, 1,000 for Newly Entering ACOs, and 800 for ACOs where more than 40% of aligned beneficiaries meet High Needs criteria. Each tier also carries a Base Year requirement.

Does LEAD have a High Needs ACO type like ACO REACH? No. LEAD applies High Needs policies at the beneficiary level across all ACOs, including a separate historical benchmark calculation, separate trend factor, and concurrent risk adjustment for those beneficiaries.

What is NPCC in the LEAD Model? Non-Primary Care Capitation, a new monthly capitated payment covering non-primary care services from enrolled Participant and Preferred Providers such as specialists and post-acute facilities. Unlike the Advanced Payment Option, NPCC is a true capitated payment and is not reconciled against fee-for-service billing.

What is CARA? CMS Administered Risk Arrangements, a voluntary modular initiative being tested first within LEAD among two-sided-risk ACOs. It supports episode-based risk arrangements with specialists and downstream providers through shared episode data, common contracting frameworks, configurable episode design, and payment based on those arrangements.

How much of the benchmark is at risk for quality in LEAD? 3%, earned back based on performance. Payments are not withheld during the year, and only the unearned portion is applied at financial settlement.

Can rural providers and FQHCs participate in LEAD? Yes, and CMS designed specific supports for them, including a non-reconciled add-on payment for infrastructure, lower alignment minimums for organizations new to ACOs, and a Medicaid integration component. CMS explicitly anticipates participation from federally qualified health centers and rural health clinics.

The Bet CMS Is Making

Strip away the payment mechanics and LEAD is a wager: that the reason accountable care has underdelivered is not that providers lack the will, but that the terms were wrong.

Too short a horizon to justify real investment. Benchmarks that punished success. Alignment minimums that excluded the small and rural. Cash flow timing that only worked if you already had capital. A structure that forced organizations serving complex patients into a separate box.

LEAD addresses each of those directly. Ten years without rebasing. Credit for prior savings. Alignment floors as low as 800. Upfront capitation, some of it never reconciled. High Needs policy applied to every ACO rather than segregated into one.

Whether it works is an open question, and a ten-year model will take most of a decade to answer it. But the design reflects an unusually honest reading of why the previous attempts fell short, and for organizations that have been waiting for terms they could actually build a business on, this is the closest CMS has come.

A rural hospital CEO reads that Congress created a $50 billion fund for rural health and asks the obvious question: how do we apply?

You don’t. Your state already did.

That single fact is the most common misunderstanding about the Rural Health Transformation Program, and it changes everything about how a hospital, clinic, EMS agency, or health technology vendor should approach it. This is not a federal grant program that providers apply to. It’s a state allotment program. The money lands in state hands, and states decide who gets it.

If you are waiting for a federal application portal to open, you are waiting for something that isn’t coming.

This guide covers what RHTP is, where it came from, how the money is split, what it can legally fund, who actually receives it, where the timeline stands, how to position for a subaward, and the serious criticism of whether $50 billion closes the gap it was created to close.

What is the Rural Health Transformation Program?

The Rural Health Transformation Program is a $50 billion federal fund created in 2025, administered by CMS, that distributes money to states over five federal fiscal years to strengthen rural health care delivery.

It was established by the One Big Beautiful Bill Act, the budget reconciliation law enacted in July 2025. The program runs $10 billion per year across federal fiscal years 2026 through 2030.

Why It Exists

The honest answer is that RHTP was a negotiation.

The same law that created the fund also made substantial changes to Medicaid, including new community engagement requirements, more frequent eligibility redeterminations, and constraints on provider taxes and state directed payments. Independent analyses projected significant coverage losses and reduced Medicaid revenue, with rural areas disproportionately exposed because rural hospitals depend more heavily on Medicaid and operate on thinner margins.

Several senators from rural states made their votes contingent on something to offset that exposure. The rural fund started smaller and was doubled to $50 billion during negotiations.

Understanding that origin matters, because it explains both the program’s generosity and its limits. It was designed to be large enough to secure votes, structured to give states wide discretion, and scoped to five years against Medicaid changes that run considerably longer.

The Problem It’s Aimed At

The underlying crisis is real regardless of how the fund came about.

More than 100 rural hospitals have closed or converted to a reduced service model since 2010, and research organizations tracking rural hospital finances have consistently identified several hundred more at risk of closure, with a substantial subset at immediate risk. Rural communities face longer travel times to emergency care, obstetric deserts expanding as labor and delivery units close, workforce shortages across every clinical discipline, and aging facilities.

Congress created the Rural Emergency Hospital designation a few years earlier as an alternative to outright closure, letting small hospitals drop inpatient services while keeping emergency and outpatient care. RHTP is the larger and blunter instrument.

How RHTP Funding is Allocated?

This is the mechanic that determines how much your state has to work with, and it’s the part most coverage gets wrong or skips.

The 50/50 Split

The $10 billion available each year is divided into two halves that work on completely different logic:

• Half is distributed roughly equally among all approved states. Every state with an approved application receives a baseline share regardless of size, rural population, or need. A state with 60,000 rural residents and a state with 3 million receive comparable baseline amounts.
• Half is distributed at the CMS Administrator’s discretion, using factors defined in the statute and elaborated in CMS’s funding opportunity, including rural population, the number of rural health facilities, and a state’s adoption of specific policies and initiatives that CMS chose to prioritize.

The equal-distribution half produces a strange outcome worth naming. On a per-rural-resident basis, small states did extremely well and large rural states did comparatively poorly. That’s not a flaw in anyone’s implementation. It’s what the statute says.

The discretionary half is where state policy choices mattered. CMS structured its funding opportunity to reward states pursuing particular reforms, and states wrote applications accordingly.

What That Means For You

Practically:

• Your state’s total is not proportional to your state’s rural need. Don’t benchmark your expectations against another state’s per-capita figure.
• Your state’s application is the actual roadmap. It describes the initiatives your state committed to funding. That document, not the federal statute, tells you what will get funded where you live.
• Awards are annual. Continued funding across the five years is tied to state performance and reporting, not guaranteed as a lump sum.

What RHTP Funds Can Be Used For

The statute defines a list of allowable use categories, and states must use their funds across at least three of them. The categories, in substance:

• Evidence-based prevention and chronic disease management interventions
• Payments to health care providers for items and services
• Consumer-facing, technology-driven solutions for preventing and managing chronic disease
• Training and technical assistance for technology-enabled care, including remote monitoring, robotics, and artificial intelligence
• Recruiting and retaining clinical workforce in rural areas, with multi-year service commitments
• Information technology advances, including software, hardware, cybersecurity capability, and technical assistance
• Right-sizing rural delivery systems, meaning helping communities identify which service lines they actually need across prevention, ambulatory, pre-hospital, emergency, inpatient, outpatient, and post-acute care
• Opioid use disorder, substance use disorder, and mental health treatment access
• Innovative care models, including value-based arrangements and alternative payment models

That list is broader than most federal rural health funding, and deliberately so.

What’s Restricted

A few limits shape what states can actually do:

• Administrative expenses are capped, with the statute limiting the share of a state’s allotment that can go to running the program rather than delivering it.
• Additional caps apply to certain categories, including limits on how much can go to capital and facility expenditures.
• Funds are meant to supplement, not replace, existing state spending on rural health.

Confirm current caps and conditions against CMS guidance and your state’s award terms, since the operational detail lives in the funding opportunity and award documents rather than in the statute.

The “Right-Sizing” Category Deserves Attention

Most coverage of RHTP frames it as money to keep rural hospitals open. Read the allowable uses again and notice that one category is explicitly about helping communities determine which services they should still be providing.

That is not the same thing as preservation. Right-sizing can mean converting an inpatient hospital to a Rural Emergency Hospital, consolidating a service line, or replacing a facility-based service with a telehealth or transport model.

Some RHTP money will fund graceful contraction, not expansion. Whether that’s the right policy is genuinely debatable. That it’s in the statute is not.

Who Actually Receives the Money

States are the grantees. Nearly everyone else is a subrecipient.

Entities that states can and do route funds to include:

• Rural hospitals, critical access hospitals, and Rural Emergency Hospitals
• Rural health clinics and federally qualified health centers
• Independent physician practices and specialty groups serving rural areas
• EMS and ambulance agencies, a chronically underfunded piece of rural infrastructure
• Behavioral health and substance use treatment providers
• Tribal health organizations
• Academic medical centers and universities running workforce pipelines
• Health IT vendors and digital health companies, typically through a state contract or through providers using funds to buy technology

A structural criticism worth understanding: the program does not require that every dollar be spent in a rural community. States have latitude in how they define rural benefit, and money can flow to non-rural organizations providing services or infrastructure that serve rural populations. Whether that’s sensible reach or simple leakage depends on the state and on the specific project.

Where the Timeline Stands

The compressed schedule was one of the program’s defining features.

• July 2025: the program is enacted.
• September 2025: CMS publishes the notice of funding opportunity, setting out application requirements and how the discretionary half would be scored.
• Late 2025: states submit applications on a very short turnaround, with CMS required to approve or deny by December 31, 2025.
• December 2025: CMS announces approvals and first-year awards.
• 2026 onward: states stand up program offices, define subaward processes, and begin distributing funds, with annual reporting and continued allocations through fiscal year 2030.

That timeline had consequences. States had weeks, not months, to design multi-year rural health strategies. Many applications were written quickly by small teams, drawing on whatever rural health plans already existed. The implementation year is where those plans meet reality, and several states have been building subaward infrastructure after the money was already awarded.

For anyone trying to access funds, this is the useful window. Program design decisions at the state level are being made now, not settled years ago.

How to Position for RHTP Funding?

1. If You’re a Rural Provider

• Read your state’s application. Most states have published theirs or summarized it. It names the initiatives, and initiatives that made the application are the ones with money behind them.
• Find the state office running it. Usually the state health department, Medicaid agency, or state office of rural health. Get on their distribution list before the first notice of funding availability drops.
• Map your ask to a statutory category. A proposal that clearly lands in workforce recruitment, behavioral health access, or technology adoption is far easier to fund than one that requires a state administrator to argue it fits.
• Prepare for reporting, not just receiving. States owe CMS outcome reporting, so subaward terms will carry measurement obligations. Organizations without the capacity to report will struggle, and some will be screened out for that reason alone.
• Think in multi-year terms. Recruitment funding tied to service commitments and technology investments both assume you’ll still be operating. Sustainability after the five years is a question every state will ask.

2. If You’re a Health IT or Digital Health Vendor

Several allowable use categories point directly at technology: consumer-facing chronic disease tools, remote monitoring and AI enablement, and IT advances including cybersecurity.

• Sell to the state, or arm the provider. Both paths exist. Statewide platform procurements and provider-level purchases funded by subawards are different sales motions with different timelines.
• Cybersecurity is an unusually clean fit. It’s named in the statute, rural facilities are demonstrably under-resourced against ransomware, and it doesn’t require clinical workflow change to justify.
• Chronic disease management is the largest category by breadth. Tools supporting chronic care management programs, remote monitoring, and prevention fit multiple use categories at once.
• Interoperability and infrastructure work qualifies. Rural facilities running aged or minimally supported systems are a real target for EHR modernization, exchange connectivity, and data infrastructure.
• Price for the cliff. Funding ends after fiscal year 2030. A vendor proposing a model that leaves a critical access hospital with an unaffordable renewal in year six will not survive state procurement scrutiny, and shouldn’t.

3. If You’re Working Inside a State Program

• Subaward design determines reach. Application burden is the single biggest filter on which rural organizations can participate. A twelve-page application excludes exactly the twenty-bed hospital with no grants staff that the program was created for.
• Technical assistance is a legitimate use of funds. Helping small organizations apply is not overhead; it’s the difference between funding the well-resourced and funding the needy.
• Build the measurement plan first. Federal reporting obligations are real and outcome-focused, and retrofitting measurement onto projects already underway is the predictable failure mode.

Does $50 Billion Actually Close the Gap?

The substantive criticism deserves direct treatment, because the answer shapes how much this program can be expected to accomplish.

The arithmetic problem. Analyses of the same law’s Medicaid provisions projected reductions in federal Medicaid spending reaching rural areas that exceed $50 billion over a ten-year window, with estimates commonly cited in the range of well over $100 billion. RHTP delivers $50 billion over five years. Even taking the most favorable framing, the fund does not offset the reduction, and the two run on different clocks.

The structural problems on top of it:

• Operating losses versus one-time investment. A hospital losing money every month on patient care is not made solvent by a grant for a telehealth platform. RHTP largely funds transformation, not operations, and the provider payment category has its own limits.
• The cliff in 2030. Five-year programs create commitments that outlive them. Staff hired, technology purchased, and services launched all need a funding source in year six.
• Equal distribution versus need. Half the money ignores rural population entirely.
• No rural spending guarantee. The absence of a strict requirement that funds be spent in rural communities leaves room for dilution.
• State capacity varies enormously. Some states have mature offices of rural health and strong grants infrastructure. Others are building from close to nothing on a compressed timeline.

The fair counterargument: rural health has been starved of capital investment for decades, and $50 billion in flexible funding aimed at workforce, technology, behavioral health, and service redesign is a genuine opportunity regardless of what motivated it. Whether it is enough and whether it is useful are different questions, and the honest answer to the first is no while the answer to the second is that it depends almost entirely on execution at the state level.

Frequently Asked Questions

What is the Rural Health Transformation Program?

A $50 billion federal fund created by the One Big Beautiful Bill Act in 2025 and administered by CMS, distributing $10 billion per year across federal fiscal years 2026 through 2030 to states to strengthen rural health care delivery.

Who can apply for RHTP funding?

Only states apply to CMS, and the application window closed at the end of 2025. Rural hospitals, clinics, EMS agencies, behavioral health providers, and vendors access the money through state subawards, not through a federal application.

How much money does each state get?

Roughly half of each year’s $10 billion is split about equally among approved states, and the other half is distributed at the CMS Administrator’s discretion based on statutory factors and state initiatives. Because of the equal-split half, allotments do not track rural population proportionally.

What can RHTP funds be used for?

States must use funds across at least three allowable categories, including chronic disease prevention and management, provider payments, consumer-facing technology, technology training and technical assistance, workforce recruitment and retention, IT and cybersecurity, right-sizing delivery systems, behavioral health and substance use treatment access, and innovative care models.

How long does the program last?

Five federal fiscal years, 2026 through 2030, with annual awards rather than one lump sum.

Where to Start

If you want to reach this money, three concrete moves beat waiting for an announcement.

Get your state’s application and read it. Not the summary, the application. It names initiatives, dollar ranges, and partners. Everything that gets funded in your state for the next five years traces back to that document.

Identify the state office and the person running subawards. Programs of this size are administered by small teams under real pressure. Being a known, credible, easy-to-work-with organization before the first funding notice is worth more than a strong application after it.

Decide which statutory category you fit, and build the case in those terms. State administrators are constrained by the same list everyone else is. The proposal that names its category, describes measurable outcomes, and explains what happens after 2030 is the one that survives review.

The states that use this well will be the ones that treated a compressed federal deadline as the start of a strategy rather than the end of one. The organizations that benefit will be the ones that showed up while the rules were still being written.

Ask five people at a health plan how many members it had last March and you’ll get five numbers.

Not because anyone is careless. Because one person counted anyone enrolled on March 1, another counted anyone enrolled at any point in March, a third counted member months, a fourth excluded members who retroactively terminated, and the fifth pulled from a table where the enrollment span had been overwritten by a correction that arrived in June.

Every one of those answers is defensible. They disagree because the underlying healthcare data model never settled what a member month is, whether history is preserved when a record changes, or which grain the enrollment table represents.

That’s what data modeling actually is. Not diagrams. Deciding what a row means, and making that decision hold.

This guide covers the layers of a healthcare data model, why clinical and claims data resist conventional modeling, the major paradigms, the standard common data models including OMOP, how vendor EHR and payer models really look, and how to choose. It’s written for people who have to build the thing, not admire it.

What is a Healthcare Data Model?

A healthcare data model is the structured definition of how clinical, claims, and administrative data are organized: what entities exist, how they relate, what each row represents, and which codes and vocabularies give the values meaning.

Data models exist at three levels, and mixing them up is the source of a remarkable amount of wasted meeting time.

Clinical Data Model vs. Claims Data Model

Before the three levels, one split worth naming. Teams often maintain a clinical data model built around patients, encounters, observations, medications, and problem lists, and a separate claims data model built around members, enrollment spans, claim headers and lines, and paid amounts.

They describe overlapping reality from different vantage points. Clinical data knows what a clinician observed; claims data knows what got billed and paid. Neither is complete, they disagree routinely, and reconciling them is the actual work in value-based care analytics. Any serious enterprise model has to hold both and be explicit about which one wins for which question.

Conceptual, Logical, and Physical

• Conceptual answers what things exist and how they relate. Patients have encounters. Encounters generate diagnoses, procedures, and claims. No technology, no field names. One whiteboard.
• Logical answers what attributes each entity carries, what the keys are, what the cardinality is, and what the grain of each table is. Still platform-independent, but precise enough to argue about.
• Physical answers how it’s implemented: table definitions, data types, partitioning, indexes, clustering keys, file formats.

Most healthcare data projects fail at the logical layer. The conceptual model is obvious and the physical layer is a solved engineering problem. The hard part is deciding whether a row in your encounter table is a visit, a claim, a claim line, or an episode of care, and then defending that decision when someone’s report doesn’t tie.

Grain is the Decision That Matters Most

The grain of a table is what one row represents. Get it wrong and every downstream number is wrong in a way that’s difficult to detect and expensive to fix.

Healthcare grain decisions that reliably cause trouble:

• Claim versus claim line. A single claim can carry dozens of lines with different procedure codes, dates, and amounts. Summing at the wrong level double counts or loses detail.
• Encounter versus visit versus episode. A hospital stay is one admission, many daily charges, several departments, and possibly multiple claims. An episode of care might span months.
• Member month. The workhorse grain of payer analytics, and the one most often defined inconsistently across teams.
• Lab result versus lab panel. A CBC is one order and roughly a dozen results.
• Medication order versus dispense versus administration. Three different events, three different tables, three different truths about whether the patient took the drug.

Write your grain definitions down in plain language, put them in the table description, and enforce them with tests. This is unglamorous and it prevents more incidents than any tooling decision you’ll make.

Why Healthcare Data Modeling is Harder than Other Domains?

People arriving from retail or finance often assume healthcare is just another transactional domain with worse acronyms. It isn’t. Several properties genuinely differ.

1. Time is Complicated

Healthcare data is bitemporal. Every fact has a time when it happened and a separate time when the system learned about it. Claims arrive weeks or months after service and get adjusted, reversed, and resubmitted. Diagnoses get added retroactively. Enrollment terminates backdated to the first of a prior month.

A model that stores only current state cannot answer “what did we know on the day we made that decision?” For risk adjustment, quality reporting, and any audit defense, that question is not optional. Claims runout and completion factors exist precisely because of this.

2. The Same Fact Arrives From Multiple Sources and They Disagree

A patient’s diabetes diagnosis might appear in a claim, a problem list, an encounter diagnosis, an HCC submission, and a lab value implying it. These will conflict on date, specificity, and existence.

Your model needs a deliberate answer to source-of-truth conflicts, and “whichever loaded last” is not an answer.

3. Meaning Lives in Vocabularies, Not Columns

A value of 250.00 means nothing without knowing it’s ICD-9. The codes carry the semantics:

• ICD-10-CM for diagnoses, ICD-10-PCS for inpatient procedures
• CPT and HCPCS for professional and outpatient procedures
• SNOMED CT for clinical findings, the terminology most EHRs use internally
• LOINC for labs and observations
• RxNorm for medications, NDC for dispensed products, CVX for vaccines
• UB-04 revenue codes, place of service, DRG, taxonomy codes on the administrative side

A healthcare data model without a terminology strategy is a pile of strings. You need code system identifiers stored alongside every code, a mapping layer, and versioning, because ICD-10-CM changes annually and value sets change with measure years.

4. Identity is Not Given

There’s no national patient identifier in the United States. Patients arrive with different name spellings, addresses, and member IDs across sources. Your model needs an enterprise identifier, a crosswalk to source identifiers, and an honest accounting of match confidence. Provider identity is nearly as messy, with NPIs, TINs, group affiliations, and location hierarchies that change constantly.

5. Attributes Change and History Matters

Patient address, primary care attribution, plan enrollment, provider group, risk score. All of these change over time, and analytics almost always needs the value as of a point in time rather than today’s value. That means slowly changing dimensions, effective date ranges, and the discipline to use them.

6. Regulation Shapes the Schema

HIPAA minimum necessary, 42 CFR Part 2 for substance use disorder records, and state laws on behavioral health, HIV status, and reproductive health all mean some data classes need separate handling, segmented access, and provenance tracking. This is a modeling requirement, not just a security configuration.

The Main Healthcare Data Modeling Paradigms

Four approaches account for most of what you’ll encounter. They are not mutually exclusive, and mature organizations use several in layers.

1. Normalized (Third Normal Form)

The Inmon-style approach: an integrated, normalized enterprise warehouse feeding purpose-built marts.

Good for: integration integrity, avoiding update anomalies, a single defensible source layer. Bad for: query performance and analyst comprehension. A question that touches patients, encounters, diagnoses, and providers can require a dozen joins.

2. Dimensional Modeling (Star Schema)

The Kimball approach, and still the most common shape for a healthcare data warehouse serving BI and reporting.

Facts are the measurable events. Dimensions are the descriptive context.

• Fact tables: claim lines, encounters, lab results, medication dispenses, member months
• Dimensions: patient, provider, facility, date, plan, diagnosis, procedure, coverage

A star schema is fast, comprehensible, and works well with BI tools. Analysts can read it without a data engineer translating.

Its weakness in healthcare is that conformed dimensions across sources are genuinely hard, and a rigid star can be painful to extend when a new source arrives with a different shape.

3. Data Vault 2.0

Hubs for business keys, links for relationships, satellites for descriptive attributes and history.

Data Vault fits healthcare unusually well, and it’s underused. It’s built for exactly the conditions healthcare imposes: many sources describing the same entities, constant schema change, full history retention, and auditability by design. Satellites keep every source’s version of the truth with load timestamps, so you never lose the ability to reconstruct what you knew and when.

The cost is complexity and row counts. Nobody queries a raw vault directly. You build dimensional marts on top of it.

The pattern that works for most large organizations: raw landing, then Data Vault for integration and history, then star schemas for consumption.

4. One Big Table and Wide Denormalized Structures

For machine learning and some analytics, a wide patient-level or patient-period-level table with hundreds of engineered features beats any normalized structure. Cheap columnar storage made this practical.

Good for: model training, feature reuse, fast iteration. Bad for: as a source of truth. Treat wide tables as derived outputs with defined lineage, never as the place data lives.

Medallion Layers Are Not a Data Model

Bronze, silver, gold is a layering convention, not a modeling paradigm. It tells you nothing about grain, keys, or history. Teams that adopt medallion terminology and skip the modeling work end up with three copies of an unmodeled mess. You still have to decide what a row means in the gold layer.

Approach	Best at	Weakest at	Typical healthcare use
Normalized 3NF	Integration integrity	Query performance	Source-aligned staging
Star schema	BI, reporting, clarity	Handling new sources	Marts for quality, finance, utilization
Data Vault 2.0	History, audit, many sources	Complexity, sprawl	Integration layer under marts
Wide tables	ML and feature reuse	Being a source of truth	Risk models, propensity scoring
OMOP CDM	Portable research, RWE	Operational reporting	Observational studies, network research

Common Data Models in Healthcare

A common data model is a published, standardized schema that multiple organizations adopt so that analytic code written once runs anywhere. This is a different goal from a warehouse designed for your own reporting, and it’s why common data models look strange to BI teams.

1. OMOP CDM

The OMOP Common Data Model, maintained by the OHDSI community, is the dominant common data model for observational research and real-world evidence. Version 5.4 is the widely deployed release.

Its structure is person-centric and event-oriented:

• person, observation_period, death
• visit_occurrence and visit_detail
• condition_occurrence, procedure_occurrence, drug_exposure, device_exposure
• measurement for quantitative results, observation for everything else
• note and note_nlp for unstructured text and its extraction
• payer_plan_period and cost for the financial side
• Vocabulary tables: concept, concept_relationship, concept_ancestor, concept_synonym

OMOP’s real contribution is the vocabulary layer, not the table layout. Source codes get mapped to standard concepts with a single concept_id, and the concept_ancestor table encodes hierarchy so a query for “any diabetes” resolves without hand-listing codes. That is what makes analytic code portable across institutions.

Choose OMOP when you’re doing observational research, participating in a research network, or generating real-world evidence, and you want to run standardized analytics packages.

Don’t choose OMOP when your primary need is operational or financial reporting. The ETL is substantial, the mapping work is ongoing, and the model deliberately discards source detail that your finance team will ask about.

2. FHIR as a Data Model

FHIR is an exchange model, not an analytics model. This distinction gets blurred constantly and it causes real damage.

FHIR resources are optimized for API request and response: nested JSON, references between resources, extensions everywhere. That’s excellent for moving one patient’s data and painful for aggregate analysis. Querying “average A1c by provider” across a raw FHIR store means flattening deeply nested documents at scale.

The practical pattern:

• Ingest with FHIR, especially via Bulk FHIR export to newline-delimited JSON
• Land the raw resources for provenance
• Flatten and model into dimensional or OMOP structures for analysis

Regulatory pressure is pushing more organizations into FHIR ingestion whether they planned for it or not. TEFCA has committed to FHIR-based exchange, and CMS payer API requirements including the prior authorization APIs run on FHIR implementation guides. Building the FHIR-to-analytics flattening layer is fast becoming standard infrastructure rather than a special project.

3. i2b2

An older star schema built around a single massive observation_fact table with a flexible concept dimension. Widely deployed in academic medical centers for cohort discovery. Its generic fact design makes it simple to load and awkward to query precisely.

4. PCORnet and Sentinel CDMs

• PCORnet CDM supports the national patient-centered research network, with a relational structure closer to claims and EHR source shapes than OMOP’s concept-normalized approach.
• The Sentinel Common Data Model, developed for FDA’s active surveillance program, is built for distributed queries against claims-heavy data.

Both are less abstracted than OMOP, which makes ETL easier and cross-network semantic consistency weaker.

5. openEHR

A dual-model approach separating a stable reference model from clinical content defined in archetypes and templates. Strong clinical expressiveness and much wider adoption in Europe than in the United States.

USCDI Is a List, Not a Model

The United States Core Data for Interoperability specifies which data classes and elements must be exchangeable. It does not specify a schema. Certified health IT was required to support USCDI v3 as of January 1, 2026, with later versions in the pipeline. Treat USCDI as a coverage requirement to satisfy, not a model to implement.

6. CDISC SDTM and ADaM

For regulated clinical trials, SDTM standardizes collected data and ADaM standardizes analysis-ready datasets for submission. Entirely separate lineage from the observational world, and mandatory if you’re filing with FDA.

EHR and Payer Data Models in the Real World

Standards are what you read about. Vendor models are what you actually query.

1. EHR Data Models

Epic runs on Chronicles, a hierarchical database, and exposes analytics through Clarity, a normalized relational extract with thousands of tables, and Caboodle, a dimensional warehouse. Most Epic analytics work happens in Caboodle, with Clarity for detail Caboodle doesn’t carry. Both are Epic’s schemas, not yours, and both change with upgrades.

Oracle Health (Cerner) exposes Millennium data through its own reporting structures and the HealtheIntent population platform.

MEDITECH provides the Data Repository as its relational reporting layer.

Every one of these is a vendor-defined physical model. Building your enterprise model directly on vendor table structures couples your analytics to their release cycle. Land it, then map it into your own model.

2. Claims and Payer Data Models

Payer data arrives shaped by EDI transactions rather than clinical workflow:

• 837 for claims submitted, 835 for remittance
• 834 for enrollment and maintenance
• NCPDP standards for pharmacy claims
• 270/271 for eligibility inquiry and response

A claims data model typically centers on:

• Claim header and claim line facts, at explicit and separate grains
• Enrollment spans with effective dates, plan, product, and line of business
• Provider dimension with NPI, TIN, specialty, and network status as of service date
• Member dimension with slowly changing attributes
• Member month as the denominator grain for utilization and cost metrics

Layered on top sit the analytic constructs that drive the business: HCC and RAF calculations, HEDIS value sets, Star measure logic, episode groupers, and risk-adjusted benchmarks. These are not raw data. They’re derived models with their own versioning problems, because measure specifications change every year and last year’s numbers must remain reproducible.

Modeling for AI and Machine Learning

This is where most published guidance on healthcare data models is a decade out of date.

Traditional warehouse modeling assumed a human wrote a query and read a number. Increasingly the consumer is a model, and that changes requirements.

• Unstructured text becomes first-class. Clinical notes, pathology reports, and imaging narratives carry information that never made it into a coded field. Your model needs a place for documents, their metadata, and the extractions derived from them, with links back to the source. OMOP’s note and note_nlp tables were an early version of this idea.
• Vector storage sits beside relational, not instead of it. Embeddings for retrieval, with the relational model providing filters, permissions, and provenance. Retrieval that can’t filter by patient, date range, and access rights is not usable in healthcare.
• Point-in-time correctness becomes a hard requirement. Training a model on data that leaked future information is the most common serious error in healthcare ML. Your model must be able to reconstruct feature values as of a prediction date. Bitemporal design pays for itself here.
• Feature definitions need governance. The same feature computed two ways in two projects produces two models nobody can reconcile. A semantic or metrics layer with versioned definitions is the fix.
• Provenance becomes a compliance artifact. When a model output influences a clinical or coverage decision, you need to show which data produced it. That’s lineage down to the row, which is much easier if you kept history in the first place.

The organizations doing this well are not the ones with the newest platform. They’re the ones whose data model preserved history and provenance before anyone asked them to.

How to Choose a Healthcare Data Model

Start from the use case, not the technology.

If your primary need is	Build toward
Operational and financial reporting	Dimensional star schemas
Multi-source integration with full audit history	Data Vault, then dimensional marts
Observational research and real-world evidence	OMOP CDM
Data exchange and regulatory APIs	FHIR, with a flattening layer for analytics
Regulated clinical trial submission	CDISC SDTM and ADaM
Machine learning and risk models	Wide feature tables derived from a modeled core
Quality measurement and Stars	Dimensional marts plus versioned measure logic

Three principles that hold regardless of choice:

1. Separate ingestion, integration, and consumption. Land raw and immutable, integrate with history, then serve purpose-shaped marts. Trying to do all three in one layer is the most common architectural mistake.
2. Never model directly on a vendor schema. Land it, map it, own your model.
3. Write the grain and the source-of-truth rules down. In the table description, in the docs, in the tests. Ambiguity here compounds forever.

Common Healthcare Data Modeling Mistakes

• Overwriting history. Updating a patient’s attributed PCP in place destroys your ability to reproduce last quarter’s report. Use effective dating.
• Storing codes without code systems. A bare code column is a future incident.
• Mixing grains in one table. Header and line data in a single fact table guarantees double counting.
• Treating a common data model as a warehouse. OMOP is not a reporting layer. Standing one up and pointing finance at it disappoints everyone.
• Modeling for today’s source list. A new payer feed, a practice acquisition, or an EHR migration will arrive. Design for the second and third source.
• Skipping identity resolution. Duplicate patients silently corrupt every rate, ratio, and cohort count.
• Ignoring completeness lag. Reporting recent claims periods without runout adjustment produces numbers that keep changing after publication.
• Letting derived metrics live in BI tools. Measure logic buried in a dashboard is unversioned, untestable, and unfindable.

Frequently Asked Questions

What is a healthcare data model?

A structured definition of how clinical, claims, and administrative data are organized: which entities exist, how they relate, what a single row represents, and which code systems give values meaning. It exists at conceptual, logical, and physical levels.

What is the OMOP common data model?

A standardized schema and vocabulary maintained by the OHDSI community for observational health research. It normalizes source codes into standard concepts so analytic code written at one institution runs at another. Version 5.4 is the widely deployed release.

Is FHIR a data model?

Yes, but an exchange model rather than an analytics model. FHIR defines resources and an API for moving data between systems. For aggregate analysis, organizations typically ingest FHIR, land it raw, then flatten it into dimensional or OMOP structures.

What is the difference between OMOP and FHIR?

Purpose. FHIR moves data between systems using nested resources over a REST API. OMOP stores data for population analysis in flat, concept-normalized tables. Many organizations use both: FHIR to acquire, OMOP to analyze.

Should I use a star schema or Data Vault for healthcare data?

Both, in layers. Data Vault handles multi-source integration and history well, which suits healthcare’s constant schema change and audit requirements. Star schemas serve reporting and BI. The common pattern is a vault integration layer with dimensional marts on top.

What is grain in healthcare data modeling?

What one row represents. Claim versus claim line, encounter versus episode, member month, lab result versus panel. Grain errors are the leading cause of numbers that don’t tie.

Why is healthcare data modeling so difficult? Bitemporal data with retroactive corrections, the same fact arriving from conflicting sources, meaning encoded in multiple changing vocabularies, no national patient identifier, attributes that change over time, and regulatory constraints that require segmented handling of specific data classes.

Where to Start

If you’re standing up or rescuing a healthcare data model, three moves produce disproportionate returns.

Write down the grain of your five most-used tables, in one sentence each, and circulate it. You will find disagreement immediately, and finding it now is much cheaper than finding it during an audit.

Pick one metric that multiple teams report differently and trace it to the model. Member months, readmission rate, PMPM, gap closure rate. The trace will expose exactly which modeling decisions were never made, and it makes the case for the work better than any architecture diagram.

Decide your history strategy before your next source goes live. Effective dating, satellites, snapshots, whichever fits. Retrofitting history onto a model that overwrote it is the most expensive remediation in this domain, and it’s the one nobody budgets for.

A patient collapses in a Phoenix emergency department. She’s from Ohio. Her cardiology history, her medication list, the stent placed eighteen months ago: all of it exists in a chart somewhere, and none of it is in front of the physician deciding what to do in the next ten minutes.

For twenty years the industry’s answer to that problem was to build more networks. Regional HIEs, vendor networks, national frameworks, point-to-point interfaces. The result was interoperability that worked beautifully inside each network and unpredictably between them. Whether the Phoenix physician got those Ohio records depended less on technology than on whether two organizations happened to share a legal agreement.

TEFCA is the attempt to fix the legal layer rather than the technical one. That distinction is the whole point, and it’s the part most explainers skip.

This guide covers what TEFCA is, how data actually moves through it, what changed in TEFCA 2.0, how it relates to information blocking rules, and where it still comes up short.

What is TEFCA?

TEFCA is the Trusted Exchange Framework and Common Agreement: a nationwide set of legal terms and technical rules that lets healthcare organizations exchange data with each other after signing one agreement instead of hundreds.

It exists because Congress told it to. Section 4003 of the 21st Century Cures Act (2016) directed the Office of the National Coordinator for Health IT to develop a trusted exchange framework and common agreement for nationwide interoperability. ONC, now the Assistant Secretary for Technology Policy (ASTP/ONC) after a 2024 reorganization, designated The Sequoia Project as the Recognized Coordinating Entity in 2019. Sequoia runs the day-to-day program: onboarding, dispute resolution, and the rulebook.

Put plainly: TEFCA healthcare data exchange swaps a web of bilateral contracts for one shared rulebook. The core promise is sometimes called “connect once, connect to all.” Sign the agreement, connect through one network, and you inherit trusted connections to every other organization in the framework.

The Four Pieces of the TEFCA Framework

People use “TEFCA framework” loosely. It’s actually four distinct documents, and knowing which one governs what saves a lot of confusion:

• The Trusted Exchange Framework (TEF) is the principles document. Non-binding, aspirational, short. Almost nobody needs to read it twice.
• The Common Agreement (CA) is the binding contract. QHINs sign it with the RCE, and its terms flow downstream to every Participant and Subparticipant. This is the document that does the real work.
• The QHIN Technical Framework (QTF) specifies the technical requirements: transaction patterns, security, identity, message formats.
• Standard Operating Procedures (SOPs) cover the operational detail: how exchange purposes work, cybersecurity expectations, how disputes get handled, how organizations onboard.

The SOP layer matters more than it sounds. Moving requirements into SOPs lets Sequoia change operational rules without renegotiating a contract with every QHIN, which is why the program can evolve faster than a federal rulemaking cycle.

What TEFCA is Not?

Three clarifications that head off most misconceptions:

• TEFCA is not a network. It’s a set of rules that networks agree to follow. Data doesn’t flow “through TEFCA” any more than a wire transfer flows through banking law.
• TEFCA is not mandatory. Participation is voluntary. No provider or payer is legally required to join.
• TEFCA is not a replacement for HIPAA. HIPAA still governs permitted uses and disclosures. TEFCA adds contractual obligations on top, and it extends similar privacy and security duties to non-HIPAA entities that participate.

How TEFCA Works: QHINs, Participants, and Subparticipants

TEFCA data exchange runs through a tiered structure. Each tier has different obligations, and the tier you occupy determines your cost, your control, and your compliance burden.

The Exchange Hierarchy

ASTP/ONC sets policy. The Sequoia Project administers the program as RCE.

QHINs (Qualified Health Information Networks) sit at the top of the operational stack. A QHIN signs the Common Agreement directly, connects to every other QHIN, and routes queries and responses across the network. Becoming a QHIN is demanding: technical testing, security review, financial and operational vetting, and an obligation to serve a broad participant base rather than a single corporate parent.

Participants connect through a QHIN. Most health systems, large medical groups, payers, and HIE organizations land here.

Subparticipants connect through a Participant. A small practice connecting through its EHR vendor’s network, or a clinic connecting through a regional HIE, is typically a Subparticipant. Obligations flow down by contract, so a Subparticipant is bound by Common Agreement terms even though it never signed the Common Agreement.

Individuals access their own records through Individual Access Services, delivered by an IAS Provider.

Who the QHINs Are

The first five QHINs were designated in December 2023: eHealth Exchange, Epic Nexus, Health Gorilla, KONZA National Network, and MedAllies. CommonWell Health Alliance, Kno2, and Availity followed.

As of early 2026 there were roughly eight designated QHINs, with additional candidates working through onboarding. The list changes, so check the Sequoia Project’s current designation page before making a selection decision.

The mix tells you something useful. You have an EHR vendor network (Epic Nexus), a payer-oriented clearinghouse (Availity), API-first data companies (Health Gorilla, Kno2), legacy national networks (eHealth Exchange, CommonWell), and a public-health-leaning regional network (KONZA). Your choice of QHIN is a strategic decision, not a commodity procurement. A provider organization optimizing for treatment queries and a payer optimizing for risk adjustment data will find very different fits.

TEFCA Exchange Purposes

An Exchange Purpose (XP) is the permitted reason for a request. Every TEFCA transaction carries one, and the XP determines whether a responder is obligated to answer.

The defined exchange purposes are:

• Treatment, which covers clinical care and is the highest-volume XP by a wide margin
• Payment
• Health Care Operations
• Public Health
• Government Benefits Determination
• Individual Access Services (IAS), which lets a person request their own records

The word to watch is obligation. Some exchange purposes carry a required response, meaning a Participant must answer a valid query. Others are permitted but optional. The specific obligations, and their phase-in dates, live in the Exchange Purpose SOP rather than in the Common Agreement itself.

This is where TEFCA gets politically interesting. Providers broadly accepted required response for Treatment. Extending required response into Payment and Health Care Operations drew real objections, because those XPs let payers pull clinical data for uses including utilization review and quality reporting. Provider groups argued they were being conscripted into supplying data that would be used against them in payment decisions. Payers argued they already have HIPAA rights to that data and were merely getting a better pipe.

Both positions are defensible. Neither side considers the matter closed.

TEFCA 2.0: What Changed?

Common Agreement Version 2.0 and QTF 2.0 were published in July 2024, roughly two and a half years after version 1.0. TEFCA 2.0 was less a rewrite than a shift in architecture and governance.

1. FHIR Moved From Optional to Required

Version 1.0 ran overwhelmingly on document-based exchange: IHE profiles moving C-CDA documents. That works for “send me this patient’s chart summary.” It works poorly for “give me this patient’s last four A1c values.”

TEFCA 2.0 committed the program to FHIR-based exchange, implemented as Facilitated FHIR, in which the QHIN handles record location and identity resolution and then the parties exchange FHIR resources more directly. Sequoia published a FHIR Roadmap with staged milestones running into 2026 and beyond.

This is the most consequential change in TEFCA 2.0. Document exchange satisfies the letter of interoperability. Granular FHIR queries are what actually enable computable data: population analytics, risk adjustment, clinical decision support, quality measurement. Anyone evaluating TEFCA for anything beyond chart retrieval should be reading the FHIR Roadmap, not the marketing material.

2. Governance Moved into SOPs

Version 2.0 pulled substantial operational detail out of the contract and into SOPs. Less elegant, far more practical. It means requirements can be updated without a multi-party contract amendment.

3. Exchange Purpose Obligations Broadened

TEFCA 2.0 expanded which exchange purposes QHINs must support and tightened the phase-in schedule, including Payment, Health Care Operations, and Public Health alongside Treatment and Individual Access Services.

4. Security Expectations Hardened

Version 2.0 formalized cybersecurity obligations, added a Cybersecurity Council, and clarified incident reporting duties. Given that a QHIN sits astride nationwide clinical data flows, this was overdue rather than innovative.

TEFCA and Information Blocking

TEFCA and the information blocking rules are separate regulations that lean on each other.

Under ASTP/ONC’s HTI-1 final rule (published December 2023, effective 2024), the information blocking exceptions include a TEFCA Manner Exception. In broad terms, if an actor and a requestor are both TEFCA participants and the actor fulfills the request via TEFCA, that can satisfy the manner in which the request must be met, even if the requestor asked for a different method.

Read the actual conditions before relying on this. The exception is narrower than the summaries suggest, and it does not convert TEFCA participation into blanket information blocking protection. It also does not make TEFCA mandatory. What it does is give organizations a defensible, standardized way to respond, which is a meaningful compliance advantage in practice.

Subsequent ASTP/ONC rulemaking through 2024 and 2025 continued adjusting information blocking definitions and certification requirements. Confirm current requirements against the published rules rather than secondary coverage, because this area has moved repeatedly.

TEFCA vs. Carequality, CommonWell, and eHealth Exchange

The most common question about TEFCA is why it exists when national exchange networks already did.

The short answer: the older frameworks solved technical connectivity. They did not solve universal legal trust.

• Carequality provided a trust framework and legal terms that let networks connect to each other. Effective, widely adopted, and governed by its own participants rather than by federal designation.
• CommonWell Health Alliance operated as a vendor-founded network with record locator services, and is now itself a QHIN.
• eHealth Exchange grew out of the federal Nationwide Health Information Network and carried heavy federal agency participation. Also now a QHIN.

Those frameworks overlapped, competed, and required organizations to join several to achieve broad reach. TEFCA’s contribution is a single floor of legal trust with federal backing, which the prior arrangements could not provide because no participant had standing to impose one.

Practically, the older networks did not disappear. Several became QHINs, and their existing exchange continues alongside TEFCA flows. Expect consolidation over time, but verify current status directly, because network relationships in this space have shifted more than once and continue to.

Who Actually Benefits From TEFCA?

1. Health Systems and Providers

The concrete win is record retrieval for unaffiliated patients: the transfer from a hospital across the state, the traveler in the ED, the new patient with a decade of history somewhere else. Broader query reach means fewer repeated tests and less clinical guesswork.

The concrete cost is responding to queries you’d rather not answer, particularly under Payment and Health Care Operations, plus onboarding effort and QHIN fees.

2. Health Plans

Payers get a standardized path to clinical data for risk adjustment, HEDIS and Star measure abstraction, utilization review, and care management. Chart chases are among the most expensive manual workflows in payer operations, and TEFCA offers a credible alternative to fax-and-courier retrieval.

It is not a solved problem yet. Document-based responses still require abstraction, coverage is uneven, and Facilitated FHIR is where the real efficiency lives. Payers should be planning against the FHIR timeline rather than the current state.

3. Public Health

Public Health as a named exchange purpose gives agencies a standing pathway for case reporting, registry submission, and outbreak investigation. The pandemic made the cost of ad hoc public health data plumbing painfully clear.

4. Digital Health and Health IT Vendors

For vendors, TEFCA is a distribution question. Connecting through a QHIN as a Participant, or offering Subparticipant connectivity to customers, can replace dozens of bespoke integrations. Vendors building patient-facing products should look closely at Individual Access Services, which is the most direct route to patient-authorized record aggregation at national scale.

5. Patients

IAS is the patient-facing piece: request your own records through an app, without filing a written request at every provider you’ve seen. Adoption has been slower than the framework’s authors hoped, and identity proofing requirements are a genuine friction point, but this is the tier with the most headroom.

How to Join TEFCA?

The process is more tractable than the acronym density suggests.

1. Decide your tier. Almost no one should pursue QHIN status. The realistic question is Participant or Subparticipant. Participant gives more control and costs more; Subparticipant is faster and cheaper with less say.
2. Pick your QHIN. Evaluate on exchange purposes supported, FHIR readiness and roadmap, existing network reach in your service area, pricing model, and whether your EHR already has a path. If you run Epic, Epic Nexus is the obvious first conversation, but obvious is not automatically correct.
3. Work the legal terms. Review the flow-down obligations carefully. Common Agreement terms bind you contractually even at Subparticipant level, and they include privacy, security, breach notification, and audit duties.
4. Plan the technical work. Patient identity matching, C-CDA generation quality, FHIR endpoint readiness, consent management, and audit logging. Identity matching is where most implementations struggle, and it deserves attention early rather than at go-live.
5. Build the response side. Organizations consistently underestimate this. You are not just querying; you are obligated to respond. That means a policy for handling incoming requests by exchange purpose, and someone accountable for it.
6. Govern it. Assign ownership for exchange purpose policy, consent handling, and audit review. TEFCA obligations are ongoing, not a project with an end date.

Where TEFCA Still Falls Short?

An honest assessment has to include the gaps.

• Voluntary participation limits reach. A framework that nobody must join will have holes, and the holes tend to be in exactly the under-resourced settings where data is hardest to get.
• Document-based exchange remains dominant. Until Facilitated FHIR is widely implemented, much TEFCA traffic delivers PDFs and C-CDAs that still require human abstraction. The pipe improved; the payload often did not.
• Data quality is not addressed. TEFCA governs whether data moves. It has little to say about whether the C-CDA you receive is a well-structured summary or a 90-page document dump with the relevant note buried on page 62.
• Patient identity matching is unsolved nationally. Without a national patient identifier, matching relies on demographic algorithms that fail at the margins, and the margins are where patients get hurt.
• The Payment and Health Care Operations question is unresolved. Required response for these purposes remains contested, and reasonable people continue to disagree.
• Cost falls unevenly. QHIN and Participant fees are easier for large systems to absorb than for federally qualified health centers, rural hospitals, and independent practices.
• Consent handling is complicated by state law. Behavioral health, substance use disorder records under 42 CFR Part 2, HIV status, and reproductive health data carry state-specific and federal restrictions that a national framework cannot fully harmonize.

TEFCA in 2026 and Beyond

Three things worth watching.

FHIR milestones. The Facilitated FHIR timeline is the single best indicator of whether TEFCA becomes infrastructure or stays a document retrieval utility. Track actual QHIN implementations against the roadmap, not announcements.

Federal policy alignment. In mid-2025 CMS announced a voluntary interoperability commitment involving a large group of health IT companies, payers, and providers, focused on patient-facing digital tools and data sharing. It runs alongside TEFCA rather than replacing it, and the relationship between these initiatives is still taking shape. This is an area where things have moved quickly, so verify current status.

Consolidation. With multiple QHINs competing and legacy frameworks converging, some consolidation is likely. Pick a QHIN with a plausible independent future, and read your exit terms.

Frequently Asked Questions

What is TEFCA in healthcare?

TEFCA is the nationwide legal and technical framework that lets healthcare organizations share patient data after signing a single agreement rather than negotiating separate contracts with every partner. In day-to-day terms, it is how a hospital in one state can pull records from a clinic in another without a preexisting relationship between them.

What does TEFCA stand for?

Trusted Exchange Framework and Common Agreement. It was mandated by Section 4003 of the 21st Century Cures Act and is administered by The Sequoia Project as Recognized Coordinating Entity under ASTP/ONC.

Is TEFCA mandatory?

No. Participation is voluntary for providers, payers, and vendors. Information blocking rules create indirect pressure by making TEFCA a defensible way to fulfill requests, but they do not require joining.

What is a QHIN?

A Qualified Health Information Network: an organization designated to sign the Common Agreement directly, connect to all other QHINs, and route exchange for its Participants. As of early 2026 there were roughly eight designated QHINs.

What is the difference between TEFCA and Carequality?

Carequality is a participant-governed trust framework that connects networks to each other. TEFCA is federally mandated, administered by a designated coordinating entity, and establishes a single nationwide floor of legal trust. Several organizations participate in both, and some Carequality-connected networks are now QHINs.

What changed in TEFCA 2.0?

Common Agreement 2.0 and QTF 2.0, published in July 2024, committed the program to FHIR-based exchange through Facilitated FHIR, moved operational requirements into SOPs, broadened exchange purpose support obligations, and strengthened cybersecurity requirements.

Does TEFCA use FHIR?

Increasingly. Version 1.0 exchange was predominantly document-based using IHE profiles and C-CDA. TEFCA 2.0 requires FHIR support on a staged timeline defined in Sequoia’s FHIR Roadmap.

Can patients use TEFCA to get their own records?

Yes, through Individual Access Services. A patient uses an IAS Provider application, completes identity proofing, and requests records from participating organizations. Availability depends on which IAS applications and providers are live.

How much does joining TEFCA cost?

There is no published standard price. Fees vary by QHIN, by tier, and by negotiated terms, and many EHR and HIE arrangements bundle connectivity into existing contracts. Get quotes from multiple QHINs.

Does TEFCA replace HIPAA?

No. HIPAA continues to govern permitted uses and disclosures. TEFCA adds contractual obligations and extends comparable privacy and security duties to participating entities that HIPAA does not otherwise cover.

What to Do Next

If you are evaluating TEFCA, the useful first step is not reading the Common Agreement. It’s answering one question: are you joining primarily to query, or primarily because you’ll be obligated to respond?

Organizations that join to query build a business case around avoided duplicate testing, faster transfers, and cheaper record retrieval. Organizations that join because responding is coming anyway should focus on response infrastructure, exchange purpose policy, and C-CDA quality, because that is where the effort will actually land.

Then get concrete: ask your EHR vendor which QHIN they support and on what timeline, ask two QHINs for pricing and FHIR roadmaps, and ask your privacy officer how you’ll handle consent for sensitive data categories under your state’s law. Those three conversations will tell you more than another month of reading.

A care manager at a mid-sized ACO opens four browser tabs before her first patient call of the day. One for the health plan’s care management platform. One for the hospital’s Epic portal. One for the primary care group’s athenahealth instance. One for a spreadsheet where she manually reconciles what the other three disagree about.

She is not an outlier. She is the norm.

That daily tab-juggling ritual is what happens when electronic medical records don’t talk to each other. EMR integration is the discipline of fixing it: connecting EMR and EHR systems to each other and to the platforms that actually run care management, billing, scheduling, quality reporting, and analytics.

This guide covers how EMR integration works in 2026, which methods and standards matter (FHIR, HL7, APIs, TEFCA), what it costs, where projects fail, and how to build an integration roadmap that holds up under real clinical and regulatory pressure.

What is EMR Integration?

EMR integration is the process of connecting an electronic medical record system with other software so that clinical and administrative data flows between them automatically, in a structured format, without manual re-entry.

The “other software” can be almost anything a healthcare organization runs:

• Care management and population health platforms
• Practice management and scheduling systems
• Labs, imaging systems, and pharmacies
• Billing, claims, and revenue cycle tools
• Telehealth platforms and remote patient monitoring devices
• Health information exchanges (HIEs) and payer systems
• Analytics, risk adjustment, and quality reporting tools

At a technical level, integration means three things happen reliably:

1. Data moves between systems (via APIs, interface engines, or file exchange)
2. Data is understood on both sides (mapped to shared standards like FHIR resources or HL7 message types)
3. Data stays consistent (the same patient, the same medication, the same diagnosis means the same thing everywhere)

Most failed integration projects get the first part working and quietly fail at the second and third. Moving data is plumbing. Making it mean the same thing in two systems is the actual work.

Why EMR Integration Matters in 2026

EHR adoption is essentially a solved problem in the United States. According to the Office of the National Coordinator for Health IT (ONC, now ASTP), 96% of non-federal acute care hospitals and roughly 78% of office-based physicians use a certified EHR.

Adoption was the easy part. Connection is the hard part, and the gap is expensive.

The cost of disconnected systems

• Clinician burnout. A frequently cited time-motion study by Sinsky et al. in the Annals of Internal Medicine found physicians spend nearly two hours on EHR and desk work for every one hour of direct patient care. Manual data reconciliation between disconnected systems is a major contributor.
• Duplicate and mismatched records. AHIMA has reported that the average duplicate medical record rate within a single organization hovers around 10%, and patient match rates between organizations can fall far lower. Every mismatch is a safety risk and a billing error waiting to happen.
• Repeated tests and delayed care. When a specialist can’t see the labs a PCP already ordered, the test gets ordered again. Patients absorb the cost, and payers absorb the claims.
• Security exposure. IBM’s Cost of a Data Breach Report has placed healthcare’s average breach cost at roughly $10 million per incident, the highest of any industry for more than a decade running. Ad hoc integrations built on CSV exports and shared drives widen that attack surface.

The regulatory push

Regulators stopped asking politely years ago:

• The 21st Century Cures Act and its information blocking rules make it illegal, with real penalties, for providers and vendors to unreasonably restrict data exchange.
• The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires impacted payers to stand up FHIR-based Patient Access, Provider Access, and Payer-to-Payer APIs, with major compliance deadlines landing in 2026 and 2027.
• TEFCA (the Trusted Exchange Framework and Common Agreement) went live in late 2023 and now has multiple designated QHINs exchanging records nationwide.

If your integration strategy is still “we’ll get a flat file from the hospital once a month,” you are behind both your competitors and the compliance calendar.

EMR vs. EHR Integration: Is There a Difference?

You’ll see “EMR integration” and “EHR integration” used interchangeably, and in practice most vendors treat them as the same service. The technical distinction:

• An EMR (electronic medical record) is the digital chart within a single practice or organization.
• An EHR (electronic health record) is designed to be shared across organizations and settings.

The integration work is nearly identical either way: same standards, same interface engines, same patient-matching problems. The difference shows up in scope. EMR integration projects tend to focus on connecting one practice’s chart to its own surrounding tools. EHR integration and broader healthcare interoperability initiatives connect data across organizational boundaries, which is where consent management, HIE participation, and TEFCA enter the picture.

For the rest of this guide, “EMR integration” covers both, because that’s how buyers search for it and how vendors sell it.

Core EMR Integration Methods and Standards

There is no single “EMR integration API.” There is a stack of standards, each with a distinct job. Understanding which one fits which use case saves months of rework.

HL7 v2: The workhorse

HL7 v2 messaging has been moving clinical data since the late 1980s, and it still carries a huge share of real-world hospital traffic: ADT feeds (admissions, discharges, transfers), lab orders and results (ORM/ORU), and scheduling messages (SIU).

• Best for: Real-time event feeds from hospitals; lab and ADT connectivity
• Watch out for: Every hospital implements v2 slightly differently. “Standard” is generous. Budget for per-site mapping.

FHIR: The modern API standard

FHIR (Fast Healthcare Interoperability Resources), now on release R4 with R5 adoption growing, represents clinical data as discrete, web-friendly resources (Patient, Encounter, Observation, Condition, MedicationRequest) accessible over REST APIs.

FHIR matters because regulation made it unavoidable. ONC-certified EHRs must expose standardized FHIR APIs based on the US Core data set (USCDI), and CMS’s payer API mandates are FHIR-based. Epic, Oracle Health, athenahealth, MEDITECH, and eClinicalWorks all ship production FHIR endpoints today.

• Best for: App integration, patient access, payer data exchange, anything new you’re building in 2026
• Watch out for: Bulk data extraction at population scale still requires the FHIR Bulk Data (Flat FHIR) spec, and vendor support quality varies.

C-CDA documents

The Consolidated Clinical Document Architecture packages a patient’s summary (problems, meds, allergies, encounters) as a structured document. It powers transitions of care and much of today’s HIE exchange.

• Best for: Care summaries, referrals, HIE and TEFCA document exchange
• Watch out for: C-CDAs are notoriously bloated and inconsistent. Parsing them into clean, discrete data is a project in itself.

Direct database access and flat files

Some EMRs, particularly older ambulatory systems, still offer read replicas or scheduled extracts (CSV, pipe-delimited files over SFTP).

• Best for: Analytics backfills, historical data migration
• Watch out for: Fragile, batch-delayed, and easy to break with a vendor upgrade. Treat as a bridge, not a destination.

Integration engines and iPaaS

Tools like Mirth Connect (now NextGen Connect), Rhapsody, and cloud interface platforms sit between systems, translating HL7 to FHIR, routing messages, and handling retries. Newer healthcare iPaaS and API aggregators offer pre-built connectors to dozens of EMRs behind a single normalized API.

• Best for: Organizations connecting to many EMRs, or many systems to one EMR
• Watch out for: An engine doesn’t remove mapping work; it centralizes it. You still need people who understand the data.

Quick comparison

Method	Data Freshness	Typical Use Case	Effort Level
HL7 v2 feeds	Real-time	ADT, labs, scheduling	Moderate to high (per-site mapping)
FHIR APIs	Real-time / on-demand	Apps, payer APIs, patient access	Moderate
FHIR Bulk Data	Batch	Population-level extraction	Moderate
C-CDA exchange	Per-encounter	Referrals, care transitions, HIE	Moderate (parsing burden)
Flat files / SFTP	Daily or weekly	Analytics, migrations	Low to start, high to maintain
Integration engine / iPaaS	Varies	Multi-system orchestration	High upfront, lower ongoing

What Can Be Integrated: Common Use Cases

EMR integration is a means, not an end. These are the use cases organizations actually fund:

• Care management integration. Pushing ADT alerts, problem lists, and encounter data into a care management platform so outreach teams work from live clinical reality instead of 90-day-old claims.
• Referral and care coordination workflows. Closing the loop between PCPs, specialists, and post-acute providers with structured referrals instead of faxes. Yes, faxes are still out there in 2026.
• Risk adjustment and quality reporting. Extracting encounter and diagnosis data to support HCC recapture, HEDIS measure calculation, and Star Ratings work without chart-chasing every record by hand.
• Telehealth and remote monitoring. Writing virtual visit notes and device readings (blood pressure, glucose, weight) back into the chart so they inform clinical decisions.
• Scheduling and patient access. Letting digital front-door tools read real appointment availability and book directly into the EMR.
• Revenue cycle. Syncing charges, eligibility, and clinical documentation between the EMR and billing systems to cut denials tied to missing or mismatched data.
• Payer-provider exchange. Supplying health plans with clinical data for prior authorization, care gap closure, and the CMS-mandated payer APIs.

The Biggest EMR Integration Challenges

If integration were only a technical problem, it would have been solved a decade ago. The recurring failure points:

1. Patient matching

There is no national patient identifier in the US. Systems match patients on combinations of name, date of birth, address, and phone, and those fields drift constantly. A Pew Charitable Trusts analysis found match rates between organizations can drop dramatically without shared identifiers or standardized demographic formatting. Get matching wrong and every downstream integration inherits the error.

2. Non-standard “standards”

Two hospitals can both send HL7 v2 ADT feeds and populate the same fields completely differently. One site’s “discharge disposition” codes won’t match another’s. Interface analysts spend most of their time on this, not on connectivity.

3. Vendor gatekeeping and fees

Information blocking rules have improved behavior, but EMR vendors still control sandbox access, app review timelines, and per-connection fees. Some charge meaningful sums per interface, per site, per year. Factor vendor cooperation into timelines from day one.

4. Legacy systems

Plenty of ambulatory practices still run EMRs that predate FHIR entirely. Integrating them means flat files, screen-scraping-adjacent workarounds, or waiting on a system replacement.

5. Governance and data quality

Integration amplifies whatever data quality you already have. If three source systems disagree on a patient’s medication list, connecting them doesn’t resolve the disagreement; it just makes it visible in a fourth place. Someone has to own reconciliation rules, terminology mapping (ICD-10, SNOMED, LOINC, RxNorm), and a source-of-truth policy per data domain.

6. Security and compliance

Every new interface is a new place PHI travels. HIPAA requires business associate agreements, minimum-necessary scoping, audit logging, and encryption in transit and at rest for each connection. Consent gets even more complicated when behavioral health data under 42 CFR Part 2 enters the exchange.

How Much Does EMR Integration Cost?

Real numbers vary widely by EMR, method, and scope, but here are honest planning ranges based on how the market typically prices this work in 2025–2026:

• Single point-to-point interface (HL7 or FHIR): roughly $5,000–$50,000 to build, depending on complexity and vendor fees, plus ongoing maintenance
• EMR vendor interface fees: anywhere from nothing (open FHIR endpoints) to $5,000–$30,000+ per interface per year for certain legacy connections
• Integration engine implementation: commonly $50,000–$250,000+ for licensing, build, and staffing in the first year
• iPaaS / API aggregator platforms: typically subscription-priced per connection or per patient volume, which can be dramatically cheaper than custom builds when connecting to many EMRs
• Full multi-system integration program (hospital + ambulatory + payer feeds): easily six to seven figures over a multi-year roadmap

Two budgeting rules save the most pain:

1. Maintenance is not optional. Interfaces break when either side upgrades. Plan for 15–25% of build cost annually in upkeep.
2. The cheapest connection is the one you don’t build. Consolidating onto platforms with pre-built EMR connectivity often beats funding another bespoke interface.

A Step-by-Step EMR Integration Roadmap

A sequence that works, whether you’re a 10-provider group or a multi-state health plan:

Step 1: Start from the workflow, not the interface. Write down the specific decision or task the integration should improve. “Care managers see hospital discharges within 24 hours” is a project. “Integrate with Epic” is not.

Step 2: Inventory your systems and endpoints. List every EMR, version, hosting model, and what each one can expose today: FHIR endpoints, HL7 feeds, extracts. Ask vendors for their API documentation and fee schedules in writing.

Step 3: Pick the standard per use case. Real-time events lean HL7 v2 or FHIR Subscriptions. App and payer integration lean FHIR R4/US Core. Population analytics lean FHIR Bulk Data or governed extracts.

Step 4: Solve patient matching early. Choose your matching logic (deterministic, probabilistic, or a dedicated eMPI) before data starts flowing, not after duplicates appear.

Step 5: Map and validate the data. Build a data dictionary that maps every source field to a target concept and code system. Validate against real records with clinicians in the room. This step decides whether the project succeeds.

Step 6: Build security and consent in from the start. BAAs signed, access scoped to minimum necessary, audit logging on, Part 2 data flagged and segmented where applicable.

Step 7: Pilot with one site, one feed. Prove the loop end to end (data lands, users trust it, errors get caught) before scaling to every location.

Step 8: Monitor like production infrastructure. Interface queues, message error rates, and match rates need dashboards and owners. Silent interface failures are how a “connected” organization quietly runs on stale data for six weeks.

EMR Integration for Health Plans, ACOs, and Medical Groups

The same technology serves very different goals depending on where you sit:

Health plans integrate to get clinical data that claims can’t provide: real-time admission alerts for high-cost members, supplemental data for HEDIS and Star Ratings, documentation for risk adjustment, and the FHIR APIs CMS now requires. The core challenge is scale: a regional plan may need data from hundreds of provider EMR instances, which makes aggregation platforms and HIE/TEFCA participation far more practical than point-to-point builds.

ACOs and value-based care organizations live and die on timely data. Shared savings depend on knowing about ED visits and admissions while intervention is still possible. ADT feeds plus a unified care management layer is usually the highest-ROI integration an ACO can fund.

Medical groups and MSOs typically integrate to remove swivel-chair work: scheduling tools, telehealth, quality dashboards, and billing all reading from and writing to the chart. For groups running multiple EMRs across acquired practices, a normalization layer beats forcing a disruptive EMR consolidation on day one.

2026 Trends: TEFCA, AI, and API-First Integration

Four shifts are reshaping EMR integration right now:

• TEFCA is becoming real infrastructure. With multiple QHINs live and exchange volume growing, nationwide record location is moving from pilot to plumbing. Organizations are starting to ask “can we get this through TEFCA?” before funding a custom interface.
• CMS payer API deadlines are forcing the issue. The 2026–2027 compliance dates for Payer-to-Payer and Prior Authorization APIs under CMS-0057-F mean health plans can no longer treat FHIR as a future project.
• AI is entering the integration layer. Machine learning is now used for probabilistic patient matching, auto-mapping nonstandard HL7 fields, and extracting structured data from clinical notes and faxed documents, cutting some of the manual mapping burden that has defined interface work for decades.
• Buyers are choosing platforms over projects. The market is moving away from funding one bespoke interface at a time and toward platforms with pre-built EMR connectivity, embedded data normalization, and workflow tools on top, so integration becomes a feature rather than a standing engineering program.

Frequently Asked Questions

What is EMR integration in healthcare?

EMR integration is the process of connecting an electronic medical record system with other healthcare software (care management platforms, labs, billing systems, telehealth tools, payer systems) so patient data flows between them automatically in a structured format, without manual re-entry.

What is the difference between EMR integration and interoperability?

EMR integration usually refers to connecting specific systems for a defined purpose, such as feeding lab results into a chart. Interoperability is the broader capability of systems to exchange data and use it meaningfully across organizations, supported by shared standards like FHIR, USCDI, and frameworks like TEFCA. Integration projects are how organizations achieve interoperability in practice.

How long does EMR integration take?

A single FHIR-based integration with a modern EMR can take a few weeks to three months. HL7 v2 interfaces with hospitals typically take one to four months per site, driven by mapping and testing. Multi-site, multi-system programs run in phased roadmaps over a year or more. Vendor cooperation and data mapping, not raw connectivity, usually set the timeline.

How much does it cost to integrate with an EMR like Epic or Oracle Health?

Costs range from minimal (using open, ONC-mandated FHIR endpoints) to $50,000+ for complex custom interfaces, plus potential vendor program fees and annual maintenance of roughly 15–25% of build cost. Platforms with pre-built connectors typically reduce per-connection cost significantly compared to custom builds.

What is FHIR and why does it matter for EMR integration?

FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard that exposes clinical data as web-friendly API resources like Patient, Encounter, and Observation. It matters because federal rules require certified EHRs to offer FHIR APIs, and CMS mandates FHIR for payer data exchange, making it the default standard for new integration work in 2026.

It’s 8:02 a.m. at a twelve-provider primary care practice, and the front desk phone has already rung four times. One caller wants to move a Thursday physical to next week. Another is a new patient trying to get in before her insurance deductible resets in January. A third gives up after two minutes on hold and calls a competing practice instead.

By 8:15, the scheduling coordinator has three sticky notes, two double-booked 2 p.m. slots, and a waitlist she hasn’t opened since Monday. None of that is because she’s bad at her job. She’s solving a real-time optimization problem with a phone and a shared calendar, and both tools were built for a slower version of healthcare than the one she’s working in.

That scene, or something close to it, repeats every morning in medical groups, ACOs, and health plan-affiliated clinics across the country. It’s also why “AI scheduling vs. traditional scheduling” has become one of the more common searches in healthcare operations. Leaders aren’t asking whether software can technically book an appointment. They’re asking whether predictive scheduling technology actually moves the numbers they’re held to: no-show rates, provider utilization, patient access, and revenue per available slot.

The short answer: AI-based scheduling outperforms manually managed scheduling on most of the metrics health systems track, from missed-appointment rates to time-to-next-available-appointment. It works best layered on top of good staff and clean processes, though, not as a wholesale replacement for either. The rest of this guide walks through why, with the mechanics behind it.

What Traditional Scheduling Actually Looks Like Today

“Traditional scheduling” covers a wider range of setups than the phrase suggests. At the low end, it’s a paper appointment book or a shared spreadsheet. More often in 2026, it’s a practice management system with a digital calendar grid that a staff member still fills in by hand, appointment by appointment, based on whatever the patient says on the phone and whatever the provider’s preset template allows.

Two things define traditional scheduling regardless of which tools sit underneath it: a human makes every placement decision, and each department usually can’t see what the others are doing.

The Phone Tag Problem

Rescheduling under a traditional model triggers a chain of phone calls. A patient cancels, staff calls the next person on a paper or informal waitlist, that person doesn’t pick up, staff moves to the next name, and the slot often stays empty long enough that it’s no longer worth filling before the appointment time passes. Every schedule change starts this chain over.

The Static Template Trap

Most practice management systems assign fixed appointment lengths by visit type: 15 minutes for a follow-up, 30 for a new patient, regardless of what that specific patient’s chart suggests about complexity. A diabetic patient with three comorbidities gets the same slot as a healthy 28-year-old there for a wellness check. Providers either run over and stack delays through the rest of the day, or a straightforward visit eats a slot that could have absorbed a same-day sick call.

What AI Scheduling Means in a Clinical Setting

AI scheduling replaces static rules with a model trained on the organization’s own historical appointment data: who showed up, who didn’t, how long visits actually ran versus how long they were booked for, and which combinations of factors predicted each outcome.

In practice, that means the system pulls signal from sources a human scheduler would never cross-reference in real time:

• Patient-level history — prior no-shows, cancellation patterns, time since last visit
• Visit-level factors — appointment type, day of week, time of day, weather forecast for the appointment date
• Provider-level patterns — which providers run long with certain visit types, typical turnover time between patients
• Resource constraints — room availability, equipment booking, staff coverage

The system uses that data to predict no-show risk per appointment, right-size appointment length instead of applying a flat template, and automatically reshuffle the calendar when something changes, without waiting for a human to notice a gap and start making calls.

AI Scheduling vs. Traditional Scheduling: Side-by-Side

Factor	Traditional Scheduling	AI Scheduling
No-show prediction	None — same risk applied to every booking	Per-appointment risk score from historical data
Rebooking a cancellation	Manual calls down a waitlist	Automatic matching to waitlisted patients by urgency and fit
Appointment length	Fixed by visit type	Adjusted using patient and visit complexity
Multi-resource coordination	Handled separately by each department	Rooms, equipment, and staff booked as one system
Patient self-service	Phone only, during business hours	Online and mobile booking, 24/7
Visibility across departments	Siloed calendars	Shared, real-time view
Staff time per schedule change	Several minutes of calls per change	Seconds, mostly automated
Scalability across locations	Each site manages independently	One model applied consistently across sites

The table makes the comparison look tidier than it is in practice. AI scheduling still needs accurate data flowing in from the EHR and practice management system to make good predictions — a health system with messy, disconnected records won’t get the gains this table implies just by buying scheduling software.

The Real Cost of Sticking With Traditional Scheduling

Missed appointments are the most visible cost, but they’re not the only one.

Lost Revenue Per Empty Slot

Outpatient no-show rates commonly run somewhere between 15% and 30%, with wide variation by specialty, payer mix, and patient population — behavioral health and pediatrics tend to run higher than, say, ophthalmology. Missed visits are frequently estimated to cost the U.S. healthcare system well over $100 billion a year in lost provider time and idle capacity. Every empty slot that can’t be refilled in time is revenue a practice never recovers, since the provider’s overhead runs whether or not a patient is in the room.

The Staffing Toll

Front-desk and scheduling staff spend a meaningful share of a shift on the phone: confirming appointments, chasing cancellations, and calling down waitlists one name at a time. That’s staff time not spent on patient intake, prior authorization follow-up, or other work that actually requires a person’s judgment.

Where AI Scheduling Delivers Measurable Gains

Reduced No-Show Rates

Predictive models flag high-risk appointments before they happen, based on the same factors listed earlier — appointment type, patient history, day of week. Staff can then target those specific patients with an extra reminder call or a text confirmation, instead of sending the same generic reminder to every patient on the schedule regardless of risk.

Faster Rebooking and Waitlist Fill

When a cancellation comes in, the system checks the waitlist against urgency, provider preference, and appointment type, and offers the slot automatically — often through a text or app notification the patient can accept with one tap. That collapses what used to be a chain of phone calls into a near-instant match.

Higher Provider Utilization

Right-sized appointment lengths mean providers spend less of the day either idle or running behind. A schedule built from actual visit-duration data, rather than a flat 15/30/45-minute template, tends to hold together better across a full clinic day.

Multi-Resource and Equipment Coordination

For specialties that depend on shared equipment — imaging, infusion chairs, procedure rooms — AI scheduling books the room, the equipment, and the provider as one transaction instead of three separate ones handled by three different people who may not be looking at each other’s calendars.

The Effect on Providers and Staff

Traditional scheduling tends to push providers toward one of two extremes: back-to-back complex cases with no buffer, or stretches of underbooked time that don’t get filled until it’s too late to matter. Neither is sustainable across a full week, and the unpredictability itself contributes to burnout independent of total patient volume.

AI scheduling doesn’t eliminate hard days, but it does spread complexity more evenly and gives staff fewer manual reconciliation tasks — double-booked slots, missed confirmation calls, waitlists nobody had time to work. That shifts staff time toward tasks that need a person: complex insurance questions, patients who need extra explanation, situations requiring genuine empathy rather than logistics.

The Effect on Patients: Access, Equity, and Trust

Access and Equity

Phone-only scheduling during business hours is a real barrier for shift workers, single parents, and anyone without flexible time during a 9-to-5 window. Online and app-based self-scheduling removes that constraint. Well-built systems go further — offering multilingual interfaces, flagging appointment slots that align with public transit schedules in areas where patients rely on it, and surfacing telehealth options for patients facing transportation barriers.

Trust and Privacy

Patients are reasonably cautious about a system making decisions using their health data. Building trust means being specific about what data the system uses and why, keeping a human reachable for anything the algorithm gets wrong, and applying standard safeguards — encryption, access controls, audit logging — consistently. AI should handle the routine matching and rebooking; a person should still be the one a patient can escalate to.

Where AI Scheduling Still Falls Short

A fair comparison has to include the limits.

• Data quality dependency. A model trained on incomplete or inconsistent historical data will make weak predictions — this is true of any predictive system, and scheduling data quality varies widely between organizations.
• Judgment for edge cases. Complex triage decisions, VIP or provider-specific scheduling preferences, and unusual clinical circumstances still need a human in the loop. AI narrows the routine cases a scheduler has to handle manually; it doesn’t remove the need for scheduling staff.
• Implementation lift. Integrating a scheduling engine with an existing EHR and practice management system takes real setup work, and organizations running older or heavily customized systems should expect that timeline to stretch.
• Change management. Staff who’ve scheduled a certain way for years need training and a reason to trust the new system’s recommendations before they’ll rely on it during a busy day.

None of these are reasons to skip AI scheduling. They’re reasons to plan the rollout instead of assuming a new tool solves the problem on installation day.

Making the Shift: A Practical Implementation Path

1. Audit current pain points first. Pull actual no-show rates, average time-to-next-appointment, and staff hours spent on scheduling calls before choosing a vendor or tool. This becomes the baseline for measuring whether the change actually worked.
2. Start with the highest-friction specialty. Behavioral health, primary care, and any department with a high no-show rate typically shows the fastest, most visible improvement — a better place to pilot than a low-volume specialty clinic.
3. Fix the data feed before the software. AI scheduling is only as good as what flows into it from the EHR and practice management system. Clean up duplicate patient records and inconsistent visit-type coding before go-live.
4. Pilot with one team, not the whole organization. Run it in parallel with existing scheduling for a few weeks, compare outcomes, and let that team’s experience shape the rollout plan for everyone else.
5. Train staff on what changed, not just how to click. Staff need to understand why the system is recommending a given slot or flagging a patient as high no-show risk, or they’ll quietly override it and the gains disappear.
6. Review the metrics monthly, not annually. Scheduling patterns shift with seasons, provider changes, and payer mix. A system tuned once and left alone drifts out of accuracy.

Metrics That Prove Whether Scheduling Technology Is Working

Track these before and after any scheduling change to know whether it’s actually paying off:

• No-show rate, by specialty and by provider
• Time-to-third-next-available appointment — a standard access metric used across ambulatory care
• Slot fill rate within 24 hours of a cancellation
• Average hold time on scheduling calls
• Staff hours spent on manual scheduling tasks per week
• Patient-reported satisfaction with the booking experience specifically, not just the visit itself

FAQs

Does AI scheduling replace scheduling staff?
No. It automates the repetitive parts — rebooking cancellations, matching waitlists, sending targeted reminders — so staff spend more time on complex cases, insurance questions, and patients who need extra help, rather than fewer roles overall.

How much can AI scheduling reduce no-shows?
Results vary by organization, patient population, and how well the underlying data is integrated, but organizations that pair predictive no-show flagging with targeted reminders typically see a measurable drop from their baseline rate. The size of the improvement depends heavily on data quality going in.

Is AI scheduling secure and HIPAA-compliant?
It can be, provided the vendor applies standard safeguards: encryption in transit and at rest, role-based access controls, and audit logging. Any system touching patient scheduling data needs a signed business associate agreement, same as any other HIPAA-covered tool.

What data does an AI scheduling system need to work well?
At minimum, historical appointment records including outcomes (kept, canceled, no-showed), visit types, and provider assignments. Better predictions come from also integrating EHR data, patient communication history, and practice management system records.

Can small practices use AI scheduling, or is it only for large health systems?
Both. Smaller practices often see AI scheduling through their practice management system as a built-in feature rather than a separate purchase, while large health systems and ACOs typically need a platform that can unify data across many locations and departments.

How long does it take to implement AI scheduling?
Timeline depends on the current state of the organization’s data. A practice with a clean, single EHR can often pilot within a few weeks; a multi-site health system integrating several legacy systems should expect a longer rollout measured in months.

Does AI scheduling work across multiple locations or specialties?
Yes, and this is where it tends to outperform traditional scheduling most clearly — a shared model applied consistently across sites reduces the maze of location-specific rules and calendars that human schedulers otherwise have to learn one by one.

Here’s a number that should stop any health system leader cold: $10.9 million.

That’s the average cost of a single healthcare data breach in 2024 — the highest of any industry, for the thirteenth consecutive year, according to IBM’s Cost of a Data Breach Report. And the damage extends far beyond the ransom payment or regulatory fine. Fragmented, ungoverned patient data quietly costs health organizations far more every single day — in duplicated lab orders, misidentified patients, failed quality audits, and care gap programs that never reach the members who need them most.

Data governance in healthcare is the discipline that puts a stop to all of it. It’s the operational backbone that determines who can access clinical data, what that data means, how it’s protected, and — critically — how it’s actually used to improve care.

This guide is built for health plan executives, health IT leaders, ACO operators, and clinical workflow architects who are done tolerating data chaos. You’ll get a comprehensive framework, current regulatory context, implementation steps, and actionable strategies to build or mature a governance program that serves both compliance and clinical outcomes.

What Is Data Governance in Healthcare?

Data governance in healthcare is the system of policies, processes, standards, and accountabilities that control how an organization collects, stores, protects, and uses health data across its entire lifecycle — from the moment a patient first interacts with the system to the moment that data informs a population health report five years later.

It is not merely a compliance checkbox. It’s an organizational discipline that touches every data consumer in a health system: clinicians, care managers, coders, analysts, finance teams, and payer operations staff.

At its core, a mature healthcare data governance program answers six foundational questions:

• Who is accountable for each data domain (clinical, financial, operational)?
• What data exists, where does it live, and is it complete?
• When should data be collected, updated, or retired?
• How should data be formatted, coded, and standardized across systems?
• Why is each data element collected — and does its use align with patient consent?
• How well is data actually performing? (quality thresholds, error rates, audit trails)

Think of it this way: Electronic Health Records (EHRs) store data. Interoperability moves data. But data governance determines whether that data is trustworthy enough to act on.

Data Governance vs. Data Management: Know the Difference

This is a distinction that trips up even experienced health IT professionals.

	Data Governance	Data Management
Focus	Strategy, policy, accountability, ownership	Execution, operations, infrastructure
Who does it	Leadership, data stewards, cross-functional councils	IT, data engineers, analysts
Output	Policies, standards, role definitions, audit frameworks	Pipelines, databases, ETL processes, dashboards
Cadence	Ongoing, evolving	Project-by-project and operational

Data governance sets the rules. Data management executes them. Both are essential — but governance must come first.

Why Healthcare Data Governance Is More Urgent Than Ever in 2026

The convergence of four major forces has made data governance a strategic imperative — not a nice-to-have — for every healthcare organization in 2026.

1. The Interoperability Mandate Has Raised the Stakes

CMS’s interoperability and patient access rules have dramatically expanded the flow of health data across payer, provider, and patient boundaries. FHIR-based APIs are now required infrastructure. More data flowing freely means more data that can be misused, misidentified, or corrupted — without strong governance in place.

2. AI Adoption Without Governance Is a Liability

Healthcare AI is proliferating fast. Clinical decision support tools, risk stratification models, prior authorization automation, ambient documentation — all of these consume patient data at scale. Any AI model trained on ungoverned, biased, or incomplete data will produce unsafe outputs. The FDA’s increasing oversight of AI/ML-based Software as a Medical Device (SaMD) means AI governance is now inseparable from clinical governance.

3. CMS V28 HCC Model Changes Demand Cleaner Risk Data

The full transition to the CMS-HCC V28 model for Medicare Advantage (MA) risk adjustment — which began phasing in during 2024 and is now fully implemented — restructured hundreds of Hierarchical Condition Category (HCC) codes. Health plans that lack clean, complete, and auditable diagnosis data are leaving RAF scores on the table and exposing themselves to RADV audit risk. Data governance is the infrastructure that makes V28 compliance sustainable.

4. The $3.7 Trillion Data Quality Problem

A 2023 study published in the Journal of the American Medical Informatics Association estimated that poor data quality costs the U.S. healthcare system approximately $3.7 trillion annually — through unnecessary testing, adverse events, administrative waste, and missed diagnoses. Every dollar of that waste has a data governance failure somewhere in its origin story.

Core Components of a Healthcare Data Governance Framework

A functional healthcare data governance framework isn’t a single tool or policy document. It’s an integrated system made up of six interlocking components.

1. Data Governance Council (Organizational Structure)

This is the decision-making body that owns the governance program. A well-structured council typically includes:

• Chief Data Officer (CDO) or Chief Medical Informatics Officer (CMIO) — executive sponsor
• Data Stewards — department-level owners for clinical, financial, and operational data domains
• Data Custodians — IT personnel responsible for technical implementation
• Privacy and Compliance Officers — HIPAA, state law, and payer contract alignment
• Clinical Representatives — frontline input on workflow impact

Without an empowered, cross-functional council, governance initiatives stall at the policy stage and never reach implementation.

2. Data Dictionary and Metadata Management

A healthcare data dictionary is the authoritative record of every data element your organization collects — its definition, source system, format, allowable values, owner, and usage rules.

Without a shared data dictionary, “diabetes” means something different in your EHR than in your claims system. Your care management platform uses ICD-10-CM Z87.39 while your analytics team pulls on E11.9. Your quality team can’t reconcile the gap — and neither can your auditors.

Metadata management extends this to include data lineage (where did this data come from, and how was it transformed?), which is now a compliance requirement under the 21st Century Cures Act’s information blocking provisions.

3. Data Quality Management

Data quality in healthcare is measured across six dimensions:

Dimension	Definition	Clinical Example
Completeness	Are all required fields populated?	Missing smoking status on 34% of patient records
Accuracy	Does the data reflect reality?	DOB recorded as 1920 instead of 1992
Consistency	Is the same data consistent across systems?	BMI = 32 in EHR, BMI = 19 in care management platform
Timeliness	Is data available when needed?	Discharge diagnoses not coded for 12+ days
Validity	Does data conform to defined formats?	Invalid NPI numbers in provider claims data
Uniqueness	Are records deduplicated?	Same patient with 7 MPI records across facilities

High-performing governance programs establish thresholds for each dimension and monitor them continuously — not just during audits.

4. Data Access and Security Controls

Healthcare data governance must define — and enforce — who can see what data, under what circumstances, and with what audit trail. This includes:

• Role-based access controls (RBAC) aligned to job function
• Attribute-based access controls (ABAC) for sensitive data classes (behavioral health, HIV status, substance use disorder records under 42 CFR Part 2)
• Data masking and de-identification protocols for analytics and research use cases
• Audit logging that captures every access, modification, and transmission event

HIPAA’s minimum necessary standard isn’t just a compliance requirement — it’s a data access governance principle.

5. Data Stewardship Program

Data stewardship is the human layer of governance. Data stewards are domain experts — typically senior analysts or clinical informatics staff — who are accountable for the quality, documentation, and appropriate use of data within their domain (e.g., claims data, lab data, ADT feeds, social determinants of health data).

Strong stewardship programs:

• Establish clear ownership for every data domain
• Create escalation paths for data quality issues
• Participate actively in interoperability and integration projects
• Document data lineage as new sources are onboarded

6. Policies, Standards, and Compliance Alignment

A governance framework requires documented, enforced policies covering:

• Data classification (public, internal, confidential, restricted/PHI)
• Data retention and destruction schedules
• Consent management and patient rights under HIPAA and state privacy laws
• Breach response procedures
• Third-party data sharing agreements (BAAs, DUAs)
• Standard code sets — ICD-10, SNOMED CT, LOINC, RxNorm, HL7 FHIR profiles

Key Benefits of Data Governance for Healthcare Organizations

Organizations that invest in mature data governance see returns across every dimension of performance.

Enhance Strategic Decision-Making

When leadership trusts the data, decisions accelerate. A health plan with a governed, unified data environment can identify care gaps in near-real-time, model the impact of benefit design changes on utilization, and respond to CMS audit requests within days — not months. High-quality data doesn’t just reduce risk. It creates competitive advantage.

Drive Operational Efficiency

Poor data quality forces workarounds. Coders manually reconcile claims. Care managers call members whose addresses are three years out of date. IT teams build redundant pipelines because no one trusts the data warehouse. A 2022 Gartner survey found that poor data quality costs organizations an average of $12.9 million per year in operational inefficiency alone. Governance eliminates the root causes of those workarounds.

Boost Financial Performance for Health Plans and ACOs

For Medicare Advantage plans, ACOs, and risk-bearing medical groups, data governance directly impacts the bottom line:

• Accurate risk adjustment requires complete, coded, and auditable diagnosis data — governance makes that possible
• RADV audit readiness depends on documentation integrity governance
• Accurate attribution in value-based contracts requires clean member/patient identity resolution
• Stars quality measures depend on consistent, complete data capture across care settings

Improve Clinical Outcomes and Patient Safety

This is the benefit that matters most. When clinicians can trust that a patient’s medication list is complete, their allergies are current, and their care plan reflects input from every provider involved — they make better decisions. Medication reconciliation errors alone contribute to over 400,000 preventable patient harm events per year in the U.S. Many of those trace directly to ungoverned data.

Maintain Regulatory Compliance

HIPAA, the 21st Century Cures Act, CMS interoperability rules, state-level privacy laws (CCPA, Washington My Health MY Data Act), and Stark Law all create data obligations. A governance framework provides the documented controls and audit trails that demonstrate compliance — and the infrastructure to respond quickly when regulations change.

Manage Risk Effectively

Beyond regulatory risk, healthcare data governance reduces:

• Cybersecurity exposure through access controls and data classification
• Reputational risk from data breaches or information blocking violations
• Operational risk from decisions made on bad data
• Contract risk in value-based arrangements where performance measurement relies on data integrity

Regulatory Compliance and Data Governance

No healthcare data governance discussion is complete without a clear-eyed look at the regulatory landscape in 2026.

HIPAA and the HITECH Act

The foundational U.S. framework for healthcare data privacy and security. Key governance implications:

• The Privacy Rule governs use and disclosure of PHI — governance policies must operationalize minimum necessary and consent requirements
• The Security Rule requires administrative, physical, and technical safeguards — governance provides the administrative and policy layer
• The Breach Notification Rule requires rapid detection and reporting — governance enables the audit logging that makes this possible
• HITECH increased penalties to up to $1.9 million per violation category per year (post-2023 inflation adjustments)

21st Century Cures Act and Information Blocking

Effective since 2021 and with enforcement fully underway, the Cures Act prohibits healthcare actors from engaging in “information blocking” — practices that interfere with the access, exchange, or use of electronic health information (EHI).

Governance is the compliance mechanism. Organizations must be able to demonstrate they have policies and processes — not just technology — that enable appropriate data sharing.

CMS Interoperability and Patient Access Rules

CMS requires Medicare Advantage, Medicaid, CHIP, and Exchange plans to implement Patient Access APIs, Provider Directory APIs, and Payer-to-Payer Data Exchange. Each of these requires governed, standardized FHIR-based data. Organizations without a governance foundation are building APIs on a sand foundation.

42 CFR Part 2 (Substance Use Disorder Records)

Updated in 2024 to align with HIPAA, 42 CFR Part 2 governs the confidentiality of SUD patient records. The key governance challenge: these records require special consent protections that must be tracked and enforced at the data element level — a governance function, not just an IT one.

State Privacy Laws: A Patchwork Growing More Complex

Washington’s My Health MY Data Act, Nevada’s health data provisions, and similar state laws are extending privacy rights to health data outside of HIPAA’s scope (including wellness apps, fitness trackers, and consumer health platforms). Organizations operating across state lines need governance programs flexible enough to accommodate this growing patchwork.

Data Governance Across Key Healthcare Sectors

Healthcare is not a monolith. Data governance challenges — and solutions — look different depending on your organizational model.

Health Plans and Medicare Advantage Organizations

Health plan data governance priorities:

• Member identity resolution across claims, pharmacy, and clinical data sources
• Risk adjustment data governance for HCC coding accuracy and RADV defensibility
• Stars quality measure data — ensuring HEDIS-relevant data is complete and consistent
• Prior authorization data — audit trails and clinical documentation integrity
• Delegated vendor oversight — ensuring downstream data governance obligations are met by IPAs, MSOs, and care management vendors

Accountable Care Organizations (ACOs) and ACO REACH

For ACOs — particularly those participating in ACO REACH — data governance is the foundation of financial performance:

• Attribution accuracy depends on clean provider and patient identity data
• Shared savings calculations require consistent encounter and claims data
• Benchmark and performance year comparisons require historically governed data
• HCC coding for ACO REACH’s benchmark model requires diagnosis data governance equivalent to MA

Medical Groups and IPAs

Often the most under-resourced for formal governance, medical groups face:

• EHR fragmentation — multiple EHR instances across acquired practices with inconsistent coding conventions
• Referral data gaps — specialist encounter data rarely flows back to the primary care record
• Value-based reporting — quality and utilization data for delegated contracts often require data integration that governance makes reliable

Health Systems and IDNs

Large integrated delivery networks govern at scale:

• Enterprise Master Patient Index (EMPI) integrity across dozens of facilities
• Clinical data repositories and enterprise data warehouses
• Research and de-identification governance
• Supply chain and operational data alongside clinical data

Building a Healthcare Data Governance Strategy: 7 Steps

Governance programs fail when they start with technology. They succeed when they start with people, purpose, and priorities.

Step 1: Identify Your Data Governance Priorities

Not all data is equally important to govern first. Prioritize based on:

• Business and clinical risk — what ungoverned data creates the greatest patient safety, financial, or compliance exposure?
• Value-based contract obligations — what data must be reliable for your most important payer relationships?
• Regulatory timelines — what governance gaps create the most imminent compliance risk?
• Quick wins — what governance improvements would create immediate, visible value for data users?

A governance priority matrix that scores data domains by risk × business value will help your council align on where to start.

Step 2: Build a Multidisciplinary Governance Team

Your governance team must include representation from clinical operations, health IT, compliance, finance, and analytics. The single most common governance failure mode is a program that lives entirely in IT — without clinical and operational ownership, policies don’t get adopted, and data stewards don’t have the domain authority to enforce standards.

Designate a Data Governance Lead with dedicated time (this cannot be a 10% of someone’s job initiative at enterprise scale).

Step 3: Appoint and Empower Data Stewards

Identify subject matter experts for each priority data domain:

• Claims data steward — understands EDI 837/835 transactions, diagnosis coding, NCCI edits
• Clinical data steward — EHR data model, clinical terminology standards, documentation workflows
• Member/patient identity steward — EMPI, MPI, address verification, consent management
• Quality data steward — HEDIS technical specifications, measure denominator/numerator logic
• SDOH data steward (increasingly critical) — standardized screening tools, Z-codes, community resource linkage

Stewards must have authority — not just responsibility. They need to be able to flag data quality failures, block problematic data integrations, and escalate to leadership.

Step 4: Standardize Definitions and Metadata

Conduct a data inventory. Document every significant data source: its system of origin, the data model, the refresh cadence, the business owner, the known quality issues, and the downstream consumers.

Then build your data dictionary. Start with the data elements that matter most for your priority use cases. Establish official definitions and defend them — the governance council is the arbiter when there’s disagreement.

This step is where most organizations underinvest. Without a shared vocabulary, every downstream data project becomes a negotiation over definitions.

Step 5: Implement Automated Data Lineage and Observability

Manual data quality monitoring doesn’t scale. Modern governance programs implement data observability tools that automatically monitor:

• Record volume anomalies (a feed that typically delivers 50,000 daily claims suddenly delivers 800 — catch that before anyone builds a report on it)
• Schema drift (an upstream system changes a field format without notification)
• Null rate changes (a previously 2% null field suddenly hits 45% null)
• Duplicate record rates across key identifiers

Data lineage tools provide visual maps of exactly how data flows from source to consumption — essential for root cause analysis when quality issues arise, and increasingly required for regulatory documentation.

Step 6: Invest in Data Management Tools Aligned to Governance Needs

Governance policies need technology infrastructure to enforce them at scale. Key platforms include:

• Healthcare data platforms with native workflow and clinical data unification capabilities
• Master data management (MDM) for patient, provider, and member identity
• Data catalogs for metadata management and data discovery
• Data quality platforms for automated profiling and rule enforcement
• Privacy and access management tools for role-based controls and consent tracking

Look for platforms built specifically for healthcare data complexity — generic enterprise data tools often lack native support for FHIR, HL7, ICD coding hierarchies, and healthcare-specific identity matching.

Step 7: Foster a Culture of Data-Driven Decision Making

Technology and policy alone don’t create data governance maturity. Culture does. Governance leaders who succeed consistently do these things:

• Make data quality visible — publish dashboards that show data quality scores by domain, system, and trend
• Celebrate data stewardship wins — recognize teams that surface and fix data quality issues proactively
• Connect governance to outcomes — show how improved data quality led to better care gap closure rates, higher Stars scores, or cleaner RADV audits
• Train continuously — onboard new employees with data governance basics; provide role-specific training for data producers
• Remove blame from quality conversations — governance programs stall when people fear consequences for surfacing data problems

Common Challenges and How High-Performing Organizations Overcome Them

Challenge 1: Siloed EHR and Claims Data

The average health plan or ACO touches data from 15 to 40+ source systems. Getting those systems to share a common data model is a years-long initiative.

How leading organizations address it: Rather than attempting a full data warehouse rebuild, they implement a clinical data unification layer — a platform that normalizes data from disparate sources into a governed, queryable data model without requiring every source system to change. Incremental integration, governed from day one, beats a “big bang” approach that never launches.

Challenge 2: Physician and Clinical Staff Resistance

Governance initiatives that impose new documentation requirements on already-overloaded clinicians will fail. Period.

How leading organizations address it: They lead with the clinical value proposition — governance that improves the quality of the data clinicians receive, not just the data they produce. Reducing alert fatigue, surfacing complete medication histories, and presenting accurate care gaps at point of care are outcomes that earn clinical buy-in.

Challenge 3: Unclear Ownership and Accountability

“Everyone is responsible” means no one is responsible.

How leading organizations address it: The governance council creates a RACI matrix (Responsible, Accountable, Consulted, Informed) for every governance function and data domain — and reviews it annually. Accountability is built into job descriptions and performance objectives for data stewards.

Challenge 4: Governance That Lives in Documents, Not Processes

Many organizations have governance policies. Far fewer have governance processes — the operational workflows that make policies real.

How leading organizations address it: They embed governance into existing workflows. Data quality reviews happen in existing operational meetings. Steward escalation paths are integrated into existing IT ticketing systems. Governance isn’t a parallel universe — it’s woven into how the organization already operates.

Challenge 5: Vendor Data Complexity

Third-party data vendors, delegated risk entities, and health information exchanges often deliver data in formats, quality levels, and governance standards that differ from internal expectations.

How leading organizations address it: They build governance requirements into vendor contracts, conduct data onboarding assessments before integration, and treat vendor data sources as governed assets from day one — with the same quality monitoring, lineage documentation, and stewardship oversight as internal sources.

Technology’s Role: Platforms, AI, and Automation

Healthcare data governance in 2026 cannot be executed at scale with spreadsheets and email threads. The right technology stack is an enabler — but only when it’s deployed in service of a governance strategy, not as a substitute for one.

Healthcare Data Platforms and Low-Code Clinical Workflow Tools

Purpose-built healthcare data platforms — particularly those with AI-powered data unification and low-code workflow capabilities — are changing what’s possible for mid-market health plans, ACOs, and medical groups that can’t afford 18-month enterprise data warehouse projects.

The most effective platforms:

• Ingest and normalize data from EHRs, claims systems, HIEs, lab feeds, pharmacy data, and SDOH sources
• Apply healthcare-specific terminology standards (FHIR, HL7, SNOMED, LOINC, ICD) natively
• Provide built-in data quality monitoring and alerting
• Offer workflow automation tools that activate governed data — converting insights into care management tasks, gap closure workflows, and risk stratification outputs
• Maintain complete audit trails for compliance

AI and Machine Learning in Governed Data Environments

AI is only as good as the data it learns from. This principle has major governance implications:

• Training data governance — what data was used to train a clinical AI model, was it representative, and was it consented for research use?
• Model performance monitoring — governance programs must track AI model drift and bias over time
• Explainability — for clinical decision support tools, governance requires that the basis for AI recommendations can be documented and audited

Conversely, AI is increasingly being used for governance: automated data quality classification, anomaly detection, duplicate patient record identification, and coding compliance monitoring are all areas where ML is delivering meaningful efficiency gains.

Interoperability Infrastructure: FHIR as a Governance Enabler

FHIR (Fast Healthcare Interoperability Resources) isn’t just a technical standard — it’s a governance infrastructure. When organizations expose and consume FHIR-based APIs, they’re creating standardized data contracts between systems. Governance programs that define FHIR profiles for their key data elements are building governance directly into the interoperability layer.

Data Governance Metrics That Actually Matter

You can’t govern what you don’t measure. These are the KPIs that mature healthcare data governance programs track:

Metric	What It Measures	Target (Mature Programs)
Data Completeness Rate	% of required fields populated per domain	>95% for clinical, >98% for claims
Duplicate Patient Record Rate	% of records with confirmed duplicates	<0.5% post-EMPI implementation
Data Latency	Time from care event to data availability	<24 hours for ADT, <72 hours for claims
Issue Resolution Time	Avg. days to resolve flagged data quality issues	<5 business days for P1/P2 issues
Stewardship Coverage	% of data domains with designated stewards	100% of priority domains
Policy Acknowledgment Rate	% of relevant staff trained on governance policies	>95% annually
Audit Finding Rate	# of governance-related audit findings per quarter	Year-over-year reduction
Data Dictionary Coverage	% of critical data elements documented	>90% for tier-1 data elements
Access Control Compliance	% of user access rights reviewed on schedule	100% on annual review cycle

Report these metrics to your governance council quarterly. Publish a subset to organizational leadership. Nothing accelerates governance maturity faster than visibility.

People Also Ask: Your Top Data Governance Questions Answered

What is data governance in healthcare?

Data governance in healthcare is the framework of policies, processes, standards, roles, and technologies that determines how health data is collected, stored, accessed, protected, and used across an organization. It ensures data is accurate, consistent, secure, and usable — for clinical care, regulatory compliance, financial operations, and population health management.

What are the key components of a healthcare data governance framework?

The core components are: (1) a governance council with defined roles and accountability; (2) a data dictionary and metadata management system; (3) data quality standards and monitoring; (4) access controls and security policies; (5) a data stewardship program with domain-level owners; and (6) documented policies aligned to HIPAA, CMS rules, and applicable state privacy laws.

Why is data governance important in healthcare?

Healthcare data governance is important because ungoverned health data creates direct patient safety risks, compliance exposure, financial losses, and operational inefficiency. With the explosion of data from EHRs, claims, HIEs, wearables, and SDOH sources, organizations that can’t trust their data can’t effectively manage risk, close care gaps, pass audits, or make sound clinical or financial decisions.

What is the difference between data governance and data management in healthcare?

Data governance sets the strategy, policies, standards, and accountability structures for how data should be handled. Data management is the operational and technical execution of those standards — building pipelines, managing databases, running ETL processes. Governance is the “what and why.” Management is the “how.” Both are required, but governance must come first.

How does data governance relate to HIPAA compliance?

HIPAA compliance requires documented policies, administrative safeguards, access controls, audit logging, and breach response capabilities — all of which are core elements of a data governance framework. A mature governance program doesn’t just meet HIPAA requirements; it provides the organizational infrastructure that makes HIPAA compliance sustainable and defensible over time.

What are the biggest challenges in healthcare data governance?

The most common challenges are: siloed source systems with inconsistent data models; lack of clear data ownership and accountability; clinical staff resistance to new documentation requirements; governance policies that exist on paper but aren’t operationalized; and the complexity of governing third-party and vendor data sources. Successful programs address all of these by connecting governance to clinical and business value — not just compliance.

How does data governance support value-based care?

Value-based care performance depends entirely on data quality. Accurate risk stratification, care gap identification, attribution, quality measure calculation, and shared savings calculations all require governed, complete, and consistent data. Organizations participating in Medicare Advantage, ACO REACH, or delegated risk arrangements that invest in governance outperform their peers in financial and clinical outcomes because they can trust their data enough to act on it.

What role does AI play in healthcare data governance?

AI serves two roles in governance. First, AI needs governance — machine learning models trained on ungoverned data produce unreliable, potentially unsafe outputs. Governance programs must address AI training data quality, model performance monitoring, and explainability. Second, AI enables governance — automated data quality monitoring, duplicate detection, coding compliance review, and anomaly detection all benefit from ML-powered tools that scale governance capabilities without scaling headcount.

How do you measure the success of a healthcare data governance program?

Measure success through metrics like data completeness rates by domain, duplicate patient record rates, data latency from care event to availability, issue resolution time, data dictionary coverage, audit finding rates, and stewardship coverage. Track trends quarterly. The most compelling success metric is connecting improved data quality to tangible outcomes — better RADV audit performance, higher Stars scores, reduced care gap rates, or faster response to compliance requests.

How long does it take to implement healthcare data governance?

A foundational governance program — council in place, priority domains covered, stewards designated, and basic quality monitoring running — can be stood up in 90 to 180 days with strong executive sponsorship. A mature enterprise program covering all data domains, automated quality monitoring, full metadata documentation, and a governed AI layer typically takes 18 to 36 months to build. Most organizations achieve meaningful ROI within the first year by focusing governance on their highest-value use cases first.

Final Thoughts: Data Governance Is Your Most Strategic Investment in 2026

Every healthcare organization is sitting on a data problem that’s costing them more than they realize — in compliance risk, clinical outcomes, financial performance, and operational efficiency. The solution isn’t more data. It’s governed data.

The organizations winning in value-based care, navigating CMS model changes with confidence, and scaling AI without fear are the ones that built a data governance foundation before they needed it. Not after a breach. Not after a failed audit. Not after a costly wrong decision.

Healthcare data governance isn’t a destination. It’s an operating model. And the organizations that treat it that way — with dedicated leadership, cross-functional accountability, the right technology, and a relentless focus on data quality — are the ones that will define what excellent care and excellent performance look like in the decade ahead.

Turn Data Governance Into a Competitive Advantage With Curitics Health

Curitics Health is an AI-powered, low-code clinical workflow and data unification platform purpose-built for health plans, ACOs, MSOs, and medical groups. We help healthcare organizations govern, unify, and activate their clinical and claims data — without the 18-month enterprise data project.

What Curitics delivers:

• Unified patient and member data across disparate EHR, claims, and SDOH sources
• Built-in data quality monitoring and governance-ready audit trails
• Low-code workflow automation that turns governed data into care management action
• FHIR-native interoperability with HL7, SNOMED CT, LOINC, ICD-10 support
• Risk adjustment and Stars quality data readiness for CMS V28 and HEDIS reporting

Whether you’re standing up your first governance program or maturing a complex enterprise data environment, Curitics is built to accelerate your journey.

Schedule a Curitics Health Platform Demo – https://curiticshealth.com/demo

Imagine running a health plan where you consistently underestimate how sick your members actually are. Your capitation payments come in lean. Your care management teams are overwhelmed — reactive instead of proactive. And your quality metrics quietly erode, quarter after quarter.

This isn’t a hypothetical. It’s the lived reality for hundreds of health plans, Accountable Care Organizations (ACOs), and risk-bearing provider groups that haven’t yet optimized their risk adjustment strategy.

At the heart of this challenge sits one of the most consequential decisions in value-based care: Should you use a prospective risk adjustment model, a retrospective one, or a thoughtful combination of both?

The answer isn’t always obvious. Both approaches have a place in modern healthcare — but confusing one for the other, or leaning too heavily on just one, creates blind spots that cost organizations millions of dollars annually and, more importantly, leave high-risk patients without the care they need.

This guide breaks it all down. You’ll walk away understanding exactly how each model works, where each falls short, what the data says about ROI, and how leading healthcare organizations in 2025 are using intelligent clinical workflow platforms to get the best of both worlds.

What Is Risk Adjustment in Healthcare?

Before we compare the two models head-to-head, let’s anchor on what risk adjustment actually does.

Risk adjustment is a statistical process used in healthcare to account for the differences in health status across patient populations. It ensures that payers and providers are compensated fairly based on the actual clinical complexity of the people they serve – not just headcount.

Under value-based care models like Medicare Advantage, ACO REACH, and Medicaid managed care, risk scores directly influence:

• Capitation payments paid to health plans and provider organizations
• Quality benchmarks and performance expectations
• Care management resource allocation
• Financial risk corridors in shared savings programs

The most commonly used risk adjustment framework in the U.S. is CMS’s Hierarchical Condition Category (HCC) model, which assigns numeric risk scores to patients based on their diagnosed chronic conditions. The average Medicare Advantage enrollee has a risk score around 1.0, with higher scores representing greater predicted healthcare costs.

The problem? That score is only as accurate as the data feeding it and that’s where the choice between prospective and retrospective approaches becomes critical.

What Is Prospective Risk Adjustment?

Prospective risk adjustment is a forward-looking model. It uses a patient’s historical health data – diagnoses, claims, clinical records, labs, pharmacy data to predict their likely healthcare needs and costs in a future period (typically the next plan year).

In simple terms: you’re building a risk profile before the care is delivered.

How Prospective Risk Adjustment Works

1. Data aggregation — Clinical and claims data from the prior 12–24 months is compiled for each member.
2. HCC mapping and risk scoring — Diagnoses are mapped to HCC codes, and a composite risk score is calculated.
3. Gap identification — Conditions that are likely to be present based on clinical signals but haven’t been recently documented are flagged as “suspected” or “presumed” diagnoses.
4. Outreach and care planning — Patients with high or rising risk scores are proactively enrolled in care management programs before they deteriorate.
5. Coding capture at the point of care — Providers are prompted to document relevant diagnoses during visits, ensuring the risk score is accurate for the upcoming payment period.

Key Characteristics of Prospective Risk Adjustment

• Timing: Applied before the service period
• Primary goal: Predict cost and utilization; drive proactive care delivery
• Data source: Historical claims, EHR data, prior-year HCC hierarchies
• Use case: Medicare Advantage plan bidding, ACO care gap closure, population health management
• Primary stakeholders: Health plans, risk-bearing provider groups, population health teams

The Real Advantage: Prevention Over Reaction

The clearest clinical win of prospective risk adjustment is what it enables before a patient has a crisis. A member with poorly controlled Type 2 diabetes and early-stage chronic kidney disease (CKD) may not have generated high costs yet but their risk trajectory is unmistakable. A prospective model catches that patient now, enabling medication reconciliation, nutritional counseling, and nephrology referrals that may prevent a hospitalization that would have cost $40,000 or more.

According to a 2024 JAMA Health Forum analysis, prospective care management programs targeting high-risk patients identified through predictive risk stratification reduced 30-day readmission rates by up to 18% in Medicare Advantage populations.

What is Retrospective Risk Adjustment?

Retrospective risk adjustment is a backward-looking model. It reconciles a patient’s actual diagnoses and resource utilization after services have been delivered, typically at the end of a plan year or contract period.

In simple terms: you’re correcting the risk score after the care has already happened.

How Retrospective Risk Adjustment Works

1. Claim submission and diagnosis collection — All medical claims and encounter data from the service period are compiled.
2. Risk score reconciliation — Final HCC risk scores are calculated based on documented diagnoses from that year.
3. Risk adjustment data validation (RADV) and submission — Final diagnosis codes are submitted to CMS or the relevant payer for reconciliation.
4. Retrospective chart reviews — Medical records are audited to identify diagnoses that were treated but not coded, allowing organizations to submit addendum or corrected claims.
5. Financial settlement — Payments are adjusted up or down based on the difference between the preliminary prospective payment and the final risk score.

Key Characteristics of Retrospective Risk Adjustment

• Timing: Applied after the service period
• Primary goal: Accurate payment reconciliation; capture all documented diagnoses
• Data source: Final claims data, medical record reviews, encounter data
• Use case: RADV audits, MA plan reconciliation, provider contract settlements
• Primary stakeholders: Health plan finance teams, revenue cycle management, compliance officers

The Real Advantage: Accuracy and Completeness

Prospective models are predictive — they’re educated guesses. Retrospective models are definitive – they reflect what actually happened. For a health plan managing $500 million in premium revenue, a 0.05 improvement in average HCC risk score across 100,000 members can mean tens of millions of dollars in additional premium revenue but only if diagnoses were properly documented and submitted.

A 2023 Government Accountability Office (GAO) report found that Medicare Advantage plans received approximately $75 billion in risk-adjusted payments that year, with CMS estimating that at least 10% of those payments were associated with diagnoses that couldn’t be validated through medical records – underscoring the critical importance of getting retrospective accuracy right.

Prospective vs. Retrospective Risk Adjustment: Side-by-Side Comparison

Feature	Prospective Risk Adjustment	Retrospective Risk Adjustment
Timing	Before the service period	After the service period
Primary Purpose	Predict risk; drive proactive care	Reconcile payments; capture all diagnoses
Data Used	Historical claims, prior HCCs, EHR signals	Final claims, encounter data, chart reviews
Clinical Impact	High — drives care management outreach	Lower — care has already occurred
Financial Impact	Enables accurate capitation bidding	Corrects underpayment/overpayment
Risk of Error	Overestimating future risk	Missing documented diagnoses
Regulatory Focus	CMS risk score trending	RADV audit exposure
Best For	Population health, ACO REACH, MA bidding	Revenue cycle, compliance, financial close
Technology Need	Predictive analytics, NLP, gap workflows	Chart review platforms, coding tools

Why Prospective Risk Adjustment Is Gaining Traction in 2025

The industry shift toward value-based care has dramatically elevated the strategic importance of prospective risk adjustment. Here’s why organizations are leaning in:

1. CMS Is Tightening Retrospective Audit Exposure

CMS’s expanded Risk Adjustment Data Validation (RADV) audit program – finalized with broader extrapolation rules in 2023 means health plans can no longer rely on aggressive retrospective coding to make up for poor prospective accuracy. The financial risk of an adverse RADV audit finding has increased significantly, pushing plans to get their risk scores right before the year begins.

2. Value-Based Care Contracts Reward Proactive Outreach

Under ACO REACH and similar programs, prospective care gap closure directly impacts quality scores and shared savings calculations. Organizations that can identify a patient with undiagnosed depression, uncontrolled hypertension, or a lapsed annual wellness visit before a costly event and actually close that gap – outperform peers on both quality and financial metrics.

3. AI and NLP Are Making Prospective Models Far More Accurate

The single biggest historical limitation of prospective risk adjustment was data quality. If a patient’s chronic kidney disease was documented in a specialist’s notes but never made it into the claims system, the prospective model couldn’t see it.

Today, AI-powered clinical data unification platforms can ingest unstructured notes, lab results, pharmacy records, and social determinants of health (SDOH) data and surface suspected diagnoses with high accuracy. This closes the gap between what the prospective model predicts and what the patient actually has.

According to a 2024 Health Affairs study, AI-assisted HCC gap closure programs identified an average of 1.8 additional actionable diagnoses per member compared to claims-only prospective models – a meaningful lift in both clinical accuracy and risk score completeness.

4. Provider Engagement Starts with Prospective Signals

When a care coordinator walks into a patient encounter armed with a prospective risk flag – “this patient likely has CKD Stage 3 based on their creatinine trend” – it transforms the clinical conversation. Prospective data enables point-of-care decision support that retrospective models simply can’t replicate.

The Limitations of Prospective Risk Adjustment (And Why Retrospective Still Matters)

Prospective models aren’t infallible. Here’s where they fall short and why retrospective processes remain essential:

Prediction ≠ Reality

A prospective model predicts that a member will have high costs. Sometimes they don’t – the patient moves, gets better, or simply doesn’t utilize services as expected. Without retrospective reconciliation, payers may overpay for years on members whose health status has materially improved.

Prospective Coding Can Miss New Diagnoses

A patient may develop a new condition during the plan year that wasn’t predictable from prior data – a cancer diagnosis, a traumatic injury, new-onset heart failure. Retrospective processes catch these and ensure they’re reflected in final risk scores.

Compliance Risk Without Retrospective Validation

Prospective coding programs that aren’t validated against clinical documentation create RADV audit exposure. Every prospective diagnosis flag should eventually be confirmed by a documented clinical encounter — and retrospective chart review is how you verify that.

Risk Adjustment ROI: What the Data Actually Shows

Let’s talk dollars. Because at the end of the day, finance leaders and C-suite executives need to understand the financial case for investing in risk adjustment infrastructure.

Prospective Risk Adjustment ROI

• Medicare Advantage organizations with mature prospective HCC programs report average risk score improvements of 0.08–0.15 HCC RAF points per member per year through systematic gap closure.
• On a typical MA plan with a $12,000 annual premium per member, a 0.10 RAF improvement translates to approximately $1,200 per member in additional premium revenue.
• For a plan with 50,000 members, that’s $60 million in incremental revenue – from better documentation and care management alone.

Retrospective Risk Adjustment ROI

• Retrospective chart review programs typically recover $200–$600 per member in previously undocumented diagnoses.
• Organizations with robust retrospective coding programs report 3–8x ROI on chart review investments, depending on population complexity and prior coding accuracy.
• Conversely, organizations that over-code retrospectively face CMS repayments. The average RADV audit extrapolation has resulted in repayment demands ranging from $1 million to $200 million for larger plans.

The Blended Approach Wins

Organizations that integrate both models — using prospective analytics to drive care management AND retrospective processes to validate and reconcile — consistently outperform single-model approaches. A 2024 Advisory Board analysis of 47 Medicare Advantage plans found that plans using integrated prospective + retrospective risk adjustment strategies achieved 22% higher risk-adjusted revenue accuracy than those relying primarily on retrospective reconciliation.

Best Practices for Blending Prospective and Retrospective Risk Adjustment

Leading healthcare organizations in 2025 don’t think of these as competing models. They think of them as two engines in the same airplane. Here’s how to run both effectively:

Build a Unified Clinical Data Foundation

You can’t run effective risk adjustment – prospective or retrospective – without clean, unified clinical data. That means:

• Breaking down silos between EHR systems (Epic, Cerner, athenahealth), claims data, pharmacy records, and lab data
• Implementing FHIR-compliant APIs for real-time data exchange
• Using NLP to extract diagnoses from unstructured clinical notes
• Applying SDOH data to identify patients at risk of care gaps due to social barriers

Stratify Your Population — Don’t Chase Everyone

Not every patient needs intensive risk adjustment outreach. A tiered approach works best:

• Tier 1 (High-risk, high-gap): Patients with high prospective risk scores AND documented HCC gaps — prioritize for care management outreach and face-to-face encounters
• Tier 2 (Rising-risk): Patients with clinical signals suggesting emerging conditions — prioritize for annual wellness visits and preventive screenings
• Tier 3 (Stable): Patients with complete, accurate documentation — focus on maintenance and HEDIS quality measures

Embed Risk Adjustment into Clinical Workflows

Risk adjustment fails when it’s treated as a back-office finance function. The most successful programs embed gap alerts, HCC flags, and coding prompts directly into the clinical workflow — surfacing the right information to the right provider at the point of care, not months later during a chart review.

Continuous feedback loops matter: Providers who see how their documentation quality affects patient care plans — not just revenue — engage more consistently.

Automate Retrospective Chart Review – Strategically

Not all charts need manual review. AI-powered coding platforms can pre-prioritize records with the highest likelihood of containing undocumented HCCs, dramatically improving efficiency. Organizations using AI-assisted chart review report 40–60% reductions in cost per chart reviewed compared to traditional manual programs.

Validate, Validate, Validate

Every prospective diagnosis flag must be anchored to a documented clinical encounter before submission. Build audit-ready documentation into your workflows from the start — don’t wait for a RADV notice to find out your prospective coding program wasn’t clinically supported.

How Low-Code Clinical Workflow Automation Transforms Risk Adjustment

One of the most significant operational challenges in risk adjustment isn’t the analytics – it’s the execution. Identifying a patient with a suspected HCC gap is step one. Getting that flag to the right provider, ensuring it’s addressed in the right encounter, confirming the documentation meets CMS requirements, and closing the loop in real time — that’s where most organizations break down.

This is where low-code clinical workflow automation platforms are changing the game.

Modern platforms enable healthcare organizations to:

• Configure custom risk adjustment workflows without engineering teams — a care coordination team can build a prospective HCC gap outreach workflow in days, not months
• Unify data from disparate sources — pulling EHR, claims, labs, and pharmacy data into a single actionable view without expensive point-to-point integrations
• Trigger automated outreach based on risk score thresholds — scheduling calls, sending patient reminders, or alerting care managers when a high-risk patient misses an appointment
• Track gap closure in real time — providing management dashboards that show which HCC gaps are open, which providers are addressing them, and what’s still outstanding before the coding submission deadline
• Support retrospective validation — automatically flagging submitted HCCs that lack supporting documentation, reducing RADV audit exposure proactively

The result is a risk adjustment program that’s not just analytically sophisticated – it’s operationally executable at scale.

Turning Insight Into Action: A Risk Adjustment Workflow Example

Here’s how a mature prospective + retrospective workflow looks in practice:

Step 1 — September (Q3): AI model runs across the full Medicare Advantage population, generating prospective risk scores and flagging HCC gaps for the upcoming contract year. A patient with hypertensive heart disease and Type 2 diabetes is flagged for a suspected CKD Stage 3 gap based on lab trends.

Step 2 — October: An automated outreach workflow schedules an AWV (Annual Wellness Visit) for the flagged patient. The primary care provider receives a pre-visit summary highlighting the suspected CKD gap and prompting a creatinine review.

Step 3 — November (visit): The provider reviews labs, confirms CKD Stage 3, documents the diagnosis in the EHR, and submits an ICD-10 code (N18.3). The workflow automatically marks the gap as closed and logs the encounter for compliance review.

Step 4 — January (new contract year): The confirmed CKD diagnosis flows into the prospective risk score, improving the patient’s RAF from 1.42 to 1.68 — reflecting their true clinical complexity and triggering enhanced care management resources.

Step 5 — Q3 of the following year: Retrospective reconciliation confirms all HCCs submitted match documented clinical encounters. The risk score holds up in RADV review. No repayment required.

This isn’t a theoretical ideal. It’s the operational reality for organizations that have invested in unified clinical data infrastructure and intelligent workflow automation.

Common Risk Adjustment Mistakes to Avoid

Even sophisticated organizations make these errors:

1. Treating prospective and retrospective as separate programs. They should be integrated. Retrospective validation should inform prospective model calibration every year.

2. Coding without clinical support. Submitting HCC codes that aren’t backed by a documented face-to-face diagnosis encounter is the #1 RADV audit trigger. Every code needs a clinical anchor.

3. Ignoring SDOH in risk stratification. A patient with poorly controlled diabetes who lacks transportation to clinic visits has a very different risk profile than a clinically similar patient with good access to care. SDOH-adjusted prospective models predict utilization more accurately.

4. Running chart reviews too late. Many organizations run retrospective reviews in Q4, after the coding submission window has narrowed significantly. Best-in-class programs run continuous retrospective monitoring throughout the year.

5. Under-investing in provider education. HCC coding accuracy is ultimately a clinical documentation problem. Providers who understand why accurate diagnosis coding matters for their patients’ care plans, not just for revenue – document more completely and consistently.

Frequently Asked Questions

What is the main difference between prospective and retrospective risk adjustment?

Prospective risk adjustment uses historical data to predict a patient’s future health needs and risk score before a service period begins. Retrospective risk adjustment reconciles actual diagnoses and costs after services have been delivered. Both are used in value-based care, but they serve different purposes – prospective drives proactive care, while retrospective ensures payment accuracy.

Which type of risk adjustment is better for Medicare Advantage plans?

Most high-performing Medicare Advantage plans use both. Prospective models drive care management strategy and capitation bidding accuracy. Retrospective processes validate documentation and reconcile final risk scores. Plans that rely exclusively on retrospective reconciliation miss significant opportunities for proactive care — and face greater RADV audit exposure.

How does HCC coding relate to risk adjustment?

HCC (Hierarchical Condition Category) coding is the primary mechanism through which risk adjustment scores are calculated in Medicare Advantage and similar programs. Each HCC represents a cluster of clinically similar, cost-predictive diagnoses. Accurate HCC coding – both prospective (predicted) and retrospective (documented) — directly determines a health plan’s risk-adjusted premium revenue.

What is RADV, and why does it matter?

RADV (Risk Adjustment Data Validation) is CMS’s audit program to verify that Medicare Advantage plans’ risk-adjusted payments are supported by medical record documentation. Under expanded RADV rules effective in 2023, audit findings can be extrapolated across an entire plan, creating significant financial exposure. Robust retrospective validation processes are essential for RADV compliance.

Can AI improve risk adjustment accuracy?

Yes, significantly. AI and NLP tools can identify suspected HCC diagnoses from unstructured clinical notes, lab trends, and pharmacy data that traditional claims-based models miss. AI-powered chart review tools also prioritize records with the highest likelihood of containing undocumented diagnoses, reducing cost per chart reviewed while improving capture rates. In 2024, health plans using AI-assisted prospective HCC programs reported up to 1.8 additional actionable diagnoses per member compared to claims-only approaches.

How does risk adjustment affect provider reimbursement in ACOs?

In ACO models like ACO REACH, risk adjustment directly influences the benchmark against which shared savings are calculated. A more accurate prospective risk score means a more appropriate benchmark – one that reflects your population’s true complexity. ACOs with systematically higher risk scores (due to better documentation, not sicker patients) are often unfairly benchmarked against lower risk scores, eroding their shared savings potential. Getting prospective risk adjustment right is essential for ACO financial sustainability.

What’s the difference between prospective and concurrent risk adjustment?

Concurrent risk adjustment uses diagnoses from the current year to set risk scores for the current year rather than using prior-year data (prospective) or post-year data (retrospective). It’s less common in commercial applications but used in some Medicaid managed care markets. It’s generally considered more accurate than purely prospective models but requires real-time data infrastructure.

How often should risk adjustment models be recalibrated?

Best practice is annual model recalibration, with quarterly monitoring of risk score trends. Organizations should also recalibrate whenever there are significant changes in their population (new market entry, major benefit changes), CMS model updates (CMS updates its HCC model periodically), or significant shifts in care utilization patterns (as seen during and after COVID-19).

The Bottom Line: An Integrated Approach Is the New Standard

The debate between prospective and retrospective risk adjustment is a false choice. The answer is both but with strategic clarity about what each model does, when to apply it, and how to operationalize it at scale.

Prospective risk adjustment is your clinical strategy engine: it drives care management, informs population health priorities, and ensures your highest-risk members get attention before they crash. Retrospective risk adjustment is your financial accuracy engine: it ensures your documentation supports your claims, protects you from RADV exposure, and corrects for what prospective models can’t predict.

The organizations pulling ahead in value-based care aren’t better at analytics. They’re better at turning analytics into action and that requires clinical workflow infrastructure that connects risk scores directly to care delivery, provider engagement, and documentation capture in real time.

Ready to Transform Your Risk Adjustment Strategy?

Whether you’re a Medicare Advantage plan looking to improve HCC capture rates, a risk-bearing provider group navigating ACO REACH, or a health system building value-based care competencies, the foundation is the same: unified clinical data, intelligent workflows, and a platform that makes risk adjustment something your care teams can actually execute on.

See how Curitics Health’s AI-powered low-code clinical workflow platform connects risk scores to real-time care delivery: https://curiticshealth.com/demo