It currently has some nice behavior. If you select ‘x’, it strikes out the condition/onset date and shows a restore button. The same behavior for the clinician-facing dashboard. After a page reload, the condition no longer appears.
Ellen, I think it is not really a delete so the strikeout seems inappropriate. Basically, when someone wants to remove a condition from the list, the application should prompt/confirm the action with a dialog. The question is what does the user want to do with the condition? Was it an error? Is it no longer active but should be included in the past medical history? I would think that most clinicians would want to MOVE the condition from the active list to the inactive list. Closing the dialog with confirmation should move the condition and refresh the screen. If the user wants to reactivate the problem, she can go to the inactive list and make it active again.
@ball, thanks for the mention – I had missed this thread.
I essentially agree with @akanter – the only reason I can think of for deleting a condition is that it was entered in error. Thus, it should be easy for the user to inactivate the condition, but not too easy to delete it; and if the user did delete it, there should be a dialog to the effect of: “Are you sure? This will delete the condition entirely from all lists,” followed by (if the condition was active), “If you want to make a condition inactive, edit the condition.”
Two other things I note in this very nice application:
Is the plus button supposed to mean “activate” and the minus button intended to mean “inactivate”? I think those will not be obvious to most users. I expect they would think these icons would add and delete conditions. Since you can inactivate and activate on the Edit form, that should take care of that need.
It appears above that you can use Edit to completely change the name of a condition. I can see how this may be useful when the clinician’s knowledge of the clinician becomes more refined – for example, if you now know that the patient’s “shortness of breath” is actually “chronic bronchitis” – but it will probably cause problems with other future uses of the condition list. In particular, some applications may use conditions to justify a prescription, or attach the condition to an encounter note. In those cases, changing the condition text here might change the condition that had been attached to a prior note, which was not what the user intended.
We don’t allow changing the name of a condition in our hospital system; you would create a new condition with the refined name and just keep going. The full solution is to define a new condition and to merge the older condition with it, but that’s not well understood and I wouldn’t recommend it. You can keep the name editing, but be aware of these side effects.
@jteich , Thank you for your insight Do you think we should remove the plus and minus buttons completely from the UI page? What kind of behavior should condition name have in Edit Conditions page? do I disable editing of condition name?
My preference would be to eliminate the plus and minus buttons, since you have another easy way to activate or inactivate.
I would also prefer to make the condition name unchangeable in the edit form. If the condition was entered in error you can delete it (with the warnings above) and if your thoughts about the condition have changed, you can inactivate it and add a new one. In practice, it will be a fairly rare event that someone actually wants to do that.
Thank you @jteich , I will make the condition name unchangeable in the edit form. I would like to take a vote on elimination of plus and minus button. @dkayiwa and @ball what’s your opinion on this?
Upgraded font awesome to latest version, to support a wider set of icons eg: awareness ribbon etc (In reference app)
Fixed the error while saving conditions:
Limit values of condition list based on its global properties
Add condition UI enhancement:
Cosmetic tweaks for Manage conditions
Added checks for onset date to ConditionValidator in core
Upgraded Fontawesome to latest 5.9.0 in UI commons
Fixed hover messsge for ‘x’ icon in manage conditions
Spent a good amount of time fixing my previous PR’s
Working on translations into other languages like french
Made suggestions regarding change of icons for coreapps (idea not yet approved) : talk link
Exploring cohortbuilder-owa to add functionality for condition list. Being new to owa its taking more time to figure out how things are working. : talk link
we seem to have a little time remaining to the completion of the GSOC projects, can we get the update on the progress of this feature. could we be able to have it into ref app??
thanks
cc @haripriya@dkayiwa@ball@c.antwi
Do you think we should remove the plus and minus buttons completely from the UI page? What kind of behavior should condition name have in Edit Conditions page? do I disable editing of condition name?
