TL;DR: FDA clearance is the first step for selling clinical AI. It does not guarantee payment. CMS checks clinical utility on a separate axis. Most cleared AI has no dedicated CPT code. The CTO's job is to design the production stack. It must capture the real-world evidence CMS wants from day one. This must happen before the policy window opens.

Key Takeaways: - FDA clearance and Medicare coverage are two independent gates with different evidence needs - As of 2026, Category I CPT codes for AI remain scarce. Imaging is the area where change has moved furthest - Coverage with Evidence Development (CED) is the lever CMS uses. It forces production-side tracking most teams have not built - The Health Tech Investment Act creates a partial payment path but excludes CDS software that meets FDA's own exemption rules - Engineering choices made well before a clinical study begins decide if you can move Category III to Category I

The FDA has cleared more than 1,000 AI/ML-enabled medical devices since 1995. The growth has been steep. It is most steep in radiology, which accounts for roughly 80% of all cleared algorithms. The number sounds like momentum. It is not.

Out of that thousand-plus portfolio, only a handful of devices have Category I CPT codes tied to real payment. Hospitals cannot bill for the rest at a level that justifies the cost of integration. That is the trap.

FDA clearance is permission to sell. It is not permission to be paid. The two things feel like the same milestone to a founding team that has just survived a 510(k) or PMA submission. However, they sit on separate ledgers. One is a regulatory artifact. The other is a revenue artifact.

Consider what this means on the ground. Hospitals buy AI on thin operating margins, as the research notes. A radiology department will not deploy a tool that needs workflow changes, PACS integration, and radiologist retraining. They deploy it only when the payer side recognizes the spend. The CFO asks one question before signing the purchase order: does this generate a billable event?

When the answer is no, procurement stalls. The tool sits in a proof-of-concept graveyard. The vendor's sales team blames slow enterprise sales cycles. The real problem is that they built a regulatory product. They also assumed payment was someone else's job.

For CTOs evaluating the top AI companies for healthcare in India, this is the filter. It also applies anywhere else. Ask any vendor how many of their cleared products have a working CPT code. The honest answer separates funded companies from perpetually grant-funded science projects.

Most CTOs assume FDA clearance unlocks revenue. It unlocks permission to sell. Understanding why is the difference between a funded product and one that runs out of runway.

The two agencies ask different questions. The gap between them is where clinical AI gets stuck.

FDA checks safety and efficacy. For Class II devices, that usually means 510(k) substantial equivalence to a predicate. For Class III, it means a Premarket Approval with clinical data. The bar is "does this device work and is it reasonably safe." That is a real bar. However, it is not the bar CMS applies.

CMS checks medical necessity under a separate "reasonable and necessary" standard for National Coverage Determinations. The question shifts to "does this service change patient management enough to justify a covered benefit?" That is a different evidence axis entirely.

A device can be clean on the FDA side and still fail CMS's clinical utility bar. Diagnostic accuracy studies show sensitivity and specificity. CMS does not pay for sensitivity. It pays for changes in downstream care that produce better outcomes at lower cost.

Device classification drives the regulatory path. It does not drive coverage. A 510(k)-cleared Class II device and a PMA-approved Class III device face the same CMS evidence question if they claim the same clinical use. The path to market is decoupled from the path to payment.

For a CTO building or buying AI/ML training infrastructure, this distinction matters. It decides what kind of data your production system must collect. A model trained and checked for FDA submission is not the same artifact as a model built for evidence generation. Treating the FDA submission as the finish line guarantees you will be unprepared for the CMS submission.

If the problem is evidentiary, what evidence is CMS actually demanding? And why are cleared AI vendors not producing it?

CPT Category I codes are the gold standard. They are permanent. They are also widely recognized across payers and tied to proven clinical utility. Category III codes are temporary tracking codes. They let CMS collect use data while evidence builds. The Category III to Category I change is where vendors either graduate or stall.

As of 2026, Category I payment codes for AI remain scarce. Imaging is the clinical area where change has moved furthest. The bottleneck is not FDA processing time. It is also not CMS administrative delay. The bottleneck is the lack of clinical studies showing that AI changes patient outcomes.

Most vendor studies stop at diagnostic accuracy. Sensitivity, specificity, AUC-ROC. These numbers are needed for FDA. However, they are not enough for CPT. The American Medical Association's CPT Editorial Panel wants to see that using the AI tool leads to a measurable change in how patients are managed. In short, did it reduce unnecessary biopsies? Did it cut time to treatment? Did it change readmission rates?

Without those outcome studies, there is nothing for a CPT panel to review. The vendor has a regulatory artifact, not a payment artifact.

Coverage with Evidence Development (CED) is how CMS handles the gap when evidence is partial. CED ties payment to the collection of extra clinical data in real-world use. For AI vendors, CED means the product must ship with tracking that captures downstream outcomes, not just model predictions. The inference layer becomes an evidence-collection layer.

That is an architectural commitment. It cannot be bolted on after FDA clearance. By the time you need to file a CED submission, the production data shape is already fixed.

The pattern is familiar. We have seen the same shape of failure in FDA-cleared clinical AI losing in court. The failure happened when post-market evidence was not built into the product. The legal system, like CMS, asks questions the FDA submission never answered.

The bottleneck is not policy. It is the product architecture choices made well before a clinical study begins. The next question is what those architecture choices actually look like in a production stack.

The engineering work for payment is mostly the engineering work for trustworthy production AI. The two goals converge more than most teams realize.

First, add tracking to the inference pipeline. It must capture per-case performance metrics, model version, and input source for every prediction. Not aggregate metrics. Per-case. CMS reviewers want to trace a specific patient encounter through the model and out to the outcome. If your logs collapse to daily counts, that trace is impossible.

Second, build unchangeable audit trails linking model outputs to downstream clinical choices. A radiologist reads the AI-flagged CT. The flag lands in the structured report. The follow-up imaging happens three months later. The audit trail needs to connect all three events. Tamper-evidence matters.

Third, design data pipelines for real-world evidence generation from day one. CED submissions need post-market data, not pre-market trials alone. Your data lakehouse, your event bus, and your de-identification layer all need to support long-term linkage across institutions. The year-two cost cliff in healthcare AI is largely driven by the cost of retrofitting evidence pipelines that were not designed in.

Fourth, design for versioning and Predetermined Change Control Plans. FDA has issued final guidance on PCCPs for AI-enabled devices. When your model updates, the evidence clock does not reset if the change is within the PCCP envelope. That is a competitive edge. It needs model registries, feature stores, and rollback paths. Most teams treat these as MLOps overhead rather than payment infrastructure.

Even if your product is ready, the payment policy itself is unstable. The Health Tech Investment Act is the most important proposed change. It will not solve the problem the way most teams think.

The Health Tech Investment Act is a recently proposed bill. It would assign FDA-cleared AI devices to a New Technology Ambulatory Payment Classification. On paper, that gives vendors a defined payment bucket in the outpatient hospital setting. In practice, the bill has a structural blind spot.

The path is only open to software that meets FDA's medical device definition. CDS software that qualifies for the FDA's Clinical Decision Support exemption cannot use it. The FDA has long held, in its own guidance, that AI which meets the CDS exemption rules is not an FDA-regulated device. It does not need clearance. It also cannot get clearance.

The result is a paradox. The HTIA path is gated on FDA authorization. CDS-exempt software, by FDA's own logic, is not authorized because it is not a device. A diagnostic support tool that helps a clinician read imaging without crossing the device line gets nothing from HTIA.

For vendors whose products sit on the CDS side of the line, this is not a partial fix. It is no fix at all.

CMS still has not issued formal AI coverage guidance. HTIA would force structure into the outpatient hospital setting. Physician office payment and private payer alignment are still open. The bill helps devices. It does not help decision support.

For CTOs evaluating partners in the top AI companies for healthcare in India space, the implication is that policy optionality is not a strategy. You cannot build a product roadmap on the hope that legislation passes. The architecture choices you make now need to be defensible. They must hold whether HTIA becomes law, gets amended, or stalls in committee.

Policy is uncertain. What is not uncertain is the engineering work. It grows in value whether payment arrives in 2026 or 2029.

Evidence is a moat, and it widens with time.

Vendors with systems running 5+ years in production hold a dataset that late entrants cannot match at any price. When a CPT panel reviews a Category I change request, it weighs the strength of the outcome evidence. A study that draws on tens of thousands of patient encounters across multiple institutions is a different kind of study. It differs from one that draws on a few hundred encounters at a single site.

The first study submitted on a given clinical use case also gets editorial framing. The CPT panel sets the precedent. The second study is measured against the first. Late entrants do not get a clean slate. They get a comparison.

This is why the production telemetry you build now is more valuable than the regulatory milestone you chased last quarter. Real-world evidence compounds. The longer the system runs, the harder it is for a new entrant to match the long-term depth.

Does FDA clearance automatically guarantee Medicare reimbursement?

No. FDA clearance confirms safety and efficacy. However, CMS applies a separate "reasonable and necessary" standard under its own National Coverage Determination process. The two agencies check on different evidence axes. Most cleared AI devices have no dedicated CPT code today.

What is the difference between a CPT Category I and Category III code for AI?

Category I codes are permanent and widely recognized across payers. They are tied to proven clinical utility. Category III codes are temporary tracking codes used to collect use data. They often serve as a step toward Category I change. Most AI vendors launch with Category III and must generate outcome evidence to upgrade.

How long does it take to get a CPT code after FDA clearance?

The gap between FDA clearance and proven payment is driven by clinical evidence generation. It is not driven by regulatory processing time. Coverage for some devices has emerged in the outpatient hospital setting. Meanwhile, Medicare physician office and private payer payment remain pending for many cleared products.

What is coverage with evidence development (CED) and how does it affect AI products?

CED is a CMS mechanism that ties coverage to the collection of extra clinical data in real-world use. For AI vendors, CED means the product must ship with tracking that can capture outcomes, not just predictions. This shapes the inference and data pipeline architecture from day one.

What should a CTO prioritize if reimbursement is 3-5 years away?

Focus on building the real-world evidence collection layer into the production stack. This includes per-case inference logging, downstream clinical outcome tracking, and audit trails. Those audit trails must be able to survive an FDA or CMS review. The engineering choices made before evidence collection begins decide if you can run a Category I conversion study. That study must be ready when the policy window opens.