Support for Visits (Design Page)

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

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

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

Value	Description
E	Emergency
I	Inpatient
O	Outpatient
P	Preadmit
R	Recurring patient
B	Obstetrics
C	Commercial Account
N	Not Applicable
U	Unknown

Archives