When a clinician records a diagnosis via the clinical note — and that diagnosis happens to be a lifelong condition like Type 2 Diabetes or Hypertension — shouldn’t that automatically form part of the patient’s Conditions list? Currently, the system does not support that.
The clinician has to fill in a clinical note, and then separately navigate to the Conditions module to capture the same information again. How can we avoid re-entering information that has already been documented during the visit?
When a qualifying diagnosis is saved, can we have a system prompt to “Add Diagnosis to the patient’s ongoing Conditions"? — with a Yes / No option.
Upon confirmation, the system automatically creates the Condition — sets the status to Active, sets the onset date to the current encounter date, and no additional data capture (in the Conditions module) is needed.
If the condition is already on the patient’s Conditions list, the system skips Condition creation - to avoid duplicate Conditions.
Any Condition promoted from a diagnosis can be updated as needed, i.e., the status and onset date.
I am new to OpenMRS development, but this idea sounds very helpful for users. It would save time because a long‑term diagnosis (like diabetes) could go straight into the patient’s Conditions list instead of typing it again.
I like the confirmation step and the check to avoid duplicates. I am still learning the codebase, but I would be interested to follow how this could be implemented and help where I can.
This goes in both directions: we want to make it easy to populate the condition list from encounter diagnoses and populate encounter diagnoses from the condition list.
My preference would be to have an option next to each diagnosis that isn’t already on the condition list that allows them to add the entry to the condition list. A slightly fancier approach would be an action button that gives choices of “Add to condition list” and “Add to past medical history” where the latter adds it as an inactive condition.
Having the affordance to add things to the condition list from the diagnosis list has a few benefits:
If only available for items not already on the condition list, it becomes a visual cue to distinguish between new & pre-existing diagnoses when looking at the list.
There’s no additional questions when adding a diagnosis. Some might want a checkbox in the diagnosis form to “Also add this to the condition list”, but then you have to deal with the case where it already exists. It could be the same amount of clicks to omit this checkbox and have them use the affordance on the diagnosis list.
No extra popups or dialogs needed.
Extra credit: having an temporary (until you re-render the list) “undo” affordance that lets you undo easily in the moment if you accidentally added the wrong entry to the condition list.
Please don’t do this. The onset date is an optional field and the relevant onset date is not the date diagnosed but the date something started being a problem.
We should maybe avoid adding an active condition, but adding it as historical seems still valid.
I would agree with @burke but also recognize that sometimes the visit Dx and condition are not identical but related (with condition often being somewhat more general). For example, the patient might have COPD, but their visit diagnosis is Exacerbation of COPD. Sometimes the visit Dx is highly specific like “sequelae of CVA” when perhaps it should be CVA on the condition list. I think we can at a minimum have a way to move identical concepts between the two lists, but we might want to add some intelligence particularly when elevating to condition list… (maybe even on using a condition on the visit where the user would be prompted to add specificity if appropriate).
Any ideas on how we can implement that sort of intelligence? I’m guessing CIEL doesn’t give us a mapping for relating “sequelae of CVA” to “CVA”, but could we leverage, e.g. snowstorm and the CIEL SAME-AS mappings?
Might be possible using SNOMED’s maps from CIEL. For ICD-11-CM there was a clear breakdown between billing codes and higher level codes, but I think this might be something which will have to be curated for common terms. Perhaps AI can help with that curation, and CIEL could consider adding that functionality if we had a way to maintain it.
Great inputs. Indeed a diagnosis during an encounter may either be a new or a pre-existing diagnosis - so having a way to distinguish/capture that is certainly important.
That’s right….the onset date reflects when the problem actually started, not when the clinician recorded the diagnosis and those are very different dates. Defaulting to the encounter date would certainly be inaccurate.
Thanks for bringing up this important nuance and i wonder if we can use this to draw the line between V1 (promotion of identical concepts) and future iterations. The idea of using AI sounds very interesting (though i don’t know the level of complexity on the same).
Quick recap: Clinicians recording a diagnosis in the Visit Note currently have to re-enter it in the Conditions module when it’s a long-term condition. This feature adds a one-click affordance on each diagnosis to promote it to the patient’s Conditions list, with a visual cue when the condition already exists.
Before I go further, there are three scope decisions I’d specifically like reactions to:
1. Encounter diagnosis vs. past medical history. My leaning is to promote to Active only from the Visit Note, and leave historical/inactive conditions to be managed in the Conditions module. Promotion happens at the point a problem is diagnosed, so “active” is the natural default; back-dating something as inactive/resolved feels like a deliberate Conditions-module task rather than a quick inline action. Do we agree, or is a “promote to Past Medical History (Inactive)” option worth keeping?
2. Classifying which diagnoses are eligible. For V1, should we add any classification so that acute diagnoses (malaria, pharyngitis, a sprain) are kept off the list - is there a way to do, or do we leave the clinician to make that judgment?
3. Onset date. Onset is left blank on promotion, with an optional month field, since the diagnosis date isn’t necessarily when the condition actually began. The clinician can fill it in if they know it, or set it later. Any objection to the optional month field suggestion?
Onset is left blank on promotion, with an optional month field […] Any objection to the optional month field suggestion?
No objection to blank-by-default, that sounds correct to me. On the month field specifically: our OpenmrsDatePicker is day-precision only (no month/year mode), so a month-only input is a custom control rather than a prop. And the backend stores onsetDate as a full timestamp, so a month gets persisted as the 1st of that month and the granularity isn’t retained. Month-only would be a UI convention we maintain, not something the data model honours. The Cheapest v1 of this feature will likely be the existing day picker (optional, blank); a real month picker can follow.
1. Encounter diagnosis vs. past medical history. My leaning is to promote to Active only from the Visit Note, and leave historical/inactive conditions to be managed in the Conditions module. Promotion happens at the point a problem is diagnosed, so “active” is the natural default; back-dating something as inactive/resolved feels like a deliberate Conditions-module task rather than a quick inline action. Do we agree, or is a “promote to Past Medical History (Inactive)” option worth keeping?
Actually, I don’t know about making users go to conditions module to cleanup resolved problems. I would think that during the visit they could say a problem should move to PMH. However, what is the definition of an “inactive” PMH? It is active PMH, just not an active condition. Perhaps this needs clarification.
2. Classifying which diagnoses are eligible. For V1, should we add any classification so that acute diagnoses (malaria, pharyngitis, a sprain) are kept off the list - is there a way to do, or do we leave the clinician to make that judgment?
This seems like a knowledge management task which could get difficult. I wouldn’t think we should decide for the user, except for obvious things like pregnancy > 9 months long.
3. Onset date. Onset is left blank on promotion, with an optional month field, since the diagnosis date isn’t necessarily when the condition actually began. The clinician can fill it in if they know it, or set it later. Any objection to the optional month field suggestion?
Thank you for the great feedback. I have removed the ‘Past Medical’ section. Seems like option 3 is not feasible, as it needs concept-level classification (concept attribute, “chronic conditions” set, or concept class) that FHIR2 doesn’t expose today, and it’s the one piece that we can defer in the V1 scope.
Mark as inactive (in remission): The diagnosis being entered is already on the conditions list with a status of Active (e.g., Asthma). This allows the clinician to quickly update the status from “Active” to “Inactive”.
Mark as active again: The diagnosis being entered is already on the conditions list but is currently flagged as Inactive (e.g., Epilepsy). This is the reactivation and allows the clinician to move an old or dormant chronic condition back into an "Active " status.
Not a long-term condition, cannot be promoted: The diagnosis being entered is an acute or transient issue rather than a chronic illness (e.g., Dysphonia). This is a disabled/informational state that doesn’t require promotion.
Add as active condition: The diagnosis being entered is a long-term/chronic condition but does not yet exist anywhere on the patient’s permanent conditions list (e.g., Type 2 diabetes mellitus). This is the core “promotion” action. Clicking it instantly creates a new entry in the patient’s main Conditions list and automatically flags its status as “Active.”
The pendulum may have swung too far, bringing too much condition management into the visit form. The visit form should focus on encounter diagnoses and leave condition management to the condition list, IMHO.
My advice would be:
Make it easy to tell whether or not an encounter diagnosis is on the patient’s condition list
For those encounter diagnoses that are not on already on the condition list, being able to add them to the condition list with one or two taps.
When adding encounter diagnoses, have an affordance that makes it easy to pick from the list of conditions that are not already in the encounter diagnoses.
It’s easier for me to imagine doing this with encounter diagnoses in a table (i.e., adding a column indicating whether the diagnoses in the condition list that either shows a checkmark or an affordance to add the item to the condition list (maybe a plus sign?).
Something like a “Select from condition list” affordance next to the search boxes could present a dropdown of active conditions not already in the encounter diagnose list to quickly (2 taps) add conditions to the encounter diagnoses.
One high-level comment I’d make, I’d think consonant with Burke’s worry about there being “too much condition management in the visit” form is that having this large amount of screen space eaten up by this for every diagnosis suggests that promoting diagnoses to conditions is something we’re expecting to have happen frequently.
I think UX-wise, we want something much smaller. I.e., maybe we render each diagnosis as a pill and in an extension menu from that pill we have the ability to manage the condition status. This keeps that out of the main form where it’s mostly noise and distraction. I’d anticipate we just need to modify the existing UI to add a
to the existing pills to build in this functionality.
to the existing pills to build in this functionality.
