Claims Data Ownership: Who Has It, Who Locks It, and Why It Matters

Claims data is the most valuable asset a level funded plan generates. It reveals which members are driving costs, which providers are billing above market rates, which pharmacy categories are trending upward, which diagnoses are producing high-cost episodes, and what the plan’s financial trajectory looks like for the next 12 months. Every cost management strategy in Series 10 depends on claims data. Every product feature in Series 15 requires it. The employer who controls their claims data can manage their plan. The employer whose claims data is locked in a proprietary system is paying for transparency they cannot access.

Who owns the data is a legal question with a clear answer. Who controls the data is an operational question with a complicated one.

Ownership vs. Control

#

Under ERISA, the plan sponsor, which is the employer, generally owns the plan’s data. The employer established the plan. The employer funds it. The claims data generated by the plan belongs to the plan and, by extension, to the employer as plan sponsor and fiduciary. The employer has the right to access, review, and use the claims data generated by its plan for purposes of plan administration, fiduciary oversight, and cost management.

The Consolidated Appropriations Act of 2021 reinforced this right through the gag clause prohibition in Section 201. The CAA prohibits group health plans from entering into agreements with providers, TPAs, or other service providers that restrict the disclosure of provider-specific cost or quality information, restrict electronic access to de-identified claims and encounter data, or restrict the sharing of such information with business associates. Plans must submit an annual Gag Clause Prohibition Compliance Attestation to CMS confirming their contracts do not contain prohibited gag clauses. The first attestation was due December 31, 2023. Subsequent attestations are due annually, with the next deadline on December 31, 2025.

The January 2025 FAQ guidance from the Departments of Labor, HHS, and Treasury clarified that the gag clause prohibition extends to downstream agreements. If a TPA’s subcontract with a network vendor or PBM restricts the plan’s access to data, that constitutes a prohibited gag clause even though the plan sponsor is not a direct party to the subcontract. Plans are expected to include provisions in their direct contracts with TPAs requiring that the TPA not enter into downstream agreements that would restrict data access.

The law is clear. The operational reality is different. The employer owns the data, but the data sits in the TPA’s claims engine, in the stop loss carrier’s underwriting files, in the PBM’s pharmacy claims system, and in the network vendor’s provider pricing database. Each entity stores the data in its own system, in its own format, with its own access controls. Ownership and control are not the same thing.

The Contractual and Technical Lock-In Mechanisms

#

Contractual restrictions on data access take several forms. Some TPA contracts limit data export to summary-level reports, providing the employer with aggregate claims totals and utilization statistics but not the underlying claims-level detail needed for provider-specific cost analysis or predictive modeling. Some contracts charge fees for detailed data extraction, pricing the data pull at rates that discourage frequent requests. Some contracts impose delays on data transfer at termination, requiring 60 to 90 days to produce a complete data file after the plan year ends, by which time the employer’s new TPA has already needed the data for months.

The CAA’s gag clause provisions address some of these restrictions, but enforcement is still developing. The attestation requirement creates an annual compliance checkpoint, but the consequences for non-compliance are not yet clearly defined. The January 2025 FAQ noted that plans failing to submit attestations may face enforcement action, but no specific penalties have been outlined. The practical effect is that many TPA contracts signed before 2021 have not been updated to remove restrictive data provisions, and many employers do not know they have the right to demand access.

Technical restrictions compound the contractual ones. The claims engine stores data in a proprietary format optimized for the vendor’s adjudication logic, not for external analysis. Export capabilities may be limited to PDF reports or fixed-format flat files that lose the relational structure of the underlying data. A claims data extract delivered as a CSV file may contain procedure codes, diagnosis codes, and payment amounts, but may lack the provider contract identifiers, network discount details, and stop loss accumulation data needed for comprehensive cost analysis.

API access to the underlying claims data is available from some vendors but not from others. Modern platforms like HealthEdge’s HealthRules Payer offer real-time API-based data access through their HealthRules Connector integration framework. Legacy claims engines may not offer API access at all, restricting the employer and the TPA to batch data extracts that reflect the system’s state at the time of extraction rather than the current state.

Vendor lock-in operates through data fragmentation. The medical claims data sits in the TPA’s claims engine. The pharmacy claims data sits in the PBM’s system. The stop loss claims data, specifically the claims that breached attachment points and were submitted for reimbursement, sits with the stop loss carrier. The provider pricing data, the contracted rates and discount schedules, sits with the network vendor. Assembling a complete picture of the plan’s cost experience requires data from four or five separate systems in four or five different formats. The employer who wants to analyze their total cost of care must first solve a data integration problem that requires technical expertise most small employers do not possess and that most brokers cannot provide.

Why Data Ownership Determines Capability

#

Every cost management strategy in Series 10 requires access to clean, structured, timely claims data at the member level and the provider level.

Identifying high-cost members for care navigation (LFP-10.02) requires member-level claims data with diagnosis codes, procedure codes, and chronological sequencing sufficient to identify utilization patterns that predict future high-cost episodes. If the claims data is locked in a system that exports only aggregate summaries, the care navigator cannot identify which members need intervention.

Routing procedures to lower-cost facilities (LFP-10.06) requires provider-level cost data showing what different facilities charge for the same procedure, adjusted for quality metrics. If the provider pricing data is locked in the network vendor’s system and unavailable to the TPA’s analytics platform, the routing recommendation cannot be generated.

Analyzing pharmacy spend for formulary optimization (LFP-10.09) requires pharmacy claims data at the drug level, showing fill frequency, cost per fill, therapeutic class, and prescribing provider. If the PBM delivers only summary-level pharmacy reports rather than drug-level claims data, formulary optimization analysis is impossible.

Screening for social determinants of health signals (LFP-10.04) requires claims data integrated with demographic and geographic data to identify members whose utilization patterns suggest barriers to care access. If the claims data cannot be exported and linked with external datasets, SDOH screening operates in a vacuum.

The product architecture described in Series 15 depends on the same data foundation. The predictive analytics in LFP-15.03 require longitudinal claims data with sufficient depth for model training. The employer reporting capabilities in LFP-15.05 require real-time claims data accessible through APIs. The broker intelligence portal in LFP-15.06 requires comparative claims data across the TPA’s book of business. The cost management routing described in LFP-15.04 requires claims data integrated with provider cost and quality databases. None of these features can be built if the claims data is locked in a legacy system with batch export and proprietary formats.

Data ownership is not an administrative issue. It is the strategic control point. The TPA that holds its claims data in a modern, accessible, interoperable format can build the capabilities the market requires. The TPA whose claims data is locked in a legacy vendor’s proprietary system has a ceiling on its capability that no amount of product strategy or AI marketing can lift.

The Regulatory Trajectory

#

The regulatory environment is moving toward data accessibility on multiple fronts.

The CAA gag clause prohibition, already law since December 2020, prohibits the contractual restrictions that have historically limited employer access to claims data. The annual attestation requirement creates an enforcement mechanism, even if penalties remain undefined. The January 2025 FAQ guidance extending the prohibition to downstream agreements closed a significant loophole that allowed TPA subcontracts to restrict data access even when the primary TPA contract did not.

CMS price transparency rules require group health plans to make available machine-readable files showing in-network negotiated rates and out-of-network allowed amounts. For self-funded plans, this means the TPA must produce and publish pricing data that was previously proprietary. Compliance has been uneven, but the regulatory direction is clear.

HL7 FHIR (Fast Healthcare Interoperability Resources) is the emerging technical standard for healthcare data exchange. FHIR provides a modern, API-based framework for accessing clinical and administrative data in a structured, interoperable format. CMS has mandated FHIR-based APIs for Medicare Advantage and Medicaid plans, with compliance timelines extending through 2026. The self-funded market is not directly subject to these CMS mandates, but the technology standard is migrating across the industry. TPAs and claims vendors that build FHIR-compatible APIs position themselves for an interoperability future. Those that do not will face increasing friction as the rest of the healthcare data ecosystem moves to the standard.

CAQH CORE operating rules establish technical standards for administrative data exchange, including eligibility verification, claims submission, and claims payment. These standards reduce the variability in data formats across trading partners. X12 EDI transaction standards, specifically the 837 (claims), 835 (remittance), and 834 (enrollment) transactions, provide the technical backbone for electronic data exchange. These standards are mature and widely adopted, but they address data transmission format rather than data access rights.

The trajectory across all of these regulatory and standards initiatives points in the same direction: toward data accessibility, interoperability, and portability. TPAs and vendors that build toward this trajectory now will be positioned when enforcement tightens. Those that rely on data lock-in as a competitive strategy are building on a regulatory foundation that is eroding.

The Strategic Question

#

Claims data ownership is the question that determines whether a TPA is a claims processor or a cost management platform. The claims processor receives claims, adjudicates them against plan terms, pays the provider, and reports the results. The data is a byproduct of the processing function. The cost management platform uses the data as its primary asset: analyzing it for cost patterns, routing care based on it, predicting future costs from it, and reporting it in real time to employers and brokers who use it to make decisions.

The employer who owns the data but cannot access it in a usable format has ownership without control. The TPA that holds the data in a modern, interoperable format but does not use it for cost management has control without strategy. The combination that produces value is accessible data applied to cost management with the analytical capability to generate actionable intelligence.

The TPA’s technology investment priority should reflect this reality. Investing in a better member app before solving the data architecture problem puts the interface ahead of the infrastructure. Investing in AI capability before ensuring data quality produces models trained on unreliable inputs. The data foundation comes first. The applications that use the data come second. Series 15 specifies the product architecture that depends on this foundation. The foundation is claims data that the TPA controls in an accessible, interoperable, analytically useful format.