A clinician in Bogotá types two words: colecistectomía laparoscópica. The note is fine. The billing problem is starting.

That phrase has to compile to:

  • CUPS 47.1.1.01 — Colombian procedure code the EPS will look for
  • CIE-10 K80.20 — diagnosis the same EPS expects
  • TUSS 30912012 — if the same procedure happens in São Paulo for a private operator
  • CID-10 K80.2 — Portuguese-localized diagnosis that pairs with it
  • CBHPM 30912012 — Brazilian supplementary segment, TUSS-aligned, its own valuation rules
  • CPT 47562 — only if a US reinsurer is in the chain

Six codes, three countries, four governing bodies. And we haven't reached the RIPS file for EPS submission or the DIAN form the same encounter feeds for tax.

This is the part of LATAM clinical software the demos hide.

Why this is genuinely hard

Every "AI medical billing" pitch we've seen is built on US substrate: ICD-10-CM, CPT, HCPCS. None of those code sets exist in production LATAM workflows. Pretending otherwise produces denied claims.

Each codeset has a different governing body, cadence, and granularity:

  • TUSS — ANS (Brazil's supplementary regulator). 8-digit numeric. Quarterly, not always backwards-compatible.
  • CBHPM — AMB. Numerically aligned with TUSS, priced and versioned independently.
  • CUPS — Colombia's Ministerio de Salud. 7-character. No fixed update calendar.
  • CIE-10 — WHO ICD-10, Colombian adaptation. 3-7 alphanumeric.
  • CID-10 — same lineage, Brazilian adaptation. Diverges from CIE-10 in non-trivial ways.
  • RIPS — not a code set; the XML/JSON submission format for EPS claims, XSD changed in 2024.
  • DIAN — Colombia's tax authority. Same encounter, different schema.

The codes are not 1:1 between countries, and not 1:1 even within a country. A single CUPS code can map to zero, one, or three-plus TUSS codes. A TUSS code can decompose into multiple CBHPM line items because supplementary valuation rules treat surgical assistants and anesthesia separately. Anyone claiming a clean crosswalk has either not tried or is lying.

The naive approach breaks at the first ambiguous case

Every team's first attempt is a giant lookup table: free text in, code out. It handles 60% of common procedures and quietly produces wrong answers on the rest, because the table flattens what matters — terminology version, governance authority, deprecation window.

Cortex uses the terminology binding pattern instead: every code is a (system, version, code) triple, never a bare string. The colecistectomía above isn't stored as 47.1.1.01. It's stored as (CUPS, 2024.1, 47.1.1.01) next to (CIE-10-CO, 2024, K80.20). The TUSS variant lives as (TUSS, 2025-Q1, 30912012). Separate bindings on the same clinical fact.

Sounds pedantic until a code-set version changes. With bare strings you silently corrupt history — a code that meant one thing in 2024 means something else in 2025, no way to detect the drift. With (system, version, code), the mismatch surfaces at write-time and gives migration logic somewhere to attach without overwriting the original fact.

Denial prevention, before the claim leaves the clinic

A meaningful share of denied claims in LATAM are not medically wrong — they are valid procedures coded with a version the operator already deprecated. The procedure happened. The diagnosis is correct. The code is six months stale. The claim bounces, the AR clock starts, the revenue cycle team eats the rework.

A multiplexer that knows current version and deprecation calendar flags this before the claim leaves the clinic. Cortex surfaces it inline as a revenue-risk signal — visible before the clinician signs the note, not three weeks later through the EPS portal. Two jobs from one multiplexer: pick the right code, warn when yesterday's right code is today's wrong one.

What's still hard

We don't pretend this is solved.

  • TUSS quarterly updates are not always backwards-compatible. The diff is published, the docs are uneven, migration windows are short.
  • Brazilian operators accept legacy codes during grace periods that are real but unpublished. You learn them from claim outcomes, not specs.
  • Colombia's RIPS XSD changed in 2024 and EPSs adopted it on staggered timelines. For a quarter, the same submission was accepted by one EPS and rejected by another.

We monitor GitHub repos and a Brazilian Ministry mirror for published updates. The unpublished chaos we catch the only way it can be caught: watching denial reasons come back from production and reverse-engineering the policy.

If you build in this space, plan for it. Code sets aren't the hard part. The grace periods are.