Tracking Progress of the Condition List Phase GSOC Project

A very good idea @haripriya.

1 Like

Thank you :slight_smile: I will try to get this in implementation

1 Like

@dkayiwa @ball Could you have a look at the request for more information from @haripriya

1 Like

Yes i also like the confirmation which prevents one from accidentally removing conditions.

2 Likes

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.

It would be great to have some feedback from a clinician about expected behavior on deleting a condition: popup or strikeout @burke @jteich

Can anyone comment on how the Bahmni UI deals with deleting a condition? @darius

1 Like

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.

1 Like

@ball, thanks for the mention – I had missed this thread.

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

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

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

1 Like

@jteich , Thank you for your insight :slight_smile: 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.

1 Like

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?

PR on confirmation before deleting a condition -

2 Likes

Edit Conditions PR after making the condition name unchangeable

3 Likes

Thanks @haripriya on the above. Any updates on this , could we have all work done by this june??

  • 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

2 Likes

great @haripriya , thanks for the awesome work

1 Like

Thank you @mozzy

2 Likes

well done here

1 Like

Thank you @herbert24

2 Likes

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

@mozzy All the objectives under Condition List project have been completed.

These 2 features are to be merged:

  1. https://github.com/openmrs/openmrs-owa-cohortbuilder/pull/182
  2. https://github.com/openmrs/openmrs-module-coreapps/pull/192

I’m currently working on the changes being suggested on these PR’s and the documentation. Also trying to fix a bug reported by @ball.
Thank you :slight_smile:

2 Likes