Condition Lists -- Updates and outstanding issues

Development
1

Hello all… first off, I wanted to thank everyone who has worked on the Condition List functionality within the Reference App for all their hard work. This is an oft-requested feature that many are looking forward to having available.

I do think we are getting close to having a stable product to release, but unfortunately testing today I did notice a few more bugs, which I have ticketed here. One, unfortunately, is related to pesky timezone issues.

https://issues.openmrs.org/browse/RA-1677

https://issues.openmrs.org/browse/RA-1678

Beyond, I’ve noticed one other thing that I think is a bug, but I want to clarify what the exact expected behavior and modeling is…

A Condition has a “clinicalStatus”, which can be “Active”, “Inactive” and “History_Of”, as well as an onset date and end date, and the Condition List UI allows the user to switch a status between “active” and “inactive”.

Let’s say I have an existing condition “Thyrotoxicosis” for a patient, with an onset date of “2019-11-04”:

2020-01-08_16-53
2020-01-08_16-531015×284 18.2 KB

Then I click the “inactive” link and mark that condition as inactive:

2020-01-08_16-55
2020-01-08_16-55991×264 19.9 KB

The updated “Inactive” list looks like this:

2020-01-08_16-55_1
2020-01-08_16-55_1970×270 18.5 KB

But in the underlying database I see the following two (non-voided) entries for this condition:

2020-01-08_16-56

This seems wrong, but I want to make sure that the expected result would be:

status: ACTIVE, onsetDate: 2019-11-04, endDate: 2020-01-08 16:55:41

status: INACTIVE, onsetDate: 2020-01-08 16:55:4, endDate:

Am I correct? It does feel kind of weird to have an “onset date” for an inactive condition.

Also, I assume the 90% use case for this widget is to simply show the active condition list for a patient… thoughts on if (and how) we could simplify the UI to just allow the adding and removing of conditions (without having to specify dates) so we could get something simple working without having to worry about all the nuances of dates?

fyi @mozzy @burke @jteich @mseaton @ball

Thanks and take care,

Mark

2

Mark - yes, I agree with you. In particular, if someone wanted to know “what were the active conditions on 2019-12-12?”, the answer would include Thyrotoxicosis. The data changes that you suggest would be needed to make that work properly. And it makes sense that an inactive problem should not have an end date shown.

Other cases: If I wanted to enter a new problem right away as inactive (say, I’m seeing a patient who developed and cured tuberculosis before they ever saw me), then I could put in an onset date and an end date (the date that the patient told me they first got TB and the date they felt they were cured — if they happened to know that) and you could create an ACTIVE and an INACTIVE entry. It will still show the problem as INACTIVE when someone looks, and all will be well.

If I just want to enter a problem as INACTIVE and don’t have any dates, then you’d probably just store an INACTIVE record starting today.

Hopefully, you don’t need to enter a date for any of these cases, as most people will simply know they have a condition, not when they first got it.

3

Thanks @jteich… you actually bring up one other question I had… is it okay for a condition to not have an onset date? It sounds like the answer is yes? The backend allows for this, and UI did as well, but I actually made a change yesterday to make the onset date mandatory in the UI. The reasoning for this is because the way the UI currently worked, it needed an onset date, because it relies on a “condition history” sorted by onset date to determine if the condition is currently active or not.

Having to track the dates tends to add complexity to the UI… one though, for the first-pass UI I’m wondering if we want to come up with a workable strategy that avoids date entry/viewing for now, and simply displays whether a condition is active or not (or even just displays active conditions) because I’m guessing that is the 80% use case? There is a “previous_version” field on condition that we could use when there are multiple entries for a condition what the most recent entry is.

Take care, Mark

4

Also flagging @alaboso and @dkayiwa… Daniel, I saw that you marked some of the tickets I added as community priority re: Condition List, thanks! I’m wondering if before we dig too deeply into those we consider a simpler UI to start out with that doesn’t deal with dates (see above).

5

First, we have to be really clear whether we are talking about clinical activity or database/data error activity. If someone wishes to remove a condition because it was wrong, that is different from saying that the condition was present, but is no longer active. If we are talking about clinical activity, sctually, I don’t think the way this discussion is going is correct. The status is independent of the dates. As @jteich mentioned, you can have an inactive problem that needs to be recorded. Also, onset date is the original date that the problem occurred. All entries should have an onset date which either should be the date it was entered, or the date overridden by the user. A condition should have a NULL end date unless it is marked as clinically inactive. In the same way, the end date should be the date the condition is inactivated unless overridden.

The next question is what happens when an inactive problem become reactivated. In that case, I think a new row should be created with a new onset date, although I’d like @jteich’s opinion. The problem is that if the end date is removed on the same row it looks like the condition was active for the entire period which would be wrong.

6

Thanks @mogoodrich , for finding out the above bugs. I think the first two tickets you have created are straight Forward and clear , but we need to label them and more that will be created, may be “conditionList” , for an easier Jira search .

7

Great, thanks @mozzy… I will label any new ones I create!

8

O-kay then… tl;dr If you really want to do it right and keep it simple for the user, you have to do some work underneath.

Here’s my take on the possible scenarios; I’m not showing the UI, but I believe that all of these would give the user a fairly easy UI with the option to enter or leave out dates:

  • Enter new active condition starting today

    add ACTIVE start: today end: null

  • Enter new active condition starting unspecified time

    add ACTIVE start: null end: null (*Note: it’s not clear whether a default of Today or null makes more sense, and I don’t want to add another field; but practically speaking the differences are mostly harmless. If you’d want to do it completely right your display and reporting algorithms have to make use of the time entered as well as the start and end times :frowning: )

  • Enter new active condition starting in past

    add ACTIVE start: specified date end: null

  • Change already active condition to inactive starting today

    Change existing ACTIVE record end: today;

    add INACTIVE start:today end: null

  • Change already active condition to inactive starting in past

    Change ACTIVE record end: specified date

    add INACTIVE start: specified date end: null

  • Change already active condition to inactive starting unspecified time

    Change ACTIVE record end: today

    add INACTIVE start: today end: null (*Note: Using today is incorrect but NULL is worse)

  • Enter new inactive condition with no known original active date (*Note most users would enter this as History-Of, which is a whole different can of worms)

    add INACTIVE start: null end: null

  • Enter new inactive condition with known past active start and/or end date (*Ditto)

    add ACTIVE start: specified start date end: specified end date

    add INACTIVE start: specified end end: null

  • Reactivate an inactive condition

    Change INACTIVE record add end: today

    add ACTIVE start: today

9

@jteich , i think that design is more better , its actaully not colliding with the design we have been having currently , its just like an improvement on the existing design

10

Thanks @mozzy @jteich @akanter…

Unfortunately, we at PIH don’t have a ton of time to focus on this functionality right now, I had just been researching the current functionality as it exists to see if it was something we could we could use out of the box right now as is or with minimal tweaks, but it looks like there’s a little more work to be done. I’m happy to continue to provide feedback and testing but I won’t be able to actively drive this forward at this point.

My main concern with the current functionality, beyond the tickets I entered, was the modelling and design issue I mentioned above with the screenshots above. I think the underlying issue is that the widget is designed to just take the most recent database entry for each condition in the DB and then display the condition, onset date, and end date for that condition, which I don’t think is really what we want in the inactive case. In the UI for the “Inactive” tab, if we are going to display any dates at all, it should be the onset date and end date of the most recent previous active entry for that tab… you can see here how the display mirrors the database, but that’s not really what I think we want:

2020-01-10_15-11

Take care, Mark

11

@mogoodrich, agreed.

The truth is that you could have done just as well with no INACTIVE or HISTORY-OF status at all, simply letting the “Inactivate” UI set an end date on a condition and letting the “history of” workflow create a condition that already has an end date (you don’t really even need that workflow, if your Add Condition workflow lets you set optional start and end dates). Clinical users only care about seeing what’s on the active list and seeing what was in the past.

12

Right, agreed @jteich!

13

@mogoodrich , Here is PR for the Ticket of voiding the entire conditioHitsory

I reviewed it and Tested it , it works fine , Could you please look at it , and if possible merge it , I want us to have the beta of Reff App 2.10 at least next week . Thanks

14

Thanks @mozzy I will take a look!

I’m still concerned about the modelling issue I mentioned above though.

Take care, Mark

1 Like
15

Aright @mogoodrich