Support for Visits (Design Page)

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

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:

/* Return visit for encounter. May be null. */
Visit getVisit();

/* 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>);

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);

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)

See Also

• TRUNK-48: Add "Visit" to data model