Unnat Patel

Healthcare documents · 4 of 31 · Evidence · 5 minutes

Healthcare products. From problem to production.

Vision

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

01

Reliable administrative flow, visible at every handoff

The target user experience, differentiated value, strategic choices and execution model for reliable claims flow.

Product decision
Make completeness and accountability part of automation.

Document type
Vision
Status
Portfolio sample · written from my healthcare claims experience
Product decision
Make completeness and accountability part of automation.

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

In this document 7 sections

Vision

Make eligible administrative claims progress with less repetitive handling, while every unresolved claim remains understandable, attributable and recoverable. The experience should let an operator explain what is known, what is uncertain and who can act next. The product’s value comes from the complete flow, not from a claim disappearing from one team’s queue.

  1. Make eligible administrative claims progress with less repetitive handling
  2. every unresolved claim remains understandable, attributable and recoverable
  3. let an operator explain what is known, what is uncertain and who can act next

The product’s value comes from the complete flow, not from a claim disappearing from one team’s queue

Users and outcomes

The vision resolves different jobs without collapsing their responsibilities.

UserDesired outcomeProduct commitment
Claims operatorComplete valid work; recover exceptionsSource evidence, correction history and a clear queue
Provider-data specialistImprove supported identity resolutionOriginal/normalized inputs and distinct mismatch reasons
Customer careExplain status accuratelyShared state vocabulary; no false completion promise
Integration consumerReceive valid attributable transactionsContract validation and stable processing identity
Product/operations leaderUnderstand net valueCost, speed, defects and reconciled inventory together

Differentiation

An OCR-only solution ends at extracted fields. A transport-only solution ends at delivery. This product commitment spans the decisions between those stages: whether the source supports a value, whether provider evidence is sufficient, whether the receiver contract is satisfied and whether downstream disposition is known. It makes exception ownership visible instead of treating all nonautomated work as one undifferentiated queue. That differentiation is an intended operating advantage, not an unmeasured competitive-market claim.

  1. whether the source supports a value
  2. whether provider evidence is sufficient
  3. whether the receiver contract is satisfied
  4. whether downstream disposition is known

It makes exception ownership visible instead of treating all nonautomated work as one undifferentiated queue

Strategic choices

Start with a bounded form/cohort contract and a usable manual path. Normalize representation without creating identity evidence. Centralize the provider response semantics consumers depend on. Keep 837 validation separate from adjudication authority. Require reconciliation before broader traffic or platform transition. These choices draw on my separate claims-automation, provider-API and internally built platform experiences; they do not impose one historical architecture on all three.

  1. Start with a bounded form/cohort contract and a usable manual path
  2. Normalize representation without creating identity evidence
  3. Centralize the provider response semantics consumers depend on
  4. Keep 837 validation separate from adjudication authority
  5. Require reconciliation before broader traffic or platform transition

Execution model

Product translates the business outcome into BR1–BR6 and resolves scope tradeoffs. Design and operations make held work recoverable. Engineering and the extraction partner prove service and data contracts. Provider/claims specialists validate domain interpretation. Security, legal and compliance establish access, data-use and retention obligations; patient-safety partners assess relevant downstream consequences. A vertical slice must include both a valid claim and its expected exceptions before broader eligibility. The separate platform initiative adds consumer inventory, replay isolation and rollback evidence.

  1. Product translates the business outcome into BR1–BR6 and resolves scope tradeoffs
  2. Design and operations make held work recoverable
  3. Engineering and the extraction partner prove service and data contracts
  4. Provider/claims specialists validate domain interpretation
  5. Security, legal and compliance establish access, data-use and retention obligations

A vertical slice must include both a valid claim and its expected exceptions before broader eligibility

Success and non-goals

More than 400,000 paper claims were converted to EDI 837, an 80-person team was redeployed and the business saved about $1M a year. Future value is assessed through net completed automation, cost per claim, tail time, rework and reconciliation, not extrapolated savings. The sample API target is p95 ≤500 ms at 50 requests/second, paired with error and identity-quality reporting. Non-goals are clinical decision-making, benefit-policy changes, provider credentialing inferred from a match, and retail pharmacy NCPDP processing in this medical-claims release. The roadmap expands only when evidence supports the next user outcome.

  1. Future value is assessed through net completed automation, cost per claim, tail time, rework and reconciliation not extrapolated savings
  2. The sample API target is p95 ≤500 ms at 50 requests/second paired with error and identity-quality reporting
  3. Non-goals are clinical decision-making, benefit-policy changes provider credentialing inferred from a match, and retail pharmacy NCPDP processing in this medical-claims release

The roadmap expands only when evidence supports the next user outcome

Roadmap and learning loop

Now: demonstrate a supported claim and representative exceptions with consistent state and metric definitions. Next: improve the most consequential failure mode using observed operator work and reconciled reporting. Later: broaden supported cohorts or migrate additional consumers only when the incremental value and control burden are understood. Customer discovery asks how people complete a recent task, not whether they like automation in principle. Include successful and unresolved cases to avoid learning only from easy work. The resulting evidence may narrow scope as legitimately as it expands it; the vision is reliable completion, not a predetermined feature count.

  1. Now: demonstrate a supported claim and representative exceptions with consistent state and metric definitions
  2. Next: improve the most consequential failure mode using observed operator work and reconciled reporting
  3. Later: broaden supported cohorts or migrate additional consumers only when the incremental value and control burden are understood