Business Associate Agreement Checklist for Social Determinants of Health Referral Platforms

A social determinants of health (SDOH) referral platform may handle sensitive details about a person’s housing, food access, transportation, or other needs alongside health information. This checklist helps you assess when a business associate agreement (BAA) is needed and what it should address. It is a practical guide, not a substitute for legal review of your specific data flows and applicable state or federal laws.

When does an SDOH referral platform need a business associate agreement?

Start by asking whose work the platform performs and what information it handles. An organization is generally a business associate when it performs certain functions or services on behalf of a HIPAA covered entity—and, in doing so, creates, receives, maintains, or transmits protected health information (PHI). A platform that manages referrals for a health care provider or health plan and handles PHI for that purpose will generally need a BAA with that covered entity. The arrangement’s actual activities matter more than the platform’s name or the parties’ labels. See HHS guidance on business associates.

Map the data flow before signing: identify who sends referral information, who controls the platform, who can access it, and which organizations receive information. Include electronic protected health information (ePHI) that the platform stores or transmits, not just data displayed to users. A vendor may still be a business associate when it maintains ePHI without viewing it.

Do not assume that every organization receiving a referral needs its own BAA. A community organization’s role and the legal basis for the disclosure matter. The last section explains how to distinguish a platform’s business associate relationship from a community organization’s role as a referral recipient.

Define permitted uses and disclosures of protected health information

Describe the platform’s permitted and required uses and disclosures of PHI in terms that match its real functions. For example, the BAA may permit the platform to receive, route, track, and report on referrals for specified care coordination or service connection purposes. It should prohibit other uses or disclosures unless the BAA or law permits them.

Specify who may access referral records, which recipient organizations may receive them, and what information may be shared at each referral stage. Address whether the platform may use PHI for its own administration or legal responsibilities, and whether it may perform data aggregation for the covered entity. Do not treat general product improvement, marketing, or unrelated analytics as automatically permitted; name and limit any intended use in the agreement, and confirm it is legally allowed.

Include the minimum necessary standard where it applies. HIPAA generally requires reasonable efforts to limit PHI use, disclosure, and requests to what is needed for the purpose. The standard has exceptions, including disclosures to a health care provider for treatment, so do not write the agreement as though it applies identically to every referral. See HHS guidance on the minimum necessary requirement.

Specify safeguards and breach reporting requirements

Require safeguards appropriate to the information and the platform’s risks. For ePHI, the HIPAA Security Rule requires applicable administrative, physical, and technical safeguards. The agreement and related security terms can specify how the platform will manage access, workforce permissions, security incidents, backups, and the protection of data in transit and at rest. HIPAA’s Security Rule is risk-based; avoid treating any particular product or security tool as universally required. See the HHS summary of the HIPAA Security Rule.

Require the platform to report impermissible uses or disclosures, security incidents, and breaches of unsecured PHI to the covered entity. Set a contractual reporting deadline that gives the covered entity time to investigate and meet its own obligations; a BAA can require notice sooner than HIPAA’s outside limit. Under the Breach Notification Rule, a business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery of a breach of unsecured PHI. See HHS breach notification guidance.

Agree on the information a report should include, such as what happened, when it was discovered, what data and individuals may be affected, and the steps taken to investigate and mitigate the incident. Clarify who will coordinate notices to affected individuals, HHS, or the media when required; the covered entity retains applicable notification duties even when it delegates notice tasks.

Address individual access requests and other privacy rights

Set out how the platform will help the covered entity respond to individuals’ rights under the Privacy Rule. The BAA must require the business associate to make PHI available as needed for the covered entity to provide access and to support amendments and accounting of disclosures, as applicable. If the platform maintains information in a designated record set for the covered entity, that information may be subject to an individual’s access rights. See HHS guidance on individuals’ right of access.

Define how the platform will route requests it receives directly, preserve relevant records, and provide information in a usable format within timelines set by the covered entity. If the platform performs a covered entity’s Privacy Rule duties, specify which duties it performs and require it to follow the applicable requirements. Include cooperation with corrections, restrictions, or other requests where relevant to the platform’s role and the covered entity’s obligations.

Require subcontractor compliance before sharing PHI

Identify the types of subcontractors that may access PHI, such as cloud hosting, messaging, analytics, or technical support providers. Before a business associate subcontractor receives PHI to perform work for the covered entity, the platform must have a written business associate subcontractor agreement that imposes the applicable restrictions, conditions, and safeguards. The same principle applies down the chain when a subcontractor engages another subcontractor to handle PHI. See HHS business associate guidance.

Require the platform to maintain a current list of subcontractors, notify the covered entity of material changes, and ensure subcontractor agreements address security and incident reporting. Specify what happens if a subcontractor refuses required terms or experiences a breach. A BAA between the covered entity and platform does not replace the platform’s obligation to secure appropriate agreements with its own subcontractors.

Set oversight, termination, and PHI disposition terms

Require the business associate to make relevant internal practices, books, and records available to HHS for determining the covered entity’s compliance. The parties may also agree on additional oversight, such as security documentation, attestations, or audit rights, based on their risk assessment. HIPAA does not generally require a covered entity to routinely monitor every method a business associate uses, but it must take reasonable steps to address a known material breach or violation. If those steps do not resolve the issue, the covered entity must terminate the agreement if feasible or report the problem to HHS when termination is not feasible. See HHS guidance on responding to business associate violations.

Specify how either party may terminate the BAA, including for material breach, and plan for continuity of referral operations and access to PHI during a transition. At termination, the BAA must require the platform to return or destroy PHI if feasible. If return or destruction is infeasible, require the platform to continue protecting the information and limit further uses and disclosures to the purposes that make disposition infeasible. Address retained backups, copies, and subcontractor-held PHI. See HHS guidance on PHI retention after services end.

Define referral data scope and agreements with community organizations

List the data elements the platform may collect, store, or transmit—for example, identifiers, contact details, referral reason, service requested, referral status, and outcome. Identify which fields are necessary for each purpose, who may see them, how long they are retained, and whether they may be used for reporting. Consider whether a community organization needs a person’s clinical details at all, or whether a narrower referral message will suffice.

A community organization does not need a BAA solely because it receives referral data. A BAA is generally appropriate when that organization performs a function or service on behalf of a covered entity or business associate involving PHI. By contrast, a community organization receiving information as an independent referral recipient is not automatically a business associate just because it receives the data. The covered entity still needs a permitted basis for the disclosure, such as an applicable treatment-related basis or the individual’s authorization. HHS explains that certain disclosures to social service organizations may be permitted in specified circumstances, including some care coordination situations; the details matter. See HHS guidance on disclosures to social service organizations.

Use an appropriate agreement with referral partners to document their role, permitted data use, security expectations, retention, onward disclosures, and incident contacts. That agreement may be a BAA when the partner is acting as a business associate or subcontractor; otherwise, use terms suited to the partner’s actual role and the applicable legal basis for the disclosure. Consider additional protections required by state law or other federal rules for sensitive information.

In short, a sound checklist ties the BAA to the platform’s actual role, limits referral PHI to defined purposes, sets clear safeguards and reporting terms, and accounts for each downstream recipient. Confirm each community organization’s role and the legal basis for every disclosure before information is sent.

FAQs

When is an SDOH referral platform a business associate?

Generally, when it performs a function or service on behalf of a HIPAA covered entity and, as part of that work, creates, receives, maintains, or transmits PHI. Whether a BAA is needed depends on the parties’ actual activities and data flows, not simply on the platform’s label.

What uses and disclosures of PHI should a BAA permit?

It should permit only the uses and disclosures needed for the platform’s defined services, such as routing and tracking referrals, and any other specifically identified purposes allowed by HIPAA. It should describe required uses, prohibit unauthorized uses and disclosures, and apply the minimum necessary standard where applicable.

Does a community organization receiving referral data need to sign a BAA?

Not automatically. A community organization generally needs a BAA when it performs a function or service on behalf of a covered entity or business associate involving PHI. An independent organization receiving information as a referral recipient may have a different role, but the covered entity still needs a valid basis for disclosing the information.

What should happen to PHI when a BAA ends?

The BAA must require the business associate to return or destroy PHI if feasible. If that is infeasible, the business associate must continue to protect the retained information and restrict further use or disclosure to the purposes that make return or destruction infeasible. The agreement should also address copies, backups, and subcontractor-held data.