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 (
  claim_id                  VARCHAR(36)    NOT NULL,
  member_id                 VARCHAR(36)    NOT NULL,
  service_start_date        DATE           NOT NULL,
  service_end_date          DATE,
  primary_diagnosis_code    VARCHAR(20),
  claim_billed_amount       DECIMAL(12,2),
  claim_paid_amount         DECIMAL(12,2),
  claim_paid_date           DATE,
  claim_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_name           VARCHAR(100),
  member_last_name            VARCHAR(100),
  member_birth_date           DATE,
  member_gender_code          CHAR(1),
  coverage_effective_date     DATE           NOT NULL,
  coverage_termination_date   DATE,
  plan_id                     VARCHAR(36)    NOT NULL,
  subscriber_indicator        BOOLEAN        DEFAULT FALSE,
  member_zip_code             CHAR(5)
);

Provider Table

CREATE TABLE providers (
  provider_id           VARCHAR(36)   NOT NULL,
  provider_npi_number   CHAR(10)      NOT NULL,
  provider_first_name   VARCHAR(100),
  provider_last_name    VARCHAR(100),
  provider_type_code    VARCHAR(20),
  provider_specialty_code  VARCHAR(20),
  practice_state_code   CHAR(2),
  network_indicator     BOOLEAN       DEFAULT FALSE
);

Common ISO-11179 Violations to Avoid

1. Missing representation class

-- Bad
member_dob,  claim_status,  provider_npi

-- Good
member_birth_date,  claim_status_code,  provider_npi_number

2. Ambiguous abbreviations

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

-- Good
service_date,  admission_date,  discharge_date

3. Mixed case conventions

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

4. Redundant table name prefix

-- Bad: table name repeated in every column
claims.claim_claim_id,  claims.claim_claim_date

-- Good
claims.claim_id,  claims.service_start_date

5. Using reserved words as column names

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

-- Good
claim_status_code,  service_date,  claim_type_code,  paid_amount,  provider_name

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)

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.