OMRS17 Hackathon Condition list

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:

  • I like the simplified actions on page 2 (Conditions), but what is their meaning (+, -, file, x)? If you hover over the symbol, does it show a word description (ie. active, inactive, history, delete)?
  • On page 3 “Add condition”, what do you expect from the red “Remove condition” button?
  • @burke @jteich @akanter - We discussed and agreed about replacing the “Diagnosis” section with this new feature and putting it prominently on the clinician-facing dashboard. Do you think the English word for the section should be “Problems”, “Problem list”, “Conditions”, or “Condition list”?


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.

Additional feedback

  • 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.

    • Both in the dashboard and the list overview, a user with privileges to manage the condition list would have an “x” next to each condition. Clicking the “x” would either (1) immediately remove the item & show a temporary “undo” action button on the screen, or (2) immediately remove the item on the backend, strike out the item in the UI, and show an undo action in place of the “x”.
  • 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!


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.


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 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!



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: omrs17-hackathon-1

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. :slight_smile:


-Burke :burke:

Got it.

Remove Condition from dashboard:

Undo operation:

Manage conditions remove/undo:


1 Like

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

Incredible work by the team during AND after the hackathon. My expectations are far exceeded. I have a new found respect for what can be accomplished during an OMRS hackathon.

Happy New Year,


Whoa! I was checking this one out to plan further work, but amazed to see how quickly the community turned this into a working app. Thanks to all contributors.

1 Like

@insiderish and others… again, great work! I was just able to get this fired up within the PIH EMR!

I did discuss one bug though and was going to enter a ticket… should we create a new Condition UI project in JIRA? Use the existing Ref App one? Thoughts?

Take care, Mark

That’s great! Were you able to start it in platform 1.11?

I think we should create a new Condition UI project in JIRA.



Yes, this was in 1.11.x

I agree re: creating a new Condition UI project in JIRA… I will do so later today or on Monday if I don’t hear any objections from others beforehand.

Take care, Mark

Was just talking with @mseaton and he was wondering if perhaps rather than keeping Condition UI in a separate project, we roll it into the Core Apps module. Do people have thoughts/opinions on this? @burke @darius

In the meantime I just add any bugs I find to the Ref App project just to get them recorded… I hope that works for you @insiderish? I will flag you on them.

Take care, Mark

That’s fine.


Added my first ticket/issue:

@insiderish let me know if I’m misinterpreting how things are supposed to work.

Thanks again for doing all these, hopefully we will get a chance to test more next week!

Take care, Mark