Healthcare Data Governance: Who Decides What Gets Used?

A patient record is pulled from the EHR for a payer request. A copy later turns up in an analytics platform, and another feeds an AI workflow. The original exchange may be covered by policy; the later uses are harder to trace. Who approved them? Which copy is current?

That is where healthcare data governance stops being a policy exercise. It becomes the work of assigning decision rights over health data, enforcing them across systems, and preserving enough evidence to explain what happened later. Access is only one decision. Definition, exchange, reuse, correction, retention, and deletion all need an accountable owner too.

The Policy Is Clear Until the Data Moves

Healthcare organizations already know how to write rules for data inside a system of record. The harder questions arrive at the handoff. A payer sends information to a provider. A patient changes plans. An application receives a record through an API. The data may still be recognizable, but the authority around it has changed.

CMS is making those handoffs more common. Under the CMS Interoperability and Prior Authorization Final Rule, certain operational provisions generally began on January 1, 2026. Patient Access API usage reporting also began then. The rule’s API development and enhancement requirements generally start on January 1, 2027, although the exact compliance dates depend on the payer.

The rule also creates decisions that can’t be handled by an API specification alone. For the Provider Access API, impacted payers must maintain an attribution process and allow patients to opt out of having their data available to providers under the rule. Payer-to-payer exchange uses an opt-in process and covers data with dates of service within five years of the request.

Consider what an opt-out has to touch. Someone records the patient’s choice. Identity and access controls have to recognize it. The API must enforce it. Downstream copies, cached data, and audit records need an agreed treatment. If the choice is entered correctly but ignored by one receiving system, the policy didn’t survive the trip.

This is the awkward part: Regulation can define the boundary, but an organization still has to decide who turns that boundary into working behavior.

Stop Asking Who Owns the Data

“Who owns the patient data?” sounds like a governance question. It rarely survives contact with the actual workflow.

The answer changes with the holder, the type of record, the intended use, and the law or contract that governs it. A patient may have access rights. A provider may maintain the clinical record. A payer may hold claims data. A vendor may process electronic protected health information under an agreement. None of that gives one person a universal answer to every operational question.

A better approach separates four kinds of authority.

First, legal and privacy teams determine whether a proposed use is permitted, prohibited, or subject to conditions. Second, an operational owner decides whether the organization should approve that use within those limits. Third, technical teams enforce the decision in identity systems, APIs, platforms, and data stores. Finally, an accountable role must retain the evidence, review exceptions, and answer when the controls don’t match the decision.

Those jobs can sit with different people. They often should. The mistake is assuming that a governance council, privacy office, or system owner automatically covers all four.

The same distinction matters under the federal information-blocking framework. ASTP/ONC identifies three categories of information-blocking actors: healthcare providers, health information networks or exchanges, and developers of certified health IT. The framework concerns practices that interfere with access, exchange, or use of electronic health information, but an entity’s obligations depend on its role and the facts. A convenient label such as “data owner” doesn’t settle that analysis.

Map Decisions Across the Data Journey

Most governance charts start with departments: clinical, privacy, security, analytics, IT. That is tidy on a slide and less helpful during an incident. Data doesn’t travel by organization chart.

Map the decisions instead. Begin with definition and provenance. Who decides what a field means? When the EHR and claims system disagree, the warehouse can’t settle the matter by picking the newest timestamp. Someone has to decide which source wins, retire the old version, and tell downstream users what changed.

This is also where semantic governance stops being academic. The same issue appears in discussions of authoritative data definitions: access to a table doesn’t tell a system which definition, key, or version it should trust.

Next comes access and exchange. Name the person who can approve a recipient, a purpose, and a time limit. Record the patient choice or other basis that applies. Then identify the control that enforces the decision and the evidence that proves it did so.

Secondary use deserves its own decision. Data collected during care may later be proposed for analytics, research, model development, or an automated workflow. A technically possible reuse isn’t automatically an approved one. Someone has to compare the proposed purpose with the original basis, applicable restrictions, and the organization’s policy, then record the answer.

Corrections are easy to overlook. If a clinician corrects a medication field after it has reached a payer, warehouse, vendor application, and AI assistant, who decides which downstream copies must change? “The EHR is correct now” is reassuring only if every consequential user knows it.

Retention, return, and deletion create a similar chain. One team may set a schedule, another may operate backups, and a vendor may hold replicas. The accountable owner needs to know which copy is governed by which rule, when a relationship ends, and what evidence confirms the resulting action.

Finally, assign incident decisions before the incident. Who can contain access, suspend an exchange, notify affected parties, approve a corrected dataset, and release the flow again? A committee can contribute. One role still needs authority to decide.

Vendors Do Not Remove Accountability

Moving electronic protected health information to a service provider changes the trust boundary. It doesn’t make the customer’s responsibility evaporate.

A cloud provider becomes a business associate when it creates, receives, maintains, or transmits ePHI for a covered entity or another business associate. HHS’s cloud guidance is explicit on a point teams sometimes miss: encryption doesn’t remove that status simply because the provider lacks the key. A HIPAA-compliant business associate agreement is required, while the covered entity or business associate still has to understand the environment, conduct its own risk analysis, and set risk-management policies.

When ePHI moves into a hosting environment for regulated health data, the governance question is not whether responsibility disappears. It is which party controls configuration, access logging, incident response, retention, return, and deletion, and where those duties are recorded in the business associate agreement and service agreement.

The split can be quite specific. A customer might control user authentication while the provider controls administrative access to the underlying resources. HHS advises the parties to confirm such divisions in writing. That written division should then match the real controls, not an architecture diagram from two years ago.

This is why “the vendor is compliant” is a poor substitute for governance. It skips the customer configuration, the approved use, the handoff between teams, and the evidence needed when either party has to investigate. Hosting can provide controls. It can’t assign your internal decision rights for you.

AI Needs a Governed Source Boundary

An AI system adds another consumer, and sometimes another actor, to the data path. Giving it access to a repository answers a technical question. It doesn’t answer whether every field, record, or purpose inside that repository is approved.

The source boundary needs an owner. That person decides which systems and versions the AI may use, which fields are excluded, how lineage is retained, and what happens when permission or source status changes. For material outputs, the organization should be able to identify the dataset and policy version that governed the result.

Data governance and AI governance meet at the source boundary, but the jobs are different. The distinction in where data governance and AI governance intersect is useful here. Data governance decides which data is defined, permitted, and available. AI governance takes up the model questions: behavior, validation, oversight, and use. In healthcare, a data owner can approve a source without approving every way a model might use it.

Action-taking systems raise the stakes because a bad source choice can move beyond an inaccurate answer. Work on governed data for agentic AI in life sciences shows how an agent can retrieve information, interpret a response, update a case, and create follow-up work. Each action depends on the source being current, permitted, and fit for that purpose.

Keep the rule simple: Model access should follow an approved data decision, not create one after the fact.

Build the Decision-Rights Matrix

A decision-rights matrix is useful because it forces a governance program to name the missing parts. It should be small enough to use during an architecture review and specific enough to test against a real data flow.

The title of each role will vary. The discipline should not. Put one accountable role in each row, even when several teams advise or execute. “Privacy and IT” is not an owner; it is a meeting invitation.

Then test the matrix with an actual handoff. A patient opts out of provider exchange. Can the team trace that choice from intake through identity, API enforcement, downstream caches, vendor systems, and audit evidence? If one step depends on “someone usually tells analytics,” the test has already found useful work.

The matrix should also name an escalation path. Governance decisions collide with clinical urgency, legal holds, research protocols, and system limitations. An owner without a route for resolving those conflicts has responsibility on paper and very little authority in practice.

Make Someone Answer for the Decision

Choose one high-risk health-data flow and follow it past the system of record. At every handoff, ask who can approve the use, which control enforces the answer, what evidence remains, and who can stop the flow when the answer changes.

If two teams both think the other one owns a decision, that is the governance finding. Fix it before the next API, vendor connection, or AI workflow carries the ambiguity farther downstream.

Trustworthy exchange depends on authority surviving the handoff. Give each consequential decision one person who has both the responsibility and the power to answer for it.