Unnat Patel

Healthcare documents · 11 of 31 · Evidence · 8 minutes

Healthcare products. From problem to production.

Product design

Claims automation, provider matching and a legacy claims integration replaced — explored through the documents and decisions.

01

Design

Design the state model before the screens

Interface behavior, data entities, sequence, API responses and recovery/security tradeoffs.

Product decision
Separate extraction, identity, submission and adjudication evidence.

Document type
Product design
Status
Portfolio sample · written from my healthcare claims experience
Product decision
Separate extraction, identity, submission and adjudication evidence.

Portfolio sample from my healthcare product experience. Requirements, thresholds and review records are illustrative; they are not employer documents or historical sign-offs.

Product design / Process flow

Paper claim → validated transaction → adjudication

  1. 01
    Receive & classify
    CMS-1500 → professional · UB-04 → institutional
    Identify the form, preserve the source and assign a traceable intake record.
    Exception:
    Unrecognized or incomplete?
    Recovery:
    Route to intake review; do not guess the form.
  2. 02
    Extract & verify
    OCR produces a candidate, not an approved claim
    Check extracted fields against the source; keep uncertainty visible.
    Exception:
    Unreadable or conflicting?
    Recovery:
    An authorized operator corrects the extraction.
  3. 03
    Resolve the provider
    Normalize → query the provider API → compare
    Use the central provider source and keep the submitted values alongside the match.
    Exception:
    Missing or ambiguous?
    Recovery:
    Hold for resolution; do not invent a provider identity.
  4. 04
    Validate & hand off
    837P / 837I → existing adjudication rules
    Validate the transaction before sending eligible claims to the adjudication system.
    Exception:
    Validation fails?
    Recovery:
    Return a specific exception. OCR does not decide coverage.
  5. 05
    Reconcile & learn
    Acknowledgment → final disposition → operating review
    Separate acceptance from adjudication, reconcile every record and monitor rework.
    Exception:
    No confirmed result?
    Recovery:
    Investigate status before retrying; prevent duplicate submission.

Portfolio product-design sample. Control details illustrate my approach; they are not an employer’s production architecture.

In this document 7 sections

Design objective and alternatives

Choose an evidence-led operator workspace over either a silent automation pipeline or a form-entry screen with hidden downstream state. Silent processing reduces interaction but hides uncertainty. A transcription-only screen preserves review while leaving handoff problems unresolved. The chosen design combines the source, current decision and next authorized action. Platform migration is a separate experience informing replay and continuity requirements, not a claim about the deployed claims architecture.

  1. a silent automation pipeline Silent processing reduces interaction but hides uncertainty
  2. a form-entry screen with hidden downstream state A transcription-only screen preserves review while leaving handoff problems unresolved
  3. an evidence-led operator workspace combines the source, current decision and next authorized action

Platform migration is a separate experience informing replay and continuity requirements, not a claim about the deployed claims architecture.

Interfaces and logical data model

These are example entities and public contract concepts, not proprietary schemas.

Entity / interfaceMinimum informationPurpose
IntakeRecordUnique identity, source reference, form type, receipt timeDeduplicate and anchor lineage
FieldEvidenceOriginal/extracted/corrected values, actor, reason, versionShow why a value is accepted
ProviderResolutionNormalized request, source/version, status, reason, lookup timeMake identity evidence inspectable
TransactionAttemptClaim identity, variant, validation version, receiver correlationSeparate attempts from distinct claims
StateEventPrior/next state, timestamp, actor or service, reasonReconcile current inventory and history
ExceptionItemClaim identity, queue, reason, age, permitted actionsSupport accountable recovery

Happy-path sequence

Receive a supported source and create one intake identity. Extract required values and check completeness; an authorized correction retains the source and revalidates. Normalize provider representation while preserving substantive unit/location distinctions. Obtain uniquely supported current provider evidence. Generate the applicable 837P or 837I and validate the receiver contract. Submit with a stable processing identity; persist acknowledgement separately. Only the receiving adjudication system can supply final disposition. Reporting projects one current state per identity instead of counting each event as another claim.

UPCigna Supplemental BenefitsPaper-to-EDI conversion

Paper in.
Claims ready to move.

One conversion. Two connected outputs.

15min

saved per claim
in manual processing

300k

claims per month

2%

of manual claims avoided

TWO OUTPUT PATHS

A processable claim.
A retrievable original.

Unnat Patel · Product leadership

Select any step to explore. Form layouts are simplified.

Step overview

Read the complete process

Claim forms and a primary-payer EOB

Incoming paper claims include CMS-1500/UB-04 forms and a primary-payer Explanation of Benefits (EOB). CMS-1500 professional claims convert to EDI 837P; UB-04 institutional claims convert to EDI 837I. The primary-payer EOB is an input, distinct from the EOB generated after adjudication. The simplified forms contain no patient data.

Process explanation: Confirm the form type and legibility before extraction.

OCR + AI read the claim

OCR and AI extract the information from the paper forms for conversion.

Process explanation: Check incomplete or uncertain values against the source image before applying conversion rules.

Custom rules prepare both outputs

Custom conversion rules create EDI files alongside image and index files.

Process explanation: Validate required values, apply the corresponding 837 format and route generation errors for review.

Keep the original retrievable

The image and index share a common claim ID in OnBase. Stakeholders can retrieve the original claim for appeals or re-review. Storage supported the project's stated 10-year retention requirement.

Process explanation: Keep the image and index associated, and surface a failed lookup or storage handoff.

Send the electronic claim for adjudication

Professional claims use EDI 837P; institutional claims use EDI 837I. The files go to the claims processor for adjudication.

Process explanation: Confirm receipt and investigate missing or rejected acknowledgements. File acceptance is distinct from adjudication.

Adjudicate, then create the outputs

The claims processor adjudicates the claim, followed by payment, invoice and Explanation of Benefits (EOB) outputs. The generated EOB is distinct from the primary-payer EOB received with the incoming paper claim.

Process explanation: Processing and its downstream outputs follow the receiving workflow. This conversion project is separate from the claims-engine replacement.

Failure states and interaction

An unsupported form is quarantined. Missing or uncertain fields appear beside their source evidence. An ambiguous provider presents unresolved evidence, never a preselected candidate. Invalid EDI displays an actionable category and keeps submission blocked. After a timeout, show status as unknown/pending investigation until receiver state is checked; silence is not proof of failure. Held claims show reason, queue and age. Corrections return through validation rather than directly jumping to submission. The design keeps operators informed without exposing protected data to unrelated roles.

  1. An unsupported form is quarantined
  2. Missing or uncertain fields appear beside their source evidence
  3. An ambiguous provider presents unresolved evidence never a preselected candidate
  4. Invalid EDI displays an actionable category keeps submission blocked
  5. Corrections return through validation rather than directly jumping to submission

After a timeout, show status as unknown/pending investigation until receiver state is checked; silence is not proof of failure.

API semantics and performance

The provider API returns MATCHED, MISSING_DATA, NO_MATCH, AMBIGUOUS, SOURCE_STALE or UNAVAILABLE. A matched response includes reference, evidence version, reason and lookup time. Error responses retain request correlation without echoing protected values into routine logs. The sample target is p95 ≤500 ms at 50 requests/second, with source-query/cache paths, timeouts and errors reported separately. Caching trades latency against freshness: an old result cannot silently be labeled current. Exact matching precedence, freshness configuration and receiver mappings require their own approved contracts.

  1. The provider API returns MATCHED, MISSING_DATA, NO_MATCH, AMBIGUOUS, SOURCE_STALE or UNAVAILABLE A matched response includes reference, evidence version, reason and lookup time
  2. p95 ≤500 ms at 50 requests/second with source-query/cache paths, timeouts and errors reported separately
  3. an old result cannot silently be labeled current Caching trades latency against freshness

Exact matching precedence, freshness configuration and receiver mappings require their own approved contracts.

Security, recovery and tradeoffs

Authorize read, correction, submission and export separately. Retain an auditable rationale for human changes and apply approved retention. Stable identities and receiver-state inspection reduce duplicate risk; they do not justify a universal exactly-once delivery claim across systems. Isolate migration replay from live submission and reconcile every expected identity before promotion. Operations and care validate recoverability; security/legal/compliance validate data controls; relevant patient-safety specialists review downstream boundaries. No component infers clinical necessity, credentialing or benefit approval from an OCR score or provider match.

  1. Authorize read, correction, submission and export separately
  2. Retain an auditable rationale for human changes apply approved retention
  3. Isolate migration replay from live submission reconcile every expected identity before promotion
  4. Operations and care validate recoverability security/legal/compliance validate data controls

No component infers clinical necessity, credentialing or benefit approval from an OCR score or provider match.

Operator confirmation and reporting views

The correction action shows the proposed change, its source and the actor’s permission before committing. The queue view groups actionable reasons while retaining individual claim age and ownership. Customer care receives an appropriate status view, not unrestricted editing. Reporting distinguishes event counts from unique claims and exposes unresolved inventory. These views share the underlying state model so the same claim cannot appear completed to one audience and unexplained to another.

  1. The correction action shows the proposed change, its source and the actor’s permission before committing
  2. The queue view groups actionable reasons while retaining individual claim age and ownership
  3. Customer care receives an appropriate status view not unrestricted editing
  4. Reporting distinguishes event counts from unique claims exposes unresolved inventory

These views share the underlying state model so the same claim cannot appear completed to one audience and unexplained to another.