Glossary: how to read a Codex device profile

A device profile in Codex pulls together five layers of regulatory and payment data, each with its own acronyms. This page explains every term that shows up on a profile, in plain English. Use the tabs below to move between topics, or print the page to read it all at once — the acronym reference on the left (or below, on mobile) is sticky throughout.

Acronym reference

AMA: American Medical Association
APC: Ambulatory Payment Classification
ASC: Ambulatory Surgical Center
CBA: Competitive Bidding Area
CCN: CMS Certification Number
CMS: Centers for Medicare & Medicaid Services
CPT: Current Procedural Terminology
DME: Durable Medical Equipment
DMEPOS: DME, Prosthetics, Orthotics, and Supplies
DRG: Diagnosis-Related Group
DRLS: Device Registration and Listing System
FDA: Food and Drug Administration
GPCI: Geographic Practice Cost Index
GPO: Group Purchasing Organization
HCPCS: Healthcare Common Procedure Coding System
ICD-10-CM: Int'l Classification of Diseases, Clinical Mod
ICD-10-PCS: Int'l Classification of Diseases, Procedure System
IPPS: Inpatient Prospective Payment System
LCD: Local Coverage Determination
MAC: Medicare Administrative Contractor
MRF: Machine-Readable File
MS-DRG: Medicare Severity Diagnosis-Related Group
NCD: National Coverage Determination
OPPS: Outpatient Prospective Payment System
PFS: Physician Fee Schedule
PMA: Premarket Approval
RVU: Relative Value Unit
SI: Status Indicator
UDI: Unique Device Identifier
510(k): FDA Premarket Notification

Start here

1. Why Codex exists

Medicare reimbursement for medical devices is opaque. A founder building a new device wants the answer to a simple question: if this gets to market, how does it get paid for? The answer lives across half a dozen CMS files, FDA databases, and contractor jurisdictions — each with its own format and its own update cadence.

Codex is device-first. You enter an FDA product code — the three-letter classification FDA assigns every device (e.g. KZD for inflatable pressure infusers, DXY for implantable pacemakers) — and you get back a complete picture: the applicable HCPCS codes, the per-setting Medicare payment, the National and Local Coverage Determinations, and how confident Codex is in each of those mappings. The product is built for medical-device founders, not coders.

2. Follow the money: three devices, three very different paydays

Getting permission to sell a medical device is not the same as getting paid for it. Those are two separate mountains, and plenty of perfectly good, FDA-approved devices never make money because nobody worked out how they'd get paid before building them. This section follows three very different devices from “allowed to sell” all the way to “cash in the bank,” in plain English. By the end you'll see why the same question — how does this get paid for? — has a completely different answer depending on what the device is.

First, who's who

A handful of players show up in every story. Think of them as the cast:

The FDA (Food and Drug Administration) — the U.S. government agency that decides whether a device is safe enough to be sold at all. Clearing the FDA means you're allowed to sell your device. It says nothing about whether anyone will pay you for it.
Medicare — the giant U.S. government health-insurance program that covers people 65 and older (and some younger people with disabilities). It is the single biggest payer of medical bills in the country, and private insurers usually copy whatever Medicare decides. So “how does Medicare pay for this?” sets the tone for the entire market.
CMS (Centers for Medicare & Medicaid Services) — the federal agency that runs Medicare and sets the prices it will pay.
The hospital and the doctor — the people who actually use your device on a patient and then send out the bills. They'll only keep using a device if the money works out for them.
Billing codes — the universal “item numbers” on a medical bill. Hospitals and insurers bill in standardized codes so everyone agrees on what was done and what it's worth. Different families of codes describe different things — that's where the acronyms come from. We'll spell each one out as it appears.

Story 1 — A spine implant (it gets paid as part of the operation)

You've built a new “interbody fusion cage” — a small implant a surgeon wedges between two bones in the spine to fuse them together and stabilize someone's back. It's cleared by the FDA, it's sterile, it's on the delivery truck. Now what? How does it actually earn money?

Step one is the FDA. Your device goes through a clearance process called a 510(k) (that's just the section number of the law that created it). In a 510(k) you show your implant is “substantially equivalent” — close enough — to a similar implant already on the market. Once cleared, the FDA files your device under a three-letter product code, which is simply its category label. That three-letter code is your device's identity inside Codex.

Here's the part that surprises almost every first-time founder: your implant does not get its own price from Medicare. Spinal hardware gets paid for through the operation it's used in, not as a line Medicare pays out on its own. (Your device still appears on the hospital's own chargemaster, and your company still sells it to the hospital at a real price — Medicare just never itemizes it inside that lump sum.) So the numbers that matter belong to the surgery, not the screw. Two separate bills go out:

The surgeon's bill. The surgeon charges for the operation using a procedure code from a system called CPT (Current Procedural Terminology) — a catalog of five-digit codes, one per procedure (a single-level lumbar fusion is code 22633). Medicare pays the surgeon for that code under its doctor price list, the PFS (Physician Fee Schedule).
The hospital's bill. This is where your device's cost lives — but you'll never see it listed by itself. If the patient stays overnight, Medicare pays the hospital one flat lump sum set by a DRG (Diagnosis-Related Group) — Medicare's version is the MS-DRG — meant to cover the room, staff, OR time, and your implant. If it's same-day at a hospital, payment runs under OPPS (Outpatient Prospective Payment System) via a bundle called an APC (Ambulatory Payment Classification). At a standalone ASC (Ambulatory Surgical Center), Medicare pays the ASC's own (lower) rate. Every way, your device is baked into one fixed payment for the whole procedure.

So your real business question isn't “what's my device's price?” There isn't one. It's: “Does my implant fit inside the hospital's fixed payment with enough room left for the hospital to still make money?” If it's too expensive for the bundle, the hospital loses money each time and quietly stops buying it.

And one more gate before any money moves: coverage — whether the insurer agreed to pay for this kind of procedure at all. Medicare decides coverage two ways: a nationwide NCD (National Coverage Determination) that applies in all 50 states, or a regional LCD (Local Coverage Determination) written by the private companies Medicare hires to process claims in each region — each called a MAC (Medicare Administrative Contractor). Spinal fusion has no national rule, so coverage is a patchwork of regional LCDs that spell out which patient conditions qualify using ICD-10-CM (International Classification of Diseases) diagnosis codes. Your implant can be reimbursable in Texas and unpayable in Pennsylvania purely because different regions wrote different rules. That coverage map is the size and shape of your market.

So what can you actually charge? Being reimbursable is step one; the real question is what to price the device at. You can't read a device price off Medicare's lump sum, so you triangulate the ceiling from three real numbers: what hospitals already pay for comparable devices (your anchor), the procedure's total payment (the size of the pie), and the room left after the hospital's other costs for the case (the headroom — estimated from their charges and published cost-to-charge ratios). Cut those other costs (a shorter stay, fewer complications) and the ceiling rises. Codex pulls these known numbers together for you so you can see the price band your device needs to fit inside — always shown as an estimate built from sourced inputs, never a quote or a made-up figure.

Story 2 — A home oxygen machine (it gets paid on its own, like a rental)

Completely different device, completely different story. You make an oxygen concentrator — the machine in a patient's living room that pulls oxygen out of the air.

This one does get its own Medicare identity: a billing code in HCPCS (Healthcare Common Procedure Coding System) — the family of codes for physical items, supplies, and equipment. The code is E1390. Because it's gear the patient takes home, Medicare pays for it under DMEPOS (Durable Medical Equipment, Prosthetics, Orthotics, and Supplies) — usually a monthly rental. (“Durable medical equipment,” DME, just means reusable gear like wheelchairs and oxygen machines.) The payment is clean and easy to look up; you can build a revenue model straight from it. (In some regions a “competitive bidding” program lowers the rate and limits which suppliers may bill.)

Coverage here is a national rule: an NCD (number 240.2) that applies the same everywhere — the patient's blood-oxygen level has to fall below a set threshold. Same test in Alaska as in Florida.

Story 3 — A disposable pressure cuff (it doesn't get paid for on its own at all)

The humblest device: an inflatable pressure infuser — a sleeve that squeezes a bag of IV fluid to push it in fast during trauma. It costs the hospital about fifteen dollars.

This one gets no Medicare code at all. It's a routine supply — like gauze or gloves. It's used during a procedure that has its own code, but the cuff never appears on the bill to Medicare; the hospital absorbs its cost inside the bigger procedure payment and its own internal price list (its “chargemaster”). There's no fee schedule to look up and no coverage decision to win — you make money by getting hospital purchasing departments to buy it, often through a GPO (Group Purchasing Organization), a buying club that negotiates supply prices for many hospitals at once.

(This is also why a “hospital price benchmark” for a routine supply can look absurdly high — like fourteen thousand dollars for a fifteen-dollar cuff. That big number is the charge for the whole procedure the cuff was used in, not the cuff.)

A trap worth knowing: a code can exist and still pay $0

Here's a confusing one you'll hit on the profiles. Take MAX — the lumbar interbody fusion cage from Story 1. When you open it you might see it does have a HCPCS billing code, yet the Office, Outpatient, and Inpatient amounts all read $0. That looks broken. It isn't.

Remember the two kinds of code: HCPCS describes the thing (the device), and CPT describes the procedure (what the surgeon does). For an implant like MAX, a device code can exist purely for tracking — but the implant is packaged, so that code pays nothing on its own. The real money is the surgeon's fusion procedure (a CPT code, paid under the Physician Fee Schedule) plus the hospital's bundled DRG (inpatient) or APC (outpatient) payment.

So the rule to remember: a code existing is not the same as the code paying. Three things can be true — the device has its own paid code (the oxygen machine), the device has a code that reads $0 because it's bundled (MAX), or the device has no code at all (the pressure cuff). A $0 next to a real code almost always means “bundled,” not “missing” — look to the procedure and the DRG for the actual dollars.

The through-line

Three devices, three completely different answers — but the same three questions every time:

Does my device get its own price, or does it get swallowed into a bigger payment? (A standalone item like the oxygen machine, a part of a procedure bundle like the spine implant, or an invisible supply like the pressure cuff.)
Which number is the real one to look at — a per-item price list (for standalone equipment), or a single bundled payment for a whole procedure or hospital stay that my device has to fit inside?
Who decides whether it's even covered — a national rule that's the same everywhere (an NCD), or a patchwork of regional rules (LCDs) that differ from one part of the country to the next?

Answer those three and everything else on the device profile — the codes, the prices, the confidence scores — is just the supporting detail behind the story.

Codes & payment

3. The code systems

Medicare reimbursement runs on six overlapping code systems. Each one describes the same world from a slightly different angle. Reading these first means the payment buckets in the next section land cleanly — every bucket is defined relative to a code system.

Flowchart tracing one patient visit to a single insurance claim: the visit generates three different kinds of billing code — an ICD-10-CM diagnosis code for why care happened, a CPT code for the procedure that was done, and a HCPCS Level II code for the supplies and devices that were used — and all three converge onto one claim. — One visit carries three kinds of code, each answering a different question — ICD-10-CM the why (diagnosis), CPT the what-was-done (procedure), and HCPCS Level II the what-was-used (supplies and devices) — all converging on a single claim. Open full-size image →

Healthcare Common Procedure Coding System (HCPCS Level II)

issued by CMS

In plain English: the master catalog of codes for physical things — supplies, equipment, and devices. If your device gets its own code, this is where it lives.

What is this?: Five-character alphanumeric codes that identify items, supplies, drugs, and durable medical equipment. Example: E1390 is the HCPCS Level II code for an oxygen concentrator.
What does it relate to?: Sits underneath the FDA product-code layer (which classifies the device) and feeds the DMEPOS, OPPS, and ASC fee schedules. The crosswalk Codex builds maps each FDA product code to the HCPCS Level II codes that apply to it.
What does it give us?: The Medicare-billable identifier for the device itself. If a HCPCS Level II code exists for your device, it appears in DMEPOS / OPPS fee schedules and you can quote a per-unit Medicare rate. If none exists, the device probably falls into the routine-supply bucket and pays through facility-level codes only.
How do we use it?: Every device profile renders HCPCS Level II codes by number. CMS owns these and publishes them free, so Codex displays them in full — short descriptors and all — without any license. They are the backbone of the device's reimbursement story.

Current Procedural Terminology (CPT)

issued by the AMA — license-deferred

In plain English: the catalog of codes for what a doctor does — the procedures and services. This is usually what actually gets paid when a device is used during a procedure.

What is this?: Five-digit numeric codes for physician procedures and services. Example: 99213 is the CPT code for an established-patient office visit of low complexity (99214 is the moderate-complexity level). The codes themselves are public; the descriptive text is AMA-copyrighted.
What does it relate to?: CPT is the code system the Physician Fee Schedule (PFS) is keyed to. Procedure-level reimbursement for outpatient services runs on CPT codes — including the procedures that use a routine-supply device like KZD (pressure infuser) during trauma resuscitation.
What does it give us?: The procedure-level reimbursement amount that captures the device's cost when the device itself has no separate HCPCS code. For routine-supply devices this is the actual revenue picture: the procedure pays, the device line doesn't.
How do we use it?: Codex displays CPT code NUMBERS but does not quote AMA descriptors. The AMA license is deferred until cash flow allows. On a device profile, a CPT row shows you the code number and the Medicare PFS amount — not the description. Once the license is active, descriptors light up everywhere.

International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)

diagnosis codes — maintained by CDC + CMS

In plain English: the codes for the patient's diagnosis — the “why” that justifies a procedure or device. No valid diagnosis, no payment.

What is this?: Alphanumeric diagnosis codes that describe why a service was performed. Example: I25.10 is the ICD-10-CM code for atherosclerotic heart disease without angina.
What does it relate to?: Every Medicare claim carries at least one ICD-10-CM code that justifies the procedure or device the claim is paying for. Coverage decisions (NCDs and LCDs) frequently include a list of diagnosis codes that establish medical necessity.
What does it give us?: Medical-necessity rationale. ICD-10-CM doesn't drive payment directly, but a procedure billed without a supporting diagnosis code gets denied. For a device, the relevant ICD-10-CM codes describe the clinical conditions the device is used to treat.
How do we use it?: On a device profile, ICD-10-CM rows surface the diagnoses that drive utilization. For a routine-supply pressure infuser (KZD), the relevant codes are hypovolemic shock (R57.1) — the code's official descriptor; hemorrhagic shock maps here as a subtype — plus massive hemorrhage variants and trauma diagnosis codes — they tell a founder how big the addressable patient population is.

International Classification of Diseases, 10th Revision, Procedure Coding System (ICD-10-PCS)

inpatient procedures — issued by CMS

In plain English: the codes for procedures done during an inpatient hospital stay. You mostly see these inside hospitals; they help decide the hospital's lump-sum payment.

What is this?: Seven-character codes for procedures performed during inpatient hospital stays. Example: 02HK3JZ is the ICD-10-PCS code for percutaneous insertion of a pacemaker lead into the right ventricle.
What does it relate to?: ICD-10-PCS codes are the inputs to the DRG grouper — Medicare's algorithm that assigns each inpatient stay to a payment category based on its diagnoses and procedures. You'll see these inside hospitals, not on outpatient device profiles.
What does it give us?: The inpatient procedural detail that determines the DRG. For an implantable device, the ICD-10-PCS code recording the implant procedure is part of how the hospital gets paid via the DRG.
How do we use it?: Rarely surfaced on a device profile. Codex stores ICD-10-PCS for completeness and for the inpatient pathway when DRG context is shown, but most device research is outpatient-first and CPT/HCPCS-driven.

Medicare Severity Diagnosis-Related Group (MS-DRG)

issued by CMS, refreshed every October

In plain English: the single bucket an entire hospital admission is sorted into — it sets one all-in payment for the whole stay, your device included.

What is this?: Three-digit groupings that bundle inpatient stays into a single payment category. Example: DRG 470 is major joint replacement (knee, hip) without complications; DRG 871 is septicemia or severe sepsis without mechanical ventilation, with major complications.
What does it relate to?: DRGs are the payment unit of the Inpatient Prospective Payment System (IPPS). The hospital gets one DRG payment per inpatient stay, regardless of which devices or drugs were used inside that stay. Coverage decisions (NCDs and LCDs) almost never reference DRGs — they govern outpatient services priced under PFS/OPPS/DMEPOS.
What does it give us?: The inpatient payment pool that captures device cost when the device is used during an inpatient stay. For a device that's part of an implantable procedure, the DRG is the actual reimbursement vehicle — the device-level HCPCS code is packaged in.
How do we use it?: Codex's drg_includes_device crosswalk pass (Session N) targets the device-to-DRG linkage. Until the chargemaster discovery layer lands (Session O.2 optional work), the linkage table is empty — DRG context shows as a placeholder on routine-supply device profiles.

Ambulatory Payment Classification (APC)

issued by CMS

In plain English: the bucket an outpatient hospital visit is sorted into — it carries the one bundled price for that visit, your device included.

What is this?: Four-digit groupings used in OPPS to bundle related outpatient services into a single payment. Example: APC 5691 is Level 1 Drug Administration; APC 5115 is Level 5 Musculoskeletal Procedures.
What does it relate to?: Each HCPCS/CPT code in OPPS rolls up into exactly one APC. The APC carries the dollar amount; the individual code carries a status indicator that says how it interacts with the APC payment (separately paid, packaged, etc.).
What does it give us?: The hospital-outpatient payment amount. When a device-related HCPCS code shows OPPS Status N (packaged), the actual money lives at the APC level — the device cost was already factored into the APC weight via a device offset.
How do we use it?: Codex surfaces the APC code AND its CMS-published group title alongside every OPPS payment row (Session L). That's how a founder reading a profile sees not just 'APC 5691' but 'APC 5691 — Level 1 Drug Administration', without having to look it up elsewhere.

4. The six payment buckets

Codex classifies every device into one of six payment buckets. The bucket tells you the shape of the reimbursement story before you even look at the codes table. Each bucket lives on top of one or more of the code systems above.

Diagram showing two layers: on top, billing codes that name things and carry no prices; below, the payment systems — OPPS, IPPS, PFS, and DMEPOS — that act as separate price lists, one per setting of care, with APC and MS-DRG shown as the buckets two of those systems use to reach a dollar amount. — Codes are vocabulary and carry no prices; OPPS, IPPS, PFS, and DMEPOS are a separate layer of price lists, one per setting of care — and APC and MS-DRG are the buckets two of those systems use to reach a dollar. Open full-size image →

Which code drives the payment? Follow the setting.

The same device gets paid a different way depending on where care happens. The setting picks the payment system, the payment system reads a particular family of codes, and that's what produces the dollar amount.

Setting	What drives the payment	What you get
Hospital outpatient (OPPS)	The procedure's HCPCS / CPT code	An APC (Ambulatory Payment Classification) amount
Physician / office (PFS)	The procedure's HCPCS / CPT code	A Physician Fee Schedule amount
Hospital inpatient (IPPS)	ICD-10-CM diagnosis + ICD-10-PCS procedure codes (CPT is not used inpatient)	One MS-DRG (Diagnosis-Related Group) payment for the whole stay
Supply device (no code of its own)	Nothing bills it directly	Folded into the facility's payment (DRG / APC / ASC package) — no device line

The rule people miss: CPT codes price outpatient and physician care, but they are not used to pay an inpatient hospital stay. Inpatient pays one MS-DRG, chosen from the admission's ICD-10 diagnosis and procedure codes. So on a device profile, a procedure-bundled device shows an APC or a fee-schedule amount outpatient, and an MS-DRG inpatient — never a separate price for the device itself.

Separately payable

bucket: separately_payable

In plain English: the best case — Medicare pays for your device on its own line, at a published price you can look up.

What is this?: Medicare pays for the device under its own HCPCS Level II code at a published per-unit rate. Example: DMEPOS-listed knee braces, oxygen concentrators, glucose monitors — each has its own HCPCS code with its own Medicare amount.
What does it relate to?: Sits cleanly on top of one of the three fee schedules — DMEPOS, OPPS, or PFS — depending on the setting. The HCPCS row carries a Status Indicator that confirms separate payability.
What does it give us?: The cleanest reimbursement story Medicare offers. A founder can quote a per-setting dollar amount, model the per-unit revenue, and target sales by setting and geography.
How do we use it?: Codex surfaces every payment row alongside its vintage (year + quarter) and any locality variation. The optimization view (post-MVP) compares a device's payment across settings so you see where it pays best.

Procedure-bundled

bucket: procedure_bundled

In plain English: your device may have a code, but the money is the procedure it's used in — the device line itself pays $0 (this is MAX).

What is this?: The device has its own HCPCS code (often a C-code) but Medicare pays the hospital for the PROCEDURE, not the device line. Example: implantable pacemakers (FDA product code DXY) and cardiac stents — paid via the inpatient DRG or the outpatient procedure CPT.
What does it relate to?: Sits underneath the procedure-level CPT/DRG layer. The device-level HCPCS is administrative — used for reporting, not for payment.
What does it give us?: The honest answer that the device's reimbursement story is the procedure's reimbursement story. A pacemaker manufacturer cares about DRG 242-244 (permanent cardiac pacemaker implant); the C-code on the device is not the unit of economic analysis.
How do we use it?: Codex's profile shows the procedure-level payment alongside the device-level HCPCS so the founder sees both layers clearly. The classifier (Session H+) buckets these correctly via the rule order in 06 §11.

Packaged with offset

bucket: packaged_with_offset

In plain English: a flavor of bundled — the device cost is folded into the outpatient procedure's payment, with an allowance already baked in.

What is this?: The device's HCPCS code carries OPPS Status Indicator N — packaged. Medicare bundles the device cost into the procedure's APC payment, with an offset already built into the APC weight. Example: infusion pumps (FDA product code FRN), some catheters.
What does it relate to?: Sits under OPPS and inherits its APC. The APC carries the dollar amount; the device-level HCPCS carries SI=N and a NULL amount because there's no separately published device payment.
What does it give us?: Honest visibility into what looks like a missing price. Codex shows the SI=N with a 'packaged' caveat instead of fabricating a $0.00 amount. The user understands that the device payment is real but lives inside the APC.
How do we use it?: Pricing decisions for a packaged device run through the APC math — what's the typical device offset, what's the residual, and where does the hospital margin come from. Codex's profile gives the user the input data; the modeling is downstream.

Routine supply

bucket: routine_supply

In plain English: no Medicare code at all — your device is treated like gauze, its cost absorbed into the procedure; you sell to hospital purchasing, not Medicare.

What is this?: No separate Medicare payment code exists for the device. Cost flows into facility payment (DRG / APC / ASC package) or the hospital's internal chargemaster. Example: surgical drapes, tongue depressors, KZD pressure infusers, gauze.
What does it relate to?: Sits OUTSIDE the HCPCS/CPT layer entirely. The device is consumed during a procedure that has its own code, but the device itself never surfaces to CMS as a discrete line item.
What does it give us?: The hard truth that not every medical device gets a Medicare code, and that's not a bug. A founder evaluating a routine-supply device needs to know the go-to-market path is hospital chargemaster sales and GPO contracts — not a HCPCS code application.
How do we use it?: Codex's profile swaps the codes table for the RoutineSupplyEnrichment surface (Session O.2 Part B): the procedures that use the device, the DRGs that capture it inpatient, the competitive landscape from FDA DRLS data, and hospital chargemaster pricing benchmarks when available.

DME (Durable Medical Equipment)

bucket: dme

In plain English: take-home equipment paid on its own under the DMEPOS rental/purchase schedule (oxygen machines, wheelchairs).

What is this?: Medicare pays under the DMEPOS Fee Schedule. Example: oxygen concentrators (FDA BSZ, HCPCS E1390), power wheelchairs (FDA IIH), hospital beds.
What does it relate to?: DMEPOS rents OR sells the equipment with explicit rental / purchase modifiers (NU, RR, UE, KE). Competitive Bidding Areas (CBAs) can adjust the amount in specific geographies. Some categories are priced per-state instead of nationally — oxygen concentrators famously have no national rate.
What does it give us?: The DMEPOS-specific reimbursement context: rental vs purchase, modifier set, capped-rental status, CBA exposure, state pricing notes. All of it material to a founder positioning a DME product.
How do we use it?: Codex's DmepoMetaSection (Session I) renders this whole picture for any device the classifier buckets as dme. The state selector on the profile re-fires the API query to surface per-state DMEPOS amounts.

Not classified

bucket: not_classified

In plain English: Codex couldn't confidently sort this device yet — treat what you see as unverified.

What is this?: Codex hasn't been able to put the device into one of the five buckets above yet. Example: capital diagnostic equipment, novel categories awaiting curator review.
What does it relate to?: Fallback bucket — the classifier rules (06 §11) didn't fire and no curator override has been applied.
What does it give us?: Visibility into the matcher's reach. About half the FDA product code corpus lands here today; as the curator works through high-priority categories and the rule set sharpens, the not_classified count drops.
How do we use it?: The codes shown on a not_classified profile are matcher candidates only — confidence scores are surfaced honestly and the user is expected to verify before relying on them. A curator can pin the right bucket via the admin UI (Session J).

A worked example: a knee replacement, traced from OR to payment

The code systems and the payment buckets come together in one real case. The flowchart below follows a knee replacement from the operating room to the dollars: a human coder reads the operative note and assigns the codes — the only judgement call — and from there pricing is automatic. The software reads each code's status indicator and maps it to an APC or an MS-DRG and a payment amount.

Worked example tracing a knee replacement from the operating room to payment: a human coder reads the operative note and assigns the diagnosis, procedure, and device codes, after which pricing is automatic — each code's status indicator maps it to an APC or an MS-DRG and a final dollar amount. — A human coder assigns the codes from the operative note — the only judgement call — then pricing is automatic: the software reads each code's status indicator and maps it to an APC or MS-DRG and a dollar amount. Open full-size image →

Reading the data

6. Status indicators

Every HCPCS / CPT code in the Medicare fee schedules carries a status indicator that tells the biller how the line will be paid. Status N in OPPS means packaged. Status S means separately paid. Status J1 means part of a comprehensive APC. The bare letter is meaningless without the dictionary, so Codex surfaces both — the letter and what it means — on every payment row.

OPPS status indicators (hospital outpatient)

The Outpatient Prospective Payment System (OPPS) is Medicare's payment system for hospital outpatient services. Each HCPCS code in Addendum B carries one of these indicators:

OPPS status indicators with descriptions
SI	Meaning
A	Services paid under a fee schedule or payment system other than OPPS (e.g., laboratory paid under CLFS; durable medical equipment paid under DMEPOS).
B	Codes that are not recognized by OPPS when submitted on an outpatient hospital Part B bill type (12x or 13x). May be paid under another setting.
C	Inpatient procedures: not paid under OPPS. Admit patient and bill as inpatient.
D	Discontinued codes: not paid under OPPS or any other Medicare payment system.
E1	Not payable by Medicare. The item or service is not covered.
E2	Not payable by Medicare — items, codes, and services for which pricing information and claims data are not available.
F	Corneal tissue acquisition; certified registered nurse anesthetist (CRNA) services and hepatitis B vaccines. Paid at reasonable cost.
G	Pass-through drugs and biologicals. Paid under OPPS at ASP+6%; transitional pass-through payment in addition to APC.
H	Pass-through device categories. Paid under OPPS; cost adjusted via offset against the procedural APC.
H1	Pass-through payment for surgical non-opioid pain management products. Paid in addition to the procedural APC for the duration of the §4135 Consolidated Appropriations Act 2023 carve-out. Not 340B-related — the '1' suffix here marks the non-opioid carve-out, not a 340B variant.
J1	Hospital Part B services paid through a comprehensive APC: all OPPS-payable services and items reported on the claim are packaged with the primary J1 service.
J2	Hospital Part B services that may be paid through a comprehensive APC: payment depends on additional criteria (e.g., observation hours).
K	Non-pass-through drugs and non-implantable biologicals, including therapeutic radiopharmaceuticals. Paid under OPPS at the published APC rate.
K1	Non-pass-through drugs and biologicals acquired through the 340B drug pricing program. Paid under OPPS at a reduced rate to reflect 340B discounts (post-AHA v. Becerra remedy methodology). The genuine 340B status indicator variant.
L	Influenza vaccine; pneumococcal pneumonia vaccine. Paid under OPPS at reasonable cost; not subject to deductible or coinsurance.
M	Items and services not billable to the Medicare Administrative Contractor (MAC). Not paid under OPPS.
N	Items and services packaged into APC rates: payment is packaged into the procedure's APC, with a device offset built into the APC weight. No separate OPPS payment.
P	Partial hospitalization program (PHP) per-diem APC. Paid as a single OPPS amount per PHP day.
Q1	STVX-packaged code: packaged when billed on the same date as a code assigned status indicator S, T, V, or X; otherwise paid at the published OPPS APC rate.
Q2	T-packaged code: packaged when billed on the same date as a code with status indicator T; otherwise paid at the published OPPS APC rate.
Q3	Codes that may be paid through a composite APC based on the composite criteria for that APC; otherwise paid at the published OPPS APC rate.
Q4	Conditionally packaged laboratory tests: packaged into the primary service when billed with a non-lab OPPS service; otherwise paid under the Clinical Lab Fee Schedule.
R	Blood and blood products: paid under OPPS at the published APC rate; not subject to outlier adjustment.
S	Procedure or service, not discounted when multiple. Paid at the published OPPS APC rate without multiple-procedure discount.
S1	Procedure or service: low-cost skin substitute products. Paid at the published OPPS APC rate under the two-tier (low-cost / high-cost) skin substitute methodology introduced in the CY 2024 OPPS Final Rule. Not 340B-related; the '1' suffix distinguishes the lower-cost tier.
T	Procedure or service, multiple-procedure reduction applies. Paid at the published OPPS APC rate; subsequent procedures on the same claim reduced 50%.
U	Brachytherapy sources. Paid under OPPS at the per-source APC rate.
V	Clinic or emergency department visit. Paid under OPPS at the visit-level APC rate.
Y	Non-implantable durable medical equipment. Paid under DMEPOS Fee Schedule, not OPPS.

PFS status codes (physician services)

The Physician Fee Schedule (PFS) covers professional services. Each HCPCS code in the PPRRVU file carries a status code:

PFS status codes with descriptions
Status	Meaning
A	Active code: paid under PFS at the published RVU rate.
B	Bundled: payment for this code is always bundled into another service. No separate PFS payment.
C	Carrier-priced: the Medicare Administrative Contractor sets the payment locally; no national RVU.
E	Excluded: not separately priced or paid under the PFS by Medicare on a service-specific basis.
I	Not valid for Medicare. The code is recognized but Medicare uses a different code.
J	Anesthesia service: paid under the separate anesthesia methodology, not at the published RVU.
M	Measurement code (Category II): no payment under Medicare PFS.
N	Non-covered service: Medicare does not pay this code under any setting.
P	Bundled / excluded code: payment is always packaged into another service when billed.
R	Restricted coverage: payable only under specific circumstances described in the manual.
T	Injection: paid only if no other service is paid on the same day; otherwise bundled.
X	Statutory exclusion: the code is for an item or service Medicare cannot pay for under any circumstance.

7. Confidence scores on crosswalk rows

Codex's core asset is the FDA product code → HCPCS crosswalk: which billing codes apply to which device classification. There is no official authoritative table for this — CMS doesn't publish one — so Codex builds it from three signals: descriptor text matching, coverage-decision narratives, and FDA predicate clusters. Each row carries a confidence score so you know how much to trust it.

High (verified)

0.95+

In plain English: a human (or a coverage rule) confirmed this code applies — safe to rely on.

What is this?: A human curator (or a coverage decision text) has confirmed this code applies to the device. Example: KZD pinned to routine_supply by a curator override is 1.00 confidence.
What does it relate to?: The top tier in the confidence ladder. Sits above the coverage-decision pass (0.75) and the predicate-inference pass (0.55).
What does it give us?: An explicit trust signal that the row has been audited. Use these for billing decisions; spot-check the curator's notes if surprised.
How do we use it?: Default profile view 'High only' filter surfaces just these rows. Useful when you want the audited subset before acting.

Medium (likely)

0.55 – 0.95

In plain English: strong evidence (usually a coverage decision) but not human-verified — a solid starting point, worth double-checking.

What is this?: Derived from a coverage decision (NCD or LCD narrative names the device → code mapping at 0.75) or a strong text match. Example: KZD → CPT 62321 came from NCD 280.14 'Infusion Pumps' at 0.75.
What does it relate to?: The middle confidence band — strong evidence but not human-verified. Includes coverage-decision and predicate-inference passes.
What does it give us?: Quality candidates worth surfacing without giving them top-tier weight. Most of the device profile's signal sits here today.
How do we use it?: Default 'Medium+' filter shows these. Treat them as a starting point — verify the underlying coverage decision before betting on a mapping for billing.

Candidate

0.40 – 0.55

In plain English: a loose text-match guess — for exploration only; never bill off it without verifying.

What is this?: Pure text-match candidate from the descriptor matcher (Session C/D). Example: KZD → G0008 at 0.55 was driven by partial token overlap.
What does it relate to?: The bottom-floor band — persistence threshold is 0.40. Rows below 0.40 don't get stored; rows in this band are surfaced for review.
What does it give us?: Visibility into the long tail of possible mappings. Useful for matcher audit and for unusual devices where high-evidence signal hasn't yet been generated.
How do we use it?: Switch the profile filter to 'All' to see this band. Use for review and for power-user crosswalk inspection; never for billing without verification.

The "All / Medium+ / High only" segmented filter on the device profile lets you switch between trust thresholds. Default is Medium+, which hides the noisy candidate band. Move to All when you want to audit the matcher; move to High only when you only want to act on verified rows.

8. FDA premarket terms

The premarket history block on a device profile carries terms that come from FDA, not CMS. Two paths get a device to market in the US: 510(k) and Premarket Approval (PMA).

510(k) clearance

FDA Premarket Notification

In plain English: the common path to market — you show your device is basically the same as one already sold. Most Class II devices.

What is this?: A submission demonstrating the device is substantially equivalent to an already-cleared device — its 'predicate'. Example: K251234 might be Acme's pressure infuser cleared by SE to K233456 (Smiths Medical's earlier product).
What does it relate to?: Lives in the FDA's premarket pathway, NOT the CMS payment world. Each 510(k) carries a K-number, an applicant, a device name, and a decision date. About 175,000 510(k) clearances exist in Codex.
What does it give us?: The pathway most Class II devices use to reach market in the US. The clearance count per FDA product code is a competitive-landscape signal: high cadence = active market entry.
How do we use it?: Codex's CompetitiveLandscape component (Session O.2 Part A) renders the 10-year clearance cadence and top firms by clearance volume for every device. The PremarketHistory section lists the recent K-numbers with deep links to FDA accessdata PDFs.

PMA approval

FDA Premarket Approval

In plain English: the high bar — full approval with clinical-trial evidence, for novel high-risk (Class III) devices.

What is this?: Full premarket approval — required for Class III devices with no suitable predicate. Example: P230030 is the FARAPULSE Pulsed Field Ablation System (an atrial fibrillation device).
What does it relate to?: Higher bar than 510(k); includes clinical-trial data. About 1,700 original PMAs cover the Class III population, with tens of thousands of supplements layered on top.
What does it give us?: Signal that a device cleared a high regulatory bar. For Class III devices, a PMA is the marker that the device made it to market at all — and the supplement chain tells you the iteration history.
How do we use it?: Codex's PremarketHistory shows PMA approvals alongside 510(k)s. The payment classifier (Session H rule 3) buckets devices with any PMA approval as procedure_bundled — because Class III payment is almost always procedure- or DRG-driven, not device-line.

Predicate device

the 'substantially equivalent' anchor

In plain English: the existing device a new 510(k) compares itself to — the “we're basically the same as that” anchor.

What is this?: The legally-marketed device a new 510(k) submission compares itself to. Example: K233456 was the predicate for K251234.
What does it relate to?: The substantial-equivalence chain that defines an FDA product code's clearance tree. openFDA does NOT publish predicate K-numbers as structured data, so Codex approximates the chain via descriptor-similarity clustering (Session G).
What does it give us?: An implicit market map. Every clearance under one product code claims SE against the others, so the cluster reveals which firms are entering a category and in what order.
How do we use it?: Codex's PremarketHistory shows the predicate cluster as a flat list sorted oldest-first. Recovering true per-clearance predicates is V1.1+ work — it requires scraping the 510(k) Summary PDFs, since FDA doesn't expose the field structurally.

Still confused? Codex is an early-stage product and this glossary will keep growing. If a term on a device profile sent you to a search engine, that's a bug — please let us know.

← Back to search