Unnat Patel

Library · Healthcare documents · Evidence · 6 minutes

Product journey / Healthcare, patient safety & platforms

Healthcare products. From problem to production.

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

Explore the document journey

See the decision inside the document.

Seven stages. Readable previews. Open the supporting documents when you need the detail.

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

Discover · 2 documents

Find the problem before choosing the system.

Document quality

Readable source.
Verified fields.

Paper claim conversion

Provider identity

Trustworthy evidence.
Explicit match state.

Provider resolution

Transaction continuity

Receiver state.
Recovery ownership.

Platform replacement

Separate projects; their outcomes are not combined.

Three product problems. Separate evidence.
Read 2 supporting documents

Define · 8 documents

Choose the option and name its boundaries.

A · Fallback baseline

Manual optimization

Less disruption

Repetitive entry remains
B · Selected sample path

OCR + validated transaction + review

Eligible automation

Inspectable exceptions
C · Rejected in sample

Unrestricted straight-through processing

Apparent automation

Unresolved identity & quality risk
The decision is visible in the comparison.
Read 8 supporting documents

Design · 1 document

Make the exception path part of the interface.

ReceivePreserve the sourceExtractCandidate fieldsResolveProvider evidenceValidate837 transaction
Unreadable / conflictingMissing / ambiguousValidation fails
Authorized reviewCorrect · resolve · return a specific exception
Adjudication remains a separate decision. OCR does not decide coverage.
A candidate becomes a transaction through explicit checks.
Read the document

Build · 3 documents

Pair each feature with a usable exception path.

FeatureStory / acceptanceDependency
IntakeClassify, extract, correct, holdVendor / form contract
ProviderNormalize and resolve explicitlyCentral data access
HandoffValidate; observe receiver stateReceiver contract
ContinuityDuplicate control; reconcileStable identity & inventory
OperationsRoles and review reportingQueue ownership

Platform replacement retains its own epic and migration dependencies.

Features carry acceptance into the story map.
Read 3 supporting documents

Validate · 3 documents

Require the evidence before making the release decision.

GateSample evidence status
Input & provider qualityExpected cases documented
Transaction integrityExecution evidence not supplied
Operational readinessApproval not supplied
Data controlsApproval not supplied
Platform cutoverSeparate decision required

No status above represents a historical sign-off.

Required evidence is not an approval.
Read 3 supporting documents

Launch · 5 documents

Expand only while quality and capacity support it.

ValidateSanctioned test casesObserveRestricted approved scopeExpandAdditional eligible cases
Pause forUnintended duplicatesMissing inventoryUnauthorized accessUnsupported provider selection
Restore approved route → reconcile identities → replay

Platform transition requires independently approved consumers and separate evidence.

Every increase has an exit condition and a way back.
Read 5 supporting documents

Operate & learn · 9 documents

Change the cause, not the rule that exposes it.

Signal: some provider matches were wrong
Measure a month of claims with and without the rule.
Remove the ruleAdditional manual fallout

The wrong matches are real; removal creates a larger operating consequence.

Fix identity at its sourceProvider-master proof of concept

Test the replacement source before funding the migration.

Identity, reconciliation and claim-file shredding were distinct projects.

Compare the consequence before removing a control.
Read 9 supporting documents

01

Healthcare / Product leadership
Three experiences

Remove manual effort.
Keep the judgment accountable.

I have built healthcare products at three points in the journey: turning paper claims into electronic transactions, resolving provider data, and replacing a legacy claims integration.

Paper-to-EDI conversion · daily reconciliation · homegrown EDI shredding into a normalized datamart · separate provider identity resolution

Results are from my claims work. The $10M is the value of claims found unprocessed. It is not a saving. Provider latency and reporting improved; I am not publishing a numerical result for that work.

From scanned forms to auto-adjudication.

I led the conversion of paper claims to EDI 837 transactions for automated adjudication. The product opportunity was end-to-end reduction in manual claims work.

Make a match the next system can trust.

Missing provider names and inconsistent addresses disrupted matching. I designed the end-to-end provider flow against the provider master and proved it with a 99% match in a proof of concept.

Replace the legacy integration.

I led the replacement of Microsoft BizTalk with homegrown EDI shredding directly into a normalized datamart before adjudication. Capturing complete claim data reduced enhancement turnaround by 50% and improved received-to-paid mapping and CMS reporting. The LifePRO engine replacement, daily reconciliation and paper-to-EDI conversion were separate projects.

Product design / Process flow

Paper claim → validated transaction → adjudication

  • 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.

Where patient safety and PBM change the decision.

For these administrative products, wrong identity, missing information and unowned exceptions are risks to control. Clinical judgment remains with qualified professionals. My PBM experience adds context for prescriber identity, benefit operations, customer care and pharmacy workflows; it does not turn this medical-claims example into a retail-pharmacy transaction.

CMS-1500 and UB-04 relate to professional and institutional medical claims. Retail-pharmacy transactions use a separate NCPDP standards path.

Read the decisions behind the delivery.

The samples show how I frame the problem, choose among options, specify the product, prepare a release and use operating evidence. They connect three experiences; they do not imply one shared production implementation.

← Back to Library