Data Governance and Metadata Management
Summary
This chapter introduces data governance, beginning with metadata management, data lineage, and data provenance -- the record of where data came from and how it changed. It covers data quality, traceability, and the master data management and data stewardship practices that keep an organization's data trustworthy, concluding with explainability and transparency as governance concerns in their own right.
Concepts Covered
This chapter covers the following 15 concepts from the learning graph:
| Concept | Concept Impact Score |
|---|---|
| Metadata Management | 50 |
| Data Lineage | 2 |
| Data Provenance | 1 |
| Data Quality | 2 |
| Data Traceability | 1 |
| Data Governance Framework | 45 |
| Master Data Management | 2 |
| Data Stewardship | 1 |
| Explainability | 22 |
| Transparency | 1 |
| Data Catalog | 20 |
| Data Dictionary | 2 |
| Reference Data Management | 1 |
| Golden Record | 2 |
| Entity Resolution | 1 |
Prerequisites
This chapter builds on concepts from:
- Chapter 2: Data Modeling: Graphs vs. Relational Databases
- Chapter 25: Healthcare Data Security Fundamentals
Securing a healthcare graph, as the last two chapters covered, answers "who may touch this data?" This chapter asks a different but equally essential question: "can we trust what this data actually says?" A perfectly access-controlled graph is worthless if nobody can tell where a value came from, whether it has been quietly corrected since yesterday, or which of three conflicting patient records is the real one. Data governance is the organizational discipline that answers these questions systematically, and it depends on a foundation of metadata — data about data — that this chapter builds from the ground up.
Meet Your Data's Paper Trail
Hi again — Sage here, and this chapter is one of my favorites, because it's basically detective work. Every fact in a healthcare graph has a story: where it came from, who touched it, and why it looks the way it does today. Learn to trace that story and you'll never again have to just trust a number on a dashboard — you'll be able to prove it. Let's connect the dots!
Metadata Management: Data About Data
Metadata management is the practice of systematically capturing, organizing, and making available data about data — not Maria Chen's diagnosis itself, but facts like which system originally recorded that diagnosis, how frequently that system updates, what format the diagnosis code is stored in, and who is authorized to change it. Metadata sounds abstract until you notice how often you already rely on it: a file's "last modified" timestamp, a column's data type in a database schema, and a photo's embedded camera settings are all metadata. In a healthcare graph spanning EHR systems, claims databases, lab interfaces, and pharmacy systems, metadata is what tells an engineer or an analyst what a given node or edge actually represents before they build anything on top of it.
Metadata in a well-run healthcare data platform typically falls into three overlapping categories: technical metadata (a property's data type, its source table, the ETL job that populated it), business metadata (a plain-language definition of what a field means to a clinician or biller, and who owns that definition), and operational metadata (how often a source refreshes, how long a pipeline took to run, how many records it touched). A worked example ties these together: suppose an analyst notices that Maria Chen's Patient node has a risk_score property. Technical metadata tells the analyst this property is a floating-point number populated nightly by a specific machine learning pipeline; business metadata tells them the score represents 12-month hospital readmission risk, on a 0-to-1 scale, as defined by the clinical analytics team; and operational metadata tells them the last successful refresh was six hours ago, with zero pipeline failures in the past thirty days. Without all three, the analyst has a number with no context — and a number with no context is a number nobody should trust for a clinical decision.
The table below reinforces the three-category breakdown with the risk_score example, showing how each category answers a different question about the same single property.
| Metadata Category | Question It Answers | Example for risk_score |
|---|---|---|
| Technical | What format and lineage does this field have? | Float, populated nightly by the readmission-risk ML pipeline |
| Business | What does this field mean in plain language? | 12-month readmission risk, 0-to-1 scale, owned by clinical analytics |
| Operational | Is this field's data current and reliable right now? | Last refreshed 6 hours ago; zero pipeline failures in 30 days |
Well-governed organizations store this metadata itself as structured, queryable records — often in the data catalog covered later in this chapter — rather than in scattered spreadsheets or a single engineer's memory. That queryability matters enormously at scale: a healthcare graph with thousands of properties across dozens of source systems cannot rely on any one person remembering what each one means, which is precisely why metadata management is treated as a discipline in its own right rather than an informal habit.
The interactive diagram below makes exactly this kind of metadata visible across eight real source systems feeding a healthcare knowledge graph, each with its own update frequency and integration pattern — metadata about the sources themselves, one layer up from metadata about individual fields.
Diagram: Data Integration Flow with Source Metadata
Data Integration Flow with Source Metadata (reused)
Type: infographic
sim-id: data-integration-flow-infographic
Library: p5.js
Status: Reused
Source: https://dmccreary.github.io/modeling-healthcare-data/sims/data-integration-flow-infographic/
Source Repo: https://github.com/dmccreary/modeling-healthcare-data/tree/main/docs/sims/data-integration-flow-infographic
Bloom Taxonomy: Understand
Bloom Taxonomy Verb: classify, summarize
Learning objective: Given eight source systems feeding a healthcare knowledge graph, the learner can classify each by its operational metadata (update frequency, integration pattern) and summarize why that metadata matters for interpreting the data downstream.
Reused from the MicroSim catalog. This infographic shows a central healthcare knowledge graph fed by eight source systems, each using a different integration pattern: real-time change-data-capture and Kafka streams for clinical events, nightly batches for claims, APIs for pharmacy and reference data, HL7 messages for lab results, federated queries for FHIR resources, and manual upload for social-services data. Hovering any source system reveals exactly the operational metadata described above — what data it provides, how often it updates, and which pattern moves it — directly illustrating why metadata about a source is as important as the data the source provides.
Data Lineage, Data Provenance, and Data Traceability
Once metadata establishes what a piece of data is, three closely related concepts establish where it has been. Data lineage is the end-to-end map of a data element's journey — every system, transformation, and pipeline it passed through from its original source to its current form. Data provenance is a narrower, more legally and scientifically flavored cousin: the documented origin and custody history of a specific piece of data, often required to establish that a value is trustworthy enough to support a clinical or regulatory decision. Data traceability is the practical ability to actually follow that lineage on demand — to start at a dashboard number and walk backward, hop by hop, to the exact source record that produced it.
These three ideas map almost perfectly onto a graph structure, which is why graph databases have become a natural fit for lineage tracking. Each transformation step becomes a node, and a DERIVED_FROM or TRANSFORMED_BY edge connects it to whatever fed into it — turning "where did this number come from?" into the same kind of traversal question Chapter 1 introduced for clinical relationships.
A worked example separates the three terms cleanly. Suppose a population-health dashboard reports that 18% of Riverside Clinic's diabetic patients are overdue for an eye exam. Data lineage is the full map: raw encounter records flowed from Epic EHR into a nightly ETL job, were joined against a diagnosis-code reference table, and were aggregated into the dashboard's summary metric. Data provenance narrows in on a single contested value within that map — perhaps one patient's diagnosis date, which provenance records show was entered by Dr. Osei on a specific date, sourced directly from a lab result rather than a clinician's manual note, which matters if that date is later challenged in an audit. Data traceability is what makes both of the above actionable rather than theoretical: an analyst who doubts the 18% figure can actually click through the dashboard, hop by hop, back to the individual encounter records responsible for it, rather than trusting the number on faith.
The diagram below traces exactly this kind of path, from an Epic EHR record through entity resolution to a graph entity and finally to a downstream risk model.
Diagram: Healthcare Data Lineage Graph Visualization
Healthcare Data Lineage Graph Visualization (reused)
Type: graph-model
sim-id: healthcare-data-lineage-graph-visualization
Library: vis-network
Status: Reused
Source: https://dmccreary.github.io/modeling-healthcare-data/sims/healthcare-data-lineage-graph-visualization/
Source Repo: https://github.com/dmccreary/modeling-healthcare-data/tree/main/docs/sims/healthcare-data-lineage-graph-visualization
Bloom Taxonomy: Apply
Bloom Taxonomy Verb: trace, demonstrate
Learning objective: Given a dashboard metric produced by a healthcare analytics pipeline, the learner can trace its lineage path backward through transformations to its originating source system.
Reused from the MicroSim catalog. This graph traces data lineage through five stages, left to right: source systems (Epic EHR, lab, pharmacy), the raw tables they populate, the transformations that clean and resolve them, the graph entities they become, and the analytics that consume them. Clicking any downstream node highlights the full lineage path back to its source, letting the learner directly verify a chain such as Epic EHR to PATIENT_MASTER to Entity Resolution to Patient to Risk Model — the same "walk backward, hop by hop" traceability described in the preceding paragraph.
Data lineage and provenance are not ends in themselves — they exist in service of data quality, the degree to which data is accurate, complete, consistent, and fit for its intended use. A dashboard's risk score is only as trustworthy as the weakest link in its lineage chain; Chapter 28 develops data quality into a full measurement discipline, but for now, hold onto the connection: lineage tells you where a number came from, and quality tells you whether you should believe it once you know.
Data Governance Framework: The Organizational Backbone
A data governance framework is the formal structure of policies, roles, standards, and decision rights an organization establishes to manage its data as a strategic asset rather than an accidental byproduct of running systems. Where metadata management and lineage are largely technical capabilities, a governance framework is organizational: it defines who is accountable when data quality slips, what standards a new data source must meet before it is trusted for clinical use, and how conflicting definitions of the same term (does "readmission" mean within 30 days or 90?) get resolved once and for all rather than argued about in every meeting.
A useful way to see a governance framework is as a set of interlocking pillars, each answering a different accountability question: a policy pillar (what rules govern data use, retention, and sharing), a roles pillar (who owns which data domain, covered fully as data stewardship below and expanded into councils and steward roles in Chapter 28), a quality pillar (what standards data must meet before it is trusted), a security pillar (built directly on the access control and encryption mechanisms from Chapters 25 and 26), and a compliance pillar (how the organization demonstrates it is meeting HIPAA and other regulatory obligations). A worked example shows why all five pillars must work together: suppose Riverside Clinic's analytics team wants to add a new wearable-device vendor's heart-rate data to the patient graph. The policy pillar determines whether the clinic's data-sharing agreements even permit ingesting this data; the roles pillar identifies which data steward must approve the new source; the quality pillar sets thresholds the incoming data must meet before it feeds any clinical dashboard; the security pillar determines what access controls apply to it; and the compliance pillar confirms the whole arrangement satisfies HIPAA. Skip any one pillar, and the new data source becomes a governance blind spot no matter how well the other four are handled.
The table below summarizes each pillar's accountability question alongside its concrete role in the wearable-device scenario just described, reinforcing which pillar owns which decision before you explore the interactive version.
| Pillar | Accountability Question | Role in the Wearable-Device Example |
|---|---|---|
| Policy | What rules govern data use, retention, and sharing? | Confirms the vendor's data-sharing agreement permits ingestion |
| Roles | Who owns this data domain and approves changes to it? | Identifies the data steward who must sign off on the new source |
| Quality | What standard must this data meet before it is trusted? | Sets accuracy and completeness thresholds before dashboard use |
| Security | What access controls and protections apply? | Applies the RBAC and encryption controls from Chapters 25-26 |
| Compliance | Does this arrangement satisfy regulatory obligations? | Verifies the integration meets HIPAA requirements |
A governance framework only works if these pillars are backed by real organizational authority rather than existing on paper alone — a policy nobody enforces, or a steward role with no actual decision rights, provides the illusion of governance without its substance. That authority question is exactly why Chapter 28 introduces the data governance council: a standing body with the actual power to resolve the cross-pillar conflicts a framework like this one will inevitably surface.
Diagram: Data Governance Framework Pillars
Data Governance Framework Pillars
Type: infographic
sim-id: data-governance-framework-pillars
Library: p5.js
Status: Specified
Bloom Taxonomy: Analyze
Bloom Taxonomy Verb: differentiate, examine
Learning objective: Given a new-data-source scenario, the learner can differentiate which of the five governance pillars (policy, roles, quality, security, compliance) is responsible for a specific accountability question and examine how the pillars interact.
Purpose: Make the five interlocking pillars of a data governance framework concrete using the wearable-device data source scenario from the preceding worked example.
Components to show: Five vertical pillar shapes arranged side by side, each labeled: Policy, Roles, Quality, Security, Compliance. A horizontal beam across the top labeled "Trusted, Governed Data" rests on all five pillars.
Data Visibility Requirements: Stage 1: Show the five pillars unlabeled with only their names, beam resting on top. Stage 2: On click of a pillar, show that pillar's accountability question (e.g., Policy: "What rules govern data use, retention, and sharing?") and the specific wearable-device-vendor decision it governs from the worked example, in a side panel. Stage 3: On click of the "Remove a Pillar" toggle for any single pillar, animate that pillar sliding out and the beam visibly tilting/dropping on that side, illustrating a governance blind spot.
Interactive controls:
- Click each pillar to reveal its accountability question and worked-example decision
- Toggle button per pillar: "Remove this pillar" to visually demonstrate what happens when that governance function is missing
- Reset button to restore all five pillars
Instructional Rationale: The Analyze-level objective (differentiate, examine) is served by letting learners actively remove a pillar and see the structural consequence, rather than just reading a labeled diagram — this mirrors the "skip any one pillar" claim in the preceding prose and lets the learner verify it interactively rather than take it on faith.
Layout: Horizontal row of five pillars, responsive width, fixed height, reflows pillar spacing on window resize.
Color scheme: Each pillar a distinct color (policy blue, roles teal, quality green, security orange, compliance purple); the beam is gray and turns red when tilted.
Implementation: p5.js with simple physics-free tilt animation triggered by button state.
Two remaining organizational concepts round out the picture. Master data management, or MDM, is the discipline of establishing a single, authoritative version of core business entities — patients, providers, facilities — that every system in the organization references rather than maintaining its own separate, potentially conflicting copy. Data stewardship assigns clear human accountability for a specific data domain: a data steward for "patient demographics" is the person responsible for that domain's quality, definitions, and access decisions, acting as the practical, human face of the roles pillar described above. Chapter 28 returns to data stewardship in depth, covering the specific steward role and the governance council that coordinates stewards across domains.
Explainability and Transparency: Governance for the AI Era
Governance concerns extend beyond the raw data pipeline into how that data is used, especially once machine learning and graph-based AI models start recommending clinical actions. Explainability is the property of a system that lets a human understand why it produced a specific output — not just that a model recommended a particular medication for Maria Chen, but which specific facts in her patient subgraph (a lab value, a drug interaction, a comorbidity) drove that recommendation. Transparency is the closely related but broader organizational commitment to make a system's data sources, methods, and limitations visible and available for scrutiny, even before any single output needs explaining.
Explainability matters enormously in healthcare governance because a clinician (and a patient) are entitled to understand the reasoning behind a recommendation before acting on it — a black-box suggestion is much harder to trust, audit, or catch a mistake in than one accompanied by a traceable chain of evidence. Graph structures again offer a natural mechanism: because a clinical knowledge graph already represents facts as nodes and relationships as edges, an explanation can be built directly from the specific path of nodes and edges the recommendation engine actually traversed, rather than from an opaque statistical summary. Compare this to a traditional machine learning model trained on tabular data, which typically must reach for a separate post-hoc technique — ranking which input features mattered most to a prediction, without any guarantee that ranking reflects genuine clinical reasoning. A graph-native explanation, by contrast, is the reasoning: "recommend Metformin because Maria Chen's HbA1c edge exceeds the diagnostic threshold, she has no CONTRAINDICATED_WITH edge to Metformin, and her INSURANCE_COVERS edge confirms formulary coverage" is both the answer and its own audit trail.
Transparency operates at a higher, more organizational level than any single explanation. A transparent healthcare AI program publishes documentation — sometimes called a model card or algorithmic impact statement — describing what data trained a clinical model, what populations it was validated against, and what its known limitations are, so that an adopting clinic can judge for itself whether the model is appropriate for its own patient population before ever seeing an individual recommendation. Explainability answers "why did the system say this?" for one output; transparency answers "should we trust this system at all?" for the system as a whole. Governance programs need both, because a perfectly explainable individual recommendation from a model trained on a demographically unrepresentative population is still a governance failure — the explanation would faithfully describe flawed reasoning.
Diagram: Explainable AI Recommendation Workflow
Explainable AI Recommendation Workflow (reused)
Type: workflow
sim-id: explainable-ai-recommendation-workflow
Library: Mermaid
Status: Reused
Source: https://dmccreary.github.io/modeling-healthcare-data/sims/explainable-ai-recommendation-workflow/
Source Repo: https://github.com/dmccreary/modeling-healthcare-data/tree/main/docs/sims/explainable-ai-recommendation-workflow
Bloom Taxonomy: Analyze
Bloom Taxonomy Verb: examine, distinguish
Learning objective: Given a graph-based clinical recommendation, the learner can distinguish the inference step that generates the recommendation from the separate explanation-graph step that makes it interpretable, and identify where a low-confidence case is instead routed to human review.
Reused from the MicroSim catalog. This flowchart shows how a graph-based clinical decision support system produces an explainable medication recommendation: the patient's subgraph and the clinical knowledge graph converge in an inference engine that scores options, and — when confidence is high — the system builds a distinct explanation graph before presenting the recommendation with its reasoning and logging the access. Hovering any step reveals its function; the low-confidence branch flags a case for human review instead of forcing a recommendation, directly illustrating that explainability is a design choice, not an automatic byproduct of a model producing an answer.
Explainability Is a Feature, Not a Side Effect
Notice in the diagram above that building the explanation graph is a separate, deliberate step — it doesn't happen automatically just because the recommendation exists. That's the mental shift worth holding onto: a system can be highly accurate and still be ungoverned if nobody designed a way to explain its reasoning. Transparency and explainability have to be built in on purpose.
Data Catalog, Data Dictionary, and the Golden Record
The remaining concepts describe the practical tools a governance program actually uses day to day. A data catalog is a searchable inventory of every data asset an organization holds — tables, graph node and edge types, dashboards, and pipelines — along with the metadata described earlier in this chapter, so an analyst can discover what data exists and who owns it without having to ask around. A worked example shows the catalog's payoff directly: a new analyst joining Riverside Clinic's data team needs to know whether a "30-day readmission" metric already exists before building one from scratch. Without a catalog, she asks around Slack and hopes someone remembers; with a catalog, she searches "readmission" and finds an existing readmission_30day graph property, its owning data steward, its last-refreshed timestamp, and a link to the dashboard that already uses it — turning a scavenger hunt into a ten-second lookup. This search-and-discover capability is precisely what separates a data catalog from a governance framework's paper policies: the catalog is the searchable, living record those policies actually point to.
A data dictionary is narrower and more precise than a catalog: a formal reference defining the exact meaning, format, and valid values of each specific field or property, so that "readmission_flag" means exactly one thing — perhaps "boolean, true if any inpatient admission occurred within 30 days of a prior discharge for the same patient" — across every system that uses it, rather than one team's 30-day definition silently colliding with another team's 90-day definition. Reference data management governs a related but distinct category: shared lookup values used consistently across systems, such as the standardized list of U.S. states, the ICD-10 diagnosis code set from Chapter 7, or the facility-type classifications used throughout this book's provider chapters. Where a data dictionary defines what a field means, reference data management governs the actual permitted values a field may take — the difference between defining "diagnosis_code" as a concept and maintaining the literal, versioned list of every valid ICD-10 code that field may hold.
Catalog, Dictionary, or Reference Data? Ask What You're Looking For
These three are easy to blur together, so ask yourself which question you're actually asking. "Does this data exist, and who owns it?" is the catalog; "what exactly does this field mean?" is the dictionary; "what values is this field even allowed to hold?" is reference data management. Three different questions, three different tools.
Finally, three concepts address what happens when the same real-world entity — a patient, most often — appears differently across multiple source systems. Entity resolution is the process of determining that two or more records from different systems actually refer to the same underlying person, despite differences in how their name, address, or identifiers were recorded. Once entity resolution identifies a match, master data management (introduced above) uses that result to construct a golden record: a single, merged, authoritative representation of that entity that reconciles conflicting field values (perhaps keeping the most recently updated address, and the most complete phone number) into one trusted record every downstream system can reference. The healthcare data integration graph below shows exactly this convergence — multiple encounters from different source systems all resolving onto one unified patient record.
Diagram: Healthcare Data Integration Graph Model
Healthcare Data Integration Graph Model (reused)
Type: graph-model
sim-id: healthcare-data-integration-graph-model
Library: vis-network
Status: Reused
Source: https://dmccreary.github.io/modeling-healthcare-data/sims/healthcare-data-integration-graph-model/
Source Repo: https://github.com/dmccreary/modeling-healthcare-data/tree/main/docs/sims/healthcare-data-integration-graph-model
Bloom Taxonomy: Understand
Bloom Taxonomy Verb: explain, illustrate
Learning objective: Given records from multiple source systems for the same patient, the learner can explain how entity resolution and master data management combine to produce a single golden record.
Reused from the MicroSim catalog. This graph shows how a graph database integrates fragmented healthcare data into one unified patient view: a single master patient record has encounters for office visits, ED visits, and hospitalizations, each sourced from a different system (Epic EHR, claims database, lab interface, pharmacy), with diagnoses attached to each encounter. Clicking the central master patient node highlights every source-system edge converging on it, making concrete how entity resolution and MDM together produce one golden record from many fragmented originals.
One Quick Question Settles Golden Record vs. Entity Resolution
If you ever mix up entity resolution and the golden record, ask: "Is this the matching step or the merging step?" Entity resolution is matching — deciding two records are the same person. The golden record is merging — building the one trusted record out of what matched. Matching comes first, merging comes second.
Chapter Summary
You Can Now Trace Any Fact Back to Its Source
That's data governance mastered — metadata, lineage, provenance, governance frameworks, explainability, and golden records all connected. You now know not just what a data point says, but where it came from and whether it deserves your trust. That's a genuine analytical superpower.
This chapter built the vocabulary for trusting healthcare data rather than just securing it: metadata tells you what a value is, lineage and provenance tell you where it came from, and a data governance framework assigns organizational accountability for keeping all of it trustworthy. Master data management, entity resolution, and the golden record solve the specific problem of one patient appearing in many systems, while explainability and transparency extend governance into how AI-driven recommendations justify themselves. In Chapter 28, we turn from these governance foundations to the day-to-day mechanics of running a governance program: measuring data quality, assigning ownership, and reporting compliance.