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

This project is assigned to the OpenMRS 1.9 release milestone

Label for project: support-for-visits

Background

When OpenMRS started, the primary use case for capturing data was transcription of clinical encounters into the EMR: during a patient visit to an outpatient clinic, data were recorded on a paper encounter form and this was later transcribed into the EMR.  The model was simple: one patient visit ? one paper encounter form ? one encounter within OpenMRS (with 0-to-n observations within each encounter).  As use of OpenMRS has grown, we've reached a point where this model is insufficient.  In a growing number of use cases, implementations have more than one form during a patient visit.  We also want to evolve toward support for inpatient care.  To accommodate these changes, we introduced the notion of a "visit".

Design

Data Model

visit

Definitions

  • Visit: encompasses one or more encounters to describe an event where the patient has interacted with the healthcare system.  Visits may occur within minutes/hours or may extend over days, weeks, or even months (for an extended hospitalization).  Examples of visits include an outpatient (clinic) visit, a hospitalization, or a visit to the lab.  In many cases, the patient is physically present; however, this might not always be the case: in the case of a telephone "visit" the physician calls the patient and writes a note and/or some orders as a result; for a documentation "visit" the provider may simply be writing some orders based on labs received between clinic visits.  For billing-related systems, the "visit" is typically where the account number would fit.
  • Encounter: is a "clinical transaction" in which a group of data (e.g., observations, notes, and orders) are recorded.  Encounters generally happen at a point in time and involve one (or a few) providers.  Examples include the paper "encounter form" with which OpenMRS started, an order entry session, a daily note & associated orders written for patient while they are in the hospital, etc.
  • Visit type: represents the assortment of visits available to an implementation.  These could include items like "Initial HIV Clinic Visit", "Return TB Clinic Visit", and "Hospitalization".
  • Visit "class": allows for categorization of visit types into INPATIENT vs. OUTPATIENT vs. EMERGENCY.  The intent of this is to provide something similar to HL7's PV1-2 "Patient Class" (see codes in Notes)

Classes / API

Visit (implements OpenmrsData)
    Integer visitId (required, primary key)
    Patient patient (required)
    Location location
    Date startDatetime (required)
    Date endDatetime
    Concept indication // defined by implementer (chief complaint, admission diagnosis, billing code, ...)
    VisitType visitType (required)

VisitType
    Integer visitTypeId (required, primary key)
    name, etc (from OpenmrsMetadata)
    VisitTypeClass visitTypeClass (required)

VisitTypeClass = enum (INPATIENT, OUTPATIENT, EMERGENCY, TELEPHONE, ...)
    inner class in VisitType

+ encounter.visit_id references visit (can be null)

The API needs:

Encounter
/* Return visit for encounter. May be null. */
Visit getVisit();
EncounterService
/* Returns all encounters grouped within a given visit */
List<Encounter> getEncountersByVisit(Visit);

/* Include visits as a parameter in search for encounters */
List<Encounter> getEncounters(..., List<Visit>);
VisitService
List<Visit> getAllVisits();
List<Visit> getVisits(VisitType, Collection<Patient>, Collection<Location>, Date minStartDatetime, Date maxStartDatetime,
    Date minEndDatetime, Date maxEndDatetime, Collection<Concept> startReasons, Collection<Concept> endReasons);
List<Visit> getVisitsByPatient(Patient);

/* Returns visits with startDatetime in the past and endDatetime in the future or undefined */
List<Visit> getActiveVisitsByPatient(Patient);
Visit Classes

Requirements

  • Visit.location should be optional (nullable)
  • A visit may exist without any encounters
  • An encounter may exist without a visit
  • Start with visit class as enum (INPATIENT, OUTPATIENT, EMERGENCY, NOT APPLICABLE, UNKNOWN).

Notes

Visit will surely need additional attributes (e.g., diagnoses, account number(s), "visit attributes", ...)

  • Can encounters exist outside of a visit?  This would be more backwards-compatible, but could make working with the API more cumbersome (i.e., having to always account for visit-less encounters).  ANSWER: Yes.
  • How will existence of visits affect the user interface? (short-term, long-term)

HL7 PV1-2 Patient Clas

to be: (aka visit_type.visit_type_class)

Value

Description

E

Emergency

I

Inpatient

O

Outpatient

P

Preadmit

R

Recurring patient

B

Obstetrics

C

Commercial Account

N

Not Applicable

U

Unknown

See Also

4 Comments

  1. If encounters can exist without a visit, how does this effect the UI and API?

    • API presents visits, which may not include all encounters for the patient.
    • When rendering encounters/visits, visits would provide grouping only when they exist.
    • Would probably need to include account information at the encounter level as well (in the future) if account info is needed at the encounter level for visit-less encounters.
  2. Unknown User (darius)

    Initially, adding visits should have a very minor impact on the UI:

    • Add an (optional) patient dashboard tab for Visits, with an Add Visit button
    • On the encounter patient dashboard tab, add a column for Visit
    • There should be an Edit Visit page that shows a list of encounters with links to their edit pages, and an Add Encounter button (similar to the Edit Encounter page)
    • Edit encounter should let you specify a visit (from existing visits for the current patient)
  3. I've been thinking about the visit_type.visit_class attribute.  The classifications feel somewhat arbitrary and unclean (they're not always mutually exclusive), so I wonder to what extent we can (or need to) program against specific classes.  At first blush, classifying visits into "inpatient" & "outpatient" seems clean.  As this extends to "emergency" and others, it gets messier.  Tagging of visit types would allow for a much richer & more flexible system for categorization.  Unless we truly need specific classifications for core OpenMRS to work with visits, I'm leaning toward removing visit_type.visit_class from the data model altogether and let visit tags & visit attributes fill the need for organizing visits.  If we come up with a visit classification that needs to be pre-defined for core OpenMRS to function, then we can re-visit (pun intended) the notion of visit_type.visit_class.

    Thoughts?  Concerns?  Reply to this comment.

    1. Discussed on Weekly Design Review Meeting on 6-April-2011.  We decided to punt visit_type.visit_class, allowing people to manually categorize visit types until we add tagging.