Authoritative
Source clinical facts remain in EHR/claims/lab/pharmacy systems; Praxis stores identifiers and immutable copies/references.
Presenter view
Data & state speaker notes
Explain state ownership first, then the relationships required to reproduce a recommendation and safely learn from clinician behavior.
Opening cue
“The model does not own memory. The application owns explicit, versioned state, and every inference is attached to the source and time that made it reasonable.”
01 · State ownership
Do not mix facts, inference, workflow and memory
Derived
Normalized state, features, summaries, embeddings and candidates are versioned and reproducible.
Operational
Workflow, approval and execution state is mutable through explicit transitions and append-only events.
Learning
Feedback, preferences and evaluation results are separately scoped, confidence-rated and expiring.
“Source systems remain authoritative. Praxis stores a replayable operational projection. Derived state is versioned, workflow state changes only through explicit transitions, and learned behavior never becomes clinical truth.”
02 · ER model
Describe the groups, not every column
Identity + scope
tenant
id · name · policy_set_id · created_at
clinician
id · tenant_id · role · active · preferences_version
patient
id · tenant_id · source_identifiers · status
panel_membership
id · clinician_id · patient_id · effective_from/to · attribution_source
Events + longitudinal state
source_event
id · tenant/patient · source · type · occurred/received_at · payload_ref · hash
patient_state_version
id · patient_id · version · as_of · trigger_set · content_hash · status
longitudinal_feature
id · state_version · key/value/unit · baseline · delta · confidence · provenance
evidence_ref
id · source_event/document_version · page · section · chunk · effective_at
Reasoning + workflow
workflow_run
id · type · temporal_id · subject_ids · input_version · status · budget · timestamps
decision_candidate
id · patient/state_version · priority · confidence · risk · status · expires_at · versions
candidate_evidence
candidate_id · evidence_id · claim_id · support_type
agent_run
id · workflow_id · agent/model/prompt version · input/output hash · cost · status
Approval + outcomes
approval_decision
id · candidate_id · clinician_id · decision · edits · reason · decided_at
action_execution
id · candidate_id · action_type · owner · status · idempotency_key · result_ref
feedback_record
id · candidate/action · signal · reason_code · outcome · observed_at
evaluation_trace
id · trace/version · dataset_case · scores · guardrail_result · created_at
Relationship cue
tenant 1 → N clinicians, patients and policy sets
clinician N ↔ N patients through effective-dated panel_membership
patient 1 → N source_events → N patient_state_versions
patient_state_version 1 → N longitudinal_features and DecisionCandidates
DecisionCandidate N ↔ N evidence_ref through candidate_evidence
DecisionCandidate 1 → N approval decisions → 0..N action executions
workflow_run 1 → N agent_runs; every output stamps all dependency versions
03 · Candidate lifecycle
No recommendation jumps to execution
Generated
Typed output exists but is not visible.
Validated
Grounding, freshness and safety checks passed.
Queued
Visible to the clinician with named owner and expiry.
Approved / modified / dismissed
A named clinician records the decision and reason.
Executing
An idempotent action request is in progress.
Completed / failed / expired
Terminal outcome is recorded; stale work cannot execute.
“The execution payload is the exact approved candidate/action version. An idempotency key prevents duplicate external actions, and a relevant state change blocks stale approval or execution.”
04 · Safe memory
Record why—not just what the clinician clicked
Explicit preference
Communication style, queue ordering or workflow choice stated by the clinician.
May change presentation; expires or can be edited.
Operational constraint
Formulary, staffing, scheduling or prior-authorization limitation.
May change feasibility; must have source, owner and review date.
Clinical disagreement
A recommendation was rejected for a stated patient-specific reason.
Applies only to the scoped patient/context unless reviewed.
Observed pattern
Repeated behavior inferred from several decisions.
Low confidence by default; never silently changes clinical standards.
Outcome evidence
What happened after an approved, modified or dismissed recommendation.
Updates evaluation and prioritization, not guideline truth.
GLP-1 answer
“No, I do not stop recommending it from rejection alone. I ask for the reason, distinguish clinical disagreement from operational constraint, scope it, add confidence and expiry, and continue to respect approved guidelines.”
05 · Freshness + temporal reasoning
Later evidence may supersede earlier evidence
“I store occurred_at and received_at. I preserve every source event, but the active patient-state version resolves which evidence is current. The heart-rate artifact remains auditable while the later EKG becomes the relevant fact.”
Candidate dependency check
Input patient-state version
Trigger event set
Evidence/document versions
Guideline + policy versions
Agent, prompt + model versions
Created and expiry times
Closing transition
“Now every fact, decision and action is reproducible. The next section defines the safety policy, cost envelope and evidence that tell us whether the system deserves trust.”