Data Sharing Between Public Bodies: 6 Use Cases

Public agencies can share data to cut repeat paperwork, check eligibility, review fraud, coordinate care, support students, oversee licenses, and measure program results - but only within strict legal and privacy limits.

If you want the short version, here it is: this article covers 6 common data-sharing uses, the main laws behind them, and the privacy checks agencies should apply every time. It also makes one point clear: the risk changes by use case. Health and student records need tighter controls than de-identified program data, and fraud matching needs extra review because a bad match can stop services for the wrong person.

Here’s what I’d take away right away:

• Benefits eligibility uses record matching so people don’t submit the same proof twice
• Fraud detection uses cross-agency checks to spot duplicates, conflicts, and improper payments
• Health and social care sharing helps agencies line up services like Medicaid, housing, and nutrition support
• Licensing and permitting sharing supports review and oversight, but data use must stay narrow
• Education and safeguarding deals with student records, so disclosure limits matter even more
• Program monitoring often uses de-identified data to review how programs perform, not to judge one person

The article also points to a small set of privacy rules that show up again and again:

• Share only the minimum data needed
• Limit access to approved staff
• Set deletion timelines
• Keep audit logs
• Give notice where required
• Put the exchange in writing through agreements like MOUs, CMAs, and ISAs

A few details stand out. The piece notes that health and social care sits at the top of the risk scale, while program monitoring is often low to moderate risk when data is de-identified. It also notes that the Evidence Act generally supports data sharing for allowed government uses unless another law blocks it, while laws like CMPPA, HIPAA, and FERPA can set tighter limits.

Quick Comparison

In other words: the article is less about whether agencies can share data and more about how narrowly and safely they do it. That means legal authority first, limited data second, and written rules before any system connection goes live.

sbb-itb-5f36581

A Quick Overview of the 6 Use Cases

Start with a side-by-side view. These six scenarios look similar on the surface, but they differ in purpose, legal basis, data sensitivity, and the main privacy risk tied to each one.

One pattern stands out right away: health and social care sits at the top of the risk scale because it deals with medical and other highly private records. At the other end, program monitoring is often less sensitive, especially when data has been de-identified. Even then, the risk does not disappear. If data can be linked back to a person, the privacy issue comes right back into play.

"The less information collected from the start, the less personal information is available to be misused and circulated beyond the user's control." - New America

The legal basis also shifts depending on the use case. Benefits and fraud review often lean on CMAs, while program evaluation is more often tied to the Evidence Act.

Next, each use case is broken down by purpose, data type, and the privacy checks that matter most.

1. Benefits Eligibility Checks

Public agencies often share data to verify that a person qualifies for a benefit without asking them to send the same paperwork twice. In most cases, that means matching records that already exist, not gathering new forms.

For example, USAC shares data with HUD and CMS, and the Lifeline National Verifier uses links to state and federal databases to confirm eligibility for broadband benefits.

The CMPPA sets the rules for electronic record matching in benefit checks and requires a risk review before agencies connect data systems. In practice, agencies handle this through MOUs, CMAs, and interconnection security agreements. On paper, that sounds straightforward. But these rules only hold up when agencies keep a tight grip on who can access the data and how long they keep it.

Agencies are also using cross-enrollment. If someone already qualifies for Medicaid, that decision can automatically certify them for a related program. At the same time, many agencies are moving toward API-based eligibility checks.

A few controls sit at the center of this work:

• data minimization
• role-based access
• retention limits
• applicant notice

Those controls set the baseline for the next use case, where shared data is used to detect fraud instead of confirm eligibility.

2. Fraud Detection and Prevention

Fraud review uses cross-agency matching to catch duplicate enrollments, identity mismatches, and improper payments. It relies on the same core matching approach used for eligibility checks, but the goal here is different: finding conflicts, duplicates, and signs that something is off.

This kind of data sharing can help agencies spot improper payments earlier. Federal, state, and local agencies - including HUD, CMS, SSA, WIC, and IG offices - may exchange records such as SSNs, names, participation records, and eligibility determinations from programs like Medicaid and Federal Public Housing Assistance.

The main legal basis is the Computer Matching and Privacy Protection Act (CMPPA). As New America notes:

"Currently, under the CMPPA, matching electronic records for benefit administration requires agencies to assess the risk of data linkage and develop procedures to protect the data."

That point matters. A false match can interrupt benefits for the wrong person, which is no small thing. So agencies need careful review before they act on a match. They also set up these exchanges through MOUs, CMAs, and Interconnection Security Agreements.

The Evidence Act starts from the position that federal data can be shared between agencies unless a law or regulation blocks it.

Some agencies are also testing privacy-focused tools to compare records without exposing raw data. These include secure multiparty computation and private set intersection. Zero-knowledge proofs are also being tested to verify identity or eligibility without revealing the personal data underneath.

Even with those tools, agencies still need to keep data use tight. That means:

• using only the minimum data needed
• limiting access to approved staff
• setting clear retention rules

In practice, fraud review is a higher-risk form of benefits matching, so access and retention controls need to be stricter.

3. Health and Social Care Coordination

This use case is different from fraud review. Here, the goal is to help agencies work together when the same person needs help from more than one program.

For example, someone might need Medicaid, housing help, and nutrition support at the same time. To make that work, agencies share status data so services line up instead of working in silos.

The agencies involved can include CMS for Medicaid enrollment and eligibility, HUD for Federal Public Housing Assistance, the CDC for standardized health reporting, and WIC agencies for nutrition program participation. By sharing eligibility and participation data, these agencies help people get coordinated support.

These exchanges usually rely on the Evidence Act, MOUs, CMAs, and security agreements.

Because this data is especially sensitive, the rules are tighter than in lower-risk exchanges. Health data has stricter confidentiality requirements, so agencies should share only the minimum data needed for the program purpose and keep tight limits on both access and retention.

4. Licensing and Permitting Oversight

Unlike health coordination, licensing data is usually administrative. Even so, the review process can still involve cross-agency checks.

When a business license or building permit needs verification across agencies, public bodies share only the records needed to finish the review. Those records usually include administrative data, prior eligibility decisions, and program participation status.

These exchanges usually rely on agency authority, the Evidence Act, and formal agreements such as MOUs, CMAs, or ISAs. The hard part is fragmented legal authority spread across different statutes and rules. That patchwork can slow reviews and lead to inconsistent drafting.

Standardized MOU language helps cut those delays. Models like the National Information Exchange Model can also make the process more consistent across agencies.

The main risk is function creep. In plain English, that means data gets used for something beyond the licensing or permitting purpose that justified the original sharing.

Even with standardized agreements in place, the privacy baseline stays strict. Agencies should:

• limit access
• restrict use to the licensing purpose
• delete records when review and appeal periods end

5. Education Support and Safeguarding

Education data sharing needs a tighter set of guardrails than standard licensing oversight because it involves minors. In most cases, schools and districts share data to confirm whether a child qualifies for school readiness or student support programs. The aim is simple: verify eligibility without exposing more student information than necessary. The records shared often include eligibility data from Medicaid, Federal Public Housing Assistance (FPHA), and WIC.

Because student records are sensitive, the legal basis for these exchanges has to be narrower than routine administrative sharing. These arrangements usually depend on MOUs, CMAs, and ISAs, and they also need to stay within FERPA and other education rules that apply.

The biggest privacy risk is over-disclosure. A close second is using the data for something beyond the student-support purpose. That’s where discipline matters. Agencies should:

• follow data minimization practices
• limit access to authorized staff
• set clear retention timelines
• inform families before sharing

The harms here aren’t abstract. They include over-sharing, stigmatization, and misuse of children’s records.

Privacy tools such as SMC and zero-knowledge proofs can help agencies confirm eligibility without handing over raw student records. That same minimization approach also applies to program monitoring, where de-identified data is often enough.

6. Program Monitoring and Evaluation

This use case is different from the earlier ones. Here, shared data is used to assess programs, not people. The focus is on program-level performance, not individual eligibility.

In practice, public bodies and service providers share program and service delivery data to see what’s working, what isn’t, and where future services or policies may need to shift.

Under the Evidence Act, federal data is presumed shareable for statistical and evaluation purposes unless a law specifically prohibits it. That said, sharing is allowed for evaluation only when the use stays within the authorized statistical purpose.

The legal basis usually comes from program statutes and formal agency authority. Agencies should also put formal data-sharing agreements in place.

Before any sharing happens, agencies should make sure the disclosure is necessary, proportionate to the privacy impact, and covered by a formal data-sharing agreement. If de-identified data is enough, use that. Share only the minimum needed. And when tools such as SMC and PSI can avoid exposing individual records, agencies should use them.

These same controls also guide how agencies handle privacy across the remaining use cases.

Privacy Checks That Apply Across All 6 Use Cases

Across all six use cases, the same baseline controls keep data sharing lawful and limited. These checks apply every time data is exchanged in this article.

First, there needs to be a clear legal basis. And any shared data has to stay inside the authorized program purpose. In plain English: data shared for one program use can't later be used for something else.

The baseline controls are straightforward:

• Data minimization
• Role-based access
• Audit logs
• Retention limits

Use these as the starting point for every exchange.

Some exchanges need tighter guardrails. That includes cases involving Medicaid, WIC, or student records. In those situations, agencies may need privacy-preserving tools that confirm eligibility without exposing raw records. Examples include Secure Multiparty Computation (SMC), Private Set Intersection (PSI), and Zero-Knowledge Proofs.

Each exchange should also be spelled out in a formal agreement before any data is shared. That agreement should define scope, security, retention, and accountability.

These controls should be built into the documentation and governance steps below.

Documentation and Governance Steps to Put in Place

These privacy checks only matter if agencies put them in writing before any sharing starts.

Before data moves, agencies should document the exchange in an MOU or CMA, along with an ISA for each use case. Under the CMPPA, agencies should also document the risks tied to linking data and the controls used to protect it.

The next step is to spell out exactly what data is needed and why. That means documenting why each data element is required, whether de-identified or aggregate data could do the job instead, and how the exchange will be disclosed. Agencies should also use data dictionaries so definitions match across systems and teams.

Agencies also need to publish the required System of Records Notice (SORN), plus a plain-language notice that explains what is collected, why it is collected, and how it is shared.

Once the exchange goes live, governance can’t go on autopilot. Agencies still need to keep access controls in place, train staff to apply the rules the same way every time, and address caution about sharing.

That keeps each exchange narrow in scope, easy to trace, and easier to defend.

Conclusion

Across all six use cases, lawful public-sector data sharing comes down to fit: the purpose, legal authority, and level of risk all need to match the specific exchange. Some cases carry more risk than others, especially when health or social services data is involved.

Safe, effective sharing starts with a clear public purpose and a narrow data scope. It also requires strong documentation and privacy-by-design safeguards. Share only what is needed, and put formal agreements in place before any transfer. Across benefits, fraud, health, licensing, education, and evaluation, the same rule holds: share narrowly, document fully, and limit use.

In federal settings, the Evidence Act often supports sharing unless another law or regulation sets a limit.

Privacy-preserving tools like secure multiparty computation and zero-knowledge proofs can cut exposure in high-risk exchanges. That balance helps protect both program performance and public trust.

Done well, public data sharing improves service delivery and reduces misuse. Done poorly, it erodes trust.

FAQs

How do agencies decide if data sharing is legally allowed?

Agencies first make sure they have the legal authority to share data. That authority may come from specific laws, common law, or statutory gateways.

From there, they look at four main points: why the data is being shared, what information is involved, who will receive it, and how it will be transferred. They also review privacy laws, governance, legal review, and, in some cases, consent.

Which use cases carry the highest privacy risk?

Use cases that combine personally identifiable information (PII) bring the highest privacy risk. The danger gets even bigger with the mosaic effect, where separate datasets seem harmless on their own but, once combined, can reveal sensitive details.

Projects that involve health, disability, or income data may require a Data Protection Impact Assessment (DPIA). Centralized data models can add another layer of risk too, because they concentrate both privacy and cybersecurity exposure in one place. If a breach happens, the damage can spread much farther and hit much harder.

What should a data-sharing agreement include?

A data-sharing agreement should spell out what data will be shared, who is sharing it, how the data will move, and why the sharing is happening.

It also needs to set the legal basis for the arrangement, name any relevant subpopulations, and lay out the rules for use, maintenance, retention, and protection.

Just as important, it should cover privacy safeguards. That includes data minimization, limits on onward disclosure, consent models, audit requirements, and access controls.

Related Blog Posts

• Checklist for Data Sharing Agreement Compliance
• Data Sharing Agreement Template Guide
• State Privacy Compliance Tools for Public Sector
• Public Sector Privacy Notice Checklist