When Medicare starts paying for outcomes, the evidence becomes the product

A category with a name

On July 2, 2026, CMS released the CY 2027 Hospital Outpatient Prospective Payment System proposed rule (CMS-1850-P). On July 14, it followed with the CY 2027 Physician Fee Schedule proposed rule. Together they do something Medicare has not done before. They give clinical software its own payment category, with a name.

The category is Software as a Medical Service, or SaMS, replacing the older label Software as a Service. CMS defines it as software-based technologies that support clinical decision-making through algorithmic analysis, and distinguishes it from prescription digital therapeutics and from remote physiologic and therapeutic monitoring.

The outpatient proposal does three concrete things:

• designates 36 HCPCS codes as SaMS, covering services such as AI-based retinal imaging analysis, CT-derived fractional flow reserve, quantitative brain MRI analysis, and algorithmic ECG risk assessment
• creates a new status indicator, O1, to identify SaMS on outpatient claims
• moves 21 SaMS codes currently paid under clinical Ambulatory Payment Classifications into New Technology APCs, which CMS describes as interim while it develops a longer-term methodology

The Physician Fee Schedule proposal is narrower. It adopts the SaMS terminology, moves certain algorithm-only analyses off the Clinical Laboratory Fee Schedule to contractor pricing, and opens a request for information asking whether CMS should build a consistent payment framework for SaMS across care settings.

What these proposals do not do

Before the implications, the limits, because they matter and a skeptical reader will find them anyway.

The Bipartisan Policy Center's read is that the interim SaMS proposal largely standardizes how these tools are categorized and does not meaningfully change payment rates. That is accurate. Most of the 36 designated codes describe clinical services Medicare already pays for today. The proposal changes the label and, in some cases, the payment bucket.

CMS is also not proposing a single Medicare payment category for AI or clinical software in general. Reimbursement stays tied to discrete clinical services, determined code by code.

So this is not the moment Medicare started paying for AI. It is the moment Medicare started building the shelf that payment will eventually sit on. The interesting part is what CMS said about where the shelf is headed.

The signal inside the interim step

CMS describes the New Technology APC assignment as interim while it develops a permanent methodology, and the Bipartisan Policy Center notes CMS is working toward a more comprehensive long-term approach aimed at reducing payment rate variation across similar technologies. STAT's reporting on the rules framed the direction plainly: CMS is ready to build a more consistent payment structure for clinical software and AI that factors in their impact on patient outcomes.

Read that last clause slowly. Impact on patient outcomes, as an input to the payment rate.

There is a parallel signal in coding. The American Medical Association's CPT Appendix S taxonomy classifies AI services as assistive, augmentative, or autonomous. Revisions accepted in May 2026, effective with the 2027 code set, key that classification to the software's outputs and the clinical role those outputs play, rather than to work performed by the machine.

Both movements point the same direction. The thing being classified, and eventually priced, is the output and what it does clinically.

Measurement becomes a financial instrument

Here is why that matters to anyone responsible for clinical AI governance.

Today a vendor's performance evidence is a quality artifact. It informs a selection decision. If it is thin or self-serving, the cost is diffuse: a tool underperforms, clinicians route around it, someone eventually notices.

If payment tracks measured impact on patient outcomes, that same evidence becomes something else. It becomes an input to a payment rate. It acquires a dollar value, and with it a party holding a direct financial interest in what it says.

This is the Independence Principle applied to money rather than to safety. The argument usually runs on grading: the party that generates a clinical AI's output cannot credibly be the party that grades it, because a self-administered benchmark measures what its author chose to measure, under conditions its author chose to set. No bad faith is required for that gap to exist. The structure produces it.

Outcome-linked payment adds a third role to the two we normally discuss. There is the party that generates the output. There is the party that measures its clinical impact. And now there is the party that gets paid on the basis of that measurement. When all three collapse into one organization, a health system is not buying a measurement. It is accepting one.

None of this requires believing a vendor acts in bad faith. It requires noticing that we are about to attach a price to a number, and asking who computes the number.

A gap worth naming

There is a structural wrinkle in the pending legislation that deserves attention.

The Health Tech Investment Act, introduced in 2025 and still in committee, would create a statutory Medicare pathway for algorithm-based healthcare services: placement in New Technology APCs based on manufacturer-submitted cost data, with no reassignment for at least five years. As drafted, eligibility turns on the service being delivered through an FDA-cleared or FDA-approved device.

That drafting choice excludes clinical decision support software that meets the statutory criteria for exclusion from the device definition under section 520(o) of the Federal Food, Drug, and Cosmetic Act.

Follow that through. The same carve-out that keeps a large class of clinical decision support outside FDA device review would also keep it outside the clearest proposed payment pathway. The tools subject to the least external evaluation are the ones locked out of the route that would demand manufacturer-submitted cost data and a five-year commitment.

Whatever you conclude about whether that is sound policy, note the practical consequence for a health system. For a meaningful share of the clinical software running in your building, neither FDA review nor this payment pathway is generating independent evidence about performance. The evaluation is yours to run. It was already yours. It is about to have a price attached.

The bill is pending and has not advanced out of committee, and no one should build a reimbursement strategy around it. The eligibility gap it exposes is real regardless of whether it moves.

What to require in a SaMS-era vendor packet

If outcome-linked payment is the direction, the evidence packet a vendor hands your value analysis committee stops being marketing collateral and starts being a financial document. Six questions follow directly.

• Who measured the outcome, and were they paid by the party being evaluated? Not an accusation, a disclosure. It should be answerable in one sentence.
• What was the comparator? Impact on patient outcomes is a relative claim. Against usual care, against a prior tool, or against nothing at all are three different claims wearing the same words.
• Was the measurement performed on a population like yours? Performance on the development population is a different number than performance on yours, and that gap is where most deployed models disappoint.
• What happens to the evidence when the model changes? A number measured against version 3 does not describe version 7. Ask what triggers re-measurement, and who decides.
• Could you reproduce the measurement in-house if you had to? If not, you cannot verify the claim your payment may eventually depend on. Worth knowing before the contract rather than after.
• Who is accountable if the measured impact does not materialize? Payment tied to outcomes creates an exposure. Ask where it sits.

Notice who these questions belong to. Not only the CMIO and the chief quality officer. A value analysis committee, a revenue cycle lead, and a CFO now own a clinical evidence question they did not previously have to ask. That is a new audience for a conversation this field has mostly held among clinicians.

The comment window is open

Both rules are open for comment. The OPPS proposed rule closes August 31, 2026. The Physician Fee Schedule proposed rule closes September 14, 2026. The PFS rule carries an explicit request for information on whether CMS should establish a consistent payment framework for SaMS across care settings.

That is an unusually direct invitation. CMS is asking how to build the permanent methodology. If you believe evidence of clinical impact should come from somewhere other than the party being paid for that impact, this is the comment period in which to say so.

Wilson Sonsini's analysis of the proposals closes on a point worth carrying forward: the rules do not eliminate the growing expectation among Medicare and commercial payers that software developers demonstrate not only analytical validity or FDA-cleared performance, but also meaningful clinical utility and measurable impact on patient care.

Measurable by whom is the question the next few years will answer.