4 Must-Do’s

1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves).

2. User Stories: Have you clearly written at least 3 user stories and use cases?

3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here)

4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement?

Optional/Encouraged

Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!)

Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can?

Later but should do

QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)?

Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those?

This checklist was inspired by this article. Additional Business Analyst Resources here.

Status: Requirements In Progress In Progress

Technical Complexity: Easy Medium Hard / Complex

Summary:

Clinicians recording a diagnosis in the Visit Note currently have to re-enter the same information in the Conditions module if the diagnosis is a long-term condition; this feature eliminates that duplication.
An affordance on each diagnosis lets the clinician promote it to the patient's Conditions list (as Active) or to Past Medical History (as Inactive) with a single click, with a visual cue when the condition already exists.

Picture showing what this project is about (e.g. a key mockup, drawing; anything visual)

1. Problem

Imagine a clinician in a busy outpatient clinic. She sees twelve patients before noon. Three of them are newly diagnosed with Hypertension. For each one, she documents the diagnosis in the Visit Note - then stops, navigates to the Conditions module, and types the same diagnosis again so it appears on the patient's ongoing Conditions list. That's six entries for information that was captured three times. By the end of the week, she loses a lot of time as a result of these re-entries. Worse, when she's rushed, she sometimes skips the Conditions module altogether, leaving the patient's record incomplete and inconsistent.

This is the problem. The Visit Note and the Conditions list are two separate modules, but for chronic diagnoses, they are recording the same clinical fact. The clinician should only have to record it once.

2. User Stories

As a clinician, when I add a diagnosis in the Visit Note that is not already on the patient's active Conditions list, I want a one-click option to add it as an Active condition, so that I don't have to re-enter it in the Conditions module.
As a clinician, I want to be able to add a diagnosis as an Inactive condition (past medical history), so that the patient's longitudinal record is complete even for resolved or historical diagnoses.
As a clinician, when a diagnosis I've entered is already on the patient's active Conditions list, I want a clear visual indicator in the Visit Note, so that I can distinguish between new and pre-existing diagnoses at a glance.
As a clinician, when I search for a diagnosis in the Visit Note, I want to see an "On conditions list" indicator next to any concept that already exists as an active condition, so that I know before I select it that no further action will be needed.
As a clinician, after I have promoted a diagnosis to the Conditions list in the current session, I want the corresponding action button to appear dimmed so that I do not accidentally promote the same diagnosis twice during the same visit.

3. Market Analysis

1: Bahmni: Conditions can be added or viewed directly alongside diagnoses.

4. Technical Considerations & Dependencies

The changes for this feature should be made on the Visit Note by adding the action buttons to the diagnosis section.
The Conditions screen itself does not need to change (MVP). It will simply reflect the new condition once it's been added.
When a clinician opens a Visit Note, the system checks the patient's existing Conditions list. It then compares each diagnosis entered against that list:
- If a match is found → show the "Already on conditions list" badge. No action needed.
- If no match → show the "Add as Active condition" and "Add to Past Medical History" buttons.
When the clinician clicks a button, the system creates a new entry in the Conditions list using information that's already there - the diagnosis name and whether Active or Inactive. No additional data capture is required.
The onset date is intentionally left blank; the clinician can fill it in later if they know when the problem actually started.
After adding a condition via the Visit Note, the Conditions screen refreshes automatically without requiring the clinician to reload the page.

Out of scope for V1

Smart concept matching, e.g., recognising that "Acute exacerbation of COPD" should map to "COPD" on the Conditions list. This requires specialist terminology work and is planned for a future iteration.
Populating Visit Note diagnoses from the Conditions list (the reverse direction).
Any automatic promotion without the clinician's confirmation.

5. Sketches

Visit Note:

+Active Condition:

Snack bar: Added as an active condition

Already on the conditions list:

+Past Medical History:

Snack bar: Added to past medical history