Streamlining retrospective data entry in OpenMRS for improved usability and traceability
Problem
Users cannot add Encounters to a past visit in the O3 UI during an Active Visit. For example, a provider wishes to retrospectively add an Order that was not documented during a previous visit.
There is no simple link between a past Visit and the forms that make up its Encounters.
Context and cause
Editing encounters: Users are only able to Edit some Encounters. This may be due to a bug with the form engine used to create the original Encounter.
Adding Encounters: User cannot Add an Encounter to a Past Visit during an Active visit
In-efficient user flows: To add Encounters, a User would need to start a new Visit with the date and time set in the past
Confusing visual states: Users feel that the correct approach to adding past data involves ending an Active visit and starting a new, retrospective visit. When information from a previous visit is added during an active visit at the point of care, a lab result, for example, users may be confused with the state of the Visit Header component. Switching āmodesā is confusing and may result in data inaccuracies. Clearer visuals that a past Encounter is being edited or added should be considered.
Sub-optimal proximity of Visits and Forms: O3 has numerous different ways of adding data; the order basket, visit notes, forms. This means for a User, adding to or editing a past visit requires interaction with one or more different forms. There is no simple link between a past Visit and the data entry components now.
Traceability: Itās currently not easy to track if changes were made, who by and when.
Objective and outcome
A simpler, streamlined approach to reviewing past data and retrospective editing / entry in OpenMRS that improves usability, efficiency, and traceability.
Proposed solution
Overview of the proposed updates to the information architecture and data entry workflows.
Areas to explore:
Streamlined user flow: Introduce a streamlined user flow to add or edit encounters from past visits, reducing the time and effort needed. Adhere to the UX principle of law of common region.
Enhanced traceability: A user should be able to easily track and review changes made to patient data, including whatās happened during a current visit. It should be possible to see who did what during a visit and who edited it later.
Clear retrospective entry mode visual: Users should be aware through clear visuals that they are editing or adding data to a past visit, even if they are in the context of an Active Visit.
Benefits
Improved efficiency: Faster data entry and updates, reducing the screen time burden on providers
Improved data quality: Easier data editing and tracking lead to more accurate patient and more complete records.
Better UX and simpler adoption: A more intuitive interface reduces the learning curve (and training time) and enhances satisfaction among users.
Demo
Scenario: A user wants to add an Order to a previous visit, during an Active Visit.
The User locates the Visit they wish to an an Order to on the Visits page
They click Edit then Add or Edit Encounters
They first review the Encounters, then select Add an Encounter
The user selects Order form from the list and clicks Add Encounter
The Order form opens, with a clear message about Retrospective data entry and the user continues to fill out the form.
The Encounter is added to the past Visit and the meta information indicates who added the update and when.
Thanks @pauladams for putting together this demo. I think this is definitely an improvement over the current state. I have a few questions, though, about the expected behavior:
If the user switches between workspaces, is the data entered into other workspaces expected to be recorded against the current visit or the edited visit? I.e., are we switching the visit context or just allowing the adding / editing of a single encounter at a time?
How would the retrospective editing notification work if, e.g., the user was editing a long form? Is it intended to always remain visible or can the user scroll past it?
Would it change anything about the designs if the user was editing a past visit for a patient who does not currently have an active visit?
If the user is working in an Active visit, e.g. todayās date and time, then adding (or editing) a past Encounter would only apply to the single Encounter they added or edited from the flow described. Filling an additional form from the Workspace UI would result in the data being saved as an Encounter for the current visit.
The retrospective notification would be sticky at the top with no way for a user to dismiss it.
In case of editing, no. The flow is the same. If an data from an entire visit is being added retrospectively (for example the power failed and the facility reverted to paper) and the user indicates that when creating (starting) a visit in the past - I think we should show the retrospective notification in these cases too, for consistency.
I see it perfectly matches a use case where a user needs to add a few number of encounters (1 or 2) to a past visit. So what you describe as:
It looks a bit heavy to cover for cases where users want to enter the documentation of an entire visit in the past (the case of a power cut the previous day). I think thatās what your point 3 mentions but Iām not sure I understand the envisioned user flow. Could you clarify?
In event that a user needs to add an entire visit, they should create a visit in the past and proceed as usual, no need to enter Encounter by Encounter using this flow.
We should include the Retrospective banner in all workspaces when the data is being added to a visit in the past though, regardless of whether its in an Active or Retrospective visit.
Thanks @pauladams - Itās great to see these capabilities being added, itās clearly a major blocker that one cannot easily review and amend a past visit. Any progress in this direction is a great step forward. A few things that, IMO, would help with clarity:
Start from a view that focuses on a specific visit, not from a view that shows every visit for the patient. From within that view, start from the part of the view that displays the current encounters.
Per the above, get rid of the modal. Start from the visit view that displays the encounters within the visit. More clearly connect the data entry workspace on the right with the view that is actually being displayed in the main body of the page and the aspect of that view that is implicated.
In general, this ties into my opinion that one of the big missing features within the chart is a view that summarizes one particular visit, and provides a place for a user to clearly review that visit and modify it as needed.
I think we can address your points by proposing some changes to the visit tile itself. If the visit tile reflected the Encounters and what happened in them, as opposed to starting with the Clinical Note (which we think is rarely used by O3 implementors), then you have a structure to review what happened and edit or add to it.
Youāre quite right that the list of Encounters in the modal is duplicating whatās in the Encounters listā¦ the intention here is that we ask a user to review those Encounters before tabbing to add a new one. That said, if Encounters formed the basis of the visit summary itself, there would be no need to do that.
We will need to keep in mind that many Primary Care providers have a need to quickly review 3 or 4 past visits for diagnoses, key pieces of information (usually clinical notes), meds prescribed and tests ordered. We will aim to maintain clarity around these pieces of information and allow for potentially adding extra data, such as patients flow in a facility.
Weāll updates the designs and come back here later this week.
We encountered a scenario that closely aligns with your objectives while developing a more efficient and user-friendly OPD workflow earlier on. The aim was to create a streamlined user flow for adding and editing encounters during an active visit. Our goal was to consolidate clinician tasks on one page. This approach was to ensure that clinicians providing OPD services can perform tasks such as adding orders, appointments, and filling additional forms, without navigating away from the main page. Instead, they could open the other workspaces directly on the page to complete these tasks.
Additionally, weāre using this opportunity to test a more structured visit note, inspired by the discussion initiated by @wamz and to explore an enhanced method of viewing forms through embedded view mode feature in the React Form Engine.
Let me know your thoughts on whether thereās potential for alignment and collaboration in this. Not sure if youāve already started development on this?
