On July 16, 2026, CMS and CDC published a Request for Information that asks a question most AI diagnostics companies assumed was settled: when your software helps interpret patient-derived laboratory data, are you still just a medical-device manufacturer, or are you also doing laboratory testing? Digital pathology, genomics, pharmacogenomics, cloud-based AI diagnostics: all of them are in scope.

The document answers nothing. It is not a proposed rule, not guidance, not a new certification requirement. But it names the boundary CMS is examining, calls out specific AI-enabled workflows, and asks industry to supply the facts that could shape future CLIA policy. Comments are due September 14, 2026.

The Question CMS Is Actually Asking 🔗

The RFI contains a section titled “Postanalytic Interpretation and Use of Artificial Intelligence.” CMS says it has received multiple inquiries about which postanalytic activities it considers part of the testing process. In the same paragraph, the agency notes that some software functions are regulated as medical devices under the Federal Food, Drug, and Cosmetic Act.

FDA device regulation and CLIA laboratory regulation answer different questions. FDA evaluates whether a device is safe and effective for its intended use. CLIA governs facilities that examine human-derived materials to produce diagnostic information. A software function can be an FDA-regulated device and still leave open whether the organization operating it is participating in laboratory testing.

Most AI diagnostics companies have treated that second question as a deployment detail. Device classification, predicate selection, clinical validation, software documentation, submission strategy: that is where the attention goes. The RFI suggests CMS is also looking at everything around the deployed software: who receives the data, who operates and verifies the system, who produces the interpretation, and which entity helps generate the final reportable result.

Not every AI company is about to become a laboratory. But FDA status alone may no longer settle the analysis.

Highlighted source excerpt: CMS describes the postanalytic boundary and notes that some software functions are FDA-regulated medical devices.

Digital Pathology Is Named, Not Implied 🔗

CMS and CDC ask what roles software functions, including AI tools, play in interpreting “histopathology slides or results.” Digital pathology is not swept in by generic language about software. It is named.

Highlighted source excerpt: CMS specifically asks about AI-assisted interpretation of histopathology slides or results.

For a typical software-enabled pathology workflow, a laboratory prepares and stains tissue, creates a digital image, and sends that image into a software system. The software may prioritize slides, identify suspicious regions, generate measurements, produce a diagnostic classification, or contribute to a prognostic result. Different products allocate those functions differently between the algorithm, laboratory personnel, and an interpreting pathologist.

The RFI does not classify the physical slide-scanning step as postanalytic. Its questions focus on software-assisted interpretation after the data exist. Keep that distinction straight. The downstream digital workflow, though, is now squarely inside the CLIA inquiry.

For a software manufacturer, the operational questions now deserve the same attention as the model architecture:

• Does the company merely provide software that a certified laboratory operates?
• Does the company receive patient-derived images or analytical data on its own infrastructure?
• Who performs production validation and ongoing verification?
• Does the software return an intermediate output or a final clinical interpretation?
• Which entity releases the result, and who is accountable when it is wrong?

Those facts will drive the analysis, not whether the product is marketed as SaaS, AI-as-a-service, clinical decision support, or a medical device.

Validation May Extend Beyond the Model 🔗

The RFI also asks how laboratories verify software functions used with a test system. Its examples include image-resolution accuracy and quality, AI tools, computers, and monitors.

This is a broader system boundary than many model-validation reports address. A development team may demonstrate discrimination, sensitivity, specificity, reader improvement, or noninferiority while assuming that the production image and display chain is controlled elsewhere. CMS is asking about the performance of the environment in which the interpretation occurs.

Highlighted source excerpt: CMS asks about verification across image quality, software, AI tools, computers, and monitors.

For digital pathology and other image-based IVD software, a complete verification strategy may need to explain:

• The characteristics and quality controls applied to input images
• The production software version and configuration
• The computing environment used to execute the software
• The monitors or displays used for review
• The behavior of the complete image-to-interpretation workflow
• The controls used when any component changes

The RFI creates none of these requirements today. It does show CMS thinking about the entire test system, not the AI model as an isolated mathematical object. Be prepared to show where your verification responsibility begins and ends, and why that boundary is safe.

The Data-Only Facility Problem 🔗

The most consequential paragraph may be in the next section, “Data-Only Facilities.” CMS describes facilities that only process analytical data or provide specialized data interpretation. It notes that some may be manufacturers of medical-device software and says it has received inquiries about whether these facilities require CLIA certificates.

Highlighted source excerpt: CMS discusses data-only facilities, including some medical-device software manufacturers.

The examples include facilities that review and interpret genetic data, digital images, and risk-factor calculations. These are not edge cases for modern diagnostics. They describe common architectures for cloud genomics pipelines, digital-pathology services, distributed algorithm providers, and software that calculates patient-specific diagnostic or prognostic outputs.

The original specimen may never enter the software company’s premises. That does not end the inquiry. CLIA’s laboratory definition turns on examinations of materials derived from the human body and the diagnostic information produced. CMS is asking what activities data-only facilities perform to generate, or help generate, test results and interpretations.

This wording does not establish that data-only facilities require certification. It does suggest that physical possession of a specimen is not the only fact CMS considers relevant. Companies should map the complete path from specimen to final reportable result, including every legal entity that transforms, interprets, or releases data along the way.

Cloud Architecture Can Change the Regulatory Analysis 🔗

CMS and CDC separately ask whether CLIA should address laboratory use of automation, cloud analytics, and AI for high-complexity tests.

Highlighted source excerpt: CMS asks whether CLIA should address automation, cloud analytics, and AI.

That question makes cloud architecture part of the regulatory analysis. Hosting a medical-device algorithm in the cloud does not automatically make its developer a laboratory. But architecture determines which organization controls the deployed version, receives patient-derived data, performs updates, monitors failures, verifies performance, and returns outputs.

A contract cannot erase operational facts. Calling the product “software only” does not answer who performs the testing activity. And naming the customer as the laboratory does not resolve the role of a vendor that centrally operates the algorithm and contributes directly to the final interpretation.

Teams should document the production workflow with enough specificity to identify:

1. Every entity that receives patient-derived data
2. The point at which raw or intermediate data become an interpreted result
3. Who controls the production algorithm and its updates
4. Who validates and verifies each component
5. Who reviews, approves, and releases the final result
6. Which entity handles corrections, complaints, and failures

This analysis is useful even if CMS ultimately decides that no additional certification is needed. It exposes gaps in quality agreements, validation ownership, deployment controls, and regulatory strategy before those gaps become commercialization problems.

What AI Diagnostics Teams Should Do Before September 14 🔗

The RFI gives affected organizations an opportunity to explain how these systems actually work before CMS and CDC decide whether existing CLIA rules need to change.

Highlighted source excerpt: Comments are due September 14, 2026.

Describe concrete workflows. Abstract arguments for more or less regulation are easy to discount. An effective response identifies the relevant section and question, explains the product’s data flow, distinguishes intermediate algorithm outputs from final reportable results, describes validation ownership, and shows what existing FDA, CLIA, quality-system, and contractual controls already cover.

AI diagnostics companies should consider three immediate actions:

1. Map the workflow. Trace the specimen, analytical data, digital images, algorithm outputs, interpretations, and final report across every entity involved.
2. Define verification ownership. Identify who verifies image quality, software performance, computing infrastructure, displays, updates, and the integrated workflow.
3. Test the regulatory position. Determine whether the company’s real production activities match the assumptions used in its FDA strategy, laboratory agreements, quality system, and commercial contracts.

The Boundary Is Still Open 🔗

CMS has not imposed a new obligation. It has done something quieter: it formally put AI-assisted postanalytic interpretation, histopathology, cloud analytics, and data-only medical-device software facilities inside the same policy inquiry. Sounds procedural. It is strategic.

For digital pathology and other AI diagnostics companies, the traditional division between “the laboratory” and “the software vendor” may be less stable when the vendor centrally processes patient-derived data and contributes to the clinical interpretation. The correct answer will depend on the specific workflow, not the label attached to the business model.

Innolitics builds FDA regulatory strategies for AI/ML medical devices. Policy questions like this one are easier to absorb when your classification, data flows, validation ownership, and regulatory evidence are already mapped. Discuss your regulatory strategy with Innolitics.

References 🔗

1. Centers for Medicare & Medicaid Services and Centers for Disease Control and Prevention. Request for Information; Clinical Laboratory Improvement Amendments of 1988 (CLIA) Regulations. Federal Register, July 16, 2026.
2. Yujan Shrestha. AI/ML in Digital Pathology and the Software-as-an-IVD Paradigm: 2026 Snapshot. Innolitics, April 28, 2026.