How to Name Database Columns: ISO-11179 Guide

The Hidden Cost of Bad Column Names

Every healthcare data warehouse has them: dt1, amt_f, cd_diag_prmry, MBR_CVG_EFF_DT, claimamount_billed. These names mean something to the person who created the column. They mean nothing to the next person, and nothing consistent to an automated system.

The downstream cost: analysts waste time reverse-engineering what columns mean, naming inconsistency makes joins fragile, and regulatory audits require documentation that should have been embedded in the names themselves.

ISO-11179 — the international standard for data element naming — solves this. Here is how to apply it.

What Is ISO-11179?

ISO/IEC 11179 is the international standard for the representation of data elements in metadata registries. The naming convention portion of the standard specifies a three-part structure for every data element name:

[Object Class] + [Property] + [Representation Class]

• Object Class: The entity the data element describes (e.g., member, claim, provider)
• Property: The characteristic being measured or described (e.g., birth, paid, effective)
• Representation Class: The type of value (e.g., date, amount, code, indicator, count, name, text)

The Standard Representation Classes

ISO-11179 defines these standard representation class suffixes. Using them consistently makes every column's data type self-documenting:

Applying ISO-11179 to Healthcare Data

Claims Table

Before (inconsistent):

CREATE TABLE claims (
  clm_id        VARCHAR(36),
  mbr           VARCHAR(36),
  dt_svc_from   DATE,
  dt_svc_to     DATE,
  diag1         VARCHAR(7),
  amt_billed    DECIMAL(12,2),
  amt_paid      DECIMAL(12,2),
  paid_dt       DATE,
  status        VARCHAR(20)
);

After (ISO-11179 aligned):

CREATE TABLE claims (
  clm_id                  VARCHAR(36)    NOT NULL,
  member_id                 VARCHAR(36)    NOT NULL,
  service_start_dt        DATE           NOT NULL,
  service_end_dt          DATE,
  primary_diagnosis_code    VARCHAR(20),
  clm_billed_amt       DECIMAL(12,2),
  clm_paid_amt         DECIMAL(12,2),
  clm_paid_dt           DATE,
  clm_status_code         VARCHAR(20)    NOT NULL
);

Every column is now self-documenting. A new analyst can read the schema and immediately understand what each field is and what type of value it holds.

Member / Eligibility Table

CREATE TABLE members (
  member_id                   VARCHAR(36)    NOT NULL,
  member_first_nm           VARCHAR(100),
  member_last_nm            VARCHAR(100),
  member_birth_dt           DATE,
  member_gender_code          CHAR(1),
  coverage_effective_dt     DATE           NOT NULL,
  coverage_termination_dt   DATE,
  plan_id                     VARCHAR(36)    NOT NULL,
  subscriber_ind        BOOLEAN        DEFAULT FALSE,
  member_zip_code             CHAR(5)
);

Provider Table

CREATE TABLE providers (
  prov_id           VARCHAR(36)   NOT NULL,
  prov_npi_number   CHAR(10)      NOT NULL,
  prov_first_nm   VARCHAR(100),
  prov_last_nm    VARCHAR(100),
  prov_type_code    VARCHAR(20),
  prov_specialty_code  VARCHAR(20),
  practice_state_code   CHAR(2),
  network_ind     BOOLEAN       DEFAULT FALSE
);

Common ISO-11179 Violations to Avoid

1. Missing representation class

-- Bad
member_dob,  clm_status,  prov_npi

-- Good
member_birth_dt,  clm_status_code,  prov_npi_number

2. Ambiguous abbreviations

-- Bad: what does "dt" mean? date or datetime?
svc_dt,  adm_dt,  disch_dt

-- Good
service_dt,  admission_dt,  discharge_dt

3. Mixed case conventions

-- Bad: mixing conventions in one schema
MBR_ID,  claimID,  service_dt,  PAIDAMT

4. Redundant table name prefix

-- Bad: table name repeated in every column
claims.clm_claim_id,  claims.clm_claim_dt

-- Good
claims.clm_id,  claims.service_start_dt

5. Using reserved words as column names

-- Bad
status,  date,  type,  value,  name

-- Good
clm_status_code,  service_dt,  clm_type_code,  paid_amt,  prov_nm

Enforcing ISO-11179 in Your Team

Writing a naming standard is the easy part — enforcing it is the hard part. Three practical layers of enforcement:

Layer 1: Automated Audit

Use the mdatool Naming Auditor to paste your DDL and instantly flag columns that violate naming conventions. It checks for missing representation class suffixes, inconsistent casing, reserved word usage, and ambiguous abbreviations — free, no setup.

Layer 2: DDL Review

Before any new table or view reaches production, run its DDL through the mdatool DDL Converter to normalize formatting and catch dialect-specific issues alongside naming review.

Layer 3: SQL Linting in CI/CD

Use the mdatool SQL Linter or SQLFluff to enforce that new queries referencing your tables follow the same naming conventions in aliases, CTEs, and column expressions.

Approved Abbreviations vs. Banned Abbreviations

Every team needs a maintained list. Recommended approach:

Always spell out (ambiguity too high):

• dt → use date or datetime
• amt → use amount
• cd → use code
• nm → use name
• ind → use indicator

Acceptable abbreviations (universally understood in healthcare):

• npi — National Provider Identifier
• icd — International Classification of Diseases
• cpt — Current Procedural Terminology
• drg — Diagnosis Related Group
• hcc — Hierarchical Condition Category
• id — Identifier (only as suffix: member_id, not id_member)

🏥

Free Tool

Look up any NPI number instantly →

📊

Free Tool

Calculate RAF scores with our free HCC Calculator →

Document your approved list in the mdatool Healthcare Data Dictionary so every team member can reference it.

Summary

ISO-11179 column naming follows one rule: Object + Property + Representation Class.

Apply it consistently and your schemas become self-documenting, your joins become more reliable, and your onboarding time drops dramatically. Start by auditing one table today with the mdatool Naming Auditor — it takes 30 seconds and will surface violations you did not know you had.