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”?
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.
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.
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 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.
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.
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.
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.
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.
@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?
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.
