Why We Removed Our SNOMED Validator

In June 2026 we deleted a feature nobody had complained about. The snomed_code validator came out of the codebase, out of the validator list, and out of the docs. There is no plan to bring it back. This is the post explaining why, because “we removed a healthcare terminology feature” is exactly the kind of change a buyer deserves a straight answer about.

What it actually was

A validator in AdaptivMapr is a small deterministic check a template field can declare. When a row is validated, the field’s validator runs against the value and either passes or returns a specific failure code — npi_checksum, gtin_checksum, iban_checksum, date_too_early — so your pipeline can route on the reason rather than on a boolean.

The snomed_code validator was a format check of that shape. It was cheap to write. It looked good in a feature list. And it was declared by zero of the shipped templates.

The licence is the actual problem

SNOMED CT is not an open code system. Using it — including distributing software that implements it — generally requires a SNOMED International Affiliate Licence, and the terms vary by territory because member countries hold national licences that cover some uses and not others. That is a perfectly reasonable model for a clinical terminology, and it is a genuinely poor fit for a validator sitting in a marketing feature table.

The uncomfortable question a security or procurement reviewer eventually asks is not “does your regex work”. It is: under what licence are you doing that? For a feature no template used and no customer had asked for, the honest answer was that we had taken on a licensing obligation in exchange for nothing.

A validator is a claim. If you cannot defend the claim in a procurement review, deleting it is cheaper than defending it.

There is a second, quieter cost. A snomed_code entry in a validator list implies a capability: that we understand SNOMED, that we can resolve a description to a concept id, that we know a post-coordinated expression when we see one. A format check does none of that. Shipping the name without the substance is how a compliance product ends up over-promising by accident rather than by intent.

What we kept, and why those are different

The removal was surgical, not a retreat from clinical terminology. The code-system validators that remain are the ones we can operate honestly:

• loinc_code, icd10_code, atc_code — format checks with an ontology resolver behind them. When the direct format check fails, the value is put through a resolver that tries to recover a canonical code, and the result is only accepted above a 0.85 confidence floor.
• cpt_code — a format check. CPT is itself licensed by the AMA; we validate the shape of the code, we do not redistribute the code set.
• npi — a real algorithm, not a regex: ten digits with a Luhn check computed over the string "80840" prefixed to the first nine, which is how the NPI check digit is actually defined.
• gln and gtin — GS1 identifiers with their mod-10 checksum verified (8, 12, 13 or 14 digits for GTIN; GLN is the 13-digit case).
• iban with the mod-97 checksum and per-country length table, bic, pharmacode, fhir_reference, uuid, email, phone, url, plus the generic regex, enum, date_range and number_range.

The pattern is consistent: each of those is either an open standard, a pure checksum algorithm, or a format assertion we are not passing off as terminology knowledge. None of them requires us to hold a licence to redistribute a code set, because none of them redistributes one.

The rule we apply now

Before a validator ships, three questions:

1. Does a template actually declare it? A validator with no call site is not a feature, it is a claim with no product behind it.
2. What licence does using it put us under — and does that licence follow through to our customers? Anything that would hand a customer an obligation they did not sign up for is a no.
3. Does the name promise more than the code does? If calling it x_code would make a reader think we resolve x, and we only check its shape, it either gets a resolver or a different name.

SNOMED failed all three at once, which is unusual and made the decision easy.

If you genuinely need SNOMED

Some integrations do, and we would rather point you at the right arrangement than sell you a placeholder. Two workable paths:

• Validate it on your side. Map the column with AdaptivMapr, declare the field with a plain regex validator if you want a shape assertion, and run your own licensed terminology service over the values after the map. The mapping problem and the terminology problem are genuinely separable, and separating them keeps the licence where the licence belongs — with the party that holds it.
• Carry it as a coded reference. Templates that emit FHIR can carry a coding system on a field, so a SNOMED-coded value can travel through to the emitted resource as a coding with its system URI intact. Passing a code through is not the same as validating it, and we are careful to describe it as the former.

The general point

Compliance products accumulate features the way a garage accumulates cables: each one was plausible at the time, none is quite worth the argument to remove, and eventually the list describes a product nobody actually shipped. The fix is to treat every line of a capability list as something you will one day have to defend in a room with somebody’s legal counsel — and to delete the ones you would not want to defend.

The full validator list, with the failure code each one returns, is in the validator reference (and one page per validator under /docs/validators); the healthcare templates and the FHIR resources they emit are in the healthcare pack; and the rest of the posture we are willing to state in writing is on the about page.