Code set

What is a code set?

A code set is the fixed list of permitted codes and their meanings for a single field. It defines the allowed domain of that field: the exact values a status, country, or currency column may hold, and what each means. An order status field might permit only NEW, PROCESSING, SHIPPED, and CANCELLED. Anything else is a data error, not a new status.

The same idea has other names: analysts call it a code list, and in healthcare it is a value set. Some code sets are yours to define, like order statuses or reason codes. Many are external standards you adopt: ISO 3166 for countries, ISO 4217 for currencies, NACE for industry classifications, or SNOMED CT value sets for clinical terms. A field bound to a code set accepts only values from that list, which is what makes it safe to validate and group.

Code set versus reference data

Reference data is the broader managed category: the shared, governed lookup values that give the rest of your data meaning. A code set is narrower, the specific permitted list for one field. Every code set is a piece of reference data, but reference data also covers fuller registers, like a country table carrying names, capitals, and dialling codes beside the code.

Healthcare draws the same line in different words. A code system such as SNOMED CT holds hundreds of thousands of concepts; a value set is the slice of it allowed in one field. HL7 FHIR defines a value set as a set of codes drawn from one or more code systems for use in a particular context, and that context is the field.

Retired and reused codes

A code set is not frozen: values get added, retired, and occasionally reused, and each change quietly threatens historical reporting. A code you drop from today's list still sits in old records, so a validation rule that accepts only current codes rejects a genuine past value. Reuse is sharper: hand a retired code a new meaning and every old row carrying it silently changes what it says, with no error raised. ISO 3166 guards against this by holding withdrawn country codes in a separate historical list for decades before reuse. Guard your own systems the same way: version the list, date each code with an effective-from and effective-to, and never silently remap old values. That protects the data quality of historical reports.

Mapping between two systems

Most integration bugs here come from one thing: two systems use different code sets for the same field. A mapping rule translates one system's codes into the other's, so a source field on one side lands as a valid code on the other. The table is small, which is exactly why it gets treated as trivial and then breaks.

Take the country field. A webshop stores countries as ISO 3166 alpha-2 codes: BE, FR, DE. A shipping carrier's API accepts only the alpha-3 form, BEL, FRA, DEU, or the three-digit numeric form, 056, 250, 276. The three forms name the same countries, so a table pairing BE to BEL to 056 looks trivial. The failure hides in the corners: a country the webshop allows but the carrier's list omits. That single missing row fails a live order at checkout. A data contract that pins the exact code set each field must use catches this before it ships.