Yes, community-based organizations can share and receive health-related data with healthcare and government partners, but the legal path depends entirely on who holds the data and why it’s being shared. A hospital sharing protected health information (PHI) for care coordination operates under different rules than one sharing raw clinical records for research. Get the purpose wrong on paper, and the whole agreement is exposed.
Before you sign anything, take three steps.
- Map the data flow. Write down exactly which fields move, from whom, to whom, and why. If you can’t describe it in one sentence, you’re not ready to negotiate.
- Pick the narrowest legal instrument that works. That might be a patient authorization, a data use agreement, or, in fewer cases than most CBOs assume, a business associate agreement (BAA).
- Document your safeguards before you ask for data you can’t yet protect. Minimum-necessary fields, role-based access, and a written retention schedule all need to exist on paper, not just in someone’s head.
Do not sign a BAA unless your organization can actually meet HIPAA Security Rule obligations around encryption, access logging, and workforce training. A BAA that outpaces your technical capacity creates liability, not partnership. When in doubt, push for purpose-limited language over broad access every time.
Key Takeaways
CBOs can lawfully share health data with healthcare and government partners when the agreement matches the actual data flow and stays limited to minimum-necessary fields.
| Point | Details |
|---|---|
| Match the instrument to the data | Use patient authorization or a DUA for narrow purposes; reserve BAAs for genuine business associate relationships. |
| Minimum necessary is enforceable | Show it technically through export templates, role-limited dashboards, and de-identified reporting. |
| Layer your agreements | Combine an MOU for purpose, a DSA for handling terms, and a DUL for specific data licenses. |
| Check state law separately | Federal rules like HIPAA and 42 CFR Part 2 set a floor; state statutes often add stricter requirements. |
| Document readiness before negotiating | A workflow diagram, access list, and breach playbook speed partner review more than lengthy legal memos. |
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Table of Contents
- What Federal and State Laws Govern Data Sharing Agreements for CBOs
- When Can Healthcare Partners Legally Share PHI with a CBO
- Agreement Types: MOU, DSA, DUA, DUL, and BAA Explained
- Choosing the Right Consent Model for Your CBO’s Workflow
- A Step-by-Step Checklist for Standing Up a Data Sharing Agreement
- Security Safeguards CBOs Need to Document
- Negotiation Tactics: What to Push For and What Should Stop You
- What WellCheck Has Learned From Closed-Loop Referral Deployments
- Getting Your Agreement Right the First Time
- Sources
What Federal and State Laws Govern Data Sharing Agreements for CBOs
Three federal frameworks show up most often in CBO partnerships, and knowing which one applies to your data changes everything about how you draft the agreement.
HIPAA governs PHI held by covered entities, meaning health plans, health care clearinghouses, and most providers. Most CBOs are not covered entities themselves, but they become bound by HIPAA the moment they sign a BAA or receive PHI from a covered entity for a permitted purpose. HHS guidance confirms that covered entities can disclose PHI to non-covered social service organizations for treatment purposes, provided the disclosure serves the individual’s health care and stays limited to the minimum necessary.
42 CFR Part 2 covers substance use disorder treatment records and imposes stricter consent requirements than HIPAA in most cases. If your referral network touches behavioral health or substance use services, assume Part 2 applies until a lawyer tells you otherwise. A single Part 2 violation can carry more regulatory weight than a routine HIPAA slip, so this is one area where guessing is expensive.
FERPA governs education records held by schools receiving federal funding. It surfaces less often in CBO work but matters when a partnership touches a school-based health center or youth-serving program that shares data with a district.
How do you figure out which law governs a specific data field? Ask three questions:
- Who holds the data right now, and are they a covered entity, a school, or a Part 2 program?
- Who is the data about, and does the record type (behavioral health, education, general medical) trigger a specific statute?
- What is the intended use, and does that use fall under a recognized exception (treatment, payment, health care operations)?
State law adds another layer on top of all three. Several states impose stricter consent standards than HIPAA for categories like HIV status, mental health records, or genetic information, and some states have their own comprehensive privacy statutes that apply regardless of whether a covered entity is involved. A state platform like InnovateOhio illustrates how state-led data integration efforts build their own governance layers on top of federal rules. Before you draft anything, check your state attorney general’s office or a legal aid organization for guidance specific to your jurisdiction. Federal law sets the floor, not the ceiling.
When Can Healthcare Partners Legally Share PHI with a CBO
Most CBO managers assume they need a signed authorization every time a clinic wants to share a patient’s information. That’s not accurate. HHS OCR guidance confirms that covered entities can disclose PHI for care coordination and case management without patient authorization, as long as the disclosure supports the individual’s treatment and stays within the minimum necessary standard.
Concrete examples help here. A clinic that refers a patient to a food pantry can share the patient’s name, contact information, and the specific need (food insecurity) without a signed release, because that disclosure directly supports care coordination. What the clinic should not share, without a much stronger justification, is the patient’s full diagnosis history, medication list, or unrelated visit notes. Healthit walk through similar scenarios where providers share targeted information for case management purposes rather than full records.
That’s the minimum necessary standard in practice: share the referral name and reason, not the chart. It’s the single most common mistake CBOs make when negotiating data flows. They ask for, or accept, far more than the workflow actually requires, which increases liability without adding value to the referral.
A BAA is a different animal entirely. Signing one means your organization is legally agreeing to handle PHI under the same security obligations as the covered entity itself. Before you sign, ask yourself:
- Do we have written policies governing who can access PHI and under what circumstances?
- Can we produce an access log if a partner or auditor asks for one tomorrow?
- Have staff who touch this data signed confidentiality agreements and completed training in the past year?
- Do we have a breach notification process, including who calls whom and within what timeframe?
If the answer to any of those is no, you’re not ready for a BAA, and pushing for a narrower data use agreement or a patient authorization model is the more honest path.
Pro Tip: Ask your healthcare partner whether the disclosure you’re requesting actually requires PHI at all. A surprising number of referral workflows only need a name, a contact method, and a reason code, none of which requires the clinical detail that makes a BAA necessary in the first place.
Agreement Types: MOU, DSA, DUA, DUL, and BAA Explained
Most successful cross-sector data partnerships don’t rely on a single document. They layer three instruments, each doing a different job.
- Memorandum of Understanding (MOU). This sets the purpose of the collaboration, the governance structure, and each partner’s general responsibilities. It’s not a data-handling document. Think of it as the constitution for the partnership, the thing everyone signs before anyone talks about specific data elements.
- Data Sharing Agreement (DSA). This is where the real work happens. A DSA spells out what data moves, under what conditions, with what security obligations, and who’s liable if something goes wrong. Academic governance literature on community health information exchange documents that effective DSAs define project goals, security requirements, and liability allocation explicitly, rather than leaving them implied.
- Data Use Agreement or Data Use License (DUA/DUL). This governs a specific recipient’s rights to use a defined dataset, often for a narrower or time-limited purpose than the broader DSA. Think of the DUL as a permission slip issued under the DSA’s umbrella.
Layering these three documents, MOU for purpose, DSA for handling, DUL for the specific license, gives you flexibility without renegotiating the whole relationship every time a new use case comes up. A three-tier structure like this is a recommended pattern in cross-sector data governance guidance, precisely because it separates governance decisions from operational data terms.
A BAA is a narrower, more specific instrument reserved for situations where your organization is genuinely acting as a business associate, meaning you’re creating, receiving, maintaining, or transmitting PHI on behalf of a covered entity for a function that entity would otherwise perform itself. If your role is closer to “receiving a referral and following up,” a DUA paired with a patient authorization is often the cleaner, lower-liability option.
Whichever instrument you’re reviewing, expect to see these clauses, and push back if they’re missing:
- Permitted uses. A specific list of what the data can be used for, not a general reference to “program purposes.”
- Data elements. A named list of fields, not a category description like “relevant health information.”
- Retention schedule. A defined period after which data must be deleted or de-identified.
- Security obligations. Specific technical and administrative requirements, referencing recognized standards where possible.
- Third-party limitations. Language restricting whether the data can be shared again, and with whom.
- Breach notification timing. A concrete number of days, not “promptly” or “as soon as practicable.”
Choosing the Right Consent Model for Your CBO’s Workflow
The consent question comes down to one tradeoff: how much friction do you accept in exchange for how much clarity your organization gets about what’s permitted?
Patient authorization is the most legally conservative model. The individual signs a specific document naming what will be shared, with whom, and for how long. It’s clean, but it’s also the slowest option and can create real gaps if a patient is unable or unwilling to sign at the point of referral.
Class authorizations solve some of that friction. Instead of naming a specific organization, the authorization names a recipient category, such as “social services providers assisting with housing and food security.” HHS OCR guidance confirms this approach is permissible when the authorization is specific enough about the type of recipient and purpose, even without naming the exact organization. This lets a patient authorize future disclosures within a defined scope, which matters for multi-partner referral networks where the receiving organization might change.
Treatment-based sharing requires no separate authorization at all, because it falls under HIPAA’s built-in exception for care coordination. This is the fastest path, but it only covers disclosures that genuinely support the individual’s treatment, not broader data uses like program evaluation or research.
Opt-in versus opt-out design carries real community trust implications, not just legal ones. An opt-out model, where data sharing happens by default unless the person declines, moves faster but can damage trust with populations who have reason to be cautious about how their information gets used, particularly in immigrant communities or among people with prior negative experiences with government systems. Opt-in models take longer to build participation but tend to hold up better over time because people understand what they agreed to.
- Keep a dated record of every authorization, including the exact recipient class and purpose named at the time of signing.
- Build a straightforward revocation process, and make sure front-line staff know how to walk someone through it.
- Review your consent forms annually to confirm the recipient classes and purposes still match your actual partner network.
A Step-by-Step Checklist for Standing Up a Data Sharing Agreement
Getting from “we want to share data with this partner” to a signed, working agreement usually breaks into three phases.
- Map your data flows before you talk to anyone. Write out exactly which fields would move, in which direction, and for what specific purpose. Vague purposes produce vague, risky agreements.
- Name a data steward. Someone at your organization needs to own this relationship, including who has access, who trains staff, and who responds if something goes wrong. In multi-partner networks, this role is sometimes called a backbone entity, and it’s responsible for coordinating consent, access rules, and reporting across all participants.
- Run an internal readiness check. Confirm you have basic technical safeguards, a designated point of contact for security questions, and at least one staff member trained on your data handling policies.
- Negotiate the specific terms. Nail down the exact purpose, the precise data elements (not categories), access controls, a retention schedule, and breach notification timing with a specific number of days attached.
- Pilot before you scale. Test the actual data exchange with a small number of records or a single referral pathway before turning on full volume. This is where field mapping problems surface, mismatched date formats, missing identifiers, inconsistent status codes, and it’s far cheaper to fix them at ten referrals than at ten thousand.
- Set a monitoring and reporting cadence. Decide up front how often you’ll review data quality, referral completion rates, and any access anomalies.
- Build in an annual review. Every agreement should have a scheduled review date, not just a renewal clause. Partner networks, funding requirements, and technical systems change, and the agreement should change with them.
Pro Tip: Treat the pilot phase as a negotiation tool, not just a technical test. Partners who see a clean, working pilot with narrow data elements are far more willing to sign a lean agreement than ones asked to approve a broad data exchange on paper alone.
Interoperability planning matters here too. If your organization is mapping fields across multiple partner systems, a practical adoption plan for public health data standards can help you avoid the common trap of building custom field mappings for every new partner instead of standardizing on a shared format from the start.
Security Safeguards CBOs Need to Document
Partners and auditors don’t expect a CBO to have hospital-grade IT infrastructure. They expect specific, documented controls proportional to the data involved, and they expect you to be able to produce evidence of those controls without scrambling.
On the administrative side, you need written policies describing who can access shared data and under what circumstances, a role-based access structure so not everyone on staff sees everything, and signed confidentiality agreements from every staff member who touches the data. Workforce training on data handling should happen at onboarding and at least annually after that.
On the technical side, expectations have gotten more specific. CMS guidance on data sharing agreements lays out operational security expectations for federal and state program exchanges, including encryption for data at rest and in transit, access logging so you can reconstruct who viewed what and when, and multi-factor authentication for any system holding shared data.
Demonstrating minimum necessary technically, not just in your consent language, is where a lot of CBOs fall short. It’s not enough to say you’ll only use the minimum necessary data; you need to show how your systems enforce that.
- Use export templates that only pull the fields relevant to the referral, not a full record dump.
- Build role-limited dashboards so a front-line navigator sees referral status and contact information, while a program director see aggregate outcomes.
- Generate de-identified reports for funder and board reporting whenever individual-level detail isn’t required.
A closed-loop referral system built around a narrow, well-defined field set naturally supports this kind of technical minimum necessary approach, because the workflow was never designed to hold more data than the referral requires in the first place.
Negotiation Tactics: What to Push For and What Should Stop You
Every negotiation over a data sharing agreement comes down to a handful of specific asks, and a handful of specific red flags that should make you pause.
Push for a narrow purpose clause that names the exact use case, not a broad reference to “program administration” or “quality improvement.” Ask for a field-by-field data element list rather than a category description. Negotiate a bounded retention period with a specific deletion or de-identification date attached. Insist on defined third-party restrictions that name who, if anyone, can receive the data downstream. And get a specific breach notification timeline, ideally measured in a defined number of business days, not “promptly.”
Watch for these red flags, and treat any of them as a reason to loop in legal counsel before signing:
- Broad reuse rights that let the partner use the data for purposes beyond what you originally discussed.
- One-way indemnity clauses that put all liability on your organization while shielding the partner entirely.
- Open-ended subprocessor clauses that let the partner share your data with vendors or contractors you’ve never vetted.
- Ambiguous deletion language that says data will be destroyed “as appropriate” instead of on a specific schedule.
If a partner won’t narrow the purpose clause or won’t commit to a specific data element list, that’s often a sign the underlying data flow itself hasn’t been thought through, not just the contract language. In that situation, proposing a DUA scoped to a single use case, or falling back to a patient authorization model, is frequently the faster path to a workable agreement than continuing to negotiate a broad DSA.
What WellCheck Has Learned From Closed-Loop Referral Deployments
Closed-loop referral work has a way of clarifying exactly how little data most partnerships actually need. Tracking whether a referral was accepted, delivered, and resolved typically requires a name, a contact method, a referral reason, a status code, and a resolution date, not a full clinical history. That’s a deliberately short list, and it’s one reason narrower agreements tend to move faster through legal review than broad ones.
The partner organizations that get through security review fastest usually share a few traits: a simple, documented role structure showing who can see what, basic access logging that took a day to set up rather than a quarter, and a routine cadence for follow-up reporting that already existed before the agreement was even drafted.
If you’re preparing to negotiate with a healthcare or government partner, three documents go a long way toward reassuring them before legal review even starts.
- A referral workflow diagram showing exactly which fields move at each step.
- A current access list naming who on staff can view shared data.
- A one-page breach response playbook describing who gets notified and within what timeframe.
In one rural health hub deployment with a multi-partner ecosystem area including both clinical and social services referrals, this kind of documentation supported 22,682 individuals screened, 45,458 services delivered, and a 93.9% closed-loop completion rate.¹
| Point | Details |
|---|---|
| Minimal fields work | Closed-loop referrals typically need a name, contact method, reason, status, and resolution date, not full clinical records. |
| Documentation speeds review | A workflow diagram, access list, and breach playbook reassure partners faster than lengthy legal explanations. |
¹ Rural health hub deployment with a multi-partner ecosystem area. Includes both clinical and social services referrals.
Getting Your Agreement Right the First Time
Data sharing agreements for CBOs work best when the legal instrument matches the actual data flow, narrow purposes get narrow agreements, and technical safeguards exist before any partner asks to see them.
If your organization is preparing to negotiate a data sharing agreement with a health system or government partner, the operational side matters as much as the legal language. A closed-loop referral implementation guide walks through the field mapping, access control, and reporting decisions that shape what a partner will actually accept in a DSA. WellCheck’s EquiLoop platform was built around exactly this problem: tracking referral status, follow-up, and outcomes with a defined, limited data set rather than open-ended record access, which is precisely the kind of minimum-necessary design that speeds up partner negotiations. Compliance documentation generated through a closed-loop referral platform can also give your legal reviewer something concrete to point to instead of a policy written in the abstract.
For organizations weighing how care coordination operations connect to broader partnership structures, this industry perspective on care coordination as an operational function offers useful context on how partner organizations think about referral accountability.
If you want to talk through what a data sharing agreement would look like for your specific partner network, schedule a 30-minute demo with WellCheck.
Sources
- HHS — HIPAA: Laws & Regulations
- Data governance and data sharing agreements for community-wide health information exchange — PMC
- CMS — Data sharing agreements
