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 getVisit() EncounterService getEncountersByVisit(Visit) getEncounters(..., List<Visit>) ??? VisitService getAllVisits() getVisits(VisitType, Collection<Patient>, Collection<Location>, Date minStartDatetime, Date maxStartDatetime, Date minEndDatetime, Date maxEndDatetime, Collection<Concept> startReasons, Collection<Concept> endReasons) getVisitsByPatient(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 |
---|---|
E |
Emergency |
I |
Inpatient |
O |
Outpatient |
P |
Preadmit |
R |
Recurring patient |
B |
Obstetrics |
C |
Commercial Account |
N |
Not Applicable |
U |
Unknown |
See Also
- TRUNK-48: Add "Visit" to data model