@cecilia,
To build on @darius’ comments…
+1 to Darius’ point that this is a data management feature and not the mechanism for creating new data.
Some history & context may help in understanding how visits, encounters, and observations relate:
When we started with OpenMRS all clinical data were collected on encounter forms. The clinical data on encounter forms (e.g., height, weight, heart rate, lab test results, answers to questions, etc.) were all stored as observations. This meant a patient coming to the clinic would have an encounter with 0-to-n observations inside it.
Later on, the simple encounter form (one encounter per clinic visit) was insufficient for all our use cases. Patients would come to clinic and have multiple encounters (e.g., a lab encounter, an encounter form completed by a triage nurse, another encounter form completed by the doctor, etc.). In other implementations, they were using OpenMRS for the hospital and wanted to track a hospital visit, which could span days and have dozens of encounters. We also had added more clinical data beyond observations (e.g., orders). So, we came up with these definitions:
-
Encounter: a single point in time interaction between the patient and the care system. An encounter may contain diagnoses, observations, and orders. In the future, encounters will also include notes. Encounters still align closely to a paper encounter form.
-
Visit: an interaction between the patient and care system that may span a period of time (hours, days, weeks, or more). A visit may contain one or many encounters. The most common use for visits are (1) a clinic visit and (2) a hospital admission.
It’s worth noting that we allow encounter outside of visits. For example, a lab report from an external lab may be recorded as an encounter (with the lab results as observations in that encounter) without requiring a visit to contain it.
So, encounters may contain 0-to-n observations, orders, and diagnoses. In the future, notes as well. Encounters may optionally be grouped into visits, with 1-to-n encounters in a visit.
Given this design, here are some additional thoughts:
-
Allow visits to be collapsed, especially if they contain a large number of encounters.
-
Avoid building a UI that assumes all encounter will be part of a visit. I would picture encounter as an optional, logical grouping of encounters rather than a required parent to encounters.
-
Clinical data are most often viewed in reverse chronological order (most recent data first).
-
Personally, I would favor keeping observation management architecturally distinct from visit & encounter management. Since encounter may already contain more than just observations, it’d be better, IMHO, to have a distinct tool for editing encounters that can grow to include not only observations, but also diagnoses, orders, and notes in the future. Instead of trying to make one massive tool to handle everything from visits down to every piece of an encounter, I’d favor a nice tool for managing browsing/searching and managing the metadata of encounters within visit and allow a separate tool to deal with the business of managing the content of an encounter. Even if we don’t tackle it at first, there’s plenty of business just within visit & encounters (e.g, visit attributes, encounter roles, etc.) without getting into the details of obs/orders/diagnoses/etc. We can decide whether the encounter editing is embedded or links to another page, but separating the business of visit/encounter management from encounter contents management (obs/orders/etc.) would be a good direction to go, IMHO.