Following up on Jen’s poll from last week, the most popular time for the Condition List UI Design Forum is next Wednesday (not tomorrow as originally stated - my mistake).
When: Wednesday, July 15 at 9pm Nairobi | 6pm UTC | 2pm Boston | 11am Seattle
Goal: Discuss how we’ll resolve the 10% of issues remaining for the Condition List UI in core apps, as this has been 90% ready-to-go for awhile now and we’d like to get it over the finish line - ideally without a rabbit hole that leads to a lot of rework.
The Condition List functionality is an oft-requested feature that many are looking forward to having available.
If it’s today at 8pm CEST I doubt I can make it (and even in general anyway unless I’m home alone which never happens).
A couple of things that I would like to convey:
Since the conditions list is a separate page, it should be done as a spa using MF.
This has been done a couple of times and is a great way to start bringing new features as a “backport” to the Ref App from OpenMRS 3.0.
Examples are: PIH patient queues, ICRC immunizations, ICRC user tasks dashboard (that one is more WIP than the other two, but worth mentioning.)
OpenMRS 3.0 already has a conditions widget on the patient chart, so perhaps there is actually very little to do.
A requirement from us: we would need the condition’s additional detail to be part of that screen. This is because there are cases where we capture unspecified conditions (they are coded with a generic/placeholder concept such as ‘other eye condition’ and the details are captured as free text using additional info.)
Good point @jteich… for clarity, let’s have this call next Wednesday, July 15th, not today. fyi @grace
I’m happy to lead. Though fyi I have a relatively targeted question I’d like to get answered,around the modelling of conditions: whether it can be changed to remove the functionality in API that tries to maintain the “state” of a condition, kind of like how program states work, which, according to @burke wasn’t the initial intent, but seems to be baked into the API saveCondition method. See thread here:
So I’m wondering:
if we can strip out this more complicated state functionality, and, if so
can it be backported to 2.3
What would be helpful would be to have anyone on the call who was involved in the initial design or using the functionality as it currently operates. Does anybody know/remember who originally build the condition functionality into EMR API and if anyone is currently using it? (@dkayiwa@darius?)
Basically, the Condition List functionality/widget in the Ref App is pretty broken (don’t think it ever worked properly). If we can agree to simplify the model, I’m hoping the functionality can be made workable with a small-to-mid level of work, and I’m hoping that PIH can commit to doing that in the next 3 to 6 months. If not, it’s probably a bigger project.
I’m also happy to discuss (and we should discuss) long-term goals, but I want to make sure I get this more immediate question answered as well.
Other than audit-trail entries, the condition is a single record that sometimes can be modified as status and onset/end dates change.
With record to Active/History-Of/Inactive, the way we talked about them in 2017 implied that they really mean “Active and Important”/“Inactive and Important”/“Inactive and Unimportant”. That’s one reasonable option, and the words, while technically incorrect, actually make sense to users (just like “Allergies” is the best word even though not technically correct). The other approach, perhaps simpler, is just to have Active and Inactive status and include them all on the display, perhaps with Inactive ones at the bottom, and let the clinicians recategorize them whenever they wish.
Practically speaking, most condition lists aren’t too long to view [unless they are auto-filled with every encounter diagnosis] and nobody spends time recategorizing them anyway.