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.
- Make eligible administrative claims progress with less repetitive handling
- every unresolved claim remains understandable, attributable and recoverable
- 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.
| User | Desired outcome | Product commitment |
|---|---|---|
| Claims operator | Complete valid work; recover exceptions | Source evidence, correction history and a clear queue |
| Provider-data specialist | Improve supported identity resolution | Original/normalized inputs and distinct mismatch reasons |
| Customer care | Explain status accurately | Shared state vocabulary; no false completion promise |
| Integration consumer | Receive valid attributable transactions | Contract validation and stable processing identity |
| Product/operations leader | Understand net value | Cost, 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.
- whether the source supports a value
- whether provider evidence is sufficient
- whether the receiver contract is satisfied
- 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.
- 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
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.
- 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
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.
- 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
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.
- 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