Work · 2 of 17 · Deep dive · 7 minutes

On this page

Incomplete provider data → a traceable match
Keep exploring.

Provider data · From my experience

Provider resolution through a central API

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.

Provider latency reduced; reporting improved.

In a proof of concept, 29,870 of 30,000 providers matched against the provider master (99%). The result won funding to move provider matching to the provider master.

My role: Missing provider names and inconsistent addresses disrupted matching. I built an API against a central provider source and normalized the data.
The decision: Combine normalization with an authorized central lookup and explicit no-match / ambiguous states, rather than local cleanup alone.
The result: In a proof of concept, 29,870 of 30,000 providers matched against the provider master (99%). The result won funding to move provider matching to the provider master.

The role, scope and reported outcome above are from my experience. The requirements, designs, thresholds and review records below are portfolio samples that illustrate the decisions. They are not employer documents or historical sign-offs; some shared tables cover the whole intake product.

Product design / Process flow

Incomplete provider data → a traceable match

01
Preserve the request
Submitted name · address · available identifier
Keep original values and identify which fields are absent or inconsistent.
Exception:
Required evidence absent?
Recovery:
Return an actionable missing-data reason.
02
Normalize carefully
Standardize representation, preserve meaning
Normalize address and name formatting without silently replacing provider identity.
Exception:
Conflicting identity?
Recovery:
Keep the conflict visible for authorized review.
03
Resolve against the source
Central provider API · source version · freshness
Return a unique supported match, ambiguity or no match with a reason.
Exception:
Stale or multiple matches?
Recovery:
Do not select the first candidate to improve match rate.
04
Observe & improve
Latency · match quality · exception reasons
Instrument the API and report cohort-level outcomes to guide the next investment.
Exception:
Faster but less accurate?
Recovery:
Hold expansion; investigate false matches and correction effort.

Sample API decision flow. It shows a general pattern, not a production system.

1 / 5 · Problem & evidence

Why did provider data disrupt matching?

Portfolio sample
Business requirements · Problem statement

Paper CMS-1500 and UB-04 claims require repetitive entry before electronic processing. Missing provider names and inconsistent address representations create additional resolution work. A faster extraction step creates limited value if the resulting claim still waits for manual correction downstream.

Portfolio sample
Problem statement · Causal hypotheses and validation

The first hypothesis is that eligible transcription can be removed without removing interpretation. The second is that a portion of matching friction comes from evidence completeness and representation, rather than slow infrastructure alone. The third is that hidden intermediate states create repeated work and inaccurate reporting. Validate each by tracing a recent failed task and a comparable successful task, inspecting source/correction history and segmenting exception reasons. These hypotheses must remain distinguishable: a faster API cannot compensate for the wrong provider, and more OCR capacity cannot fix a receiver-contract error.

Read the complete samples
Problem statement →
Business requirements →

Normalize the representation, or resolve the identity?

Portfolio sample
Options & decision record · Provider matching — representation or identity?

Normalization alone is the smallest change, but it does not recover a missing name from trustworthy evidence. A central provider API makes source reuse possible while introducing a shared dependency. The selected product direction combines normalization with an authorized lookup and explicit no-match/ambiguous states. I would reconsider the scope if source quality or response behavior made review work worse.

Option	Benefit	Limit
Local cleanup only	Fast, bounded formatting change	Cannot resolve missing or conflicting identity evidence.
Consumer-by-consumer lookup	Local integration autonomy	Duplicated rules and inconsistent reporting.
Shared provider API + normalization	Consistent source and response contract	Requires freshness, failure handling and accountable data ownership.

Portfolio sample
Feature prioritization · Priority decision

I prioritize failure modes that can misroute, lose or duplicate claims before convenience features. The baseline provider API and normalization belong in P0 because downstream processing cannot be trustworthy without reliable identity evidence.

Read the complete samples
Options & decision record → Feature prioritization →

What does the API promise the next system?

Portfolio sample
Functional requirements · Provider API response contract

These are public sample response semantics; production endpoints and proprietary mappings are omitted.

Result	Required response	Permitted next action
MATCHED	Provider reference, source/version, lookup time and match reason	Advance only if all required claim fields are valid.
MISSING_DATA / NO_MATCH	Missing evidence or no supported candidate, with a reason	Request correction or assign review. Do not fabricate the missing name.
AMBIGUOUS	Conflicting candidate evidence without automatic selection	Authorized resolution with a recorded rationale.
SOURCE_STALE / UNAVAILABLE	Source health/freshness status and traceable request identity	Hold or controlled retry; an old result cannot silently become current.

Portfolio sample
Product design · API semantics and performance

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.

Portfolio sample
Functional requirements · Acceptance examples for provider ambiguity

Given two plausible providers at a normalized address, when lookup completes, then return AMBIGUOUS and retain the unresolved claim. Given an absent provider name and other insufficient identifiers, when lookup is attempted, then return MISSING_DATA. A normalization rule cannot create identity evidence.

Read the complete samples
Functional requirements → Product design →

How are speed and match quality measured?

Portfolio sample
Functional requirements · Performance and recovery acceptance

For this sample contract, test provider resolution at 50 requests/second with p95 response time ≤500 ms; report cache-hit and source-query paths separately. Inject a timeout and replay the same request identity to verify that a second live claim is not emitted. These are proposed acceptance targets, not historical production measurements.

CMS: professional claims and CMS-1500 ↗ · CMS: institutional CMS-1450 / 837I ↗ · CMS: adopted transaction standards ↗

Portfolio sample
Measurement contract · Input and output measures

Compare equivalent cohorts; isolate changes in form mix and source quality.

Measure	Definition	Product decision
Input completeness	Claims with all required source fields / all unique received claims, by form and channel	Improve upstream intake or narrow eligible scope.
Net automation	Eligible received claims reaching final disposition without manual work / all eligible received claims; show pending share alongside	Expand only when completion rises without hidden rework.
Throughput	Distinct claims reaching final disposition per operating hour; show automation and manual paths separately	Plan capacity using actual end-to-end output.
Processing speed	p50/p95 time from receipt to final disposition for completed claims; pending age reported separately	Prioritize the stage driving tail delay.
Provider API latency	p50/p95 elapsed time from API request acceptance to response, separated by source-query/cache path; report timeout rate	Choose performance work without sacrificing match quality.

Read the complete samples Measurement contract →

How does the evidence change the roadmap?

Portfolio sample
Training material · Walkthrough

Completion means explaining the state and its consequence, not merely clicking through the flow.

Exercise	Correct interpretation
Malformed form	Hold rather than fill missing facts by assumption
Address variation	Normalization changes representation, not substantive identity
Multiple provider matches	Do not pick the first candidate
EDI rejection	Correct and revalidate; this is not an adjudication decision
Timeout / replay	Check identity and state before retry
Reporting discrepancy	Investigate missing inventory; do not hide the denominator

Portfolio sample
Actions from metrics · Roadmap implication

Identity, reconciliation and claim-file shredding were distinct projects. 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.

Read the complete samples
Training material → Actions from metrics → Monthly business review →

Related evidence

Keep exploring.

All healthcare documents →

← Back to Work