Review the Reconciliation Summary
Read the reconciliation report to see pipeline stats, inferred relationships, and post-processing actions.
Review the Reconciliation Summary
The reconciliation summary gives a higher-level view of pipeline activity than the full resolution report. It covers: how many entities were merged and how many relationships were inferred, plus the specific post-processing actions applied (family history reclassification, status inference, symptom linking).
Fetch as Markdown
The default response is a human-readable Markdown report:
curl "https://<workspace-id>.w.clinia.cloud/v1/patients/{patientId}/reconciliation" \
-H "Authorization: Bearer <access-token>"# Reconciliation Summary - Jeanne Tremblay
## Pipeline Stats
- Input entities: 24
- Resolved entities: 21 (3 groups merged)
- Explicit relationships: 11
- Inferred relationships: 17
- Post-process actions: 2
## Merged Entity Groups
- Chronic obstructive lung disease (condition): 2 sources, matched by deterministic-code (0.97)
- Tiotropium 18mcg daily (medication): 2 sources, matched by nlp-normalization (0.85)
- FEV1 (lab): 2 sources, matched by embedding-similarity (0.91)
## Inferred Relationships
- tiotropium → prescribed_for → chronic_obstructive_lung_disease (0.94)
- fev1 → monitors → chronic_obstructive_lung_disease (0.96)
- acute_exacerbation_of_copd → complication_of → chronic_obstructive_lung_disease (0.92)
## Post-Process Actions
- [infer-status] "Resolved bilateral knee osteoarthritis" → status: active
- [link-symptom] Dyspnea → likely parent: chronic_obstructive_lung_diseaseFetch as JSON
For programmatic access, append ?format=json:
curl "https://<workspace-id>.w.clinia.cloud/v1/patients/{patientId}/reconciliation?format=json" \
-H "Authorization: Bearer <access-token>"The JSON response has four sections: stats, mergedEntities, inferredRelationships, and postProcessActions.
Understanding inferred relationships
Inferred relationships come from the clinical knowledge base, they are not present in the source records. The pipeline adds them in Phase 2 of the resolution pipeline.
Common inferred types:
| Relationship | Example |
|---|---|
prescribed_for | metformin → type_2_diabetes |
monitors | hba1c → type_2_diabetes |
complication_of | ckd → type_2_diabetes |
risk_factor_for | hyperlipidemia → cad |
These relationships are what powers condition stories, the "Current Treatment" and "Monitoring Labs" tables come from prescribed_for and monitors edges, and the "Complications" section comes from complication_of edges.
Understanding post-process actions
Post-processing runs after entity deduplication and adds or adjusts nodes and edges without re-running the 4-layer cascade.
| Action type | What it does |
|---|---|
reclassify-to-family-history | Conditions coded as "hx of X" or "family history of X" are moved to the family history subgraph |
infer-status | Conditions with textual cues ("resolved", "in remission", "former") have their status set accordingly |
link-symptom | Non-specific symptoms (fatigue, nausea) are linked to likely parent conditions via clinical knowledge |
filter | Entities determined to be duplicates or administrative artifacts after the main pipeline are removed |
Comparing to the full resolution report
| Reconciliation | Resolution | |
|---|---|---|
| Scope | Summary stats + actions | Every entity with full provenance |
| Inferred relationships | ✓ Listed | ✗ Not included |
| Post-process actions | ✓ Listed | ✗ Not included |
| Conflict detail | ✗ Not included | ✓ Full field-by-field conflicts |
| Good for | Understanding what happened overall | Debugging a specific entity |
See Audit Entity Resolution for per-entity provenance detail.
Audit Entity Resolution
Read the resolution report to understand how entities from different sources were merged, what conflicts were found, and which resolver made each decision.
API Overview
Patient Memory exposes two API surfaces: MCP tools for AI agent integration and a REST API for direct HTTP access.