The TPA Technology Stack: What Vendors Claim vs. What Actually Runs

The vendor presentation shows seven modules connected by clean arrows: claims adjudication, eligibility management, stop loss coordination, employer reporting, member portal, broker dashboard, analytics. The arrows imply real-time data flow. The interface looks modern. The demo runs smoothly. The slide deck describes an integrated platform built for the modern self-funded market.

What actually runs is something different. The claims engine was built in the late 1990s or early 2000s, configured for standard fee-schedule adjudication, and ported to a web interface sometime after 2010. The eligibility system came with a book of business the TPA acquired in 2015. The member portal was built by a web development contractor who understood front-end design but not benefits administration. The reporting module produces PDF files from a data warehouse that refreshes on a 30-day lag. The broker dashboard is a login that displays the same PDF reports the employer receives. The analytics capability is a set of canned queries that a data analyst runs manually when someone requests them.

KLAS Research, which evaluates healthcare technology vendors through direct client feedback, has repeatedly noted that payer core administrative processing platforms carry some of the lowest average performance scores of any segment they measure. The 2024 KLAS Claims and Administration Platforms vendor guide observed that many products in this market are widely perceived as outdated, complex, and low-performing. That assessment describes the large health plan market. The mid-market TPA space, where budgets are smaller and vendor options narrower, runs technology that is a generation behind what KLAS even evaluates.

The Claims Engine: The Oldest Component in the Stack

#

The claims adjudication engine is typically the most mature and the most legacy component in a TPA’s technology stack. For mid-market TPAs, the engine is often a product from vendors like Cognizant’s TriZetto QicLink (built specifically for TPAs), PLEXIS Healthcare Systems, VBA Software, HealthAxis, or a proprietary system built in-house decades ago. The larger platforms, TriZetto QNXT and TriZetto Facets, serve health plans processing millions of claims annually but carry price points and implementation timelines that place them beyond reach for a TPA administering 50,000 to 200,000 covered lives.

The claims engine handles standard commercial claims processing adequately. It applies plan design rules, calculates cost-sharing, reprices against fee schedules, and produces explanation-of-benefits documents. Auto-adjudication rates for well-configured systems reach 85% to 97%, depending on plan complexity and data quality. Healthcare Finance News has cited 85% as the threshold for efficient auto-adjudication. HealthEdge, a next-generation CAPS vendor, reports that its clients regularly achieve 90% to 97% first-pass auto-adjudication with at least 99% accuracy. Those numbers represent the upper bound. Many mid-market TPAs operate well below that range, with auto-adjudication rates in the 70% to 80% range for small group plans because small group plan designs produce proportionally more exceptions than large group designs.

The problems emerge when the claims engine encounters anything outside standard fee-schedule adjudication. Reference-based pricing, where the plan pays a percentage of the Medicare allowable rate rather than a network-contracted rate, requires pricing logic that was not part of the original data model for most legacy engines. The engine was designed around the assumption that every procedure code maps to a single contracted rate from a single network. When the pricing model is 150% of Medicare, the engine must calculate the Medicare rate for that procedure code, that provider location, and that date of service, then apply the plan’s multiplier. Some legacy engines handle this through bolt-on modules or custom coding. Others handle it through manual repricing outside the engine, which defeats the purpose of automated adjudication.

Bundled payment arrangements create a similar problem. When a hip replacement is reimbursed as a single episode rather than as separate charges for the surgeon, the anesthesiologist, the facility, the implant, and the post-acute rehabilitation, the claims engine must recognize that multiple claims belong to a single episode and apply a single bundled price. Most legacy engines process claims individually. Episode recognition requires logic that sits outside the engine’s original architecture.

Real-time cost management routing, where the system identifies a cost management opportunity at the point of adjudication and routes it to the appropriate program, requires the engine to process the claim, run a decision model, and return a routing recommendation before the adjudication is complete. Legacy engines are batch-oriented. They process claims in queues, not in real time. The cost management strategies described in Series 10, from MSK pathway routing to maternity risk identification, require a claims intelligence layer that most legacy engines were never designed to support.

The Eligibility System: Where Small Group Breaks the Model

#

Eligibility management is the most common daily failure point in TPA operations. The eligibility system manages who is enrolled, in what plan, with what coverage tier, effective as of what date, and with what dependent coverage. For a 500-person employer with stable employment, the eligibility system handles the standard case without difficulty: new hire, add to plan, assign coverage, generate ID card.

For a TPA serving 300 to 500 small employers with an average of 12 employees each, the eligibility system handles thousands of exception cases annually. The employee who starts on the 15th of the month and whose coverage is effective on the first of the following month, but whose employer’s plan document says coverage is effective on the date of hire. The dependent child who turns 26 mid-month and whose coverage must terminate at the end of that month under ACA rules. The COBRA qualifying event triggered by a termination that occurs during the employer’s open enrollment period, requiring simultaneous processing of the termination, the COBRA offer, and the open enrollment change for the employee’s spouse who remains employed by a different division of the same company.

Each of these exceptions requires manual intervention in most eligibility systems. The system was designed for the standard enrollment transaction. Exceptions, which in small group administration constitute a significant share of all transactions, route to a benefits administrator who opens a ticket, makes a manual adjustment, and documents the change. In a TPA serving 5,000 covered lives across 400 small groups, manual eligibility adjustments consume substantial staff time every month. The eligibility system is technically functional. It is operationally expensive because the exception volume exceeds what the system was designed to handle without human intervention.

The downstream consequences are specific. An eligibility error propagates through the claims engine, stop loss reporting, member portal display, and ID card production. A member whose eligibility is entered with the wrong effective date may have claims denied at the point of service. A terminated employee whose coverage is not properly ended may have claims paid after termination, creating an overpayment the plan may never recover. The stop loss carrier may deny reimbursement for claims paid on behalf of an ineligible member, shifting the financial exposure back to the employer.

Stop Loss Coordination: The Spreadsheet Problem

#

Stop loss coordination tracks individual member claims accumulation against specific attachment points and total plan claims against the aggregate threshold. When a member’s claims approach or breach the specific attachment point, the TPA prepares and submits a claim to the stop loss carrier for reimbursement. When aggregate claims approach the aggregate corridor, the TPA files for aggregate reimbursement.

In many TPA technology stacks, stop loss coordination is not integrated into the claims engine. It operates as a separate tracking system, sometimes a standalone application, sometimes a spreadsheet maintained by a stop loss coordinator. The coordinator reviews high-dollar claims manually, identifies claims approaching attachment points, and prepares submission packages for the carrier. The submission process involves assembling claim documents, clinical records, and supporting documentation in the format the stop loss carrier requires.

Real-time stop loss tracking, where the claims engine knows at the point of adjudication whether a claim will breach the specific attachment point, is rare in mid-market TPA stacks. The stop loss accumulation data refreshes nightly or weekly, meaning the TPA’s stop loss position is always at least 24 hours stale. For a member whose claims are accumulating rapidly due to a hospitalization or surgical episode, the lag means the TPA may not identify the stop loss breach until days after the triggering claims were adjudicated. The delay does not change the financial outcome, because stop loss carriers reimburse based on incurred claims regardless of when the TPA identifies the breach. But the delay affects the TPA’s cash flow visibility and the employer’s understanding of their plan’s financial position.

Employer Reporting: 60 to 90 Days Behind the Data

#

Employer reporting produces monthly or quarterly reports showing claims experience, surplus or deficit position, utilization trends, and plan performance. The reporting architecture in most TPA stacks follows a pattern: claims data is extracted from the claims engine, transformed into a reporting database, and used to generate PDF reports or static dashboards.

The reporting lag is typically 60 to 90 days. An employer reviewing their January report in March or April is seeing data that is two to three months old. The data is retrospective: what happened, not what is happening. The employer learns in Q2 that their Q4 claims spiked, but cannot act on that information for Q4. The report tells the employer that their plan ran a deficit last quarter. It does not tell the employer which members are currently accumulating high-cost claims, which providers are billing at above-market rates, or which pharmacy costs are trending upward this month.

The gap between retrospective PDF reporting and real-time dashboards is the gap between financial awareness and financial management. The employer who sees claims data in real time can intervene: engage a care navigator for a member with escalating costs, steer a scheduled procedure to a lower-cost facility, adjust a pharmacy formulary before the next quarter’s spend is locked in. The employer who sees claims data 90 days after the fact can observe what happened but cannot change it.

The Integration Points: Where Data Transfer Fails

#

The individual components of the TPA technology stack are not the primary problem. The claims engine processes claims. The eligibility system tracks enrollment. The reporting module produces reports. Each component does what it was built to do with reasonable adequacy.

The problem is the connections between them. Each component uses a different data model, a different update frequency, and a different integration capability. The claims engine connects to the eligibility system through a nightly batch file transfer. An eligibility change entered at 2 PM is not reflected in the claims engine until the following morning. A member who is terminated at noon may have claims adjudicated that afternoon against eligibility data that still shows active coverage.

The claims engine connects to stop loss tracking through a manual or semi-automated process. The stop loss tracking system connects to employer reporting through a batch extraction that introduces additional lag. The eligibility system connects to the member portal on a schedule that may range from real time to weekly batch, meaning a member who checks their portal may see stale information about their coverage status, deductible accumulation, or claims history.

Each integration point is a place where data can be lost, delayed, or corrupted. The manual workarounds that bridge these gaps are understood by specific team members but rarely documented. The benefits administrator who runs the Friday reconciliation between the eligibility system and the claims engine knows the procedure from experience, not from a manual. When that administrator leaves, the workaround is at risk. The system does not fail immediately. It fails quietly, producing small errors that accumulate until someone notices a pattern.

Why This Is Architecture, Not Quality

#

The TPA did not choose this architecture deliberately. It inherited the architecture through decades of vendor selection under constraint, system acquisitions that came with books of business, and configuration decisions made by teams solving immediate problems without designing for the long term. The claims engine was the best available option when it was selected in 2005. The eligibility system came with an employer block the TPA acquired in 2017. The reporting module was built to address a specific broker request in 2019. The member portal was added to satisfy RFP requirements in 2021.

The 2024 Gartner CIO and Technology Executive Survey found that 59% of healthcare payer CIOs identified CAPS modernization as a critical investment priority. Bain and Company’s 2024 healthcare IT spending research found that more than 65% of payers cite legacy technology as a key operational problem, noting that aging infrastructure limits scalability and flexibility while imposing significant maintenance costs. Those findings describe the large health plan market. Mid-market TPAs face the same architectural constraints with a fraction of the budget. A health plan covering two million members can fund a multi-year CAPS migration to HealthEdge or a next-generation platform. A TPA covering 50,000 lives across 400 small employers cannot.

The workarounds that keep the system running are load-bearing. The nightly batch file that synchronizes eligibility with claims. The manual stop loss tracking process. The Friday reconciliation. The custom data extract that feeds employer reporting. Each workaround solves a specific integration failure. Removing any workaround without replacing the underlying integration risks operational failure. Adding a new capability, whether cost management routing, predictive analytics, or member navigation, requires integrating it into this architecture, which means adding more workarounds on top of existing workarounds.

The technology stack is not underperforming. It is overperforming relative to its architectural limitations. The people who operate it have built a functioning system from components that were never designed to work together. But the architecture prevents the capabilities the market increasingly requires: real-time claims intelligence, predictive identification of high-cost members, integrated cost management, and the member technology that Series 12’s AI-augmented workforce expects. Understanding what actually runs is the prerequisite for understanding what needs to change.