Introduction: The Most Expensive Assumption in This Category
One assumption costs more than any other in this category. Those states are broadly similar and can be handled by configuration. A workers comp claims technology consultants earn their fee largely by testing it.
It is an easy assumption to make. The claim lifecycle looks the same everywhere: injury, report, determination, benefits, treatment, resolution. The differences appear to be parameters.
They are not. Benefit calculation methods differ structurally, not just in rate. Filing triggers differ in what counts as an event. Fee schedules differ in construction. Dispute processes differ in kind. And EDI implementations differ even between states on the same release. Sound claims platform development starts from that variation rather than discovering it later.
A platform built on the assumption of similarity works acceptably for the first few states. Then it accumulates conditional logic until each new state is a development project rather than a configuration exercise. At that point, what was supposed to enable growth constrains it. The same applies to client and injured worker portal development, where access rules and disclosures also vary by state.
Scoping exists largely to test that assumption before it is built in.
This article covers what goes wrong, what scoping examines, and how to read the answer.
Pre-build scoping is the decision layer of the full custom claims platform development guide.
What Goes Wrong Without Scoping
- Jurisdiction implemented as conditional logic. It works for three states and becomes unmaintainable at fifteen. Correcting it means rebuilding the calculation and filing layers.
- Rules without effective dating. A claim from two years ago recalculated under this year’s rates produces wrong numbers. A fee schedule applied by payment date rather than service date pays incorrectly. Retrofitting temporal versioning touches everything.
- EDI built against the standard rather than against implementations. Filings are rejected on elements the standard treats as optional and the state requires. And acknowledgment handling built as an afterthought means nobody knows it is happening.
- Migration scoped as a data transfer. Open claims arriving without reserve history, filing position, or diary state produce immediate compliance failures, and they lose the records an audit examines.
- Reserve controls are treated as workflow. Change history, authority levels, and review cycles are adequacy controls with financial and regulatory consequences. An audit trail cannot be retrofitted for the period before it existed.
- The build-versus-buy comparison was never properly made, because nobody costed the permanent jurisdictional content function.
What Scoping Before Coding Actually Means
A paid, time-boxed engagement, typically four to six weeks in this category. That is longer than most, because the jurisdictional analysis takes real work. It ends in documented findings and a costed recommendation, not a proposal to build.
It should be contracted separately from any development. A partner whose fee depends on winning the build has an incentive to recommend building.
Who participates: an executive with authority, the claims leadership, the compliance officer, and a senior adjuster who handles multi-state claims. The EDI coordinator, if the organization has one, and finance for the reserve and reporting requirements.
The senior adjuster’s participation matters more than it sounds. They know which states behave differently and why. They know which requirements the current system handles badly, and where the workarounds are. The workarounds are the requirements nobody wrote down.
The core of the work is a structured comparison across the actual jurisdiction footprint. That is domain analysis rather than technical assessment.
And the output belongs to the organization.
What Scoping Examines
The Jurisdiction Footprint and Its Variation
Which states, at what volume, and how they differ structurally rather than parametrically. The output should identify which states are genuinely hard and why, because those determine the engine’s design and a disproportionate share of the cost. Averaging effort across states is the mistake this analysis exists to prevent.
The EDI Position, Measured
Not what the organization believes its filing compliance to be, but what it actually is. Filings submitted, acknowledged, rejected, and never corrected, by state and by age. This frequently produces a finding worth acting on immediately, independent of any software decision. Administrators regularly discover their real filing position is materially worse than reported.
Reserve Practice
How reserves are set, reviewed, and changed today. Whether change history exists, whether authority levels are enforced, and whether development patterns suggest adequacy issues. A financial and regulatory finding as much as a software one.
Migration Reality
What the incumbent system will release, whether reserve history, filing position, and diary state can transfer intact, and what closed claim retention requires.
The Content Function
Who would maintain jurisdictional rules after go-live, with what capacity and what expertise. The answer frequently decides the whole question.
The regulatory scope scoping is set out in State EDI Reporting Mandates, State Medical Fee Schedules, CMS Section 111 Mandatory Insurer Reporting and NAIC Data Security Rules.
What Scoping Should Produce
A jurisdictional variation analysis identifying structural differences across the footprint, naming the hard states and explaining their complexity.
An EDI compliance position measured from actual submission and acknowledgment data, with immediate remediation recommendations.
A reserve practice assessment covering controls, history, and development patterns.
A rule engine design recommendation covering how rules should be structured, versioned, and applied. This is the single most consequential technical output.
A migration assessment covering open claim state and closed claim retention.
A content function plan naming who maintains jurisdictional rules, at what cost, and with what expertise.
A defined minimum version with its state selection justified and its exclusions written down.
And a costed comparison of at least three paths. Configure an established platform. Retain a core and build the client-facing and analytical layers. Or go full custom. Each should show the annual content maintenance burden separately, because that is the line that decides it.
The staged budget scoping produces is detailed in Custom Workers Compensation Claims Administration Platform Pricing in 2026.
Reading the Answer: Configure, Layer, or Build
Configure when an established claims system handles the footprint, and the frustration is with implementation rather than capability. For most administrators, this is correct, and the jurisdictional content burden alone justifies it.
Layer when the core system works and the gap is client-facing or analytical. Portals, client reporting, data and analysis, or workflow the packaged product handles rigidly. Building only those against a retained core avoids taking on the content function, which is the commitment that never ends. This is the answer for a substantial share of administrators, and the one least often priced.
Build when scale makes licensing material, when the organization’s structure genuinely cannot be expressed in existing products, or when the platform is a product the organization intends to sell rather than a tool it uses.
One consideration is specific to this line. Whatever is built must be kept current across every state, every year. An organization without a durable plan and budget for that should weigh the layer option heavily. That layer is also the natural home for mobile app development aimed at injured workers and field case managers, since those apps can run against the retained core rather than replace it.
Red Flags in the Conversation
- A fixed price before jurisdictional analysis
- States priced at an average
- Jurisdiction described as configuration without a rule engine design
- EDI described as a file format
- Acknowledgment handling not mentioned
- Effective dating absent from the data model discussion
- Migration priced as a transfer
- The content maintenance function absent from running costs
- The layer option never priced
And the ones that should end the conversation:
- Any proposal for scoring that predicts denial likelihood or litigation outcome for use in handling
- Any suggestion that AI could determine compensability or set reserves
- Any reporting design presenting denial or closure rates as adjuster performance
- Any return-to-work feature built around a days-away target
The strongest positive signal is a partner who asks which of your states are the difficult ones, and why.
Final Thoughts
Administrators who scope before coding test the assumption that costs the most, that states are broadly similar. They either design an engine that survives a national footprint, or they discover that the content maintenance burden is one they would rather a vendor carry. Both outcomes are worth the engagement, and the measured EDI position that comes out of it is usually worth acting on regardless. NewAgeSysIT runs scoping engagements that end in findings, not a proposal to build.
If you are weighing a custom claims platform against the system you run today, a structured scoping engagement that starts with your actual jurisdictional variation turns the decision into an evidence-based one. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.
