Context & Problem
I joined Optum as a TDP intern during the Summer of 2026, as part of a team with three other interns. Over the next 10 weeks, we would join a broader team and be tasked with a problem in automation, where we would be responsible for the end-to-end design and development of a solution.
Our first two weeks of the internship revolved primarily around communicating with stakeholders to understand in-depth the problem at hand, and using insights from them to brainstorm plausible solutions.
From these meetings, we learned about the logistics behind the old 835 remediation process. An 835 file contains remittance advice to reconcile claims in order for the healthcare providers to post. In particular, the stakeholders explained that there are two teams involved in the old process: the engineers/”835 team”, who traditionally are business analysts, and the EDI team. Below is the flow for the original 835 remediation process:
On average, the EDI team receives roughly 560 835s per week. Of those, about 30 fail. The amount of time it takes to fix just one 835 can vary significantly depending on the complexity of the error, ranging from 3 minutes to 20 minutes, without consideration of the wait time for emails. Despite a 5% fail rate, this translates to many hours each week spent dedicated just to finding and suggesting errors for 835s.
The time demand for this current process is critical because major delays in remediating 835 files mean the corresponding payment claims do not get reconciled by the healthcare provider and posted efficiently. With an automated, centralized platform, engineers not only will save hours each week from finding and sending remediations, but healthcare payments can be made much sooner.
The Solution Workflow
One of the biggest takeaways that I got out of meeting with stakeholders was the need for a centralized platform where users can see everything and work efficiently. With these insights, and after brainstorming, I came up with an idea involving an AI-powered web application, where the AI would be responsible for grouping erroneous 835s by error and coming up with intelligent and accurate suggestions. The web application would include a way for users to view all erroneous 835s and their individual contents, contain a visually intuitive way to handle AI suggestions, and a history of how previous 835s have been handled.
1
2
3
The user must go through the standard Optum authentication process through Microsoft Azure Authentication. Once they are authorized to access the application, they are presented with a dashboard, with three major sections: firstly, a weekly metrics section. Then, the actual list of all failed 835 claims. Finally, a section that includes a processed 835 and log history.
For the editor, I designed and implemented a three-panel UI where AI suggestions would get rendered through an inline-diff system, taking inspiration from how Visual Studio Code/Cursor visually handles Git conflict resolutions. The leftmost panel would list all erroneous 835s for users to click and view the contents and suggestions of each, the middle serving as the file editor + where AI suggestions render as a diff and users have options to approve or deny each suggestion within the editor itself. The rightmost panel would display what the resulting file would look like after users approve suggestions, so that they get a clearer view of the 835 without the diff display.
For each AI suggestion that is rendered in the 835 editor panel, there are two immediate options for the user: one to approve, and the other to deny. If the user approves, the suggestion gets applied and overrides the original line, which is then reflected in the resulting panel.