I built a dental insurance claim verifier using Cognee's GraphRAG — with session memory

Insurance claim denials cost policyholders billions of dollars every year.

Not because the coverage doesn't exist — but because understanding whether a specific procedure is covered, for a specific patient, against a specific policy, is genuinely hard. Policy documents are dense, cross-referenced, and written for administrators, not patients.

This is what I set out to solve for the WeMakeDevs × Cognee Hackathon.

The problem in one sentence

A 67-year-old patient needs urgent oral infection treatment. Is it covered? How much? Under what conditions? Do their medications matter?

A PDF doesn't answer that. A chatbot hallucinating over a PDF definitely doesn't answer that.

A knowledge graph that remembers who you are — does.

What I built: Cover-Clarity

cover-clarity.onrender.com

Cover-Clarity lets Aetna Bronze Benefit Plan policyholders (and their doctors) input a patient's medical history and ask natural-language questions about dental coverage. It gives precise, policy-traced answers — not summaries, not guesses.

Why Cognee made this possible

Standard RAG (Retrieval-Augmented Generation) would have failed here. Insurance policy documents aren't linear — they're a web of cross-references: procedure codes pointing to clinical criteria, clinical criteria referencing age limits, age limits tied to benefit tiers. A flat vector search over chunks can't reason across that structure.

Cognee's GraphRAG builds a hybrid graph-vector knowledge store from your documents. When you query it, it traverses entity relationships — not just similarity scores. This meant Cover-Clarity could answer questions like "Is extraction covered for a 96-year-old on Metformin?" by actually following the policy's logic, not just pattern-matching on keywords.

The data pipeline

Aetna DCPBs (PDF) + Bronze Benefit Plan (PDF)

        ↓

  cognee.add() → document ingestion

        ↓

  cognee.cognify() → graph construction

        ↓

  Knowledge graph on Cognee Cloud

Aetna's Dental Clinical Policy Bulletins were cleaned, structured, and ingested into Cognee Cloud. The result: a queryable graph where every node is a policy concept, every edge is a relationship.

The session memory architecture

This is where Cognee's infrastructure shone beyond just retrieval.

Every user gets a persistent session on Cognee Cloud, identified by a session_id. Each call to cognee.recall() within that session carries the conversation's context forward:

results = await cognee.recall(

    query_text=augmented_query,   # patient history + user question

    session_id=session_id,

    datasets=["dental_insurance_kb"]

)

The augmented_query injects the patient's medical history as a context prefix:

ctx = f"""Patient Context:

- Age: {history['age']}

- Chronic Conditions: {', '.join(c['condition_name'] for c in history['chronic_conditions'])}

- Current Medications: {', '.join(m['name'] for m in history['current_medications'])}

- Allergies: {', '.join(history['allergies'])}



Query: {user_question}"""

This means Cognee isn't answering "is root canal covered?" — it's answering "is root canal covered for a 52-year-old diabetic on blood thinners with a penicillin allergy?" Every. Single. Time.

Sessions persist until explicitly deleted (SESSION_TTL_SECONDS=604800 — 7 days). A user can log out, come back three days later, and Cognee still has their conversation history. No re-ingestion, no context reconstruction.

Session lifecycle on Cognee Cloud

User signs up  →  default session created (session_id = username_default)

User asks Q1   →  cognee.recall(session_id) → answer + graph node IDs returned

User asks Q2   →  cognee.recall(session_id) → answer uses Q1 context automatically

User logs out  →  session data persists on Cognee Cloud (7-day TTL)

User logs in   →  GET /api/v1/sessions/{session_id} → full QA history restored

Graph trace visualization

Every answer from Cognee returns used_session_context_ids — the IDs of knowledge graph nodes that were traversed to generate the response. Cover-Clarity renders these as an interactive D3 force graph:

Answer ──── Policy node a80d0a75...

       ──── Policy node 95be53c0...

       ──── Policy node f5fcb9e5...

       ...

This isn't cosmetic. It tells the user (and their doctor) exactly which policy clauses drove the answer — auditable, traceable, trustworthy.

The full stack

The backend is intentionally thin — it's mostly a secure proxy between the frontend and Cognee Cloud. All the intelligence lives in the graph.

What I learned about Cognee

A few things that weren't obvious from the docs but matter in production:

Sessions aren't "abandoned" — they're just labelled that way. Cognee computes abandoned status at read-time based on inactivity threshold. The cache data is untouched. You can call GET /api/v1/sessions/{session_id} on a session that's been "abandoned" for days and get full QA history back instantly.

cognee.session.get_session() reads local cache, not cloud. If you're running in remote mode (pointing at Cognee Cloud), use the REST API directly with X-Api-Key header to fetch session history — the SDK's session module doesn't proxy to the cloud backend.

recall() creates sessions implicitly. Don't pre-check is_session_valid() before the first recall() call — Cognee creates the session on first use. Pre-checking an uninitialised session always returns 404.

Medical history context injection works better as a prefix than a separate recall. I tested both sending medical history as a separate recall() and injecting it as a query prefix. The prefix approach gave significantly more contextually accurate answers because Cognee sees the full context in one traversal rather than merging two separate retrievals.

Try it

🔗 Live app: cover-clarity.onrender.com

📦 GitHub: github.com/Rushanksavant/Cover-Clarity

Sign up, fill in a patient profile, and ask anything about Aetna dental coverage. Every answer shows you which policy nodes were used to generate it.

What's next

Cover-Clarity currently serves Aetna's Bronze Benefit Plan. The architecture is plan-agnostic — swap the ingested documents and the same graph-memory system works for any insurer, any plan tier, any country's healthcare policy documents.

The bigger vision: a system where patients walk into a doctor's office, the doctor inputs their history, and gets an instant pre-authorization likelihood — before treatment begins, not after denial.

Cognee's infrastructure made the session memory and graph traversal parts trivial to implement. The hard part was understanding insurance policy structure well enough to trust the answers. That's a data quality problem, not a technology problem — and it's very solvable.

Built by @rushanksavant for the WeMakeDevs × Cognee Hackathon