Header: The OPPS proposed rule for 2027 is released. After a couple years of patchwork solutions, CMS adopts broad interim measues for software-dominant services. CMS also promised a more worked-out plan for next year.
##
Find the proposed rule here:
##
CMS Takes the Next Step on Paying for Medical Software:
From RFI to Rulemaking
In July 2025, CMS asked the public how Medicare should think about reimbursement for software-based medical services. It did so in both major Medicare payment worlds: the Physician Fee Schedule, where the issue is practice expense and Part B professional services, and OPPS, where the issue is hospital outpatient payment. In the PFS proposal, CMS specifically asked for comment on “Software as a Service,” noting that software algorithms and AI do not fit comfortably into older practice-expense categories built around clinical labor, supplies, and equipment.
December widened the aperture. In December 2025, HHS issued a broader RFI on accelerating the adoption and use of AI in clinical care. One of its sections focused directly on reimbursement, noting that government fee-for-service payment can be slow in recognizing high-value interventions. (HHS.gov) (Federal Register)
That December HHS RFI was not limited to Medicare coding minutiae. It asked a larger policy question: if AI-enabled tools can improve care, reduce friction, or avoid downstream costs, how should federal health programs avoid becoming the bottleneck?
ACCESS as the Parallel Universe
CMMI is already testing a different answer. The ACCESS model — Advancing Chronic Care with Effective, Scalable Solutions — tests outcome-aligned payments in Original Medicare for technology-supported chronic care. CMS describes ACCESS as a model that uses predictable payments, with full payment tied to measurable health goals rather than simply paying for enumerated activities. (CMS) (CMS)
That matters because ACCESS is, in effect, one policy laboratory for paying software-enabled care. Vendors and care organizations can receive recurring payments for chronic disease interventions, but they must meet defined outcome measures to avoid reduced payments. This is very different from the OPPS problem, where CMS is still trying to decide whether a software output should sit in a clinical APC, a new technology APC, a packaged status indicator, or something else entirely.
SaaS Becomes SaMS
In the new OPPS proposal, CMS says it has been evaluating a comprehensive SaMS payment approach for several years, has sought input through several comment solicitations, and wants a payment strategy aligned with quality, health improvement, cost reduction, and system strengthening.
A new name for a Medicare problem. CMS now proposes to retire “SaaS” and use “Software as a Medical Service,” or SaMS. The reason is partly linguistic and partly policy-driven. “SaaS” already means ordinary cloud-based software in the technology world. CMS wants a Medicare term for software-based technologies that support clinical decision-making through algorithmic analysis, including diagnostic or clinical functionality.
The distinction is important. CMS is not talking here about ordinary hospital IT, billing software, EHR modules, or cloud subscriptions. It is talking about clinical software that produces medical information — for example, algorithmic analysis of images, risk models, computer-aided detection, and other outputs that assist diagnosis or treatment planning.
Why OPPS Has Trouble With Software
The old system prices tangible inputs. CMS candidly states the core problem. Medicare Part B payment systems, including OPPS, were built mainly to pay for services with material resources: staff time, equipment, supplies, rooms, and procedural overhead. SaMS is different. Its value may lie in a proprietary algorithm, a trained model, scalable non-material infrastructure, licensing terms, and clinical performance.
That creates two awkward questions. First, how should Medicare value a service when the “cost” is not a scanner, a catheter, or a technician’s minutes, but a licensed algorithm? Second, how should Medicare handle hospital acquisition models that may involve subscriptions, enterprise licenses, per-use charges, or “per-click” fees?
CMS also flags program integrity. A per-click software fee can look like a cost input, a royalty, a utilization incentive, or all three, depending on how the business arrangement is structured.
The 2027 Interim Policy: A Holding Pen
New technology APCs for now. For CY 2027, CMS proposes an interim policy. It would designate 36 HCPCS codes as SaMS services. For 21 separately paid SaMS codes currently assigned to clinical APCs, CMS would move them into new technology APCs that approximate their CY 2026 payment rates.
This is not yet a full value-based methodology. It is more like a structured holding pen. CMS is saying that the clinical APC architecture does not adequately accommodate SaMS, but CMS is not yet ready to announce a final long-term payment model.
- SIDEBAR: Table 61 shows 36 HCPCS codes that will be reclassifed as SaMS.
The New O1 Status Indicator
A label with payment consequences. CMS also proposes a new OPPS status indicator: “O1,” defined as Software as a Medical Service, paid under OPPS with separate APC payment. Functionally, O1 would behave like status indicator S, meaning separate payment and no multiple-procedure discounting.
CMS also asks whether a status indicator behaving more like T — subject to multiple-procedure discounting — would be more appropriate. That is a small technical question with large implications. If SaMS tools are frequently used alongside imaging, procedures, or other diagnostic services, multiple-procedure discounting could materially change the business model.
Packaging Is Not Forgotten
CMS avoids sudden disruption. Some SaMS codes are currently conditionally packaged under Q1. CMS considered more aggressive packaging, including unconditional packaging under status indicator N, but concluded that such a move could interrupt patient access. For 2027, CMS proposes to maintain current clinical APC and status-indicator assignments for SaMS codes that are already conditionally packaged.
That is classic CMS incrementalism. The agency is not declaring that every algorithm deserves separate payment. But it is also not forcing all software into packaging before it has a durable framework.
The Table Is the Policy
Table 61 is the map. The proposal includes a detailed Table 61 listing the HCPCS codes CMS proposes to treat as SaMS. The list includes automated retinal imaging analysis, coronary FFR derived from CT angiography, fracture-risk software, concussion eye-movement analysis, ECG algorithmic risk assessment, brain MRI quantitative analysis, cardiac arrhythmia simulation, prostate cancer estimation mapping, perivascular fat cardiac risk assessment, 3D anatomical segmentation, and other software-derived clinical analyses.
The diversity of the list is the point. SaMS is not one clinical specialty. It is a payment category cutting across ophthalmology, cardiology, radiology, neurology, orthopedics, oncology, and procedural planning.
The Laboratory Pivot
The next problem is lab algorithms. CMS proposes that primarily software-driven or algorithmic lab tests are no longer classed as lab tests, but as non-CLFS software medical services. This will certainly be controversial. CMS proposed to remove about a dozen codes from the CLFS and plant them instead on the OPPS code list. For now, prices would be crosswalked from the most recent CLFS price.
Why This Matters
CMS is separating the specimen from the software. This is the conceptual move. The original lab work may be regulated, coded, and paid as a laboratory test. But subsequent algorithmic interpretation of already-generated data may be a different thing. It may be proprietary. It may be scalable. It may not map cleanly onto CLFS, PFS, or OPPS conventions.
For laboratories, hospitals, AI companies, and genomics firms, this is a major signal. CMS is beginning to build vocabulary and payment architecture for software-derived medical information, even when that information is downstream from a conventional diagnostic input.
The Policy Direction
Not value-based yet, but not business-as-usual. The 2027 OPPS proposal does not create a grand unified theory of medical software payment. It does something more modest and more practical. It renames the category, creates a SaMS-specific status indicator, moves many separately paid services into new technology APCs, preserves some packaging arrangements, and asks for further comment.
Seen alongside the July 2025 RFIs, the December HHS AI RFI, and the ACCESS model, the direction is clear. Federal policy is no longer treating medical software as a novelty at the edge of the payment system. CMS is now trying to decide whether SaMS should be paid like a diagnostic test, a procedure, a hospital resource, a software license, or an outcome-linked intervention.
For 2027, the answer is still transitional. But the transition itself is the story.