In both its OPPS proposed rules, and its PFS or Part B proposed rules, CMS has proposed to drop AI-based or software-intensive lab diagnostic tests from the Clinical Laboratory Fee Schedule. CMS says these services are not "CLIA tests" and do not require CLIA lab status. In both rules, CMS preserves coding and payment pathways. In OPPS, coding is the same, payment is shifted to APCs, and in PFS, coding is the same, payment is "contractor priced."
However, CMS neglected to mention a third factor. How would such labs enroll in Medicare? You have to enroll as "something" - as a doctor's office, as an ambulance service, as an ASC, and so on.
I let Chat GPT chew on this dilemma and discuss it.
###
CMS has addressed coding and payment—but not the supplier enrollment pathway
The proposal exposes a third problem distinct from coverage and pricing:
Benefit category: Is the service a clinical diagnostic laboratory test or an “other diagnostic test”?
Payment system: Is it paid on the CLFS, under the PFS, or through an OPPS APC?
Enrollment category: What kind of Medicare supplier is legally permitted to submit the claim?
CMS addresses the first two but largely overlooks the third. It reasons that a downstream algorithmic analysis of previously generated genomic, histologic, or other laboratory data is not itself an examination of human material and therefore need not be performed by a CLIA-regulated entity. (Some will strongly disagree.) CMS consequently proposes to treat these analyses as “other diagnostic tests,” contractor-price them under the PFS, and place the corresponding hospital services in new-technology APCs.
But Medicare does not pay an unclassifiable commercial entity simply because its service has acquired a code and price. Under 42 CFR 424.505, a provider or supplier must be enrolled to receive Medicare payment. (eCFR)
The enrollment form is CMS-855B
The classic Part B organizational enrollment application is CMS-855B, Medicare Enrollment Application—Clinics/Group Practices and Other Suppliers. The form requires the applicant to select a supplier type. Among the choices are:
Independent clinical laboratory
Independent diagnostic testing facility
Clinic/group practice
Pharmacy
“Other”
But “Other” is not an open-ended invitation to invent a new supplier category. The form expressly says that it may be selected only when the supplier type is already eligible to enroll and bill Medicare but is not shown on the list. An applicant uncertain whether it is eligible is directed back to its MAC. (CMS)
That is precisely where the circularity can begin.
IDTF is the apparent destination—but it is an awkward one
Once CMS calls the service an “other diagnostic test” paid under the PFS, an IDTF becomes the most obvious existing enrollment category for a freestanding, nonphysician software company. Section 410.33 says that PFS diagnostic procedures generally must be performed by a physician, physician group, certain enumerated practitioners or suppliers, or an independent diagnostic testing facility. For a corporate software vendor that is neither a medical practice nor a laboratory, IDTF may be the only plausible item on that list. (eCFR)
There is some precedent for stretching the IDTF concept toward remote services. The regulations recognize IDTFs that perform services remotely and never see beneficiaries at their premises, relieving them of requirements such as handwashing facilities and patient-privacy accommodations. (eCFR)
Nevertheless, the IDTF framework remains heavily designed around imaging and physiologic testing:
A physical practice location
Diagnostic equipment maintained at that location
Equipment inventories, model numbers, and serial numbers
Named technicians and their credentials
An interpreting physician, when applicable
A supervising physician proficient in each procedure
Code-by-code approval by the MAC
State licensing and multi-state operational requirements
Site inspections and record-production obligations
The CMS-855B IDTF attachment requires the company to identify every CPT/HCPCS code and the associated equipment model. More pointedly, it currently instructs applicants point blank that “clinical laboratory and pathology codes should not be reported.” (CMS) (Conversely, possibly CLIA labs are only allowed to submit CLIA codes - not surgeries or MRIs - and if CMS says the codes are CLIA codes for submission purposes but are not CLIA codes for CLFS purposes, that's a hall of mirrors.)
Therefore, merely moving 0510U, 0512U, 0418U, 0220U, and similar services from the CLFS to PFS contractor pricing does not make them readily enrollable as IDTF services. CMS would have to answer such questions as:
May these newly reclassified codes now be entered on the IDTF attachment despite their laboratory or pathology origins?
Is the “equipment” a server, a cloud environment, a software version, or the algorithm itself?
Who or what is the “technician” performing an automated analysis?
For IDTFs, physician supervision required, and at what level? (Is he supervising a computer chip?)
How does the MAC define the medical specialty? Must the supervising physician be a pathologist, molecular pathologist, radiologist, oncologist? Pathologist seems natural but contradicts the CMS position the test is not a laboratory service.
Where is the service furnished for place-of-service and multi-state licensing purposes?
Can one national software center enroll once, or must it enroll separately in multiple MAC jurisdictions?
Once the code is ejected off the CLFS, is the service technical, professional, or global?
Without national answers, the proposal could produce a service that is covered, coded, and priced—but not billable by the entity that actually performs it.
HeartFlow is the scary precedent
The early HeartFlow experience illustrates this danger almost perfectly. HeartFlow sought IDTF enrollment for its FFRct software service. Noridian denied the application partly because it concluded that the proposed code was not separately payable and partly because the proposed supervising cardiologist did not meet what Noridian viewed as the applicable radiology-supervision requirement. Noridian therefore refused to grant HeartFlow a Medicare supplier number. (HHS.gov)
The Departmental Appeals Board candidly described the circularity: HeartFlow had to meet the requirements applicable to IDTFs, but Noridian primarily denied enrollment because HeartFlow had not identified a service reimbursable under the existing payment structure. The Board observed that HeartFlow could not—and would have no reason to—enroll as an IDTF if it could not bill Medicare for its only service. (HHS.gov)
That is the danger here on a larger scale. A MAC evaluating a SaMS company’s CMS-855B application might ask:
Is this really an IDTF test? Is this code authorized for IDTF billing? Where are the equipment and technician? What supervision applies?
Meanwhile, the payment staff may respond:
The code is payable under the PFS to an eligible enrolled supplier.
Each side can point to the other, leaving the company without a PTAN.
The OPPS route is less troublesome—but only because the hospital can bill
For a hospital outpatient service assigned to an APC, the hospital is already an enrolled Medicare provider and can ordinarily purchase the algorithmic analysis under an arrangement with the vendor. The software company may not need to enroll or submit the Medicare claim itself.
That does not solve the freestanding PFS problem. CMS would effectively be creating two commercial models:
Hospital: the hospital bills the APC and pays the software vendor contractually.
Nonhospital: the algorithm company must either find a valid supplier category or arrange for a physician or other enrolled entity to purchase and bill the service.
The latter approach could raise additional purchased-diagnostic-test, reassignment, anti-markup, supervision, place-of-service, and claim-reporting questions. It would also mean that the proprietary test developer no longer necessarily bills Medicare directly.
What CMS should do
CMS should not finalize the payment migration without simultaneously establishing an enrollment pathway. It has at least three options:
1. Preserve laboratory enrollment for this limited purpose.
CMS could permit an entity already enrolled as an independent clinical laboratory to bill designated SaMS codes even though the codes are paid under the PFS rather than the CLFS. Fee schedule and supplier enrollment category do not inherently have to be identical. Pure software entities would still require either a special “dry laboratory” enrollment subtype or another route.
2. Establish a defined remote-SaMS IDTF pathway.
CMS could state nationally that these services are eligible IDTF diagnostic procedures and modify the CMS-855B attachment and PECOS requirements for software-based testing. It would need software-appropriate rules for equipment, personnel, supervision, locations, and code approval rather than allowing each MAC to improvise.
3. Create a separate SaMS supplier category.
A new category on CMS-855B/PECOS would be the cleanest long-term answer. It could include enrollment screening, ownership disclosure, medical-record access, ordering requirements, cybersecurity and software-version controls without forcing cloud software into rules written for imaging machines and technicians.
At minimum, CMS should grandfather existing laboratory enrollments and PTANs during the transition, synchronize enrollment implementation with the January payment change, and prohibit MACs from denying enrollment merely because the affected code was historically categorized as laboratory or pathology.
The central comment point
CMS cannot logically conclude that SaMS analyses require no CLIA-regulated entity, remove them from the CLFS, and then remain silent as to which Medicare-enrolled supplier may furnish and bill them.
Unless CMS preserves an independent-laboratory enrollment route, expressly designates these entities as remote IDTFs, or creates a SaMS supplier category, the new proposal risks reproducing the HeartFlow problem: a separately payable diagnostic service for which the actual supplier cannot obtain Medicare billing privileges.
SIDEBAR
The CLIA number for ArteraAI (e.g.) seems to be 10D2258449, Jacksonville, per online Report Form.
The CLIA number for Valar Labs seems to be 45D2278995, per app.Dexzcodes.com. 1200 Binz St, Houston. NPI 1891554481 as Clin Med Lab, 1200 Binz St, Houston.
