Encounters & Observations OWA Sprint Announcement

Overview: Hi all, in this sprint, we will be migrating the existing legacy model for encounter and observation to the new OWA. The features we will be working on include; Create, view, edit & search functionalities on encounters. Create, view, edit & search functionalities on observations.

Objectives: Migrate CRUD features to React-Redux Write JS tests Improve UI/UX

Start Date: 04/08/2017 End Date: 18/08/2017

JIRA Board: #

Github Repo: https://github.com/openmrs/openmrs-owa-obsadmin Wiki Link: https://wiki.openmrs.org/display/docs/Encounter+and+Observation+Module

@cecilia Will this OWA support some of the needs in this thread Tabular Views of OpenMRS Data including exporting of Obs data to Excel/CSV?

@cecilia Hi, currently in my country we are adapting openmrs to a hospital. Where can I follow the project? I was checking the repository but it is still empty. I know React/Redux as well, are you guys accepting pull requests?

@cecilia great to see that this project is going to happen!

A couple of comments off the top of my head:

  1. It’s not clear to me why you’d need Redux here. Redux helps you effectively manage global state in more complex applications, but I would imagine that this app is going to be much more straightforward, e.g. “pick a person -> pick an encounter -> edit it”. So I wouldn’t add the complexity of Redux for this use case.

  2. Don’t think of this as “CRUD features”, you should be thinking of it as Data Management features. E.g. this isn’t the way to create encounters, it’s the way to delete/undelete them, edit them, after they’ve already been created through the normal UI.

  3. I personally hate the existing UI of these screens in the legacy UI, so it would be great if you can avoid replicating all its bad features, but can come up with a better flow! (For example my first thought is to redesign it so that it all flows from choosing a patient first, e.g. you choose a patient, then you have subsections for visits (listing them all in a pageable way), encounters (listing them all in a pageable way), obs (user would need to drill into them, e.g. by concept).


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.

Hi @kuteri Welcome to the OpenMRS Community :slight_smile: Contributors are always welcome to join. You can go through this Getting Started developer guide to get more details. Since you already know React/Redux you can also have a look at working on Open Web Apps. with the community.

Thank you all for your feedback, we have considered your input as we brainstormed on the UI/UX. Below is a link to the post on mockups. Please have a look.