2016-01-25 Design Forum
How to Join
Agenda
eSaude w/ Jan Flowers (Post potential topics of interest on Talk with the tag design-forum)
Review next meeting agenda
Notes
Attendees
Jan Flowers
Burke
Darius
Wyclif
Terry
Agenda
eSaude (Jan)
Notes
Jan: the problem with "visits" is that in real life where we are working there is no way to capture visits.
multiple entry points
no discharge
in KenyaEMR we implemented a way to "close all outpatient visits at the end of the day" but Steven says this has been a battle to get people to use it
Darius: in Mirebalais there was also no official discharge (for outpatients) so we have an automated task close this (after X hours with no more activity)
Burke: just because you aren't clear on when the visit ends doesn't mean there is no meaning in the fact of the visit
especially valuable for things like billing, etc
Jan: CDC uses the term "visit" in a very specific way for PEPFAR reporting, and we don't want to use "visit" in a way that doesn't match PEPFAR's usage
Jan: Valeria has been looking at workflows across HIV treatment
e.g. cycles, each one having X tests, and Y followup visits
Jan: thought that maybe this is Episode Of Care; Bill says this is more of a Clinical Pathway or Care Plan
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)
Subject/Topic
Diagnosis
Sentinel Event (observation?)
Program
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:
Here's an example of a "contract" class about assigning encounters to visits: https://github.com/openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/api/handler/EncounterVisitHandler.java
Transcripts
Audio recording of the call: Listen online or download (available after the meeting)