Introduction: Fifty Systems Wearing One Name
Workers’ compensation is often spoken about as a line of insurance. It is more accurate to describe it as fifty-odd separate statutory systems sharing one name. Any workers comp claims software development project encounters that reality during the first week of scoping. That reality shapes claims platform development from the first architectural decision.
Each state decides how benefits are calculated and at what rate. States also determine waiting periods, retroactive payments, required forms, and filing deadlines. Medical charge limits, treatment guidelines, impairment ratings, settlements, and electronic reporting also vary by state.
A third-party administrator handling claims in thirty states is running thirty regulatory programs simultaneously, on one platform, with one team. That is the defining engineering problem of this category. It is also why claims systems built for other insurance lines often fail here. Jurisdiction is not a field on a claim record. It is the architecture.
Employers, injured workers, and treating providers also need appropriate access to claim information. That puts client and injured worker portal development in scope from the beginning.
Two other factors shape the platform just as much. Reserves are professional judgments about what claims will ultimately cost, made with incomplete information. Those estimates drive the client’s financial picture and the excess carrier’s exposure. Reserve adequacy is a discipline that software can either support or quietly undermine.
At the center of every claim is a person injured at work and currently not earning. Every determination affects that person, shaping what the platform should and should not optimize.
This guide covers claims workflows, reserves, return-to-work, integrations, EDI compliance, 2026 costs, and what scoping should settle first.
The Claim, and the Three Parties in It
A workers’ compensation claim has a structure unlike most insurance claims. Three parties have standing in it, and their interests do not align neatly.
The injured worker needs medical treatment and wage replacement, and the claim needs to be accepted. The employer, self-insured program, or carrier bears the cost, wants the worker recovered and back at work, and wants claims that are not compensable identified as such. The adjuster sits between them, owing duties to both and statutory obligations to the state, with timeframes attached to nearly everything.
A third-party administrator adds a fourth relationship, contractual obligations to the client covering service standards, reporting, and settlement authority. None of it is a conflict for software to resolve. It is the structure of the job, and a platform’s task is to support the adjuster in doing it properly. Weighting the work in any direction is not the software’s role.
The claim record, therefore, includes more parties than most. The worker, the employer and the specific location, the policy or self-insured program, and the treating providers. Attorneys where they appear, the state agency, and vendors handling bill review, pharmacy, and case management.
And the file is a legal record. Notes, diary entries, correspondence, and decisions may be produced in a dispute, read by a judge, or examined in an audit. That is worth designing for from the start.
The complete module and workflow set is covered in Workers Comp Claims Software Features: Core Modules and Daily Workflows.
The Jurisdiction Engine
If a platform gets one thing right, it should be this. Everything else depends on it, and retrofitting it later is not realistic.
A jurisdiction engine holds the rules that govern a claim in each state. How the average weekly wage is calculated and over what period. The benefit rates with their minimums and maximums, the waiting period, and any retroactive provision. The forms required at each stage and the deadlines attached to them. The fee schedule governing medical charges, the treatment guidelines, and the utilization review requirements. The impairment rating method, the settlement mechanisms, and the EDI implementation the state requires.
Those rules also change. Benefit rates are typically adjusted annually, fee schedules revised, and statutes amended. A platform must apply the rules in force on the relevant date rather than the current ones. The engine is therefore versioned by both time and state.
The consequences of getting this wrong are not cosmetic. An indemnity payment on the wrong basis underpays or overpays an injured worker. A form filed late incurs a penalty. A bill paid above the fee schedule is money the client will not recover.
The design implication is simple to state and expensive to ignore. Build the rules as data, with an engine that applies them, rather than as logic branching on a state code. Adding the thirty-first state should be a configuration exercise, not a development project.
The EDI, bill review, pharmacy, and return-to-work mechanics are covered in FROI and SROI EDI Release 3.1 Filing, Medical Bill Review and PPO Repricing, Pharmacy Benefit Feeds and Return-to-Work Task Automation.
Indemnity: Paying People Who Are Not Working
Wage replacement is the part of a claim the injured worker experiences most directly. Getting it right matters to someone paying a mortgage while unable to work.
The calculation starts with the average weekly wage, determined by a state-specific method over a state-specific period. Rules cover workers who had not been employed long enough, who held concurrent employment, or whose earnings varied. From there, the benefit rate follows the state’s formula, subject to its minimum and maximum limits. Those limits are typically adjusted annually and applied by date of injury rather than date of payment.
Benefit types differ. They include total and partial disability during recovery, permanent partial and permanent total disability where impairment remains, and death benefits with their own dependency rules. Each has its own calculation, duration limits, and interaction with the others.
Payments are processed on a schedule, and late payments incur penalties in most states. Offsets and coordination apply in some circumstances, and overpayment recovery has its own rules.
For the platform, that means calculation driven by the jurisdiction engine rather than by a spreadsheet. It requires a payment schedule that runs reliably and a complete history of what was paid and on what basis. It must also let an adjuster explain a figure to a worker who asks, because they will. An adjuster who cannot answer erodes trust in a system the worker did not choose to be in.
Reserves, Which Are a Judgment
A case reserve is the adjuster’s estimate of what the claim will ultimately cost. It covers indemnity, medical, expense, and legal, set with incomplete information and revised as the picture develops.
It carries weight beyond the file. Reserves drive the client’s loss picture and its cost of risk. They determine when an excess or reinsurance carrier must be notified. They inform actuarial analysis and, for self-insured programs, regulatory security requirements. In aggregate, they are how an organization understands what it owes.
That makes reserve adequacy a genuine professional discipline rather than an accounting exercise.
Two failure patterns are recognized in this industry and worth naming. Reserves set below the honest estimate make current results look better and defer the problem. Raising a reserve gradually, in small increments rather than to the correct figure when information changes, obscures the true development. It also delays the subsequent notifications. Neither is a software failure, but software can enable or discourage both.
What a platform should provide: reserve categories maintained separately. A complete change history recording who changed what, when, by how much, and why. Authority levels requiring approval above defined thresholds. Review cycles that prompt reassessment at defined points and on defined events. And excess notification triggered when a reserve reaches the attachment point.
What it should never provide: reserve targets, reporting that presents low reserves favorably, or any pressure toward a number other than the adjuster’s honest estimate.
Medical Management
Medical costs account for the majority of workers’ compensation spending in most programs. Managing them is where legitimate cost control lives.
Treatment authorization runs against the state’s guidelines and utilization review requirements. Each sets timeframes for decisions and a defined process for when treatment is disputed. Getting these timeframes wrong is a compliance failure. For the worker, it is also a delay in care.
Bill review applies the state fee schedule and identifies charges outside it, followed by network repricing where a preferred provider arrangement applies. Most administrators outsource this, which makes it an integration rather than a build.
Pharmacy runs through workers’ compensation specialist managers with their own formularies and controls. It is also where opioid oversight concentrates.
Nurse case management belongs on claims that warrant it, coordinating care and communicating with treating providers. Independent medical examinations and peer review apply where permitted by the state, each with its own procedural requirements.
Then there is the provider network, where a state’s rules on directing care differ substantially. Some states let the employer direct treatment, some let the worker choose, and several fall in between.
The framing throughout is worth holding onto. This is where cost is managed legitimately, through clinical appropriateness and correct pricing, rather than through the claim decision.
Return to Work, Which Is a Recovery Outcome
Return to work is the outcome the whole system is theoretically organized around, and it is genuinely good for injured workers. People who return to appropriate work recover better, stay connected to their workplace, and are less likely to become permanently disconnected from employment.
It also reduces indemnity costs substantially. The clinical and financial interests genuinely align here in a way they do not everywhere.
That alignment is worth stating plainly and then respecting. It is easy to build software that treats cost savings as the point and recovery as a side effect.
The workflow holds the treating physician’s restrictions as they actually are, and the employer’s available modified or transitional work described honestly. Then the matching between them. Job descriptions need to include physical demands, so a match is real rather than notional. Communication runs across the worker, the employer, and the treating provider. Progress is tracked as restrictions change. Vocational rehabilitation also belongs here, where a return to the original employer is not possible. Mobile access matters more in this workflow than in most, bringing injured worker app development into scope alongside limited field use by nurse case managers.
What the workflow must not hold: a target for days away, pressure to place someone before restrictions permit, or reporting that presents a worker’s recovery as a metric to improve.
The distinction shows in small design choices, and it matters.
Compliance: EDI, Fee Schedules, Federal Reporting, and Data Security
Four compliance surfaces shape a claims platform, and two of them have moved recently.
State reporting obligations require electronic filing of first and subsequent reports of injury on defined triggering events. These follow an industry standard whose releases have been adopted by different states at different times. Each state publishes its own implementation guide, required elements, and edits. Penalties attach to late or inaccurate filing.
State medical fee schedules govern what may be charged and paid for treatment. They vary in structure and are revised on their own cycles, alongside treatment guidelines and utilization review requirements.
Federal mandatory insurer reporting requires responsible reporting entities to report claims involving Medicare beneficiaries. Those requirements were expanded to include set-aside information, which connects settlement practice to reporting obligation.
Insurance data security requirements, adopted by a growing number of states from a model law, reach the platform itself. They impose information security program, risk assessment, incident response, oversight, and notification obligations.
Alongside those sit third-party administrator licensing in many states and claims handling standards with timeliness and communication obligations. Statistical reporting drives employer experience rating. And privacy rules treat this line distinctively, with provisions specific to workers’ compensation that are frequently misunderstood in both directions.
This is educational content, not legal advice. Confirm the current position with counsel experienced in workers’ compensation regulation and with each state’s agency.
The full compliance guide is covered in State EDI Reporting Mandates, State Medical Fee Schedules, CMS Section 111 Mandatory Insurer Reporting and NAIC Data Security Rules.
Cost and the Staged Build Sequence
The build stages outward from the jurisdiction engine, because everything attaches to it.
Stage 1 covers the claim core and jurisdiction engine. That means the claim record with its parties, the rule engine holding state requirements as versioned data, first report of injury capture, compensability investigation and determination, notes and diary with the discipline a legal record requires, and document management. It runs roughly $130,000 to $240,000 over 8–10 months, and it is the largest and most consequential stage.
Stage 2 covers indemnity and reserves. Average weekly wage and benefit calculation driven by the engine, payment scheduling with late-payment awareness, benefit type transitions, reserve categories with change history, authority levels and review cycles, excess notification triggers, and recovery. It adds roughly $115,000 to $210,000 over 7–9 months.
Stage 3 covers medical management and EDI. Treatment authorization and utilization review with state timeframes, bill review and repricing vendor integration, pharmacy feeds, nurse case management, and first and subsequent report EDI filing per state implementation with acknowledgment handling, plus federal reporting. It adds roughly $120,000 to $225,000 over 7–9 months.
Stage 4 covers return to work, litigation, settlement, and reporting. Restrictions and job matching, litigation and hearing management, settlement, including set-aside handling, subrogation, and client, regulatory, and statistical reporting. It adds roughly $105,000 to $195,000 over 6–8 months.
A full four-stage platform lands broadly in the $470,000 to $870,000 range across 28–36 months. All figures are 2026 planning ranges, not quotes.
The MVP definition, full build pricing, drivers, and the comparison with established platforms are covered in Custom Workers Compensation Claims Administration Platform Pricing in 2026.
Final Thoughts
Administrators who build the jurisdiction engine properly end up with a platform that can add a state without a development project. Rules held as versioned data and applied by an engine, rather than logic branching on a state code, is the difference between a system that grows with the business and one that constrains it.
The same holds for the two things that sit alongside it. Reserve controls that protect adequacy and return-to-work workflows organized around genuine restrictions rather than days-away targets produce software that supports adjusters in doing the job properly.
Which matters because at the center of each of these files is someone who was hurt at work. Teams at NewAgeSysIT work with administrators on that kind of build. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.
If you are evaluating a custom claims platform, establishing your jurisdiction footprint and how the rule engine will be structured before mapping features is the decision the entire build rests on.
