Healthcare Data Governance for Revenue Cycle and Predictive AI
Healthcare data governance gives a provider one agreed meaning for the data behind its revenue and its predictive models. Charges, claims, remittances and patient risk scores are built from many systems, and when each system or team defines the same term differently, revenue goes uncollected and models score patients on inputs nobody can explain. A governed business glossary, lineage from encounter to payment and clear rules on which data AI tools may use address both problems with the same foundation.
Claim denials are still rising, and many of them start with data, such as incomplete registration details or missing authorizations. Reconciling what was billed with what payers actually paid is hard when the EHR, the billing system and the clearinghouse each define the same terms differently. The same gap affects predictive models and risk scores built on patient data. A governed business glossary, lineage from encounter to payment and a clear line between metadata and patient records give finance, analytics and AI teams one source of truth without spreading protected health information further than necessary.
What is healthcare data governance?
Healthcare data governance is the set of definitions, owners, rules and records that decide what a provider's data means, who is responsible for it, where it comes from and who may use it. It covers protected health information (PHI), which HIPAA regulates, and the business data built around it: charges, claims, remittances, authorizations and the metrics that finance and operations report every month.
In practice it rests on four elements.
- A business glossary. One agreed definition for each term the organization reports on, such as "clean claim", "initial denial rate" or "readmission", with a named owner.
- Ownership. A person accountable for each critical data set and each definition, so that a disagreement has someone who can settle it.
- Data lineage. A traceable path from the source system, through transformations, to the report, dashboard or model that uses the data.
- Access rules. Who may see which data, for what purpose and for how long, with patient data limited to what each use actually needs.
None of this is new to healthcare. What has changed is the number of people and tools that now read the data. Revenue cycle teams, analysts, data scientists and AI assistants all work from the same sources, and each one needs the same answer to the question "what does this number mean?"
Why revenue cycle reconciliation is a data governance problem
Revenue cycle reconciliation is the work of matching what a provider billed with what payers paid, and explaining every difference. It is a data governance problem because the evidence sits in several systems that were never designed to agree with each other.
A single encounter typically passes through registration and scheduling, the EHR, charge capture and coding, a billing or practice management system, a clearinghouse, the payer's adjudication and finally the remittance that comes back. Each step adds or changes data. When a payment is lower than expected, the team has to work out whether the cause was a registration error, a missing authorization, a coding mismatch, a contract term or a denial that was never appealed.
The scale of the problem is well documented.
- In Experian Health's State of Claims 2025 survey of 250 healthcare professionals, 41% of providers said their claims are denied more than 10% of the time, up from 30% in 2022. 54% said claim errors are increasing.
- The same survey found that incomplete or inaccurate information collected during check-in is now the third most common cause of denials.
- Premier's survey of 280 hospitals put denial rates at nearly 15% of claims, estimated that claims adjudication cost providers more than $25.7 billion in 2023, and found that about 70% of denials were eventually overturned and paid.
The last figure matters most for governance. If most denied claims are eventually paid, a large share of the cost is rework: finding the right data, correcting it and resubmitting it. Rework shrinks when each data point has a clear definition, a known source and an owner who fixes the cause rather than the single claim.
Reconciliation fails quietly when two systems use the same word for different things. The numbers look comparable, and the gap only appears when the cash does not match.
The payer side is also changing. Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), impacted payers such as Medicare Advantage organizations and Medicaid managed care plans must decide prior authorization requests within 72 hours for urgent and seven calendar days for standard requests from January 1, 2026, and must give a specific reason when they deny one. The rule's Prior Authorization, Provider Access and Payer-to-Payer APIs follow from January 1, 2027. More structured data will flow between payers and providers, and it will only help reconciliation if both sides can map it to definitions they trust.
For a broader introduction to the discipline, see what data reconciliation is and how data governance supports it.
Revenue cycle terms that need one definition
The terms that cause the most reconciliation work are the ones everybody assumes are obvious. Each of the examples below is reported by finance, operations and analytics teams, and each can be calculated in more than one defensible way. Industry bodies publish benchmark definitions for several of them, but what matters internally is that every report and every system uses the same version.
| Term | Where definitions typically differ | What the glossary entry should settle |
|---|---|---|
| Clean claim | Accepted by the clearinghouse, or paid on first submission by the payer | The point in the process at which a claim counts as clean, and the source system that records it |
| Initial denial rate | Counted by claims or by dollars, with or without denials later overturned | Numerator, denominator, time window and whether partial denials are included |
| Collected payment | Posted in the billing system, or matched to a deposit in the bank | Which date and which system define "collected", and how adjustments are treated |
| Encounter | One visit, one admission, or one billable episode across several visits | The unit that links clinical activity to charges, and how it is identified in each system |
| Expected reimbursement | Contract rate, chargemaster price or historical average | Which contract terms apply and who maintains them |
A glossary entry is only useful if it is linked to the data. Each term should point to the fields that implement it in the EHR, the billing system and the warehouse, and to the reports that display it. When an auditor or a payer asks how a number was produced, the answer is then a lookup rather than a project.
Governing data for predictive models and risk scores
A predictive model in healthcare is only as reliable as the definitions of its inputs. Providers use patient data to score readmission risk, predict no-shows, flag claims likely to be denied and prioritize care management. Each of those models combines clinical and financial fields, and each field carries the same definitional questions as the revenue cycle metrics above.
Three governance questions come up for every score.
- What exactly does each input mean? "Prior admission" may count observation stays in one source and exclude them in another. A model trained on one definition and run on the other will drift without any error message.
- Where does each input come from? Lineage from the source system to the feature tells a data scientist which upstream change could alter the score, and tells a clinician or a compliance officer what the score is actually based on.
- Who may use the score, and for what? A risk score derived from patient data is itself sensitive. Its permitted uses, its owner and the population it was validated on belong in the same record as its definition.
Impact analysis is where this pays off. When the EHR team changes a field or a code set, column-level lineage shows every report, model and score downstream of it before the change goes live. Without it, the first sign of a problem is often a model whose predictions have quietly shifted.
Governance defines and traces these inputs. It does not replace the tools that test the data itself. Many teams run a dedicated data quality or observability tool alongside their catalog, and the two work best when quality results are attached to the same glossary terms and data sets that people already look up.
Metadata vs patient data in a context layer
A context layer for healthcare should be built mostly from metadata, and keep access to patient records as a separate, approved step. This is the question security and compliance teams ask first: does the governance platform, or the AI assistant connected to it, need to see PHI?
For most questions, it does not. Definitions, owners, classifications and lineage are metadata. They let an analyst, a revenue cycle manager or an AI assistant answer "what does initial denial rate mean, which systems feed it and who owns it" without reading a single patient record. That is the part of the work that is repeated most often and that benefits most from a shared answer.
When someone does need the records, HIPAA's minimum necessary standard (45 CFR 164.502(b)) generally applies, with exceptions such as disclosures to a provider for treatment. It requires covered entities and business associates to make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose. A governed access flow puts that into practice.
| Metadata in the context layer | Patient-level data | |
|---|---|---|
| Examples | Term definitions, owners, classifications, table and column descriptions, lineage | Patient records, encounters, claims lines, diagnoses |
| Who reads it | Anyone who needs to understand the data, including AI assistants | Only people and tools with an approved purpose |
| How access is granted | By role in the governance platform | By request, with purpose, scope and duration, enforced in the data platform |
| Default for personal data | Not applicable, no records are needed | Masked unless unmasking is justified and approved |
The same split is the practical answer to AI governance in a hospital. Instead of a broad policy about AI in general, the organization decides which assets AI tools may reach, gives them the metadata layer by default, and routes any request for patient-level data through the same approval and masking rules that apply to people.
How to start with healthcare data governance
Start where the money and the risk are, and expand from there. These steps work for a single hospital as well as a health system.
- Pick one reconciliation problem. For example, the gap between expected and collected payments for one payer or one service line. A specific problem gives the program a measurable result.
- List the terms behind it. Usually ten to twenty: the metrics in the report and the fields they are built from. Agree one definition for each and name an owner.
- Catalog the systems involved. Bring the metadata from the EHR reporting database, the billing system and the warehouse into one data catalog so the definitions can be linked to real fields.
- Trace lineage for the critical metrics. From source to report, at column level where it matters, so that every number in the reconciliation can be explained.
- Classify sensitive data and set access rules. Mark PHI, decide what AI tools may reach, and make masked access the default for anything at patient level.
- Extend to predictive models. Document the inputs, owners and permitted uses of each score using the same glossary, so finance and clinical analytics share one vocabulary.
The people who know the data are the ones who make this work. Revenue cycle analysts, coders and clinical informatics staff hold most of the definitions in their heads today. Writing them down once, with their names on them, gives the organization a shared reference and gives those experts a way to answer a question once instead of many times. For a broader checklist, see data governance best practices for 2026.
How Dawiso supports healthcare data governance
Dawiso brings the elements described above into one platform that business and technical users share.
- Business glossary. The Dawiso Business Glossary holds business terms, indicators and rules as governed objects. Terms are automatically linked wherever they are mentioned in other documentation, and can be related manually to other objects in the catalog.
- Lineage. Interactive Data Lineage is extracted from supported platforms, collected from tools such as dbt, parsed from SQL scripts for enterprise customers or added manually, and shown at system, table and column level.
- Governed access. In the Data Market, a request states its use case, level of access and duration. Masked access to personal data is the default where the source supports masking, a policy can require a row-scope limit, and the underlying data platform enforces the permission on the data itself.
- AI assistants. The Dawiso MCP server lets MCP-compatible assistants search the catalog, read definitions and trace lineage. It uses the same authentication as the user, and the tools it offers depend on the user's role, so a viewer's assistant can read but not change anything.
How Dawiso keeps patient data where it is
Dawiso is built around metadata rather than patient records. For sources connected through the Dawiso Integration Runtime, ingestion runs entirely inside the customer's own infrastructure and exchanges only metadata with the source system, such as table and column names, descriptions and lineage. Row values, document contents and other payloads are never read or transmitted. Source credentials stay inside the customer's network, the customer can inspect the staged metadata before it leaves, and the connection to Dawiso cloud is outbound HTTPS only, so Dawiso never opens a connection into the hospital's network.
This is why a context layer can describe the EHR, the billing system and the warehouse in detail without becoming another place where PHI is stored. The AI assistant built into Dawiso is indexed from catalog metadata as well, and Dawiso does not train or fine-tune language models on customer content. Some optional features do work with data samples, such as attaching a sample to a catalog object or previewing one through the MCP server, and an organization governing PHI decides whether to use them for clinical systems.
Dawiso holds SOC 2 Type II and ISO/IEC 27001 certifications, and can run as SaaS on Microsoft Azure or, on the Enterprise plan, in the customer's own cloud tenant or on premises. Ask Dawiso AI and the MCP server are available in the cloud deployment.
Dawiso is a governance and context platform. It is not a claims scrubber, a denial management system or a clinical system of record, and it does not make an organization HIPAA compliant on its own. What it provides is the shared definitions, ownership and lineage that those systems and the people who run them depend on.
FAQ
What is healthcare data governance?
How does data governance help reduce claim denials?
Does a context layer need access to patient records?
What is the difference between a business glossary and a data dictionary in healthcare?
Sources
- Experian Health, State of Claims 2025, survey of 250 healthcare professionals, June and July 2025, published September 23, 2025
- Premier Inc., Claims Adjudication Costs Providers $25.7 Billion, survey of 280 hospitals covering 2023 claims, published February 24, 2025
- Centers for Medicare and Medicaid Services, CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet, January 17, 2024
- 45 CFR 164.502(b), Standard: minimum necessary, Legal Information Institute, Cornell Law School
- Dawiso Help, Business Glossary
- Dawiso Help, Sources of data lineage
- Dawiso Help, Data lineage
- Dawiso Help, Requesting access in the Data Market
- Dawiso Help, Dawiso Model Context Protocol (MCP)
- Dawiso Help, Dawiso Integration Runtime security overview
- Dawiso Help, Ask Dawiso AI security overview
See it in action
One definition for every revenue cycle metric
See how the Dawiso Business Glossary connects agreed definitions, owners and lineage across your systems.
