Paper-to-EDI claims conversion

Broader intake design sample

This broader intake sample illustrates a design contract. Provider resolution and daily reconciliation were separate projects.

1. Paper claimBeforeSupported paper claims require repetitive entry before electronic processing.

   Exception routes

2. 01 Classify

   Intake

   Identify the form and preserve the source.

   • CMS-1500 → professional
   • UB-04 → institutional

   Traceableintake record assigned

   First: define input quality.

   Unrecognized or incomplete?Route to intake review; do not guess the form.Intake review

3. 02 Verify

   OCR

   Check extracted fields against the source.

   SourceCandidate

   Candidatenot an approved claim

   Keep uncertainty visible.

   Unreadable or conflicting?An authorized operator corrects the extraction.Authorized operator

4. 03 Resolve

   Provider match

   Keep submitted values beside the match.

   SubmittedMatch

   Normalize → query the provider API → compare

   One sourcethe central provider source

   Next: establish provider resolution.

   Missing or ambiguous?Hold for resolution; do not invent a provider identity.Hold for resolution

5. 04 Validate

   Transaction

   Validate the transaction before adjudication.

   837P837I

   Existing adjudication rules

   EDI 837validated transaction

   I led the conversion to EDI 837 transactions.

   Validation fails?Return a specific exception. OCR does not decide coverage.Specific exception

6. 05 Reconcile

   Reconciliation

   Keep acceptance separate from adjudication.

   • Acknowledgment
   • Final disposition
   • Operating review

   Reconcileevery record; monitor rework

   Then: validate downstream handoff and reconciliation.

   No confirmed result?Investigate status before retrying; prevent duplicate submission.Investigate status

7. AdjudicationAfterPaper claims converted to EDI 837 transactions for automated adjudication.

The decision

I choose bounded automation with reviewable exceptions.

• AManual optimizationFallback baseline
• OCR + validated transaction + reviewSelected sample path
• Unrestricted straight-through processingReject unresolved identity and quality risk

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

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

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

1 / 7 · Problem & evidence

What made manual claims intake worth changing?

Portfolio sample
Problem statement · Business problem

Supported paper claims require repetitive entry before electronic processing. A clean extraction result still creates limited value if provider evidence is incomplete, the transaction is rejected, or downstream completion is invisible. Operators then repeat work across intake, matching and recovery. Customer care inherits an ambiguous status, while product reporting can overstate improvement by counting successful intermediate steps instead of completed claims.

Portfolio sample
Problem statement · Current journey and friction

The following journey expresses the problem this product contract addresses.

Step	User need	Failure mechanism	Consequence
Receive form	Know the source is supported and readable	Malformed or incomplete source	Manual clarification before entry
Extract and correct	Trust required values	Uncertain field looks complete	Error moves downstream
Resolve provider	Use supported identity evidence	Missing name or variable address	No match, false match or repeated lookup
Generate and submit	Meet receiver requirements	Wrong variant or invalid field	Rejection and rework
Track completion	Know what happened after handoff	Acknowledgement confused with disposition	Misleading status or unsafe retry

Portfolio sample
Problem statement · Evidence and attribution

The mailroom program converted more than 400,000 paper claims to EDI 837, redeployed an 80-person keying team and saved about $1M a year. Those program results are distinct from the conversion measures above. Provider resolution and claims-engine replacement were separate projects.

Read the complete sample
Problem statement →

Why OCR plus a validated transaction and review?

Portfolio sample
Options & decision record · Options

The recommendation balances value, operating effort and failure consequences.

Option	Customer / operator value	Disposition
A: manual optimization	Less disruption; limited removal of entry work	Fallback baseline
B: OCR + validated transaction + review	Eligible automation with inspectable exceptions	Selected sample path
C: unrestricted straight-through processing	Maximum apparent automation	Reject unresolved identity and quality risk

Portfolio sample
Product strategy · Strategic diagnosis

OCR removes transcription effort but cannot resolve provider identity or prove that a downstream transaction completed. I separate the bottlenecks so each investment has a clear value case and a verifiable contract.

Portfolio sample
Vision · 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.

Read the complete samples
Options & decision record → Product strategy →

What did the product commit to?

Portfolio sample
Business requirements · In scope / out of scope

The primary release covers a defined medical-claims cohort. The integration platform migration has a separate scope and release decision.

In scope	Out of scope
CMS-1500 / professional and UB-04 / institutional intake	Additional form types without an explicit contract and validation.
OCR extraction, required-field validation and authorized correction	Inferring missing clinical facts or approving coverage from an OCR score.
Provider normalization and authorized central-source resolution	Credentialing, network eligibility or prescriber authority inferred solely from an identity match.
Valid 837 handoff, acknowledgement tracking and reconciliation	Changing benefit policy, clinical judgment or receiving adjudication rules.
Role-based exception handling and operational reporting	Retail-pharmacy NCPDP processing within this medical-claims release.

Portfolio sample
Business requirements · Functional requirements and Given / When / Then acceptance

The functional specification expands these contracts with response semantics and boundary cases.

Requirement	Given	When	Then
FR1 · Supported forms	A complete CMS-1500 or UB-04 source is received	The intake service classifies it	Create a traceable claim record and select the professional or institutional mapping; quarantine unsupported or unreadable forms.
FR2 · Extraction & correction	A required field is missing, uncertain or inconsistent with the source	An authorized operator reviews the candidate	Display the source beside the field; record the correction and revalidate before the claim can advance.
FR4 · Provider resolution	The authorized central source has current, uniquely supported provider evidence	The API resolves the request	Return the matched provider reference, evidence version and reason; return distinct missing, no-match, ambiguous or stale statuses otherwise.
FR5 · EDI validation	A complete reviewed claim has resolved required provider evidence	The applicable 837P or 837I transaction is generated	Validate against the applicable implementation and receiver contract; block invalid transactions and return an actionable field-level reason.
FR6 · Adjudication handoff	A validated claim is authorized for the receiving adjudication system	The transaction is submitted and acknowledged	Persist submission and acknowledgement separately; update final disposition only from the receiving system’s adjudication result.
FR7 · Retry & duplicate protection	A request times out or is repeated with the same processing identity	The service checks status or retries	Preserve identity, inspect known receiver status and prevent an unintended second claim submission; do not treat silence as failure.
FR9 · Authorization & audit	An actor requests claim access, correction or export	Their identity and permissions are evaluated	Allow only the permitted operation and record the action; deny unauthorized access without exposing protected values in errors or logs.
FR10 · Exception ownership	A claim is held, rejected or awaiting a confirmed result	Operations opens the exception queue	Show current state, reason, accountable queue and age; a resolved correction re-enters validation with its source history intact.

Portfolio sample
Business requirements · Nonfunctional and safety requirements

The values below are acceptance targets for this sample, separate from reported historical outcomes.

Requirement	Acceptance evidence
Access & data protection	Authorized role checks cover read, correct, submit and export; sensitive values excluded from routine logs; retention follows an approved policy.
Provider API performance	At a declared 50 requests/second sample load, p95 ≤500 ms; publish source-query/cache breakdown and error rate.
Recoverability	Injected timeouts and replay retain one processing identity and produce no unintended duplicate live submissions.
Traceability	Every test claim retains source, validation version, provider resolution and state-change history.
Safety boundary	No OCR or matching component decides clinical necessity, benefit approval or medication appropriateness.

Read the complete samples
Business requirements → Functional requirements →

What happens when the happy path breaks?

Portfolio sample
Product design · 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.

Portfolio sample
Product design · 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.

Read the complete sample
Product design →

Who decided, and what earned the release?

Portfolio sample
Business requirements · Stakeholders and decision rights

I connect the business outcome to the people accountable for its consequences.

Partner	Decision or evidence
Product	Outcome, option comparison, MVP scope, priorities and acceptance contract.
Operations & customer care	Usable exceptions, staffing, training, status language and escalation ownership.
Engineering, vendor & design	Extraction/interface feasibility, source visibility, contract tests and recovery.
Provider-data & claims specialists	Matching evidence, authorized correction and downstream transaction interpretation.
Security, legal & compliance	Permitted data use, access, retention, partner obligations and release evidence.
Patient safety & clinical partners	Review plausible downstream consequences and boundaries requiring professional judgment; administrative gains alone do not establish clinical benefit.

Portfolio sample
Test cases & QA · Traceable test set

Expected outcomes below are acceptance criteria, not reported pass results.

Case / requirements	Given / When	Expected result
Q1 · Valid professional claim · FR1/5/6	Given a complete sample CMS-1500 and uniquely supported provider, when processed	Select 837P; pass the agreed receiver contract; retain submission identity and receiver status.
Q2 · Valid institutional claim · FR1/5/6	Given a complete sample UB-04 and required provider evidence, when processed	Select 837I; validate institutional mapping; retain source lineage and receiver status.
Q3 · Extraction correction · FR1/2	Given an unreadable required field, when an authorized operator corrects it	Hold initially; record source and correction; advance only after revalidation.
Q4 · Invalid EDI · FR5	Given a wrong variant or required-field violation, when validated	Block handoff and display a specific error; no invalid live submission.
Q5 · Normalization · FR3	Given equivalent address representations, when normalized	Preserve original values; match only with sufficient identity evidence.
Q6 · Missing / ambiguous provider · FR4	Given missing required identity evidence or two plausible candidates, when resolved	Return a distinct unresolved reason and review path; no arbitrary choice.
Q7 · Stale / unavailable source · FR4	Given an expired sample freshness limit or unavailable provider source, when queried	Expose source status; hold or controlled retry; no silent current-match assertion.
Q8 · Acknowledgement vs outcome · FR6	Given an accepted acknowledgement but no final result, when state is reported	Show accepted/awaiting disposition; only a later adjudication response updates the final state.
Q9 · Timeout / repeated request · FR7	Given a lost response and the same request identity, when retried	Check known state and emit no unintended duplicate live claim.
Q10 · Migration comparison · FR8	Given a bounded replay inventory, when legacy/new results differ	Isolate replay from live submission, identify every discrepancy and block promotion.
Q11 · Access denial · FR9	Given an unauthorized actor, when read/correct/export is attempted	Deny the action without claim-data exposure and record the access event.
Q12 · Queue / reporting · FR10 / MR1–MR5	Given mixed current states and known operator actions, when reports are built	Reconcile unique inventory; show held items, manual work and correct denominators.

Portfolio sample
User acceptance testing · Acceptance scenarios

Record actual behavior beside the expected result; do not replace it with a checkbox alone.

ID / Given	When / participant action	Expected result	Actual / status
U1 valid CMS-1500 or UB-04	Operator follows the claim through handoff	Correct 837 variant; acknowledgement distinct from final disposition	NOT RUN
U2 uncertain required field	Authorized operator compares source and corrects	Correction lineage retained; revalidation before advance	NOT RUN
U3 missing or ambiguous provider	Operator interprets response and assigns review	No arbitrary selection; reason and accountable queue visible	NOT RUN
U4 stale/unavailable provider source	Operator examines status and next action	Does not treat old evidence as current; controlled hold/retry	NOT RUN
U5 invalid EDI or delayed acknowledgement	Claims specialist explains current state	Correct error action; no unsupported completion promise	NOT RUN
U6 retry and replay discrepancy	Operator/engineer recover a bounded fixture	Stable identity; discrepancy visible; no live replay duplication	NOT RUN
U7 restricted user	Customer-care role attempts an unauthorized change	Action denied; appropriate status remains available	NOT RUN
U8 mixed inventory	Operations reviews queue and report	Unique records reconcile; pending/held work remains visible	NOT RUN

Read the complete samples
Test cases & QA → User acceptance testing → Go / No-Go decision →

How is the result read?

Portfolio sample
Measurement contract · Reported outcomes

At Cigna Supplemental Benefits, Paper-to-EDI converted CMS-1500 to 837P and UB-04 to 837I using OCR and custom rules. OnBase stored the claim image and index under a common claim ID for retrieval, appeals and re-review. EDI fed claim processing and adjudication, followed by payment, invoice and generated EOBs. The conversion saved 15 minutes per paper claim on about 300,000 paper claims per month, with 2% of manual claims avoided.

Portfolio sample
Measurement contract · Defect, cost and operating measures

Numerators, denominators and observation coverage remain visible in the review.

Measure	Definition	Product decision
Extraction correction rate	Claims requiring an extraction correction / extracted claims reviewed; disclose sampling coverage	Tune capture or field review before automating more forms.
False-match rate	Confirmed incorrect provider matches / reviewed matched claims; disclose review sample and confidence limits	Pause matching changes and investigate identity risk.
EDI rejection rate	Distinct rejected transactions / distinct receiver-evaluated transactions; pending acknowledgement reported separately	Correct mappings or receiver contract, not OCR indiscriminately.
Duplicate defect rate	Confirmed unintended duplicate live submissions / distinct submitted claim identities	Stop rollout and repair retry/recovery behavior.
Cost per completed claim	Allocated extraction + compute + support + manual correction cost / distinct completed claims in period; publish backlog movement	Fund improvements with measurable total-cost benefit.
Reconciliation completeness	Received identities with exactly one known current state / all unique received identities at cutoff	Investigate every missing identity before migration expansion.
Exception age & ownership	p50/p95 age of unresolved items from hold time to cutoff; unassigned items / all open exceptions	Adjust staffing, workflow or source correction.

Read the complete samples Measurement contract →

What would I avoid next time?

Read the complete sample
Mistakes & lessons →

All healthcare documents →