Links to Know

• Key Contacts: @Fiona Anderson (PIH) @Veronica Muthee (GPST) @robaikisia (AMPATH)

• Communication:

• Designs: 

• 
  Code: 

In this page: 

In this wiki:

Sample Visual

Problem & Goal

O3's clinical workflows are designed primarily for point-of-care (POC) data entry. In real deployments, data routinely needs to be entered after the fact — because the system was down, the clinic temporarily reverted to paper, or data was captured at a site without connectivity. End users need a first-class way to add, edit, and review past clinical data so the patient chart is accurate, without disturbing any currently active visit.

Goal: Allow authorized users to create and complete past (retrospective) visits — including forms, observations, orders, and results — with clear validation and clear visual separation from the active POC visit. 

Key Definitions

Market Analysis

How O2 RDE Works Currently (AMPATH)

⑴ RDE is enabled from the logged-in user's menu ("Retrospective Data"), which opens a settings page: an Enable Retrospective Data Entry checkbox revealing Paper Forms Provider, Original Visit Date, Original Visit Time, and Location. Once saved, a persistent yellow banner rides above every patient header showing Provider · Location · Visit Date with an Update Settings button. Starting a visit then creates a real backdated visit (labelled "…started retrospectively"), and forms entered land inside it. The mode is global to the session and persists across patients.

Scope

• Creating, editing, and closing visits dated in the past ~ ~ without affecting the active visit.

• Adding, editing, and voiding encounters/forms within a past visit ~ without affecting the active visit.

• Adding retrospective drug orders and lab/test orders to a past visit.

• Entering lab results and associating them with the correct past visit.

• Clear UI differentiation between retrospective entry and the active visit. Examples

• Banner providing an explicit Exit retrospective mode (AMPATH O2 Parity)

• RDE exits automatically on logout

• When the user opens a different patient while RDE is on, the system prompts to confirm the RDE date still applies ~ should not silently inherit the prior content.

• Allow the user to add a form/encounter to a past visit. A captured form is saved as an encounter within the selected visit, with the encounter datetime taken from the RDE date/time capture and defaulting within the visit window.

• Add an RDE visit tag whenever the visit chosen is dated in the past

• Date inheritance ~ default dates based on the RDE dates ~ vitals, orders, forms

User Stories

More detailed use cases documented here:

RDE Improvements 2026 ↔ 3.9.0 Release Target

Discussion Points for RDE Design Inputs:

• Visit context in the patient banner: banner stating which visit you are working with, and everything visit-sensitive hangs off it

  • A visit context header in the patient banner naming the visit in context (type, date/time, location). Does putting visit context in the banner make it unmissable?

  • An End button on the active-visit context header, with a confirmation modal and a "Visit ended — no visit is in context" toast. Is End the right affordance here, and is one confirmation step enough?

  • With no visit in context, the banner shows entry buttons: "Add visit" (POC/Both) and "Select past visit" (RDE/Both). Are two side-by-side buttons clear, or should this be one button with a menu?

  • A "Past Visit" chip on the banner during RDE, with a one-click exit (✕). Is the chip + ✕ a sufficient and discoverable way to leave RDE?

• Signalling that you are in the past: how loudly should the UI shout that entries will not be dated today?

  • The entire chart background changes colour in past-visit context. Is a full-page colour change the right move?

  • Colour semantics: peach/orange = past visit context? Other suggestions?

  • RDE styling activates when a past date is chosen, not when the form is opened. Is "on date chosen" the right trigger point?

  • A PAST VISIT tag in every workspace header (peach), so the signal follows you into forms. Is repeating the tag in each workspace helpful reinforcement or visual noise?

• Entering RDE & choosing the visit: How a user gets into a past visit, and how they find the right one among potentially many.

  • A dedicated "Add/Edit past visit" action, separate from "Add new visit" (renamed from "Add visit"). Do the two labels clearly communicate today vs. past?

  • Where the past visit is selected: from the patient banner vs. inside the Add/Edit past visit form. Which entry point do you prefer, and why?

  • A combo-box "Select past visit" listing existing visits (date · type), placed above the date fields. Does a combo-box scale for a patient with 10+ years of visits?

  • Selecting an existing visit pre-populates the form (dates and visit type) from that visit. Should selecting a visit pre-fill and stay editable, or lock the fields?

  • The New/Ongoing switcher is hidden entirely when adding a past visit. Is hiding it right, or does removing the control lose orientation?

  • Date fields use the blank dd/mm/yyyy format (as in registration), with no default date pre-filled. Is starting blank correct, rather than defaulting to today?

  • Times default to 12:00 AM start / 12:00 PM end, both editable. Should we capture time at all for a past visit, or date only?

• Duplicate visits & conflict handling: What happens when a visit already exists on the chosen date?

  • Inline resolution message: "No visit exists on {date}. A new past visit will be created" vs. "A visit already exists on {date} ({type}). Is stating the outcome before the user commits helpful, and is the wording clear?

  • The duplicate case is a warning (amber), not a block — "Are you sure you want to add a similar visit?". Warn-but-allow, or hard-block duplicate visits on the same date and location?

  • When a visit exists, entries attach to it rather than creating a parallel one. Is silent attachment right, or should the user explicitly confirm "add to existing visit"?

• Date behaviour inside workspaces: Once you're in a past visit, what date does each form use — and can the user override it?

  • Vitals & Biometrics are stamped with the visit's date/time, not the moment of entry

  • Clinical form onset dates are capped at the visit date

  • Visit Note shows the inherited visit date

  • Lab (test) orders have no date of their own and take the visit date

  • Drug orders inherit the visit date as prescription start

• What can be entered retrospectively: is RDE about visits, or about backdating anything? We initially restricted RDE to visit-context data only, which would have blocked a clerk from entering a historic allergy or immunization. Is this the right conceptual split?

  • Visit-bound data (vitals, notes, orders, forms) attaches to the visit;

  • Patient-level records (allergies, conditions, immunizations, procedures, programs, attachments) are backdated but not tied to a visit.

    • Each patient-level record carries its own clinical date (onset/vaccination/procedure/enrollment/document date), defaulted to the RDE date but changeable.

    • Is defaulting these to the RDE visit date helpful, or presumptuous?

  • The "No active visit" modal is retained for visit-required workspaces when no visit is in context.

• Downstream apps: RDE doesn't end at the chart - orders, labs, and dispensing all inherit the date.

  • The Orders app shows the past-visit date as the order date, not the entry date. Should the orders table show the clinical date, the entry date, or both?

  • Lab orders placed retrospectively flow into the Laboratory app's "Tests ordered" queue like any other.

  • The dispense date defaults to the past-visit date in the Dispensing app.

  • Saved entries surface in the Visits app under the correct past visit, dated to it. Does the Visits app need to distinguish retrospectively entered encounters from live ones?

• Roles & permissions: Who can do retrospective entry at all, and how capability differs from a point-of-care user

  • RDE as a separate privilege, not a mode everyone has. Users are POC, RDE, or Both.

  • Requiring both start and end date for a retrospectively created visit.

• Others:

  • A guided walkthrough / narrated tour of the RDE flow for training.

  • Metadata for records: "Added retrospectively on {date} by {user}, dated to visit of {date}".

Sketches / Mock-Ups

(Based on Discussions with Veronica, Fiona, and Chi Bong on July 22, 2026)

These mock ups are meant to aid the design conversation but should be considered a draft that can be added to or modified. Some considerations:

• Even when you are in “past visit mode” the Active/Unpaid/Outpatient Consultation/Not Urgent tags are still visible. Is it confusing that these tags remain while in past visit mode? They have nothing to do with the visit that was selected.

• Should a user always be forced to pick a visit context when navigating to a patient chart? Right now you automatically “go in to” the Active visit when a patient has an active visit. If the user is forced to pick the context before they start entering data would that be clearer or cumbersome?

1. Include a Past Visit menu item in the Actions menu. This will allow the user to select a past visit or create a new past visit

Open

2. When Past Visit is selected, the user can select from a Past Visit or create a new past visit

Open

3. When the user selects the past visit and enters Past Visit Mode, they are limited to entering only data that requires a visit context (Forms, Orders, Visit Notes, Vitals). The Add+ buttons are removed from the chart. Once the data is entered, the user can click Done-exit past visit mode and return to the current Active visit.

Open

Previous mockups:

• In the past, switch the chart into RDE.

  • Patient banner now turns peach/apricot with a peach PAST VISIT chip that doubles as the quick-exit

  • New / Ongoing / In-the-past helper texts added

Open

• Recording Vitals & Biometrics retrospectively:

  • Observation stamp date - should be as per the past visit date selected

Open

• Recording Visit note

  • Visit date should inherit the visit as selected in the select a visit modal.

Open

• Recording Lab orders

  • Date of order stamp - should be as per the past visit date

Open

• Recording Drug Orders

  • Date of order stamp - should be as per the past visit date

  • Prescription date should inherit the past visit date selected (currently defaults to today)

Open

Open

Dispensing

Open

Clinical Forms

Open