Context
When someone is injured at work, their employer reports the incident to the workers’ compensation insurer by filing a claim on the injured worker’s behalf. The First Report of Injury (FROI) is the form used to collect the information needed to start that claim.
At the workers’ compensation insurer where I work, employers previously submitted FROI forms by downloading a fillable PDF, completing it, and uploading it through the web portal. They could also submit the information by phone, email, or in person, which created multiple intake paths for the same process.
Problems
For employers:
- The one-page PDF contained 70+ fields with limited room for guidance.
- All fields were shown regardless of whether they were relevant to the specific injury or claim.
- Submitters could not attach supporting documents with the form.
For the claims processing team:
- Handwritten or scanned forms were often difficult to read.
- Staff manually re-entered submission data into the claims system.
- Submissions arrived through multiple channels, making intake harder to track.
My Role
As the sole engineer, I owned the project end to end. I partnered with business stakeholders to gather business requirements, designed and implemented the user experience and technical solution, performed QA testing, and coordinated production release.
Constraints
The post-submission workflow could not be changed, meaning the digital form needed to be sent to the document ingestion system as a PDF. The digital form must be available to both authenticated and unauthenticated policyholders.
Approach
To reduce cognitive load, I converted the single-page PDF into a multi-step online form and grouped fields by context. I added conditional logic so users only saw relevant fields, clear required-field indicators, and both client-side and server-side validation to provide immediate feedback and improve data integrity. For the UI, I prioritized responsive design, because policyholders ranged from office workers on desktops to field supervisors on phones. Additionally, submitters could attach documents with their submission to provide further information regarding their claim.
The online form supported both authenticated and unauthenticated user submissions. Authenticated users got the benefit of pre-populated policyholder data and could save their progress, while anonymous access supported first-time visitors and policyholders who did not want to create a portal account.
Because the existing document ingestion system expected PDFs, the application generated a populated PDF after submission and sent it through the existing pipeline. This kept downstream systems unchanged and limited the project scope. Alongside the PDF, the application generated an XML file mapped to the claims system schema. Once ingested, the XML auto-populated fields in the internal claims system, eliminating manual data entry for digitally submitted forms.
Tech stack
.NET Framework, ASP.NET Razor views, C#, Data Annotations, Vue.js 2, T-SQL, SQL Server, ActiveReports 11
Outcome
Annual online submissions increased from approximately 1,600 to more than 8,000. The increase was not driven by an increase in total claims filed, but by consolidating submissions that previously arrived through phone, email, in-person, and PDF upload channels.
For digitally submitted forms, the claims processing team no longer needed to manually re-enter FROI data into the internal claims system. Required fields, validation, and document attachments also reduced follow-up for missing or unclear information, allowing claim setup to begin sooner.
What I’d Do Differently
Although the original solution used semantic HTML, I would now take a more rigorous accessibility-first approach. I would validate the experience against WCAG criteria, test keyboard-only navigation and screen reader behavior, improve focus management between form steps, and ensure validation errors are announced clearly to assistive technologies.