Skip to main content

Knowledge Graph

The memory-store backs a 3-collection clinical knowledge graph: entities, relationships, claims.

Entity taxonomy​

The taxonomy_category field (added in SPEC-05 §3) enables aggregation routing. Seed categories:

  • problem — conditions, diagnoses
  • symptom — patient-reported
  • intervention — medications, procedures
  • outcome — labs, vitals, patient-reported outcomes
  • population — cohort identifiers

Backfill migration: scripts/migrate-add-taxonomy-category.py (idempotent, resumable).

Claim lifecycle​

Retrieval paths​

Two complementary access patterns:

  • Graph traversal — $graphLookup up to depth 4 over memory_relationships, producing entity → entity paths
  • Full-text — Atlas Search index claims_fts over encrypted-decrypted claim text (search handled server-side with encrypted-field considerations)

The 4 routes combine these (see Hybrid retrieval).

Governance​

  • Every entity has a patientId scope (or null for public ontology data)
  • Every claim has pii_fields[] marking which fields are PHI → serializer redacts
  • Every write audit-chained via AuditService.append()
  • Retention: entities + claims retained per patient's data-retention policy; findings (correlator/replicator/librarian) 180d TTL

MCP server (spec 044)​

6 query operations exposed as Claude Code tools:

  • memory_find_entity_by_name
  • memory_get_claim_chain
  • memory_screen_completeness
  • memory_list_hypotheses
  • memory_graph_expand (capped at 2 hops)
  • memory_search_claims (consent-scoped when patient_id provided)

All tool calls emit memory.mcp.tool_invoked audit events with metadata-only payloads (tool_name, user_sub_hash, patient_id, latency_ms — no args or response content).