Burke: Episodes would be tracking what actually happened; Programs might define the expected path; could compare these together
Episode = What Actually Happened
Jan: do Encounters get attached after the fact, or at the time of the visit, or what?
Burke: <pedantic>Encounter would have a foreign key to episode of care</pedentic>
Darius: actually, an encounter could belong to >1 episode
Burke: we would implement the data model for this first, without presuming a specifically UI workflow
e.g. you could enter these real-time, or they could be added retrospectively during a chart review
Jan: functionally how can we have this happen without extra work?
Darius: in the eSaude application you could do it automatically via encounter types
Burke: don't forget that Episodes are *episodic* so you don't just throw them all in a single episode for TB forever.
Darius + Burke: this is going to be similar to the approach to visits, you would set up automated business roles that create/continue episodes 95% of the time, and occasionally someone has to "break the glass" manually.
Plan = What Should Happen
could be against a diagnosis
could be against a program
could be against a single event (e.g. you have X observation)
Sentinel Event (observation?)
Burke: "Episodes are a way of grouping encounters around some theme, across multiple visits"
Tarry: Episodes of care are defined based on where there is clinical decision-making (e.g. in chemotherapy you reassess after each cycle, so it would make sense for a single chemotherapy cycle to be a single episode)
Burke: like we did with Visits, the business rule aspect is going to need to be pluggable: