There is a team at the OMRS17 Hackathon in Lilongwe, Malawi who are working on the Condition list for the RefApp. This has already been implemented in Bahmni. Thanks @darius.
These are (crude) mockups of the 2 pages:
Great to hear! This is an incredibly valuable addition to the RefApp.
What does the “Diagnosis List” widget represent?
Condition list (often called “problem list”) is typically used a list of diagnoses, symptoms, or findings that are being tracked over time (i.e., across encounters). It would probably be one of the first widgets on the dashboard. When I saw the screenshot, I thought the condition list had been titled diagnosis list (not a great choice, since conditions don’t have to all be diagnoses). Seeing condition list at the bottom, I’m assuming that’s the target of the hackathon, so I’m confused by the diagnosis list widget. Is the diagnosis widget just an artifact from not having condition list yet and will be replaced by the condition list widget?
Burke, your comments reflect the thinking of all those involved in the hackathon. The conditions are not just diagnoses, but also symptoms.
The group just added the new widget to the existing clinician facing patient dashboard. It is intended to be put where the existing diagnoses widget is placed. It is an open question on whether the existing diagnoses widget should still be somewhere on the page, but in a less significant place.
Please note the code is not complete.
[off-topic] 1.5 days for the hackathon was a bit too short. It takes the best part of a day to get people new to the specific development process the best part of a day to familiarise themselves with the environment. In this case that was refapp modules, sdk, gsp, etc. So another 0.5 day would have had significantly more progress.
Since we have a pretty good idea of what should be done, I suggest we write this module to completion and follow the correct practices. Writing code in1.5 days meant hard-coding stuff in the logic in order to have something by the end of hackathon.
Andrew
@burke.Has the team recorded any clips.For the OpenMRS University?I would really like to look at the Procedure?
i doubt if we did any recordings, checkout #OMRS17 for some pics probably
This is great! So nice to see the progress in such a short time. Wish you could have had more time to work on this. (Maybe it would be helpful to have a setup sdk workshop before the next OMRS conference or during some BOF so that it wouldn’t cut into the hackathon time.)
Some small comments:
Ellen
Thanks for working on this everyone, I will echo what @ball said about great to see so much progress in such a short time.
Where does this code live? We may be able to do some further testing and/or tweaks…
Take care, Mark
I’m assuming these were just default action icons. If I were guessing, I’d guess “+” and “-” to move items up/down the list, file icon to “file away” as inactive, and “x” to remove.
My expectation would be it would remove from the list (like the “x” on the list page).
While any of them are reasonable choices for the title, I’d probably go with “Conditions”, since it’s both forward-thinking and concise.
Condition lists are typically quick to grow and very difficult to maintain, because nobody takes the time to manage them. Therefore, I’m a big fan of single click removal from the list (lowest possible barrier to get something off the list). A confirmation can be avoided by providing an undo option.
Active conditions should be prioritized in views. Don’t show inactive conditions by default or show them separately.
Consider designing the condition management as a embeddable component, since it would likely be useful in multiple screens/forms.
Great start for a condition list UI!
On page 3 “Add condition”, what do you expect from the red “Remove condition” button?
The red button will be removed as it’s not useful on the page. Conditions will be removed from the manage lists page.
Where does this code live? We may be able to do some further testing and/or tweaks…
Here is the github link.
@burke and others: should conditions be added one at a time or multiple entries at a go (like most ref app add pages)?
Thank you all for the useful feedback!
Andrew
I would expect conditions to be added one at a time in most cases (e.g., like allergies), since we may want to allow additional information to be gathered alongside the condition as well as provide a screen (or DIV) modules could hook to add additional features or decision support in the future.
Hey folks, I have a lot to say about problem lists versus diagnoses (visit-specific) and history. Please see: Incorporating Encounter Diagnoses into openmrs-core
I would love to have a more interactive session about this where I could contribute. Hard to do this via a talk thread without a working version in front of me.
Andy
I think we’re in full agreement that encounter diagnoses, problem lists, and past medical history are distinct. If you have a lot to say on the topic (more than you can easily type into Talk), you could use om.rs/designtime to propose a design call on the topic and we could use that call to capture your input and bring it back to Talk or wiki docs.
I scanned FHIR resources again…
FHIR defines Condition as a general resource to represent “detailed information about a condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern” and then uses this Condition resource for encounter diagnoses, problem lists, and past medical history.
- Encounter diagnoses: Encounter.diagnosis to record a condition as it relates to a specific encounter.
- Problem List: List (with code=“problem”) of Conditions
- Past Medical History: From what I can infer, Questionnaire (presumably with type
item.type=open-choice) to capture coded concepts from a patient. Maybe a List of Conditions for a provider-managed past medical history; however, I don’t see Past Medical History (PMH) in the list of example codes for List.
For anyone who may want to play around with the module, the latest code allows ability to Create Conditions, Manage (make active/inactive, move to history, void) and view active conditions on the Patient Dashboard.
Add Condition:
Features: Search Concepts with class diagnosis,symptom,finding,symptom/finding, Enter a Start Date, Select Status.
Manage Conditions:
This page uses tabs to view Active Conditions & Inactive Conditions (where should the HISTORY conditions be shown? I’ve added them on the Inactive conditions tab). The ‘+’ icon (should probably use a more descriptive icon) allows a condition to be made Active, whereas the ‘-’ does the opposite. The ‘folder/directory’ moves a condition to history. The ‘x’ removes a condition.
Notice the ‘undo’ icon that lets you revert a ‘remove’ operation (this option will only be available until the page is refreshed)
Inactive Conditions:
Patient Dashboard:
Shows only the active conditions. It doesn’t yet have ability to remove conditions from the list.
Looking forward to your feedback!
Thanks,
Andrew
Nice! Though, it would be nice for the row to appear “deleted” and the other actions to disappear as soon as the “x” was clicked:
If you get bored, an equally awesome addition would be to allow editing (i.e., removal of entries from) the condition list directly on the dashboard – i.e., a little “x” following each entry that, when clicked, strikes out the item and provides an undo option until the page is refreshed:
This would allow a provider (someone with privileges to manage the condition list) the ability to remove a condition (like “Diastolic blood pressure”) from the list with a single tap. Given that the #1 complaint and reason for entropy of condition lists over time is the inability to easily prune items for the list, such a feature would lower the barrier to condition list management about as low as possible. 
Thanks!
-Burke 
Awesome! This is looking like a viable replacement for the diagnoses widget!
Just wanted to say thank you to @insiderish and others for all the hard work on this, and to continuing to work on it post-hackathon!
We are currently in the process of upgrading our implementations to OpenMRS 1.11, at which point we plan to try this out.
Take care, Mark
