OODA HealthClaims Processing Software

Designing around what could actually change in a complicated claims system

How I used contextual research to reconstruct a complicated claims-processing workflow, separate necessary complexity from constraints and workarounds, and focus the product strategy on the parts of the system we could actually improve.

Role: Senior & Lead Product Designer
Timeframe: Five Months
Collaborators: 2 PMs, 1 Design Director, Engineering
Methods: Contextual Research
Design: Systems Design, Prototyping
Outcome: Polished prototype ready for investors

03.01We didn’t know enough yet to design anything successful

I could have drawn the obvious solution—a claim header, a table of claim lines, a document panel—and made something that looked plausible. But if our model of the work was wrong, a plausible interface would only create more work later. I needed to see the claims process happening in front of me.

Before OODA, I had spent years working around medical claims at a clearinghouse, so I understood the ecosystem. Providers submit claims, payers adjudicate them, and information has to move between organizations that do not share the same technology.

That background helped me get oriented quickly, but it also made me wary of designing from domain familiarity alone. The people doing the work knew which policies mattered, what medical records were required, how facility contracts changed a decision, what history needed to be checked, when an FCR nurse could make the determination, and when a claim had to escalate to a physician.

Blue Shield gave us a workflow chart early in the project. It was one of the most complicated processes I had seen. Even so, a diagram at that level could not show most of the hands-on work required to keep a claim moving from one box to the next.

Original claims adjudication flowchart showing steps and handoffs across teams, with a callout explaining that key workflow details were still missing.

03.02I pushed to watch people actually doing the work

Before I arrived, the product strategy understandably leaned on healthcare standards such as CCDA, SNOMED, and LOINC. Those standards were important technical building blocks for describing and exchanging clinical information, but they could not tell us how a Blue Shield employee actually got a difficult claim from a provider to a final monetary decision.

I pushed for contextual inquiry. We started with remote chair-side sessions and then went onsite to Blue Cross Blue Shield in Sacramento. I asked people to show us their day, work real examples, share their screens, and say out loud what they were thinking as they moved through the process. My goal in these sessions was first to observe the work closely enough that the hidden handoffs and exceptions became visible.

That level of observation mattered because experts skip enormous pieces of their own process when they explain it to someone. It has become muscle memory. Watching them work surfaced a rule remembered from experience, a second system opened because the first one did not contain the document, a note entered twice, or a phone call that existed only because a file never arrived.

The onsite visit also changed our understanding of the users themselves. These were experienced, fast, multi-monitor desktop users working in software they had used for years. They were not beginners who needed a simplified wizard. They were experts trying to keep an enormous operational system moving as fast as possible.

Photos of the Blue Shield of California office and a research participant, documenting an onsite visit to observe claims processing and review firsthand.

03.03“Reviewing a claim” wasn’t one task, it was an in-depth process

The claim and the evidence needed to adjudicate it moved through separate systems, separate teams, and sometimes separate countries. The claim itself lived in Facets, BCBS’s core claims system. Supporting documents moved through a separate pipeline involving PCH and DocDNA.

An offshore preparation team in India pulled claim information from Facets, retrieved UBs, itemizations, and medical-record images from DocDNA, paginated and bookmarked the records, and assembled the case in ClaimLogiq so the FCR nurses — our target users — could spend their time reviewing the claim instead of preparing it.

Missing medical records exposed how fragile the system was. A missing document did not create a neat error state. It created another workflow: reports of outstanding records, faxes, phone calls, voicemails, retries, better contact information, escalation through provider-network teams, incoming paper or electronic records, scanning and indexing, another Facets task, offshore preparation, and then another trip through FCR.

Appeals added another loop. A later reviewer might need to reconstruct the evidence the previous nurse and physician had seen across the same systems because the information never ended up in one place.

The user was not merely reviewing a claim. They were constantly assembling the information required to make a decision.

ClaimLogiq claims review screen with callouts showing offshore case preparation, missing medical records, and the additional review and feedback loop created by appeals.

03.04I needed to know which parts of the mess could actually change

Once I could see the work, I started challenging the reasons behind it. It was crucial to my design work that I understood the system our product had to compete against.

Why were they scanning? Who owned that step? Why did the India team handle some importing but not all of it? What access did each group have? Why were records downloaded from one system only to be paginated and uploaded into another?

I was assuming there was a constraint I did not understand yet. One of the questions I kept asking was: what are the obvious things I do not know that are preventing an easier workflow from happening? I wanted to challenge the workflow by understanding why it had been created in the first place.

That questioning separated the problem into different kinds of complexity: clinical judgment and contracts that belonged to the work, third-party systems and permissions we could not easily change, and accumulated workarounds that existed because people had learned to bridge the gaps themselves.

Three categories of workflow complexity: unchangeable clinical judgment and contracts, hard-to-change third-party systems and permissions, and changeable accumulated workarounds.

03.05Before I designed screens, I documented the mess

I started reconstructing how a claim actually moved: who touched it, which system was used, what evidence had to exist before the next step, what rule caused a branch, what happened when something was missing, and how much time each handoff consumed.

Time was also a major constraint. Only part of the total claim timeline was available for preparation and FCR before Claims Processing still needed enough time to finish the claim. Missing records or physician escalation could quickly consume that margin.

Once those relationships were visible, the question changed from “How do we make claims processing faster?” to “Where should our product sit, what should it bring together, what decisions should it support, and which steps can it remove?”

Service blueprint mapping the claims workflow, systems, and teams, with each step classified by what was unchangeable, hard to change, or more changeable.

03.06Strategy became clear: automatically bring evidence to the reviewer

One of the initial product ideas before the research was a rules-driven product that could recognize when supporting clinical data would be needed. The research gave that direction validation and a much higher priority.

Different claim characteristics, medical policies, facility contract rules, trauma cases, hospital-acquired conditions, medications, and high-cost reviews all required different clinical data. Much of that knowledge was carried by people. Claims staff and nurses knew from experience that a particular situation meant, “we are going to need these records.”

The research validated a stronger product direction: move more of that work into Claims Plus. The product could store explicit rules, determine the evidence likely to be needed, retrieve or request it earlier, surface relevant policy beside the clinical data, and make missing information visible without forcing the reviewer into another phone, fax, or email chase.

Workflow comparison showing Claims Plus connecting providers directly to reviewers, bypassing mail, fax, scanning, and offshore document preparation.

03.07I translated the research into an expert interface, not a prettier one

These were advanced users willing to invest the initial learning time to become fast at an interface. I wanted the experience designed for that end state of speed and knowledge.

The prototype brought the information around the clinical decision closer together: claim context, claim lines, the reason for review, applicable policies and rules, itemized charges, clinical evidence, prior history, notes, evidence status, other clinical data, and a faster way to request what was missing. I also explored a patient facesheet so reviewers could see relevant context around the patient instead of only a single claim.

The point was not to turn every possible data point into one giant dashboard. The design work was deciding what belonged close to the decision and arranging it in a hierarchy that fit the reviewer’s mental model while optimizing for review speed.

Full Claims Plus interface bringing claim lines, patient and claim context, clinical records, and applicable medical policies together for review.

Annotated Claims Plus interface highlighting claim lines as left-side navigation, automatically found medical records, and related insurance policies.

03.08Once the prototype was visible, the conversation got better

When the system mostly lives in people’s heads, Product, Design, and Engineering can be discussing slightly different versions of the problem without realizing it. Translating the research into a concrete prototype made those assumptions easier to expose and faster to resolve before difficult-to-change code was written.

Product could discuss scope and priorities more concretely. Engineering could focus on integrations, data sources, permissions, and technical boundaries. I could keep pushing on whether the interactions still represented the way reviewers actually made decisions.

At OODA, much of the product direction depended on technical feasibility: what data could be retrieved, what rules could be made explicit, what systems could connect, and what would remain a future opportunity. The research gave us a better model of the product problem, and the prototype gave the team a place to negotiate what was actually buildable.

Three Claims Plus prototype screens showing two claim-line views and a patient facesheet, bringing claim details and clinical evidence together for review.

03.09OODA reinforced how I learn hard domains

My value is not walking into every problem as the person who already knows everything. It is my ability to get to the truth quickly without pretending that I already know.

OODA is still one of my favorite examples of the kind of work that keeps my brain alive. The users were experts, the domain was dense, and almost every answer created two more questions.

I liked asking basic questions until they stop being basic. What happens next? Why? Who owns it? Where does the information actually live? What happens when the normal path fails? What would break if we removed this step?

I kept going until the complexity separated into things that must remain, constraints we have to design around, and workarounds we can change. That is the point where I can stop researching and start designing with confidence.