About Services Case Studies Pricing Blog Book Free Audit
CLINICAL AI / GRAPHRAG20262 min read

GraphRAG-Powered Clinical Chatbot for OBGYN Documentation

A graph-based retrieval system that correctly distinguishes between highly templated OBGYN clinical notes that read almost identically in plain text but represent genuinely different patients, encounters, and findings.

CLIENT
NoteGraph
INDUSTRY
Healthcare (NDA)
TIMELINE
~16 weeks
ROLE
End-to-end engineering: knowledge graph modeling, GraphRAG retrieval pipeline, multi-agent orchestration with tiered models, full chat product UX
// overview

NoteGraph is a chat assistant built over a large body of OBGYN clinical documentation, where notes are heavily templated and dozens of unrelated documents can share nearly identical boilerplate wording. Instead of standard vector RAG, NoteGraph models notes and their real relationships explicitly as a knowledge graph in Neo4j, and retrieves by traversing that graph.

// the problem

Standard vector RAG confidently retrieves the wrong notes.

Embedding-based similarity search can't reliably tell "relevant because it discusses the same clinical picture" apart from "uses the same standard phrasing as a thousand other notes." The real distinguishing signal was relational, not lexical — same patient, same encounter, a referenced prior visit, a linked finding — which is a graph problem, not a text-similarity problem.

  • Retrieval that understands relationships, not just word overlap
  • A familiar, polished chat experience — conversation history, save, delete
  • Cost- and latency-aware at scale across a multi-agent architecture
  • Careful handling of sensitive clinical documentation throughout the system
// approach

How we built it.

01

Neo4j as the knowledge graph layer

Clinical notes are modeled as nodes; edges capture same patient, same encounter, referenced prior visit, and linked finding or diagnosis.

02

GraphRAG retrieval combining vector anchoring with graph traversal

A query uses embedding search to find candidate anchor nodes, then expands outward through Neo4j's relationship edges to assemble genuinely connected context.

03

Multi-agent architecture with tiered models

The primary reasoning agent runs on Claude Opus with automatic fallback to Claude Sonnet; a separate, lighter-weight agent runs on Claude Haiku.

04

PostgreSQL for the application layer

Conversations, users, and saved/deleted conversation state live in PostgreSQL, kept cleanly separate from the Neo4j knowledge graph.

// what we shipped

The solution.

01

A GraphRAG retrieval pipeline

Queries anchor into the knowledge graph via vector search, then expand through Neo4j's relationship edges to assemble context driven by genuine connections, not wording similarity.

02

A knowledge graph purpose-built for templated documentation

Notes are nodes; relationships (same patient, same encounter, referenced prior visit, linked finding) are edges.

03

A multi-agent system with tiered models

A primary Opus-driven agent with Sonnet fallback handles core reasoning; a separate Haiku-powered agent handles a lighter supporting task.

04

A full-featured chat product experience

Conversation history, save conversation, and delete conversation give users the same baseline UX as a mainstream AI chat product.

05

Clean separation between graph and application data

Neo4j owns clinical relationships; PostgreSQL owns conversations, users, and product state.

// the results

Outcomes that shipped.

Retrieval correctly distinguished between clinically connected notes and merely similarly-worded ones, directly solving the failure mode that made standard RAG unreliable on this documentation set. Users got a chat experience with the polish of a mainstream AI assistant without needing to understand the graph-based retrieval running behind it, and tiered model routing kept the multi-agent system's cost and latency reasonable despite several LLM calls per interaction. Validated GraphRAG as the right tool for domains where documents are lexically repetitive but relationally distinct.

// stack
Neo4jPostgreSQLGraphRAG pipelineClaude OpusClaude SonnetClaude Haiku
// learnings

What we took with us.

  • 01Formalize the graph schema earlier — as relationships grew more intricate, the Neo4j schema evolved organically rather than being defined rigorously upfront.
  • 02Build evaluation tooling for the multi-agent pipeline sooner — understanding where an answer's context came from took manual tracing early on.
  • 03Earlier load-testing of the Opus-to-Sonnet fallback path rather than validating it primarily through real usage.
// ready when you are

Have a build that needs this level of thinking?

Free 30-min audit. We'll tell you what to build, what it'd cost, and whether we're the right shop.