Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Documentation

Page tree
Skip to end of metadata
Go to start of metadata

Background

During the OpenMRS Implementers meeting in 2009, we designed a way to expand on single-form encounters into the notions of visits and episodes of care.  Encounters become a representation of a clinical transaction (a combination of orders, observations, notes, and/or metadata collected at a point in time) and are grouped within visits (e.g., clinic visit, hospitalization, emergency room visit, etc.).  Episodes of Care are a grouping of encounters and/or visits related to a single topic (e.g., all encounters relating to a pregnancy).

Definitions

 

Description

Examples

Encounter

A clinical transaction.  One or more providers generating a set of data (orders, labs, notes, and/or observations) for a patient at a point in time.

  • An encounter form entered during a patient visit
  • A doctor writes some orders and a note in one "ordering session" during a hospitalization
  • A set of lab results delivered to the EMR

Visit

A group of one or more encounters that typically occur within a contiguous span of time.

  • A clinic vist
  • A hospitalization

Episode of Care

A collection of visits and/or individual encounters that a related to a condition or treatment plan.

  • A pregnancy
  • Treatment of hepatitis over 1 hospitalization and multiple clinic visits

Designing Episodes of Care

Per the notes taken during the implementers meeting 2009, the episode table would be designed as:

episode

column

description

episode_id

internal primary key

patient_id

patient to whom episode applies (is this redundant, since we're grouping visits & encounters which already link to patient?)

episode_topic

defines the type of episode, probably a link to a concept (e.g., pregnancy)

start_date

date on which episode began (could be earlier than first encounter/visit)

end_date

date on which episode ended (could be later than last encounter/visit)

voided

true if episode voided

voided_by

who voided episode

date_voided

date episode was voided

creator

who created this row

date_created

when row was created

episode_visit_map

column

description

episode_visit_map_idinternal primary key

episode_id

link to an episode

visit_id

link to a visit that is within the linked episode

voidedtrue if voided
voided_bywho voided link of visit to episode
date_voideddate link of visit to episode was voided
creatorwho created this row
date_createdwhen row was created

We would link visits to an episode only when all encounter(s) within the visit are part of the episode.

episode_encounter_map

column

description

episode_encounter_map_idinternal primary key

episode_id

link to an episode

encounter_id

link to an encounter that is within the linked episode

voidedtrue if voided
voided_bywho voided link of encounter to episode
date_voideddate link of encounter to episode was voided
creatorwho created this row
date_createdwhen row was created

We would link encounters to episodes when other encounters in the same visit are not part of the episode.

Relationship to programs

There is a similarity to programs, which track programs of care.  Episodes of care differ in that they only represent a grouping of encounters & visits -- i.e., episodes do not have to be part of a patient program of care and episodes would not directly reference study protocols, workflows/states, etc.  Once episodes of care are realized within OpenMRS, then programs could link to episodes to define the set of encounters/visits that are part of the program of care.

Since each program requires a concept (program.concept_id), an episode of care (and all of the visit/encounters it contains) can be related to a program by setting the episode_topic to this concept.

2 Comments

  1. Based on discussion in the 2016-01-25 Design Forum, when considering episode_topic we may want something that sits above Episodes of Care, Programs, Conditions, and Care Plans to provide the "glue" to relate these various resources. For example, a episodes of care may be related to one or more treatment program, they may be related to a condition, or they may be related to an aspect of a care plan. Rather than trying to build the inter-relationships into each of these resources, we may be better served to define the resources independently and then add a resource above them to create flexible relationships between them.