What Is OPPS Status Indicator O1 and Why It Matters for Software Reimbursement

If you sell software that runs in a hospital outpatient department, one two-character code on a CMS addendum decides more about your revenue than almost anything in your regulatory file. That code is the payment status indicator, and CMS has proposed a new one specifically for software: O1.

Most teams meet status indicators late, usually when a hospital customer asks how a service gets paid and nobody on the commercial side can answer. This is a short guide to what status indicators are, what O1 is meant to do, and how to work out whether it changes your reimbursement strategy.

What a payment status indicator actually is

The Outpatient Prospective Payment System (OPPS) is how Medicare pays hospitals for outpatient care. Every HCPCS and CPT code that can appear on an outpatient claim is assigned a status indicator in the annual OPPS addenda. The indicator is not a description of the service. It is an instruction to the claims system about how the line is treated.

A few of the common ones make the logic obvious:

J1 means the line is a comprehensive APC. The hospital gets one payment for the whole encounter and almost everything else on the claim is packaged into it.

S and T mean the line is separately payable, with T subject to multiple-procedure discounting when several T-coded services occur on the same day.

N means packaged. The service is recognised, it is coded, and it generates no separate payment at all.

Q1 through Q4 mean conditionally packaged. Whether the line pays separately depends on what else is on the claim.

That last group is where most software has historically landed. A code exists, the service is real, the claim goes through, and the payment is zero because the software line was folded into the procedure it supported.

Why software needed its own indicator

Software as a medical device breaks the assumptions OPPS was built on. There is no supply item, no room time, no staff minutes that scale with volume. The costs are development, validation, regulatory maintenance, cloud infrastructure and monitoring, and they do not show up in a hospital cost report in any way that hospital charge data can recover.

The result was a mismatch. Algorithmic services were being cleared by the FDA at pace, coded through CPT Category III or HCPCS, and then either packaged into nothing or paid at rates derived from claims data that never captured what the software cost. See our post on AI-enabled devices cleared in 2025 that still are not getting paid for how large that gap has become.

O1 is CMS's answer. In the CY2027 OPPS proposal, CMS set out a distinct payment status indicator for a defined set of software services, alongside its renaming of software as a service to Software as a Medical Service (SaMS). The point of a dedicated indicator is that the payment logic for software stops being inherited from procedure logic and becomes something CMS can set, protect and revise on its own terms.

What O1 does and does not change

O1 signals that a software line is recognised as its own payable category rather than a packaged input. In practice that matters in three ways.

It creates a rate basis. Once a service has its own indicator, CMS can assign it to a New Technology APC or set a rate without pretending the cost behaves like a supply.

It creates rate stability for low-volume services. Software used a few thousand times a year produces thin claims data. A protected category avoids the collapse that happens when a rate is recalculated from almost nothing.

It creates a reporting obligation. A separately identified line has to be coded correctly and consistently by the hospital, which means your field team needs billing guidance, not just clinical training.

What it does not do is guarantee a good number. An indicator determines how a line is treated, not how much it is worth. Nor does it resolve the open question of whether O1 lines are subject to the same multiple-procedure discounting that applies to T-coded services. That detail alone can move real revenue for any product used alongside other outpatient procedures.

It also does not create coverage. Payment rules and coverage rules are separate systems, and a hospital can hold a payable code for a service its Medicare Administrative Contractor does not cover.

How to work out whether this affects you

Start with the code, not the rule. Find the HCPCS or CPT code your service is billed under today, or establish that none exists. Then check that code's status indicator in the current OPPS addenda. If it is N or a Q value, your product is almost certainly generating no separate payment right now, whatever your customers believe.

Next, check the setting. OPPS covers hospital outpatient departments. If your volume sits in physician offices, the Physician Fee Schedule governs, and the status indicator question is replaced by RVU and coverage questions. Many software products span both, and the economics differ sharply between them.

Then check the pathway assumption behind your forecast. If your financial model assumes payment follows clearance, it is wrong in the US in a way it is not in Germany or France. Our market access guide works through the coding, coverage and payment sequence, and our FDA pathways guide covers the authorisation side that feeds it.

Finally, test the assumption across markets rather than just the US. MedTech Compass scores reimbursement friendliness and route alongside regulatory difficulty across 25+ markets, which is usually what turns a coding question into a launch-sequencing decision.

What to do now

Three practical actions.

Identify your current code and its status indicator, and write the answer down where your commercial team can see it. If nobody in the company knows it, that is the finding.

Read the OPPS proposal for your own code list rather than for the headline. The designated code sets are where the money is, and a service can be perfectly aligned with the policy intent and still be left off.

Build a billing guide for your customers. A recognised indicator only pays if the hospital codes the line, and coding behaviour is the variable you can influence fastest.

Status indicators are not a detail for the billing department. For software companies, they are the difference between a service that is used and a service that is bought.

Sources

1. CMS, Hospital Outpatient Prospective Payment System: https://www.cms.gov/medicare/payment/prospective-payment-systems/hospital-outpatient 2. Federal Register, Medicare Program; Hospital Outpatient Prospective Payment and Ambulatory Surgical Center Payment Systems, CY 2027 proposed rule: https://www.federalregister.gov/documents/2026/07/07/2026-13656/medicare-program-hospital-outpatient-prospective-payment-and-ambulatory-surgical-center-payment 3. CMS, Healthcare Common Procedure Coding System (HCPCS): https://www.cms.gov/medicare/coding-billing/healthcare-common-procedure-system 4. CMS, Medicare coverage determination process: https://www.cms.gov/medicare/coverage/determination-process

This article is general information about payment policy, not legal, coding or reimbursement advice. Confirm current status indicator assignments in the applicable OPPS addenda before relying on them.