The Domain Knowledge Problem: Why Technology People Who Do Not Understand Benefits Build the Wrong Systems

Frederick Brooks identified the core problem in 1975. In The Mythical Man-Month, he argued that the essential difficulty of software is not writing code. It is understanding the problem domain well enough to specify what the code should do. The conceptual integrity of a system depends on the architects understanding the domain at a level of specificity that requirements documents rarely capture. Brooks was writing about operating systems for mainframes. The observation applies with equal force to TPA technology fifty years later.

TPA technology fails because it is built at the boundary between two knowledge domains that rarely overlap. Software engineers understand data models, system architecture, API design, and scalable infrastructure. Benefits administrators understand eligibility rules, claims adjudication logic, stop loss coordination, COBRA administration, and the exception patterns that dominate small group plan management. The systems that result from this divide reflect what each side thinks the other needs rather than what the domain actually requires.

The Technology Side of the Gap

#

Software engineers build systems from data models and functional requirements. When the requirements are written by someone who does not understand the operational specifics of benefits administration, the resulting system reflects a simplified version of the domain. The simplification creates specific, predictable failure patterns.

Eligibility systems designed by technology teams without deep benefits knowledge build around a clean enrollment model: employee starts, employee enrolls, employee selects coverage tier, employee receives ID card. The data model handles this standard transaction well. What it does not handle is the exception volume that defines small group administration. The employee whose hire date falls on the 15th but whose plan document specifies first-of-the-month effective dates. The dependent who turns 26 on March 12 and whose coverage must continue through the end of the month under ACA rules, but whose employer’s plan document specifies termination on the date of the birthday, creating a conflict the system was never designed to adjudicate. The COBRA qualifying event triggered by a reduction in hours rather than a termination, which produces a different set of qualified beneficiaries and a different maximum coverage period than the termination workflow.

Each of these scenarios is common in small group administration. A TPA serving 400 employers with an average of 12 employees processes hundreds of these exceptions annually. The eligibility system handles the standard case and routes every exception to manual processing. The manual processing is where the benefits knowledge lives: in the heads of the administrators who have handled these situations before and know which plan document provisions apply, which regulatory requirements override plan language, and which carrier notifications must be generated. The system that was supposed to reduce manual work instead creates a parallel manual workflow for every non-standard transaction.

Claims engines exhibit a different version of the same problem. The technology team builds an adjudication engine that processes claims against a fee schedule: procedure code maps to contracted rate, cost-sharing rules apply, payment calculates. This handles standard network claims for plans with conventional fee-schedule pricing. It does not handle reference-based pricing, where the payment amount is calculated as a percentage of the Medicare allowable rate for that procedure code, that provider location, and that date of service. The original data model assumed a single contracted rate per procedure per provider. Reference-based pricing requires the system to query a Medicare fee schedule database, identify the correct geographic adjustment, apply the plan’s multiplier, and calculate the patient responsibility, all before the adjudication is complete. Most legacy claims engines were not designed for this calculation because the technology team that built the engine did not know reference-based pricing existed or did not understand why it required a fundamentally different data model.

Reporting modules present a third failure pattern. The technology team builds a reporting system that extracts claims data, aggregates it by service category, and produces summary statistics: total claims paid, average cost per member, claims by category. The report answers the question the technology team thought the employer was asking: “How much did we spend?” The question the employer actually needs answered is different: “Which members are driving cost increases? Which providers are billing above market rates? Is my plan trending toward a deficit this quarter, and if so, what can I do about it?” Answering those questions requires real-time data, member-level detail, provider-level analysis, and trend comparisons. The retrospective summary report, delivered 60 to 90 days after the data period, cannot answer any of them.

The Benefits Administration Side of the Gap

#

The mirror problem is equally damaging. Benefits administrators who specify system requirements base those specifications on their current workflows. If the current workflow involves printing a paper form, faxing it to the stop loss carrier, and filing the confirmation, the system requirement becomes “digitize the form, send it electronically, and store the confirmation.” This is workflow digitization, not workflow redesign.

The benefits administrator who writes the requirement often does not understand what the technology could do if the problem were specified differently. The system could automatically identify claims approaching the stop loss attachment point and prepare the submission before the human reviewer needs to act. The system could route a member to a lower-cost facility in real time based on the procedure scheduled, the member’s geographic location, and the facility’s quality and cost data. The system could predict which members are likely to incur high-cost claims next quarter based on utilization patterns and clinical indicators. These capabilities are technically feasible. They are not specified because the person writing the requirements does not know they are possible. The technology team does not suggest them because the team does not understand the benefits administration context well enough to identify where the opportunities exist.

A study published in the Journal of the American Medical Informatics Association found substantial barriers to developing health IT tools for care coordination, identifying the lack of knowledge of users’ needs and the lack of standardized roles and protocols as primary obstacles. The researchers concluded that development teams need immersive exposure to the operational environments their systems serve, not just requirements documents produced at a distance from the work. That finding applies directly to TPA technology development. The requirements document captures what the administrator says they need. Observation captures what they actually do, including the workarounds that reveal where the current system fails and where the opportunities for genuine automation exist.

The System Failures That Result

#

The eligibility exception problem compounds at scale. A TPA serving 5,000 covered lives across 400 small employers processes eligibility exceptions constantly. The employee who is eligible for coverage but has not yet enrolled because the employer’s onboarding process is delayed. The terminated employee whose COBRA election period has not yet expired, creating a liminal coverage state the system cannot represent cleanly. The employee who transfers between two divisions of the same employer, each with a different plan design, requiring a simultaneous termination and enrollment that the system treats as two separate transactions with a coverage gap between them.

Each exception requires a manual workaround. Each manual workaround consumes staff time. The cumulative staff time consumed by eligibility exceptions at a mid-market TPA is significant. The system was designed to reduce administrative labor. Instead, it has redistributed administrative labor from routine transactions (which the system handles) to exception transactions (which the system cannot handle), while adding the overhead of maintaining the system itself. The net effect on total administrative cost may be neutral or negative.

The claims intelligence problem is structural. The claims engine processes claims after the service has been rendered and the bill has been submitted. By the time the claim is adjudicated, the opportunity to steer the member to a lower-cost provider has passed. The MRI has been performed at the hospital outpatient department at $2,800 rather than at the independent imaging center at $450. The surgery has been scheduled at the high-cost facility rather than the ambulatory surgery center. The specialty drug has been filled at the retail pharmacy rather than through the specialty pharmacy with manufacturer rebate access.

Real-time claims intelligence, the capability to identify a member who is scheduled for a procedure and route them to the optimal cost-quality option before the procedure occurs, requires a different architectural approach than retrospective claims adjudication. It requires the system to receive prior authorization requests or scheduling data, match them against provider cost and quality databases, generate a routing recommendation, and deliver it to a care navigator or directly to the member. This is a fundamentally different system than a claims processing engine. Building it requires architects who understand both the clinical workflow that produces the prior authorization and the technology architecture that can process it in real time. Those architects are rare because the knowledge domains rarely overlap.

The reporting latency problem affects the employer relationship directly. An employer who receives a report in March showing that their January claims spiked cannot act on that information for January. The report is forensic, not operational. It tells the employer what happened but not what to do about what is happening now. A real-time dashboard showing current-period claims experience, members approaching high-cost thresholds, and utilization trends would transform the employer from a passive observer of plan costs to an active participant in cost management. Building that dashboard requires architects who understand both the data pipeline from the claims engine (technology domain) and what the employer needs to see and do with the information (benefits domain).

What Closing the Gap Would Require

#

The gap closes only when individuals hold both knowledge domains simultaneously. System architects who understand benefits administration at the operational level, not from a requirements document, and software engineering at the systems architecture level, not at the configuration level. These people exist. They are rare. They are the competitive advantage of any TPA or technology company that employs them.

Hiring for one domain and training for the other is the practical approach. A software engineer who spends six months working in a TPA’s operations department, processing eligibility exceptions, handling COBRA qualifying events, and reconciling stop loss submissions, understands the domain at a level that no requirements document can convey. A benefits administrator who learns data modeling, API design, and system architecture concepts can specify requirements that reflect what the technology can actually do rather than what the current workflow happens to be.

Development methodology matters. Systems validated by watching the actual benefits administration workflows, not by reviewing requirements documents, produce different designs. The requirements document says “the system must process eligibility changes.” Observation reveals that 30% of eligibility changes involve exceptions that the standard process cannot handle, that the exceptions follow identifiable patterns (mid-month effective dates, COBRA during open enrollment, dependent aging), and that each pattern requires specific logic that the requirements document did not specify.

Domain-specific data models are the technical expression of domain knowledge. Rather than forcing benefits administration data into a CRM schema (LFP-13.02) or a generic relational database, the data model should reflect the structure of the domain. An eligibility data model that natively handles concurrent coverage states, COBRA continuation periods, mid-month effective dates, and dependent aging. A claims data model that supports real-time intelligence rather than batch adjudication. A stop loss tracking model that integrates with the claims engine rather than operating as a separate system or spreadsheet.

The domain knowledge problem is the root cause of the technology failures described in LFP-13.01 and 13.02. The claims engine that cannot handle reference-based pricing was built by engineers who did not understand the pricing model. The Salesforce implementation that cannot manage a plan lifecycle was configured by consultants who understood CRM but not benefits. The eligibility system that routes every exception to manual processing was designed from a requirements document that described the standard case and omitted the exceptions. Solving the technology problem without solving the domain knowledge problem produces new systems with the same failures in newer interfaces.