ISO-11179 Naming Convention Complete Guide for Healthcare Data Engineers

Introduction

A healthcare data warehouse will accumulate naming drift over time unless a standard is enforced from the start. DOB in one table, birth_dt in another, member_birth_date in a third — all meaning the same thing. When a HIPAA audit asks you to identify every column containing a date of birth, or when CMS asks why your encounter data does not match your claims submission, the answer usually traces back to naming inconsistency.

ISO-11179 is the international standard that fixes this. It defines how data element names should be constructed so that the name itself communicates the structure, content, and format of the field. Healthcare organizations adopted it because the standard aligns with how EDI transactions, FHIR resources, and CMS reporting requirements are already organized — by domain and data type.

This guide covers the full standard: core rules, standard abbreviations for every major healthcare domain, common mistakes, platform-specific DDL examples, and a SQL audit query you can run against your existing schema today.

---

What Is ISO-11179?

ISO/IEC 11179 is an international standard published by ISO and the International Electrotechnical Commission for the representation and management of data elements. Part 5 of the standard defines naming and identification rules for data elements — and that is the part that healthcare data engineers care about.

The core idea is that every column name should follow a three-part structure:

Object class: What entity the data describes — mbr (member), clm (claim), prvdr (provider), pt (patient), rx (prescription).

Property: The characteristic being captured — birth (date of birth), paid (paid amount), svc (service), eff (effective).

Representation: The data type or format — dt (date), amt (monetary amount), cd (code), id (identifier), nm (name).

The result is a column name like mbr_birth_dt that tells you immediately: this is a member-domain field, it captures the birth property, and it is stored as a date. You do not need a data dictionary to decode it.

Healthcare adopted ISO-11179 because it was already implicit in EDI standards (837 loops use similar object-property-class patterns), HIPAA transactions, and CMS reporting specifications. Formalizing it through ISO-11179 gives organizations a defensible, auditable standard — not an internal convention that disappears when the original architect leaves.

---

The Core Rules

Every ISO-11179-compliant healthcare column name follows five rules:

1. Lowercase snake_case only. All characters are lowercase. Words are separated by underscores. No camelCase, no PascalCase, no mixed case. mbr_eff_dt — not MemberEffectiveDate, not mbrEffDt.

2. Standard abbreviations, not full words. Use the approved domain abbreviation set (covered in the next section), not spelled-out words. clm_pd_amt — not claim_paid_amount. Abbreviations must be consistent across the entire schema: if mbr is your member object class, it is mbr everywhere, not mem in some tables and member in others.

3. 30-character maximum. Most SQL platforms impose limits (PostgreSQL truncates identifiers at 63 chars; Snowflake allows 255 but BI tool compatibility degrades above 30). Staying under 30 ensures portability. If a name exceeds 30 characters, abbreviate the property term — icd_diag_cd_1 not icd_diagnosis_code_primary.

4. No special characters or spaces. Only alphanumeric characters and underscores. No hyphens, dots, parentheses, or brackets.

5. Consistent representation suffixes. The suffix signals the data type and eliminates ambiguity at a glance:

Use the mdatool Naming Auditor to validate your schema against these rules automatically — it flags violations and suggests compliant alternatives.

---

Standard Healthcare Abbreviations by Domain

The following abbreviation sets are used in production healthcare schemas at major payers, health systems, and data vendors. Cross-reference the full term list at the mdatool glossary.

Claims

The claims domain uses the clm_ prefix for claim-level fields, pmt_ for payment tracking, and adj_ for adjustments.

See Healthcare Claims Data Model: Complete SQL Schema for a full Star Schema built with these naming conventions.

Member / Enrollment

The member domain uses mbr_ for member attributes, subscr_ for subscriber (employer/group) fields, and elig_ for eligibility period fields.

Clinical

The clinical domain uses pt_ for patient-level fields, diag_ for diagnosis data, and proc_ for procedures.

📊

Free Tool

Calculate RAF scores with our free HCC Calculator →

Pharmacy

The pharmacy domain uses rx_ for prescription fields, ndc_ for drug code data, and pharm_ for dispensing pharmacy attributes.

🏥

Free Tool

Look up any NPI number instantly →

Provider

The provider domain uses prvdr_ as the base prefix, npi_ for NPI-specific columns, and tax_ for tax identifier fields.

For NPI validation patterns and provider data architecture, see the NPI Guide.

---

Common Mistakes and How to Fix Them

These are the naming patterns that appear most often in legacy healthcare schemas and fail ISO-11179 compliance:

The most common root cause is that the original schema was designed for a single application (where DOB is obvious from context) and later promoted to a shared data warehouse where that context disappears.

---

Applying ISO-11179 in Snowflake, BigQuery, and Databricks

Each platform handles case sensitivity differently, which affects how strictly ISO-11179 enforcement works in practice.

Snowflake stores unquoted identifiers as uppercase internally but displays them as lowercase — unless you quote them. Always create healthcare tables without quoting identifiers, and ISO-11179 lowercase names work naturally:

-- Snowflake: ISO-11179 compliant claims table
CREATE TABLE claims.fact_claim_header (
  clm_id          VARCHAR(50)    NOT NULL,
  mbr_id          VARCHAR(50)    NOT NULL,   -- PHI
  prvdr_npi       VARCHAR(10),
  clm_svc_dt      DATE           NOT NULL,
  clm_pd_dt       DATE,
  clm_bld_amt     NUMBER(12,2),
  clm_alwd_amt    NUMBER(12,2),
  clm_pd_amt      NUMBER(12,2),
  clm_sts_cd      VARCHAR(20),
  icd_diag_cd_1   VARCHAR(7),
  icd_diag_cd_2   VARCHAR(7),
  icd_diag_cd_3   VARCHAR(7),
  load_ts         TIMESTAMP_NTZ  NOT NULL DEFAULT CURRENT_TIMESTAMP,
  CONSTRAINT pk_fact_clm PRIMARY KEY (clm_id)
);

BigQuery is case-insensitive for identifiers and uses ANSI SQL types. Replace Snowflake's NUMBER(12,2) with NUMERIC and TIMESTAMP_NTZ with DATETIME:

-- BigQuery: ISO-11179 compliant claims table
CREATE TABLE claims.fact_claim_header (
  clm_id          STRING         NOT NULL,
  mbr_id          STRING         NOT NULL,
  prvdr_npi       STRING,
  clm_svc_dt      DATE           NOT NULL,
  clm_pd_dt       DATE,
  clm_bld_amt     NUMERIC,
  clm_alwd_amt    NUMERIC,
  clm_pd_amt      NUMERIC,
  clm_sts_cd      STRING,
  icd_diag_cd_1   STRING,
  icd_diag_cd_2   STRING,
  icd_diag_cd_3   STRING,
  load_ts         DATETIME
);

Databricks (Delta Lake) uses DECIMAL for financial amounts and supports COMMENT clauses — use them to document PHI columns directly in the DDL:

-- Databricks: ISO-11179 compliant claims table
CREATE TABLE claims.fact_claim_header (
  clm_id          STRING         NOT NULL   COMMENT 'Claim identifier',
  mbr_id          STRING         NOT NULL   COMMENT 'Member ID — PHI, mask in non-prod',
  prvdr_npi       STRING                    COMMENT 'Rendering provider NPI',
  clm_svc_dt      DATE           NOT NULL   COMMENT 'Date of service',
  clm_pd_dt       DATE,
  clm_bld_amt     DECIMAL(12,2),
  clm_alwd_amt    DECIMAL(12,2),
  clm_pd_amt      DECIMAL(12,2),
  clm_sts_cd      STRING,
  icd_diag_cd_1   STRING,
  icd_diag_cd_2   STRING,
  icd_diag_cd_3   STRING,
  load_ts         TIMESTAMP
)
USING DELTA
PARTITIONED BY (YEAR(clm_svc_dt));

Use the mdatool DDL Converter to translate schemas between these platforms automatically without manually rewriting type mappings.

---

Auditing Your Existing Schema

If you are applying ISO-11179 to a legacy schema, start with an audit before migrating. This query surfaces columns in Snowflake's information schema that are likely non-compliant — camelCase, all-caps, or missing standard suffixes:

-- Snowflake: find columns that are likely ISO-11179 non-compliant
SELECT
  table_schema,
  table_name,
  column_name,
  data_type,
  CASE
    WHEN column_name != LOWER(column_name)          THEN 'mixed_case'
    WHEN column_name LIKE '%[A-Z]%'                 THEN 'contains_uppercase'
    WHEN column_name NOT LIKE '%\_%'                THEN 'no_underscore_separator'
    WHEN column_name NOT RLIKE '.*_(dt|ts|amt|cd|id|nm|nbr|flg|cnt|pct|txt|ind)$'
                                                    THEN 'missing_type_suffix'
    ELSE 'ok'
  END AS compliance_status
FROM information_schema.columns
WHERE table_schema NOT IN ('INFORMATION_SCHEMA', 'PUBLIC')
  AND table_name NOT LIKE 'SYS_%'
ORDER BY compliance_status, table_schema, table_name, column_name;

Run this against your warehouse and export the results. The Naming Auditor automates this and generates a full compliance report with suggested replacements for every violation.

Migration strategy: Rename columns using views first — create ISO-11179 compliant views over non-compliant base tables, migrate downstream consumers to the view, then rename the base tables in a maintenance window. This decouples the migration from application deployments and gives you a rollback path if a consuming system breaks.

-- Step 1: Create compliant view over legacy table
CREATE OR REPLACE VIEW claims.v_fact_claim_header AS
SELECT
  ClaimID          AS clm_id,
  MemberDOB        AS mbr_birth_dt,
  PaidAmount       AS clm_pd_amt,
  DateOfService    AS clm_svc_dt,
  ProviderNPI      AS prvdr_npi
FROM claims_legacy.ClaimHeader;

-- Step 2: Migrate consumers to the view, then rename the base table
ALTER TABLE claims_legacy.ClaimHeader RENAME TO fact_claim_header;

---

Frequently Asked Questions

What is ISO-11179 naming convention?

ISO/IEC 11179 is an international standard for naming and defining data elements. The naming convention it defines — object class + property + representation — produces column names that are self-documenting, unambiguous, and consistent across systems. In healthcare, it means that mbr_birth_dt is always a member's date of birth, clm_pd_amt is always a paid claim amount, and prvdr_npi is always a provider NPI — regardless of which table, which system, or which team created the column.

Why use ISO-11179 for healthcare data?

Healthcare data is consumed by many systems simultaneously — HIPAA audits, CMS submissions, BI tools, ML pipelines, and operational applications. Each consumer expects to find PHI columns, financial amounts, and code values in predictable locations with predictable names. ISO-11179 creates that predictability. It also makes HIPAA compliance easier: when PHI columns follow a naming pattern (all end in _nm, _dt, or _id with a patient object class prefix), automated PHI discovery tools can identify them reliably without manual tagging.

What is the correct abbreviation for patient identifier?

The ISO-11179 compliant name for a patient identifier is pt_id. In payer data warehouses where the entity is a health plan member rather than a clinical patient, use mbr_id. In claims data, mbr_id refers to the member on the claim and is a PHI field that requires HIPAA-compliant handling. The mdatool glossary contains the full approved abbreviation set for every healthcare domain.

How do I audit my schema for naming violations?

Run the compliance query in the section above against your Snowflake, BigQuery, or Databricks information schema. It identifies four violation types: mixed case, uppercase letters, missing underscore separators, and missing type suffixes. For a complete automated audit with suggested replacements, use the Naming Auditor — it checks all four rules, applies domain-specific context (so it knows npi does not need a _cd suffix even though it is a code-like value), and exports a prioritized remediation list.

Does Snowflake require specific naming conventions?

Snowflake does not enforce any naming convention — it accepts any valid identifier. But Snowflake's behavior makes ISO-11179 compliance important in practice. Snowflake stores unquoted identifiers as uppercase internally. If developers use quoted identifiers ("MemberDOB") to preserve mixed case, every query must also use quoted references — creating brittle SQL that breaks when the quoting is omitted. Using ISO-11179 lowercase snake_case without quotes eliminates this problem entirely. Unquoted lowercase names work consistently across Snowflake SQL, dbt models, Looker LookML, and any other tooling that reads Snowflake.