A few days ago, this blog flagged that CMS was proposed to take software-intensive lab tests OFF the clinical lab fee schedule (at least in the hospital outpatient setting.) Here. We flagged that this is not a lab-only policy but a whole new field of CMS policy for "software as a medical service" or SaMS. Here.
"SaMS" occurs 91 times in the outpatient rule.
On July 7, CMS published the Federal Register rulemaking for both (1) SaMS in general AND for (2) SaMS applied to software-intensive lab tests. Find it here:
https://www.govinfo.gov/content/pkg/FR-2026-07-07/pdf/2026-13656.pdf
Comments due August 31, 2026; starting point here.
Pagination of New Rules
- CMS overviews SaMS on page 41803.
- Note that references to new SaMS concepts occur througout the New Tech applications; e.g. 41804 including footnote column 3.
- The discussion of general SaMS starts on page 41918 to 41920 (plus tables 41921-41925.
- The discussion of LABORATORY SaMS starts on 41925 and runs to 41926, plus table 41927.
- Discussion of new SaMS modifier O1 on page 41929, table 63.
What about Non-OPPS Settings? Wait for PFS Rule!
This maneuver—pulling AI pathology codes off the Clinical Laboratory Fee Schedule and placing them into the general-purpose OPPS “New Technology” APC framework—appears in the CY 2027 proposed Outpatient Prospective Payment System rule. But the corresponding Medicare Physician Fee Schedule proposed rule, governing many non-hospital Part B settings, had not yet been released as of July 7. It seems likely that CMS may try to make a parallel move there as well, but that remains to be confirmed. For now, readers should treat the OPPS proposal as a strong signal of CMS’s direction, while watching for the Part B rule, expected shortly, to see whether CMS extends the same policy logic beyond hospital outpatient settings.
CMS Sounds P*ssed-Off
In several places, CMS sounds less like it is merely proposing a technical payment change and more like it is regretting how these codes got onto the CLFS in the first place. The agency’s basic message is that these algorithmic services are a poor fit for the Clinical Laboratory Fee Schedule. CMS says it has been making its crosswalk and gapfill decisions on this kind of test, with limited visibility into the real costs of the algorithmic component, especially when companies describe those elements as proprietary and therefore provide little useful detail.
In the earlier, general SaMS discussion — which lab readers really do need to read alongside the lab-specific section — CMS also complains about the difficulty of valuing subscriptions, licenses, and per-click fees. That discussion appears before the lab section, but it is essential background for understanding why CMS is now trying to move certain lab-associated algorithmic codes into a broader SaMS framework.
CMS opens the lab section by saying that it is familiar with tests that combine sequencing, immunoassays, or other laboratory methods with computer algorithms — the classic MAAA model. But CMS says the field has moved beyond that.
“More recently,” the agency writes, it is seeing “the development of distinct algorithmic analyses alone.” Once genomic data have been generated, CMS argues, the data can be analyzed again and again, potentially “an infinite number of times,” to produce different diagnostic, prognostic, or risk-related outputs. These analyses may be proprietary to a single laboratory, but CMS emphasizes that they could also be performed in a range of settings.
That leads CMS to its key conclusion: these downstream algorithmic analyses should not be treated as clinical diagnostic laboratory tests for CLFS payment. CMS states that it does “not believe it is appropriate” to consider secondary algorithmic analyses to be CDLTs, because the software analysis performed “on” laboratory data does not necessarily require a CLIA-regulated laboratory. In CMS’s framing, the sequencing or other wet-lab step may require a CLIA laboratory, but a later software analysis of the already-generated data could be performed by “any non-regulated entity” with the necessary computer software. CMS also says that a laboratory performing only algorithmic analysis of previously sequenced data may not qualify as a CLFS laboratory since CLFS status mandates CLIA certification.
This seems wrong. It is true that not every experiment with machine learning is a medical laboratory test. Today a high school honors student might sequence a gene; a graduate student might run a machine-learning model on a laptop; anyone with a slide scanner and open-source software might experiment with digital pathology images. None of that makes the activity a medical CLIA test. But the reverse is surely true: the fact that a clinical result is generated by software does not automatically make it non-laboratory medicine. Modern molecular diagnostics and digital pathology often turn human specimens into data, and then turn those data into patient-specific clinical reports. (Signing out all-digital slides is to use "bits and software" not "things." But radiologists also work on computers and screens with "bits only" images from MRI or CT.) The key distinction is not whether a computer is involved. The key distinction is whether the activity is a validated, ordered, patient-specific diagnostic service performed and reported in a clinical framework.
CMS proposes, for now, to move about ten CLFS codes into the OPPS New Technology APC system, flag them with the new SaMS status indicator, and set payment rates by matching current CLFS payment levels as closely as the APC bands allow. But this is plainly transitional. CMS is not saying the New Technology APC amounts are the final answer. It is saying, in effect, that SaMS needs its own payment policy, and CY 2027 is the holding pattern while the agency works on that broader framework. The real policy fight may come next summer, in the July 2027 proposed rules for CY 2028.
If you'd like my redlined pages of Fed Reg, they are in the cloud here.
###
What follows is a Chat GPT 5.5 discussion of the SaMS proposed rule.
###
CMS’s proposed SaMS policy in the CY 2027 OPPS rule
CMS’s CY 2027 OPPS proposed rule marks an important transitional moment for software-based diagnostic services. CMS proposes to stop using the term “SaaS,” which it had used in earlier rulemaking, and instead use “Software as a Medical Service,” or SaMS, for software-based technologies that support clinical decision-making through algorithmic analysis. The change is partly semantic, but not trivial: “SaaS” is a broad commercial-cloud term, while CMS wants a term that signals a medical service rather than a generic software delivery model. In the proposed rule, SaaS and SaMS are functionally interchangeable, but going forward CMS proposes to use SaMS as the Medicare payment term. SaMS is used 91 times.
Years of Struggles
CMS also makes clear that it has been struggling with this topic for several years. The agency points back to prior comment solicitations in earlier OPPS rules and says it has been trying to design a payment strategy that supports quality, improves health, reduces costs, and strengthens the health system. The difficulty is that Medicare Part B payment systems were built around services that consume material resources: staff time, equipment, supplies, rooms, drugs, devices, and technical work. SaMS products do not fit that model neatly. Their value may be concentrated in proprietary algorithms, model development, validation, FDA work, cybersecurity, updates, monitoring, clinical support, and distribution. The marginal cost of running one more case may be small, but the total cost and clinical value of the service may be substantial.
A Lot of Policy - But It's Still "Interim Policy"
For CY 2027, CMS is therefore proposing an interim policy, not a final architecture. CMS proposes to move many separately paid SaMS services into New Technology APCs and to create a new OPPS status indicator, O1, meaning “Software as a Medical Service, paid under OPPS; separate APC payment.” Functionally, O1 would operate like status indicator S, allowing separate APC payment. CMS also asks whether a status indicator more like T, subject to multiple-procedure discounting, might be more appropriate for some SaMS services. This is a warning signal: CMS is not merely relabeling codes, but actively testing how these services should behave inside OPPS payment logic.
The proposed CY 2027 policy is deliberately conservative. CMS proposes to maintain payment continuity for SaMS services already in New Technology APCs and to place many clinical-APC SaMS codes into New Technology APCs that match their CY 2026 payment rates.
The agency says it wants to avoid disruption while it develops a more comprehensive methodology. In practical terms, this means CY 2027 should be understood as a bridge year. Major new payment policies may not emerge until the July 2027 OPPS proposed rule for CY 2028, when CMS may have more comments, more claims experience, and a more developed theory of how algorithmic services should be valued.
Reimbursement Stumbled with Per Click Fees
A major theme, although somewhat understated, is CMS’s discomfort with subscriptions, licenses, and per-click fees. CMS notes that SaMS technologies may be acquired by hospitals through subscription arrangements, license fees, or per-use/per-click charges, and that these arrangements raise program-integrity concerns. The concern is understandable. A per-click fee can look like a vendor-created tollbooth attached to a Medicare service. A subscription fee can be difficult to allocate to a specific patient encounter. A license fee may bundle software access, support, updates, and proprietary value in a way that does not look like a conventional hospital cost.
But there is a counterproblem. If CMS distrusts subscriptions, licenses, and per-click fees, it may also be discarding the only market evidence available for valuing the service. A SaMS product may actually be sold on a per-click basis. If that fee is disregarded, the remaining “cost” may appear to be only a trivial computation, even though the fee is paying for the clinical model, the validation, the regulatory file, the ongoing maintenance, the user interface, the reporting system, and the risk borne by the developer. In ordinary OPPS rate-setting, acquisition cost is often a starting point. For SaMS, CMS is wary of the acquisition structure itself. That leaves a valuation vacuum: the observable economic transaction is suspect, but once it is ignored, there may be no obvious substitute.
Pivot to the laboratory section
The laboratory portion of the SaMS discussion is likely to be of highest interest to laboratory and molecular-diagnostics readers. But a laboratory reader still has to read both sections: the general SaMS section and the laboratory-specific SaMS section. The lab section cannot be understood in isolation. CMS’s proposed O1 status indicator, its preference for New Technology APCs, its concern about algorithmic scalability, and its broader discomfort with current OPPS and CLFS valuation tools are all developed first in the general SaMS discussion. The lab section is an application of that broader policy theory to tests historically paid under the Clinical Laboratory Fee Schedule.
From MAAA Tests - Chemistry + Numbers - to Algorithm Data Only
CMS opens the lab discussion by saying that it has become accustomed to tests that combine laboratory analysis with algorithms. The familiar example is the MAAA category: multi-analyte assays with algorithmic analysis. In that model, a laboratory performs sequencing, immunoassays, expression profiling, methylation analysis, or other wet-lab work, and then applies an algorithm to produce a clinical result. CMS then says that the field has moved further. It is now seeing “algorithmic analyses alone.” Once genomic or other laboratory data exist, the data can theoretically be reanalyzed repeatedly to generate different clinical outputs. CMS emphasizes that such secondary analyses may be proprietary to a single laboratory, but also may be performed in a range of non-laboratory settings.
CMS’s proposed conclusion is clear, but it may not be correct: these secondary algorithmic analyses should not be treated as clinical diagnostic laboratory tests for CLFS payment.
CMS argues that the original genomic sequencing must be performed by a CLIA-certified laboratory for Medicare CLFS payment, but the downstream algorithmic analysis of the sequence data can be performed by any entity with the necessary software. [This may be wrong.] Therefore, CMS proposes to treat these services not as diagnostic laboratory tests, but as “other diagnostic tests” under Medicare law, and to move ten such codes from the CLFS into OPPS New Technology APCs with the new O1 status indicator. Table 62 lists examples, including oncology algorithmic analyses based on previously sequenced RNA data, digitized whole-slide images, histologic and immunohistochemical features, tumor microenvironment culture panels, and exome comparator analyses. [Probably 81416 should be 81417 and 81427 should be added - BQ]
This is the most provocative part of the proposal. CMS is correct that not every downstream computation is automatically a laboratory test. It is also correct that data can be reused, and that a sequence file or image file can become the substrate for many later analyses. But CMS’s reasoning risks overshooting. The fact that an analysis can be performed on a computer does not prove that it is not a laboratory service. Modern laboratory medicine is already deeply computational. Variant calling, copy-number analysis, methylation classification, gene-expression scoring, tumor-fraction estimation, minimal residual disease modeling, and whole-slide image analysis may all involve extensive computation after the human specimen has been converted into data. CLIA inspections, CAP inspections, all include software.
A useful way to see the problem is to separate technical possibility from regulated clinical use. A high school student may be able to sequence a gene. A graduate student may be able to run machine-learning experiments on digitized slides using a laptop. A person with a slide scanner and open-source tools may be able to classify images, cluster tumors, or train a model. But none of that, standing alone, makes the activity a Medicare-covered medical CLIA test. The regulatory and payment question is not whether computation is possible. It is whether a patient-specific clinical service is being ordered, performed under appropriate controls, interpreted, reported, and used for diagnosis, prognosis, treatment selection, or risk assessment.
That distinction cuts both ways. Mere experimentation with machine learning is not a clinical laboratory test. But a validated, patient-specific algorithmic analysis embedded in a laboratory workflow may still be part of laboratory medicine, even if the final analytic step is computational. CMS appears to treat “could be performed by a non-regulated entity” as a reason to remove the service from the CLFS. That logic is unstable. Many technically simple acts can be performed outside a regulated environment; what matters is whether the service is being offered as a clinical diagnostic result. A thermometer can be bought at a pharmacy, but vital signs in a hospital chart are still clinical data. Any kind of DNA sequence file can be analyzed by software outside a lab, but a clinically controlled validated patient report from a certified laboratory is a different thing.
CMS’s “infinite reanalysis” point is also only partly persuasive. A genome may be sequenced once, and the resulting data may be reanalyzed many times. But Medicare payment is not for infinite computation in the abstract. Payment is for a medically necessary clinical service at a particular time, for a particular patient, for a particular clinical purpose. A second interpretation may be duplicative and non-covered, or it may be clinically reasonable because the patient has a new cancer, a new therapy choice, a new variant database, a new family history, or a new diagnostic question. The reusability of data creates payment challenges, but it does not by itself define the service as non-laboratory.
Where is CMS Going?
The more balanced policy question is whether CMS needs a new category for algorithmic diagnostic services that are neither conventional wet-lab tests nor ordinary imaging services. CMS seems to be moving in that direction through SaMS. The concern is that, in the lab section, CMS may be using SaMS not merely as a neutral payment category, but as a lever to pull certain algorithm-heavy codes out of the CLFS. For laboratories, the stakes are substantial: CLFS payment has no beneficiary cost-sharing and follows lab-specific rate-setting rules, while OPPS payment is embedded in hospital outpatient policy, APC bands, packaging logic, cost-sharing, and budget-neutrality concerns.
For now, the practical message is that CY 2027 is a transition year. CMS is not yet presenting a mature theory of how algorithmic medical services should be valued. It is creating a SaMS label, assigning a new O1 status indicator, using New Technology APCs as a temporary holding area, and asking for comments. The lab section should be read as a warning that CMS is actively reconsidering whether some algorithmic diagnostics belong on the CLFS at all. But the agency’s proposed boundary — laboratory test if CLIA wet-lab work is required, SaMS if downstream software can run elsewhere — may be too crude for modern diagnostics. The harder and more durable boundary will have to distinguish research computation, software utilities, clinical decision support, physician interpretation, and bona fide patient-specific diagnostic testing.
