CKD Care Orchestration Framework · Conceptual Note
Operational definitions and grouping rules for representing clinical time, and how they map to standard informatics models.
The phrase “an event may be made up of numerous encounters or illnesses” is the tell. Event is being used as an aggregating container, but the same word is also natural for an atomic happening (an MI, dialysis start, an AKI onset). Almost every mature clinical information model splits these into two distinct primitives. The recommendation is to do the same: reserve event for the atomic happening and use episode for the container.
Five primitives, ordered from atomic to aggregate:
The common mistake is treating these as a single continuum. They are independent attributes of an illness, and nephrology shows why they don’t collapse into one another.
Tempo and current intensity — onset acuity (acute vs. insidious) and current activity (flaring vs. quiescent). “How fast did it arrive / how hot is it now.”
Persistence — self-limited vs. persistent vs. recurrent/relapsing-remitting. “Will it end.”
Direction over time — improving / stable / progressive / fluctuating. “Which way is it heading.”
| Illness | Acuity | Chronicity | Progression |
|---|---|---|---|
| CKD (nephrosclerosis) | Low | Chronic-persistent | Slowly progressive |
| AKI on CKD | High | Acute / may resolve | Resolving or progressive |
| Lupus nephritis | High on flare | Chronic-recurrent | Relapsing-remitting |
| FSGS post-transplant recurrence | Moderate | Chronic | Progressive |
The same illness moves along the progression axis over time while its chronicity classification stays fixed — that is the distinction that lets you say “CKD is stable this year” without implying it stopped being chronic.
Four composition rules fall out of these definitions:
Episode ↔ Encounter is many-to-many. One clinic visit can serve several episodes at once (the CKD thread, a new HTN finding, a med-safety review); one episode spans many encounters. Encounters can’t “belong to” a single episode — you need a link table, and probably a notion of the primary episode for an encounter plus secondary links.
Event → Episode is mostly many-to-one. Events are the spine of an episode, and one event can open or close it.
Event ↔ Illness: an event marks a state-change on an illness’s trajectory. The AKI-on-CKD event is what bumps the CKD thread’s progression vector. This is how the acuity/chronicity/progression attributes get updated — they are not static fields, they are recomputed as events land on the thread.
The decision that matters most. Illness is referenced by episodes, never contained by them. An illness outlives any episode — CKD persists through the sepsis admission, the access surgery, the transplant. If you nest illnesses inside episodes (or inside encounters), longitudinal CKD becomes impossible to represent and you’ll be re-deriving the disease thread from scratch at every visit. Episodes and encounters point at the illness; the illness owns its own timeline.
This is not novel — it rediscovers a well-trodden model, which is reassuring for a demo tool aiming at face validity. The relevant bodies of work:
FHIR separates Encounter (a single activity/contact) from EpisodeOfCare — explicitly “the container that can link a series of Encounters together for problems/issues… even if not currently participating in an encounter.” That is precisely the episode-vs-encounter split. And Condition.clinicalStatus already encodes the acuity/chronicity/progression axes as a value set: active, recurrence, relapse, inactive, remission, resolved — plus separate onset, abatement, and severity elements. Adopting those status terms makes the framework speak the same language as any modern EHR.
OMOP’s condition_era is literally “a span of time when the person is assumed to have a given condition,” built by collapsing individual condition_occurrence rows using a 30-day persistence window. That is the algorithm for turning atomic events into an illness thread — and the observation_period concept (when the patient is “at-risk to have a clinical event recorded”) is a useful honesty check on whether absence of data means absence of disease.
For provenance: Weed’s problem-oriented medical record (the original argument that the problem/illness — not the visit — should be the organizing spine); the primary-care “episode of care” tradition (Lamberts & WONCA/ICPC, which formalized episode-of-care as the unit of analysis in ambulatory data); openEHR’s archetype model and HL7’s RIM Act/clinical-statement pattern (both distinguish atomic acts from their groupings); and Shahar’s knowledge-based temporal abstraction, the academic basis for deriving “progression / stable / worsening” trends from raw observation sequences — directly relevant to computing the progression axis rather than hand-entering it.