PAPrathamesh Adarkar
CLAIMPATH / HEALTHCARE OPERATIONS / FHIR R4

Evidence beforeaction.

From missing documentation to a reviewable appeal.

I built ClaimPath to make the next step in a claims investigation visible: identify the missing evidence, connect it to its source, prepare a draft, and keep a human responsible for approval.

ROLE

End-to-end product & implementation

BUILT WITH

Next.js · TypeScript · PostgreSQL · FHIR

FOCUS

Evidence, traceability, human approval

01 / INSIDE CLAIMPATH

See the work.
Then follow the evidence.

Actual application: the overview brings evidence gaps and pending reviews into one queue. Click the image to enlarge.

Actual ClaimPath overview with case metrics and an investigation queue
02 / ONE CLAIM, END TO END

What needs to happen
before an appeal is ready?

Follow CP-1001, an authored case for Maya Chen. This interactive walkthrough explains the workflow; it does not modify the live application.

CP-1001 / MAYA CHEN

Start with the missing referral.

The case needs a referral document. A denial reason tells the reviewer where to investigate, but it does not establish that the required evidence is present.

Missing evidence
Required document: Referral
Next action: Attach supporting evidence
Submission: Blocked until checks pass

Illustrative walkthrough of the implemented workflow. In the application, open CP-1001 and attach its sample referral to try it.

8Workflow screens
30Authored claim scenarios
FHIR R4External clinical data connection
HumanFinal approval

A denial is a starting point.
It is not a next step.

Claims investigation involves more than reading a status. A reviewer has to find the right document, check that it belongs to the case, understand what is still missing, and explain the request clearly enough for another person to review.

I designed ClaimPath around those handoffs. The queue leads into a claim workspace; documents feed evidence checks; the checks inform a draft; review decisions remain visible in the audit history.

04 / HOW THE WORKFLOW IS BUILT

Clinical context in.
Traceable decisions out.

01

FHIR source

Verified Synthea patients
Source references retained

02

Case & evidence

Documents and identifiers
Explicit completeness checks

03

Appeal studio

Editable draft
Supporting evidence nearby

04

Human review

Approve or request changes
Export and audit history

DATA INTEGRATION

Preserve the original context.

The importer accepts three allowlisted Synthea patients from the SMART Health IT sandbox, verifies provenance and references, and preserves source Bundles and actual service dates.

APPLICATION

Keep the work together.

Next.js and TypeScript connect the eight screens. The Vercel edition uses PostgreSQL for session workspaces, documents, drafts, and audit events.

ASSISTANCE

Explain retrieved evidence.

The evidence assistant provides rules-based answers. The code also supports server-side OpenAI explanations when an API key is configured. Approval stays with a person.

05 / PRODUCT DECISIONS

Make the gaps visible.

ClaimPath evidence map linking the denial, policy requirement, and missing referral
The evidence map keeps the missing referral visible beside the denial and its policy requirement.

Check identity before completeness.

A document must match the claim and member identifiers, document type, and required marker. Attaching a file alone does not make a packet ready.

Review the version that will leave.

Editing or regenerating an approved draft invalidates approval. The updated request has to go through review again.

Separate source data from scenario data.

Imported clinical records retain their source. Payer names, financial amounts, denial reasons, and review targets are explicitly authored claim scenarios.

06 / TRY THE APPLICATION

Follow the evidence yourself.

Open the claims queue, select CP-1001, and attach its sample referral under Document intake. Inspect the checks, generate a draft, and route it for review.

Open full application ↗

If the embedded view is unavailable or your browser restricts its session cookies, use the full application link.

07 / WHAT I VALIDATED

A working workflow.
A clear boundary.

Local integration checks covered incomplete-evidence blocking, document intake, draft-to-approval transitions, persistence, session separation, and invalidating approval after edits. Live FHIR checks covered all three patients, duplicate imports, mismatched references, and source provenance.

These checks establish application behavior. They do not establish clinical sufficiency, insurer acceptance, recovery rates, or time savings. Next I would test the workflow with claims reviewers and measure where they need to leave the workspace to complete a task.

SOURCE & SCOPE

All patient data is synthetic. Original claims are authored examples; imported clinical records are Synthea-generated data from the shared SMART Health IT FHIR R4 sandbox. Missing Coverage records do not imply lack of insurance. Evidence checks verify identifiers and markers, not medical necessity. Approval is internal; the application does not submit appeals to insurers.

SMART Health IT ↗Synthea ↗ClaimPath ↗