Do payers pay for AI? Or do they assume AI-mediated savings, and deflation of prices? Is one clinical area totally different from another in terms of AI financing and strategies?
STAT just ran a three-part series on AI and reimbursement, with Medicare and other use cases. Peterson Institute just released a 15pp on AI financing in healthcare. And there are collateral sources, e.g. a PathAI webpage on the cost strucures of digital pathology.
Here's a consolidated view from Chat GPT...
This essay is also available as a PDF white paper in the cloud - here.
##
Summary.
- Clinical AI is not simply another medical device awaiting a code and payment rate. It can replace human labor, operate continuously, and scale at low marginal cost, creating both opportunities for better care and risks of uncontrolled spending.
- A useful financial architecture must therefore address six interconnected layers: investment, transactions, workflow and accountability, evidence, market integration, and dynamic governance.
- The Peterson framework provides the central economic argument.
- STAT, PathAI, CMS policy, and academic research then show how implementation costs, downstream utilization, platform power, weak evidence, and changing professional roles shape the result.
- Together, they determine whether AI lowers costs or merely adds another reimbursable layer.
##
The Financial Architecture of Clinical AI:
Six Layers, Three Economic Species, and One CMS Contradiction
The payment question is larger than coding
Health care discussions of artificial intelligence often begin with the algorithm. How accurately does it detect disease? Has the FDA reviewed it? Can it be integrated into the electronic health record?
Commercial discussions often begin one step later: Is there a CPT code? Will Medicare pay separately? What rate can be obtained?
But the deeper question is not simply whether an algorithm can be assigned a code and payment. Clinical AI can change the way care itself is produced. It may substitute software for professional labor, perform work continuously rather than during discrete encounters, and apply an intervention across thousands or millions of patients at low incremental cost.
The most systematic recent treatment of this problem is the Peterson Health Technology Institute’s July 2026 report, Payment for Clinical AI. Peterson supplies the central economic argument. A three-part STAT series provides real-world stress tests. CMS policy reveals the difficulty of translating theory into claims rules. PathAI presents the enterprise and vendor business case. A systematic review by McGenity and colleagues examines whether the scientific evidence is ready for routine use. MedCity compresses the argument for a wider health-technology audience. Even a Google AI Overview illustrates how the emerging field is being packaged for ordinary users.
These sources are not equivalent. Peterson is a workshop-based policy framework. STAT is investigative journalism. CMS offers proposed rules and a demonstration model. PathAI is a vendor describing its own value proposition. McGenity is a peer-reviewed systematic review. The Google result is an automatically generated synthesis of heterogeneous internet sources.
Their differences are useful. Each illuminates a different part of the architecture.
Begin with the map: six interconnected layers
The six-layer framework should come before the individual sources because it explains where each source fits.
1. The investment layer
This includes the initial and continuing costs required to make AI operational:
software acquisition and licensing;
scanners, devices, cloud services, and storage;
EHR, LIS, PACS, and data integration;
cybersecurity and privacy infrastructure;
clinical validation;
staff training;
governance; and
redesign of clinical workflows.
The invoice for an algorithm may be only a fraction of the actual investment. An apparently inexpensive AI application can become costly if it requires six months of integration, multiple review committees, new data pipelines, and a team to act on its outputs.
2. The transaction layer
This layer determines how money moves. Possibilities include:
payment per image, case, patient, or algorithmic analysis;
enterprise subscriptions;
per-member-per-month payments;
condition-level bundles;
capitation;
shared savings;
milestone payments; and
payments withheld pending clinical outcomes.
The transaction model determines whether AI is rewarded for being used, for being available, for reducing labor, or for producing a result.
3. The workflow and accountability layer
An algorithm does not become clinical care merely by generating an output. Someone must:
review the result;
determine whether it is clinically relevant;
communicate with the patient;
resolve false positives and ambiguous cases;
respond to alerts;
coordinate follow-up;
maintain the treatment plan; and
remain responsible when the system fails.
AI can reduce one kind of work while creating another. Automated screening, for example, may reduce the effort required to find abnormalities but dramatically increase the work required to triage them.
4. The evidence layer
The evidence problem extends beyond model accuracy. It includes:
internal and external validation;
performance across different populations and institutions;
effects on clinician behavior;
patient outcomes;
downstream utilization;
comparative effectiveness;
health equity;
real-world monitoring; and
deterioration or “drift” after implementation.
An algorithm can be statistically impressive and still fail to improve care.
5. The market and integration layer
AI products do not compete solely on accuracy. They compete within existing technology markets.
An EHR or imaging-system incumbent may offer a moderately performing algorithm that is already integrated, inexpensive, supported, and easy to activate. An independent vendor may offer a better model but require a separate contract, security review, interface, workflow redesign, and ongoing support.
Platform power, switching costs, interoperability, data access, and distribution may therefore determine which algorithm wins.
6. The dynamic governance layer
Coverage, pricing, utilization rules, and evidence requirements should evolve.
An early payment may need to support adoption and evidence generation. It should not necessarily become a permanent toll. As volume rises, software costs fall, competition increases, and real-world evidence develops, payment may need to be reset.
Dynamic governance also includes:
utilization thresholds;
patient-selection criteria;
payment withholds;
clawbacks;
outcome reporting;
postmarket monitoring; and
scheduled reassessment.
The six layers continuously interact. A poor transaction model can encourage excessive utilization. Weak evidence can produce inappropriate coverage. An unintegrated product can fail despite excellent accuracy. A labor-saving algorithm can create uncompensated review work elsewhere in the organization.
Clinical AI payment is therefore not simply a code and rate. It is an interconnected system.
Three different economic species of clinical AI
Peterson’s distinction between assistive and autonomous AI is important. Assistive AI recommends; a clinician reviews and decides. Autonomous AI performs more of the clinical task with limited direct involvement.
But the sources suggest another useful taxonomy. “Clinical AI” contains at least three economically different species.
1. Diagnostic and interpretive AI
Examples include:
coronary-calcium detection on CT scans;
automated diabetic-retinopathy interpretation;
pathology image analysis;
fracture-risk prediction;
AI electrocardiography;
prostate-cancer mapping; and
algorithms applied to genomic or laboratory data.
The natural transaction is often per use, per case, or as an add-on to another diagnostic service.
The central risk is scalability. If the AI can be applied to every eligible image or dataset, even a small payment can produce substantial aggregate spending. The algorithm may also generate downstream visits, tests, biopsies, medications, and procedures.
For these products, the central policy questions are:
Which patients should be analyzed?
Is the AI replacing work or merely adding another layer?
Should payment be separate or bundled?
Does finding more abnormalities improve outcomes?
How much downstream utilization follows?
2. Enterprise workflow AI
Examples include:
digital-pathology image-management systems;
slide collation and case assembly;
case prioritization;
consultation platforms;
EHR-integrated prediction models;
documentation tools; and
systems that organize or transfer measurements into reports.
The purchaser is usually a hospital, laboratory, or physician organization. The payment model is more likely to be a subscription, enterprise license, or internal capital investment than an insurance claim.
The business case rests on:
productivity;
faster turnaround;
reduced shipping and physical handling;
avoidance of duplicated equipment;
increased capacity;
staff redeployment;
easier consultation; and
improved recruitment or professional satisfaction.
Here, market integration may be more important than reimbursement. The hospital may not need a new Medicare code if the technology creates enough operational value.
3. Longitudinal and increasingly autonomous care AI
Examples include:
hypertension management;
medication titration;
chronic-care monitoring;
behavioral-health support;
automated coaching; and
continuous detection of patient deterioration.
The natural unit is not an image or algorithmic output. It is the patient over time.
Appropriate payment may therefore resemble:
per-member-per-month financing;
condition-level bundles;
capitation;
shared savings; or
outcome-contingent payment.
The principal questions involve attribution, patient selection, clinical accountability, escalation, coordination with the patient’s regular physician, and whether the program substitutes for existing care or simply adds another service.
These three species overlap, but they should not be forced into one payment methodology. A pathology workflow platform, an incidental-imaging algorithm, and an autonomous hypertension program have different purchasers, cost structures, time horizons, and sources of value.
Peterson’s central argument: AI breaks fee-for-service assumptions
Peterson begins with a structural observation. Most American professional payment remains based on clinician time, practice expense, and discrete activities. These rules were created for human-delivered services supported by technology—not for technology capable of performing clinical work itself.
Current payment may discourage high-value AI when the technology reduces billable visits or procedures. At the same time, separately paying for each AI action can create rapid spending growth when software operates at scale.
Peterson identifies three mismatches.
Labor-based payment. Fee-for-service assumes that more output requires more professional work. AI can produce additional output without a proportionate increase in clinician time.
Encounter-based payment. Traditional payment revolves around visits and procedures. AI can monitor and interact with patients continuously between encounters.
Utilization-based economics. Human capacity places a natural ceiling on service volume. Software can be deployed across entire populations, while marginal costs increasingly resemble computing costs rather than clinical labor.
Under fee-for-service, reimbursement rises with billable volume rather than with value. If every additional algorithmic action generates another payment, spending can grow much faster than the underlying cost of production.
This is the central Peterson warning:
Software with near-zero marginal cost should not automatically receive labor-like payment each time it produces another unit of output.
Why capitation and pay-for-performance are not enough
Capitation and performance-based payment are better aligned with AI because they reward efficiency and outcomes rather than sheer volume. Yet Peterson argues that they still do not reliably support adoption.
Successful implementation requires far more than buying software. Organizations must redesign workflows, retrain staff, establish governance, define escalation rules, and decide when AI may act independently.
Most providers also operate under multiple payer contracts. A health system may bear the cost of redesigning care for all patients even when only a subset are covered under risk-based arrangements.
Attribution creates another difficulty. If blood-pressure control improves after home monitoring, navigation, pharmacist review, physician intervention, and algorithmic recommendations, how much value belongs to the AI?
Finally, the organization making the investment may not receive the financial return. A provider may pay for implementation while a health plan benefits from avoided hospitalization. Returns are often delayed, uncertain, and distributed among stakeholders who did not contribute equally to the investment.
This is why value-based care does not make the financing problem disappear. It converts a coding problem into a contracting problem:
Who supplies the capital, who assumes the risk, who receives the savings, and how is the value divided?
Assistive AI may preserve the old bottleneck
Assistive AI is easier to fit into current payment because a clinician remains involved. Medicare might pay for reviewing a recommendation, supervising the system, or incorporating the result into an encounter.
But this approach may preserve the same capacity limitation AI was supposed to overcome. If every recommendation still requires individual professional review, scale remains constrained by clinician time.
It may also become inflationary. If AI allows a clinician to process more patients while the payment for each service remains unchanged, aggregate spending can rise even though the labor required per case falls.
Peterson therefore gives autonomous AI special importance. As AI performs more of the cognitive work, the clinician’s role changes from producing every service to:
supervising systems;
validating outputs;
managing exceptions;
orchestrating care;
assuring quality; and
accepting responsibility.
The payment system must recognize that new role without recreating a full professional fee for every inexpensive software action.
Peterson’s design principles
Peterson proposes three broad principles.
- Payment should produce deflationary system value
“Deflationary” does not mean that AI must reduce every individual line item. It means reducing the long-term cost of care for a defined population while maintaining or improving outcomes.
The comparison should be real care without the AI—not an idealized clinical benchmark.
[BQ - I've joked that AMA's Appendix S on software and AI, should explain when it produces services that have negative RVUs. MRI, 20 RVU. MRI with our new software, 19 RVU.]
- Payment should be tied to results and appropriate utilization
Per-use payment may reward volume rather than value. Peterson suggests safeguards such as:
payment withholds;
clawbacks;
declining prices as utilization expands;
outcome contingencies; and
explicit controls against overuse.
- Payment should change as the technology matures
Early rates may need to support development, implementation, and evidence generation. But rates should be revisited as:
utilization grows;
marginal costs fall;
workflows stabilize;
competitors enter;
evidence improves; and
the clinician’s role changes.
Peterson’s approach resembles a payment life cycle rather than a permanent code.
ACCESS:a prototype for outcome-aligned AI financing
Peterson identifies the CMS Innovation Center’s ACCESS Model as the most concrete current example of payment that can accommodate AI-enabled care.
ACCESS is a ten-year model focused initially on cardiometabolic, musculoskeletal, and behavioral-health conditions. It does not require AI. Rather, it gives participating organizations flexibility to determine how care is produced.
Half of the payment is made upfront, while the balance is withheld pending achievement of defined outcomes. Because payment is not built from a stack of individual clinical activities, an organization may substitute software, automation, devices, or centralized services for conventional labor when those methods achieve the required results.
This is conceptually important. ACCESS does not pay for every blood-pressure reading, message, recommendation, or algorithmic calculation. It pays for managing a condition and achieving measurable results.
The model will not fit every use case. Outcome payment requires measures that are validated, observable, and reasonably attributable to the intervention. Hypertension is more tractable than general primary care, where multiple illnesses, physicians, and interventions overlap.
Still, ACCESS demonstrates what a different financial chassis may look like: defined patients, recurring financing, flexible production methods, and payment linked to results rather than to each unit of activity.
SIDEBAR:
CMS Drives a Stake Through RPM, Then Toasts ACCESS
The contrast between ACCESS and the CY 2027 Physician Fee Schedule proposed rule is startling.
In its RPM and RTM proposals, CMS writes as though remote monitoring had become a payment mechanism in need of emergency containment. The agency cites fragmented care, weak practitioner involvement, third-party cold-calling, uncertain device costs, incomplete service components, and proliferating codes.
CMS proposes:
an established-patient requirement for RTM;
a separately reportable initiating visit for RPM and RTM;
initiation by the billing practitioner during an in-person or telehealth encounter;
direct employment of the clinical staff whose time supports billing;
restrictions on outsourcing to third-party monitoring companies; and
substantial reconsideration of practice-expense valuation.
CMS repeatedly states that it lacks reliable information about typical devices and actual acquisition costs. It proposes lower or alternative crosswalks and removal of practice-expense inputs from some treatment-management codes while retaining professional work values.
It also cites an OIG finding that approximately 43% of remote-monitoring enrollees did not receive at least one of the three expected components: setup and education, device supply, and treatment management.
Yet CMS does not propose to abolish monthly remote monitoring. It considers collapsing 17 codes into four G-codes: setup and monthly management codes for RPM and RTM. The monthly codes would bundle device supply, data transmission, and at least 20 minutes of treatment management, including real-time communication.
That resembles ACCESS more than the hostile rhetoric initially suggests. Both models involve longitudinal care, recurring payment, remotely generated data, technology, patient interaction, and clinical management.
The decisive difference is the payment chassis.
Traditional RPM generates payment by documenting activities. Each enrolled patient can produce another set of monthly claims. Revenue depends primarily on satisfying code elements, not on demonstrating that the patient’s condition improved.
ACCESS finances management of a condition and withholds part of the payment pending outcomes. The participant has flexibility in how the work is performed but assumes more explicit accountability for results.
CMS therefore appears to be drawing this distinction:
RPM is represented as the physician practice’s billable service. If so, the practice must actually initiate, supervise, integrate, and furnish it. ACCESS is represented as an accountable organization’s longitudinal intervention. If so, the organization may use scalable technology—but payment depends substantially on outcomes.
CMS is not driving a stake through remote care. It is attempting to drive a stake through the RPM arbitrage model: fragmented code stacking, uncertain device expense, outsourced labor hidden behind a physician’s billing relationship, and payment triggered by activities rather than results.
But the tension should not be dismissed too easily. ACCESS may employ many of the same operational ingredients: centralized teams, software platforms, remote devices, protocols, and technology-supported patient engagement.
Outcome payment does not magically eliminate:
aggressive enrollment;
duplication of existing care;
weak coordination with regular clinicians;
selection of patients most likely to succeed;
optimization around narrow measures; or
excessive data and alerts.
The abrupt transition from RPM bashing to ACCESS enthusiasm reveals CMS’s central bet: the same technology-supported machinery becomes acceptable when the organization receiving payment is visible, the service is integrated, and revenue is tied to measurable results.
Whether that distinction proves durable in real-world practice will be one of the most important questions of ACCESS.
STAT Part 1:
Enter with low marginal cost, but enormous downstream consequences
Katie Palmer’s first STAT article, “AI could check millions of CT scans for heart risk. Who will pay for it?”, examines algorithms that detect coronary artery calcium on chest CT scans ordered for other reasons.
This appears to be an ideal use of AI. The scan already exists. There is no additional radiation from running the algorithm. Computers can examine every eligible image without fatigue. Missed abnormalities may be identified, and patients at cardiovascular risk may receive preventive treatment.
Medicare payment of roughly $15 per qualifying scan could encourage adoption. But approximately 19 million general chest CT scans are performed annually. A very small unit payment can become a substantial national expenditure when applied at scale.
The larger cost lies downstream.
A positive calcium finding may result in:
primary-care or cardiology visits;
statin treatment;
stress testing;
coronary CT angiography;
invasive angiography;
stenting; or
bypass surgery.
A health system operating under fee-for-service may view those patients as downstream revenue. A payer may see a population-wide cascade whose long-term benefit remains uncertain.
The Stanford experience discussed by STAT found much greater initiation of statins among notified patients, but also more follow-up testing. That is evidence that the algorithm changes care. It is not yet proof that it reduces heart attacks, strokes, or mortality.
The workflow burden is also substantial. Someone must determine whether a patient is already under treatment, whether the finding is clinically relevant, whether notification is appropriate, and who will manage the response.
This example crosses nearly all six layers:
Investment: implementation and data integration;
Transaction: payment per scan;
Workflow: review, notification, and referral;
Evidence: outcomes beyond statin initiation;
Market: vendor access to imaging systems;
Governance: patient selection and utilization controls.
STAT invokes the term “biomarkup” for the tendency of commercially attractive biomarkers to proliferate because they generate additional care. AI makes biomarkup scalable.
The economic question is not whether the algorithm can find more disease. It is whether finding and acting on that disease improves health enough to justify the full cascade.
STAT Part 2:
Incumbents: Why the best algorithm may not win
The second article, “In the battle of sepsis algorithms, performance alone doesn’t predict victory”, addresses market power and integration.
In theory, hospitals should compare algorithms and select the model that performs best in their population.
In practice, the choice is often determined by three questions:
Does it work?
Is it easy to turn on?
Is it inexpensive?
EHR companies have a major advantage. Their systems are already installed, connected to clinical data, integrated into workflows, and supported by existing contracts. STAT reports that the large majority of hospitals using predictive clinical algorithms rely on tools developed by EHR companies.
An independent company may offer earlier detection or better accuracy yet lose because implementation is costly and disruptive. A “pretty good” embedded product may defeat a better standalone product.
FDA clearance can help an independent vendor differentiate itself. Separate Medicare payment may also alter purchasing decisions. But vendors still need to build an economic case involving:
shorter length of stay;
improved bed capacity;
documentation;
coding;
reduced denials; or
operational efficiency.
Some companies respond by developing suites rather than individual point solutions, allowing the health system to spread integration costs across multiple applications. One developer described reducing implementation time from six months to six weeks.
The lesson is blunt:
Clinical performance is only one component of product value. Integration is itself an economic asset.
This raises a policy concern. If incumbent platforms control distribution, health systems may not adopt the strongest model. Competition policy, interoperability, procurement, and model-comparison infrastructure become part of AI payment policy.
STAT Part 3:
CMS creates an interim payment laboratory
The third article, “CMS signals intent to revamp how it pays for clinical software and AI”, describes Medicare’s emerging approach to software-based clinical services.
CMS proposes the term software as a medical service, or SaMS, rather than software as a service.
For 2027, CMS proposes moving a group of separately paid software codes into New Technology Ambulatory Payment Classifications. It would also create a distinct status indicator to identify these services.
The immediate payment changes may be modest. The strategic importance lies in categorization and data collection. New Technology APCs give CMS a place to pay provisionally while accumulating claims experience and deciding where the service ultimately belongs.
This is an interim payment laboratory.
Several disputes remain unresolved.
Should an algorithm be paid separately when it is layered onto an already-paid imaging interpretation, pathology workup, or laboratory service?
Should payment be reduced when the AI is billed with another procedure?
How should CMS calculate a per-use rate when hospitals purchase the same technology through radically different arrangements—per click, per case, subscription, or enterprise license?
CMS’s proposals also reveal a stronger evidentiary posture. The agency appears less willing to assume that FDA breakthrough status alone demonstrates sufficient clinical improvement. It increasingly asks whether a technology produces better outcomes or lower downstream costs.
For algorithmic analyses applied to laboratory data, CMS proposes treating the software more consistently with algorithms applied to imaging. But this creates difficult questions about pricing, CLIA, FDA oversight, contractor jurisdiction, and the boundary between a laboratory test and an independent medical service.
CMS clearly recognizes that it cannot simply create an unlimited number of separately payable AI widgets. But it has not yet settled on a general alternative.
Digital pathology:
The enterprise case comes before reimbursement
Digital pathology is a particularly useful test case because AI depends on a much larger infrastructure.
The algorithm may require:
whole-slide scanners;
image-management software;
storage;
networks;
interfaces with the LIS;
pathologist workstations;
digital archives;
cybersecurity;
validation; and
redesigned laboratory processes.
A Google AI Overview captured on July 21, 2026, organized digital-pathology financing into three categories: implementation and investment, coding and reimbursement, and emerging sources of revenue.
It described estimated implementation costs, per-slide and subscription pricing, temporary CPT pathways, and long-term workflow savings.
The framing is useful, but its precision should not be overinterpreted. A Google AI Overview is generated dynamically from sources of varying quality. Figures such as $100,000 to $400,000 for implementation or $1.3 million in five-year savings should be treated as leads to underlying evidence—not as independently validated findings.
Its real importance is informational. It shows how a complicated policy and business environment is being compressed for executives into a familiar checklist:
What does it cost, how do vendors charge, what can be billed, and when does the investment break even?
PathAI’s article, “Digital Pathology: The Top Four Cost Saving Use Cases in Pathology Labs,”, gives the vendor version of the enterprise case.
PathAI emphasizes:
removal of manual slide collation and case assembly;
reduced shipping and coordination for consultations;
automation of repetitive review tasks; and
lower spending on conventional microscopy equipment.
It cites an example in which digital pathology reduced case preparation, delivery, and handling time by 84%. It also describes major reductions in time associated with multidisciplinary conferences and external consultations.
AI-assisted platforms may prioritize cases, align images, identify regions of interest, and transfer measurements into the laboratory report. PathAI estimates a 20% productivity gain from adding AI to digital workflows.
These are vendor claims and selected examples, not a neutral systematic assessment. But they reveal something important: the business case for pathology AI may not depend primarily on separate insurance reimbursement.
A laboratory may invest because digitization:
expands capacity;
reduces scarce professional labor;
enables remote consultation;
shortens turnaround;
avoids physical shipping;
facilitates recruitment; or
supports a broader pathology network.
In that setting, a per-slide Medicare payment may be less important than enterprise return on investment.
Evidence architecture: high accuracy, weak foundations
The systematic review by McGenity and colleagues, “Artificial intelligence in digital pathology: a systematic review and meta-analysis of diagnostic test accuracy,”, provides a necessary counterweight to optimistic business cases.
The review included 100 studies, 48 of which entered the meta-analysis, representing more than 152,000 whole-slide images. Reported mean sensitivity was 96.3%, and mean specificity was 93.3%.
Those results are impressive.
But 99% of the included studies had at least one area of high or unclear risk of bias or applicability concern. Selection of cases, separation of development and validation datasets, raw performance data, and data sources were often inadequately described.
Routine clinical use remained uncommon despite rapid research development. The authors identified concerns involving:
representativeness of datasets;
external validation;
differences in specimen preparation;
heterogeneity of performance measures;
insufficient reporting;
limited numbers of institutions; and
publication bias.
They also note that slide-level performance may be more clinically relevant than performance on selected patches or tiles, because pathologists diagnose complete cases rather than isolated image fragments.
This distinction matters for payment. A payer or health system should not assume that a high AUC from a selected research dataset proves:
improved diagnostic outcomes;
safe deployment across laboratories;
better patient management;
reduced costs; or
superiority to existing workflow.
Accuracy is necessary. It is not the entire value proposition.
A mature evidence architecture must connect technical performance to actual care:
model output → professional response → altered management → patient outcome → total cost.
Failure at any link can erase the value suggested by the algorithm’s test-set performance.
MedCity: how a complex framework becomes a market narrative
Marissa Plescia’s MedCity article, “How Should Clinical AI Be Paid For? 3 Takeaways,”, compresses Peterson into three propositions:
Existing payment models can inflate costs.
AI payment should be deflationary, outcome-based, and adaptive.
Autonomous AI requires new models rather than minor modifications.
That summary is accurate and useful.
It also demonstrates how policy ideas travel. A nuanced report about labor substitution, attribution, contracting, and dynamic prices becomes a concise market narrative: current payment is broken, outcomes should matter, and autonomy needs a new model.
Such compression is inevitable. But it can conceal the hardest question: what operational rules transform “outcome-based payment” from an appealing principle into a workable contract?
Peterson identifies the direction. RPM, ACCESS, and the STAT examples show how difficult the implementation will be.
What each source contributes to this essay
Read together, the sources form a useful division of labor.
Peterson supplies the economic theory: current payment was designed for human work and may misprice scalable software.
STAT Part 1 shows the utilization problem: inexpensive computation can trigger expensive downstream cascades.
STAT Part 2 shows the market problem: integration and incumbent power may matter more than accuracy.
STAT Part 3 shows the administrative problem: CMS needs transitional categories, claims data, evidence, and a method for distinguishing software cost from clinical value.
The RPM proposal shows what happens when a scalable monthly code family becomes associated with weak integration, questionable valuation, and incomplete services.
ACCESS shows CMS’s proposed alternative: recurring but outcome-aligned financing with flexibility in how care is produced.
PathAI shows the enterprise business case: workflow savings may be more important than separate reimbursement.
McGenity shows the evidentiary gap: promising accuracy rests on studies with major risks of bias and limited clinical translation.
MedCity shows policy translation into a market-facing narrative.
Google’s AI Overview shows how the field is being simplified for general users into implementation cost, pricing model, billing route, and break-even analysis.
Each source circles the same center from a different direction.
Strategic implications for AI developers
Developers should begin with four questions before seeking a code:
What kind of AI is this—diagnostic, workflow, or longitudinal care?
Who makes the investment?
Where does the value appear?
Who is in a position to capture that value?
A developer should not assume that reimbursement is always the best commercial strategy.
A workflow product may be more credible as an enterprise investment. A diagnostic AI may require careful patient-selection criteria and evidence about downstream utilization. An autonomous chronic-care platform may need a condition-level outcome contract rather than a professional fee.
Developers also need evidence aligned with the commercial claim. If the value proposition is reduced length of stay, accuracy alone is insufficient. If the proposition is labor savings, a retrospective AUC does not answer the purchaser’s question. If the proposition is fewer cardiovascular events, increased statin initiation is only an intermediate outcome.
Strategic implications for health systems
Health systems should assess the full workflow rather than the algorithm in isolation.
Questions include:
Who will review the output?
What happens to positive results?
Which department bears the labor burden?
Does the tool create new referrals?
Can the system absorb them?
Does one service line earn revenue while another performs uncompensated work?
Is the technology replacing existing effort or simply adding another layer?
What happens when the vendor raises prices or the organization wishes to switch?
A separately reimbursed AI may still have negative enterprise value. Conversely, an unreimbursed AI may be worth purchasing if it expands capacity or removes enough operational friction.
Strategic implications for payers and CMS
Payers should be cautious about creating permanent per-use tolls for software whose marginal cost falls sharply with scale.
Temporary separate payment may be justified when it:
supports early adoption;
finances evidence generation;
identifies utilization through claims; or
offsets genuine implementation costs.
But mature payment should increasingly reflect:
outcomes;
appropriate utilization;
declining unit costs;
real-world performance;
substitution for existing services; and
downstream consequences.
The most important distinction may not be whether an AI service is separately paid or bundled. It may be whether the entity receiving payment is accountable for the full consequences of deploying it.
That is the core contrast between ordinary RPM and ACCESS.
Conclusion
Clinical AI has no single financial architecture because clinical AI is not a single economic product.
A diagnostic algorithm applied to millions of images raises questions about per-use payment and downstream cascades. An enterprise workflow platform raises questions about capital investment, integration, productivity, and vendor lock-in. An autonomous chronic-care program raises questions about longitudinal accountability, attribution, patient selection, and outcome-based financing.
The Peterson report correctly places payment at the center of AI adoption. But the surrounding sources show why payment cannot be considered alone.
Evidence determines whether the product deserves adoption. Workflow determines whether its information becomes care. Market structure determines whether the best product can compete. Governance determines whether early prices and coverage rules become permanent. Transaction design determines whether scalable computation lowers costs or creates unlimited billable volume.
CMS’s simultaneous hostility toward loosely integrated RPM and enthusiasm for ACCESS captures the issue unusually well. CMS is willing to support many of the same technologies, devices, and remote-care methods—but only after changing the financial chassis from activity-based billing toward accountable outcomes.
That may be the central policy experiment of the next decade.
AI has the potential to become a genuinely deflationary technology by substituting scalable computation for scarce labor. It also has the potential to become a new layer of automated utilization, recurring fees, downstream testing, and platform rents.
The difference will not be determined by the algorithm alone.
It will be determined by the architecture around it.
Bibliography
Centers for Medicare & Medicaid Services. (2026). ACCESS Model: Advancing Chronic Care with Effective, Scalable Solutions.
Centers for Medicare & Medicaid Services. (2026). CY 2027 Physician Fee Schedule Proposed Rule, CMS-1848-P: Regulations.gov docket.
Google Search. (2026, July 21). Google AI Overview search: Paying for AI in digital pathology. Dynamic search-generated overview; content may vary by date, user, and location.
McGenity, C., Clarke, E. L., Jennings, C., et al. (2024). Artificial intelligence in digital pathology: A systematic review and meta-analysis of diagnostic test accuracy. npj Digital Medicine, 7, 114.
Palmer, K. (2026, April 15). AI could check millions of CT scans for heart risk. Who will pay for it?. STAT.
Palmer, K. (2026, May 12). In the battle of sepsis algorithms, performance alone doesn’t predict victory. STAT.
Palmer, K. (2026, July 16). CMS signals intent to revamp how it pays for clinical software and AI. STAT.
PathAI. (2025, March 5). Digital pathology: The top four cost saving use cases in pathology labs.
Peterson Health Technology Institute. (2026, July). Payment for Clinical AI.
Plescia, M. (2026, July 20). How should clinical AI be paid for? 3 takeaways. MedCity News.
