Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Child pages
  • 2016-01-25 Design Forum
Skip to end of metadata
Go to start of metadata

How to Join

 Click here to expand...

 

Audio, Chat, & Screen Sharing (latest Firefox, Chrome, or other WebRTC-compatible browser)

Audio Only (Telephone or your favorite VoIP client)

Be Prepared for Your Meeting

 

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:

Transcripts

  • Audio recording of the call: Listen online or download (available after the meeting)