Healthcare Data Governance: Building a Data Dictionary for Your Health Plan or PBM

The Governance Gap No One Wants to Own

Data governance is the number one strategic priority for healthcare organizations in 2026. CMS interoperability mandates require payers to expose structured data through FHIR APIs. HEDIS reporting deadlines demand consistent measure definitions across disparate systems. HCC risk adjustment accuracy depends on claims and clinical data that is precisely defined and consistently captured.

📊

Free Tool

Calculate RAF scores with our free HCC Calculator →

The problem is not a shortage of ambition. It is a shortage of implementation.

Most health plans and PBMs have a data governance policy. They have a data governance committee. What they often do not have is the artifact those committees produce: a working, maintained, team-adopted data dictionary that engineers actually use when they build pipelines.

Without that artifact, data governance is a presentation deck, not a practice.

Section 1: The State of Healthcare Data Governance

The Naming Convention Sprawl Problem

A typical mid-size health plan has accumulated five to ten naming convention systems over 15 years of technology cycles:

• The claims adjudication system, built in 2008, uses CLMNT_ID and PROC_CD
• The data warehouse migration in 2015 introduced claim_id and procedure_code
• The dbt project started in 2020 uses clm_id and proc_cd
• The Snowflake layer added by the analytics team in 2022 uses claim_identifier and cpt_code

Four names for claim ID. Four names for procedure code. In the same organization, queried by the same analysts, loaded by the same pipelines.

Every join between these layers requires a mapping table. Every new engineer must learn all four conventions. Every HEDIS extract has a reconciliation step. Every audit includes an explanation section justifying the field mappings.

The cost of this sprawl is not visible in any single project. It is distributed across every data initiative the organization undertakes — estimated by Gartner at $12.9 million per year in data quality costs for the average enterprise.

Why Governance Programs Stall

Data governance programs at health plans stall for three predictable reasons:

They start with policy, not tooling. A governance framework document in Confluence does not change how engineers name columns. An automated linting rule in CI/CD does.

They try to boil the ocean. A mandate to rename 50,000 existing columns is dead on arrival. A standard applied to all new development, with migration of high-traffic tables on a rolling basis, is achievable.

They lack a reference artifact. Without a canonical dictionary that engineers trust and refer to, every naming decision falls back to individual judgment — which is precisely where inconsistency originates.

Section 2: What Good Healthcare Data Governance Looks Like

Effective healthcare data governance for a health plan or PBM has three characteristics.

A single dictionary, used by the entire team. Not a spreadsheet maintained by one data steward. Not a Confluence page that is three years out of date. A living, searchable reference that engineers bookmark, architects cite, and compliance teams use in audit documentation. Coverage must span every domain: claims, clinical, pharmacy, member, and provider.

ISO-11179 compliant naming standards. The international standard for data element naming provides the structure that makes governance scalable. When every column name follows the same object–property–representation pattern, documentation is embedded in the name itself. clm_adj_dt documents itself. x1234_processed does not.

✅

Free Tool

Check these column names against healthcare naming standards →

Integration with the data engineering workflow. A governance standard that lives outside the data stack will be ignored by the data stack. Standards must be enforced at the point of code — in dbt model definitions, Snowflake column descriptions, Databricks Unity Catalog entries, and BigQuery table schemas. Automated naming audits in CI/CD are the enforcement mechanism that prevents drift.

Section 3: How to Build a Healthcare Data Dictionary

Step 1: Start with Your Core Domains

Do not try to document everything at once. A health plan's data platform typically has five to seven core domains that account for 80% of analytical activity: claims, clinical, pharmacy, member, provider, and potentially risk adjustment and quality metrics. Start there.

For each domain, identify the 50–100 most-used data elements: the fields that appear in HEDIS reports, CMS submissions, operational dashboards, and regulatory audits. These are the elements with the highest cost of inconsistency and the highest value of standardization.

Step 2: Adopt ISO-11179 Naming Conventions

Map each existing data element to its ISO-11179 standard name. This does not require immediately renaming production tables — it requires agreeing on what the standard name is and using it in all new development. For a health plan, a working set of 500–800 standard element names covers most analytical use cases.

A reference dictionary of 100,000+ healthcare-specific terms already structured to ISO-11179 — such as mdatool's glossary — eliminates the months-long effort of building this foundation from scratch. Your team extends it for organization-specific elements rather than building the common core themselves.

Step 3: Document Every Data Element

For each element, document: the standard name, the business definition, the technical definition (data type, valid values, source system), the domain, and any known aliases in existing systems. This documentation is your audit artifact. It is also the onboarding material that turns a three-month ramp into a three-week ramp.

Step 4: Enforce Standards in Code Review and CI/CD

Governance that relies on documentation alone will drift. Standards must be enforced at the code level. A naming auditor that checks new column names against the standard dictionary before merge — integrated into the PR review process or CI/CD pipeline — catches violations before they enter production.

Step 5: Use a Reference Platform as Your Team's Standard

The most effective data governance programs anchor their standards to a maintained, versioned external reference that the team treats as authoritative. This reduces the internal governance burden: instead of building and maintaining a dictionary, the team adopts and extends one. The dictionary becomes a dependency, not an initiative.

Section 4: Making It Stick Across Teams

Building the dictionary is the straightforward part. Getting five teams with five different legacy conventions to adopt it is the organizational challenge.

Get architect buy-in first. Data governance driven top-down by compliance officers fails. Data governance championed by the architects who design new tables succeeds. Make the dictionary useful to the people who name things, and adoption follows naturally.

Start with new projects, not migrations. A mandate to rename existing production tables creates risk, slows delivery, and builds resentment. A standard applied to all greenfield work creates visible progress without disruption. Within 12–18 months, all new tables follow the standard. Legacy tables migrate opportunistically during refactoring cycles.

Use automated linting to enforce standards. A naming auditor in CI/CD does more for governance than any policy document. When a non-compliant column name is flagged in a PR review, engineers learn the standard quickly — and the standard reinforces itself without manual oversight.

Link to the reference dictionary from code. Column descriptions in dbt models and data catalog entries should link directly to the canonical definition in the data dictionary. This makes the dictionary discoverable at the point of use, not just in a governance portal that engineers visit once during onboarding.

---

Start with mdatool's free healthcare data dictionary — 100,000+ terms already documented and standardized. Your team can begin using it today, and extend it for your organization's specific elements as your governance program matures.

Frequently Asked Questions

What is healthcare data governance?

Healthcare data governance is the set of policies, standards, and practices that ensure healthcare data is consistently defined, accurately documented, properly secured, and used responsibly across an organization. For health plans and PBMs, governance typically covers data naming standards (ensuring the same field is called the same thing everywhere), data quality standards (ensuring data meets defined accuracy and completeness thresholds), access controls (ensuring only authorized users can access sensitive data), and audit documentation (ensuring data lineage and transformations are recorded). Effective governance is not a committee or a policy document — it is a set of enforced standards embedded in the data engineering workflow.

How do you build a healthcare data dictionary?

Building a healthcare data dictionary involves five steps: (1) define your core domains and the data elements within each; (2) adopt a naming standard — ISO-11179 is the international reference for data element naming; (3) document each element with a business definition, technical specification, and known aliases; (4) integrate the dictionary into your data engineering workflow via automated naming audits and column descriptions; and (5) establish a maintenance process to keep the dictionary current as new data sources and elements are added. For most health plans, starting with an existing reference dictionary — like mdatool's 100,000+ term healthcare dictionary — and extending it for organization-specific elements is faster and more sustainable than building from scratch.

What is the ROI of data governance for health plans?

The ROI of data governance investment at health plans manifests in several measurable areas. New engineer onboarding drops from 3–6 months to 4–6 weeks when a working data dictionary exists — representing $30,000–$50,000 per hire in recovered productivity at typical engineering salaries. Data quality incidents decrease as naming ambiguity is eliminated, reducing emergency rework costs that average hundreds of engineering hours per year. CMS reporting and HEDIS preparation cycles shorten as field reconciliation becomes routine rather than investigative. And audit findings decrease as data documentation becomes current by design rather than retrospective by necessity. Gartner estimates poor data quality costs the average enterprise $12.9 million annually — data governance is the investment that systematically reduces that number.