Paper in.
Claims ready to move.
One conversion. Two connected outputs.
saved per claim
in manual processing
claims per month
of manual claims avoided
Select any step to explore. Form layouts are simplified.
Healthcare documents · 11 of 31 · Evidence · 8 minutes
Healthcare products. From problem to production.
Claims automation, provider matching and a legacy claims integration replaced — explored through the documents and decisions.
01
Design
Interface behavior, data entities, sequence, API responses and recovery/security tradeoffs.
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
Portfolio product-design sample. Control details illustrate my approach; they are not an employer’s production architecture.
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.
Platform migration is a separate experience informing replay and continuity requirements, not a claim about the deployed claims architecture.
These are example entities and public contract concepts, not proprietary schemas.
| Entity / interface | Minimum information | Purpose |
|---|---|---|
| IntakeRecord | Unique identity, source reference, form type, receipt time | Deduplicate and anchor lineage |
| FieldEvidence | Original/extracted/corrected values, actor, reason, version | Show why a value is accepted |
| ProviderResolution | Normalized request, source/version, status, reason, lookup time | Make identity evidence inspectable |
| TransactionAttempt | Claim identity, variant, validation version, receiver correlation | Separate attempts from distinct claims |
| StateEvent | Prior/next state, timestamp, actor or service, reason | Reconcile current inventory and history |
| ExceptionItem | Claim identity, queue, reason, age, permitted actions | Support accountable recovery |
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.
One conversion. Two connected outputs.
saved per claim
in manual processing
claims per month
of manual claims avoided
Select any step to explore. Form layouts are simplified.
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 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 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.
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.
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.
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.
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.
After a timeout, show status as unknown/pending investigation until receiver state is checked; silence is not proof of failure.
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.
Exact matching precedence, freshness configuration and receiver mappings require their own approved contracts.
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.
No component infers clinical necessity, credentialing or benefit approval from an OCR score or provider match.
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.
These views share the underlying state model so the same claim cannot appear completed to one audience and unexplained to another.