What brokers should watch in claims data sharing

Employers are asking harder questions of their health plan data than they did a few years ago, but each innovative use of data comes with increased regulatory complexity. 

Today, employers that sponsor self-insured plans want claims analytics to evaluate mental health parity, identify cost drivers, improve plan design, measure vendor performance, and support navigation and care management strategies. At the same time, service providers increasingly want broader access to claims data so they can power dashboards, stratify populations, target outreach and demonstrate value.

None of that is inherently problematic. In many cases, better use of data can help plans improve participant outcomes in addition to helping plans run more efficiently. But the push for deeper analytics often creates a quiet tension between what is useful from a business perspective and what is permissible from a HIPAA and privacy perspective. Navigating that tension is where brokers and advisers can add real value.

The problem usually does not start with a bad actor. It starts with what presents as a helpful request. A vendor that wants a more complete claims feed to refine its reporting. A navigation vendor asks for data that includes behavioral health information so it can better target members. A broker wants to combine reporting across multiple vendors to help the employer see the full picture. An employer asks whether one vendor can simply share data with another to avoid duplicative file feeds. 

These requests may sound operationally sensible, but each also raises basic questions that too often get skipped: Why is the data needed, who really needs access, how much data is actually necessary and what contractual limits apply once the data leaves the plan's hands?

For brokers and advisers, the first point to keep in mind is that HIPAA does not simply allow broad sharing because the end goal is worthwhile. Even where a use or disclosure is permitted, the plan still needs to think about the minimum necessary standard. That is where many arrangements start to drift. Data requests that begin as targeted and defensible can quickly expand into full claims feeds, broader identifiers, longer retention periods and downstream sharing that no one fully mapped at the outset.

That makes the contracting process critically important. Brokers who serve as Business Associates should not treat their business associate agreements (BAAs) as boilerplate or assume the vendor's standard language adequately protects the plan. The BAA, along with any data-sharing addenda that is required by the relations, should do more than set out basic HIPAA compliance. It should clearly define what the vendor is allowed to do with the data, and just as importantly, what it is not allowed to do.

For employer-sponsored plans, purpose limitations are one of the most important protections. If a vendor is receiving data to perform a specific service, the agreement should say so in a way that is concrete. "Providing analytics" is too vague. "Producing plan-level utilization and cost reports to support plan administration and vendor performance review" is better. 

Clear purpose language helps prevent function creep where data provided for one reason gradually gets used for unrelated benchmarking, product development, AI training or cross-selling activities. Brokers should push for language that limits use of the data to the services actually being purchased and prohibits use for the vendor's independent commercial purposes unless that use has been specifically vetted and authorized.

The same goes for the minimum necessary principle. It is easy for vendors to ask for the broadest possible data set on the theory that more data leads to better insights. Brokers should slow down that conversation. Does the vendor need identifiable claims data or would a more limited file work? Does it need diagnosis information at the individual level, or only aggregated reporting? Does it need full dates, member IDs and dependent data, or can some fields be masked or omitted? These are not just technical questions; they go directly to whether the plan is exercising appropriate discipline over sensitive information. 

Subcontractor controls are another area where brokers should be more demanding. Many vendors rely on downstream service providers for hosting, analytics, outreach, data enrichment or other support functions. If the primary vendor receives patient data, but half the vendor's work is subcontracted, the plan should have appropriate downstream controls in place. 

Contracts should require the vendor to flow down equivalent privacy and security obligations to subcontractors, remain responsible for their compliance, disclose the categories of downstream recipients involved in servicing the account and indemnify the plan for subcontractor breaches. A promise that subcontractors will be handled "consistent with applicable law" is often not enough.

Security terms also deserve more attention than they sometimes get during procurement. A plan sponsor may focus heavily on fees, performance guarantees and implementation timelines, while privacy and security language, often overlooked as boilerplate, is resolved late and quickly. To mitigate risk, brokers should encourage clients to look for specific commitments around encryption, access controls, incident response, audit rights and timelines for breach notification. The more sensitive the data set, the less comfortable plan sponsors and brokers should be with generic assurances.

Return and destruction provisions matter, too – particularly when employers are changing vendors or layering new solutions on top of old ones since claims data can linger. Contracts should say when data must be returned or destroyed, what exceptions apply, what certification the vendor must provide and the controls that apply to any data stored in backup or cloud solutions (if it cannot be purged). Without those provisions, legacy data can remain dispersed across vendors long after the original purpose has ended.

Some of the most common trouble spots arise around de-identification and cross-vendor sharing. Employers often hear that de-identified data is a simple solution. However, brokers should be cautious about treating that as a panacea, particularly as it is a carefully regulated process and generally involves stripping personal health information of meaningful information. Whether data is actually de-identified in a compliant way, the receiving party can re-identify it and the practical context makes re-identification more likely all deserve real scrutiny. 

Similarly, cross-vendor sharing may sound efficient, but it needs to be executed in a compliant way. One vendor should not become a clearinghouse for another vendor's services without a clear legal and contractual basis, a defined purpose and a careful review of whether the data elements involved must be shared.

This is also an area where litigation, regulatory enforcement actions and reputational exposure can outpace regulatory enforcement. Participants may not know the details of a BAA, but they do notice when highly sensitive health information seems to circulate more broadly than expected. Even where a sharing arrangement was intended to improve care or reduce cost, it can look very different in hindsight if a dispute, data incident or vendor misstep brings it to light.

For benefit brokers and advisers, the practical takeaway is simple: treat data-sharing requests as a risk-allocation exercise, not just an operational convenience. Ask why the data is needed, narrow the scope to what is truly necessary, confirm who will receive it and make sure the contract reflects those answers with real specificity. In an environment where everyone wants richer data, the broker's role is not to say no to analytics. It is to make sure the client gets the insight it wants without quietly expanding the plan's privacy and litigation risk along the way.