Insurane Database Connection Status Page
Main Page
All and past requests
Test 1 Insurance Missing Information
Test 1 Insurance Policy Mismatch
Latest Insurance Updates

Inspiration

Why do we have to bear the cost?

Not the insurer. Not the hospital. We: the patient who leaves without medicine, the officer who gets blamed, the system that pays twice for one decision. Someone always pays when a rule changes and nobody hears it. The question is why it is always the one who had no part in the change.

Every rule has two clocks. One belongs to the insurer: the moment a rule becomes true. The other belongs to the hospital: the moment someone finds out. We have treated them as one clock. They are not, and the gap between them has no owner, no dashboard and no name. It shows up only as a rejection, the system’s most expensive way of measuring itself.

Experian Health's 2024 survey found that 77% of respondents reported more frequent payer-policy changes. But knowing a policy changed is not enough. Hospital teams need to know which cases are affected and what needs attention.

That is why we created Coverage Guard.

How we built it

We built the frontend with React, TypeScript, and Tailwind CSS, and the backend with Python and FastAPI.

The backend reads PDFs with PyMuPDF and uses RapidOCR for images and scanned documents. It extracts the insurer and prescribed treatment, retrieves relevant public policy documents, and compares the prescription’s information against supported policy rules.

Results include the policy source, relevant requirements, and effective dates. Requests and reports are saved in SQLite.

We organized the application into four pages:

New Insurance Check
All Requests
Insurance Database Connection
Latest Insurance Updates

Challenges we ran into

One challenge was extracting useful information from documents with different layouts and image quality.

Another was distinguishing a policy mismatch from incomplete information. Missing evidence should not automatically become a rejection.

We also needed to keep the interface simple while showing enough source information for employees to understand each result.

Accomplishments that we’re proud of

We created a complete upload-to-result workflow while preserving a consistent visual design.

The prototype explains policy mismatches, cites retrieved sources, and clearly identifies uncertain results. We tested the workflow with fictional prescriptions covering accepted, mismatch, and needs-review cases.

The application builds successfully, passes 41 backend tests, and has been verified through browser testing.

What we learned

We learned that reliable document processing requires both accurate extraction and careful interpretation.

A medication appearing in a policy does not establish acceptance. The applicable requirements matter, and the application must communicate when it lacks enough information to decide.