I’ve been diving back into the Condition List functionality and have been remembering what I found confusing/frustrating about it previously and I had some questions for people… not sure who was on the initial design?
My main frustration, is that a “Condition” has an “onset date” and “end date”, but also has a “Clinical Status” enum that can be one of three values: ACTIVE, INACTIVE, and HISTORY_OF.
This could lead to funky, confusing states. Note that from the API level, an “active” condition is just a condition with end date == null, it isn’t dependent on the “clinicial status” at all:
In our current model it’s unclear to me what the “proper” model should be, even for simple use cases.
For instance, say a patient went to see a doctor on January 1, 2000 and was diagnosed with “Condition A” on that date and the doctor added it to their condition list. In the database, I’d expect to see the following row in the DB:
Condition: Condition A, Clinical Status: ACTIVE, Onset Date: 2000-01-01, End Date: Null
Now let’s say 10 years later on Feb 1, 2010, at a doctor decides that the condition is no longer active, and removes it from the patient’s condition list. The simplest thing to do would be to update the existing row to follows:
Condition: Condition A, Clinical Status: INACTIVE, Onset Date: 2000-01-01, End Date: 2010-02-01
However, it’s possible the intended modelling might be for two rows to end up the database:
Condition: Condition A, Clinical Status: ACTIVE, Onset Date: 2000-01-01, End Date: 2010-02-01 Condition: Condition A, Clinical Status: INACTIVE, Onset Date: 2010-02-01, End Date: null
This is particularly relevant because there’s an existing Condition List widget in the reference app, and one is being built in the new SPA framework, and we’d want them to interpret the data in the same manner!
Right now, if the above scenario was entered using the existing Condition List Reference App UI, you’d get neither of the above in the underlying database, but the following 2 rows, which seems clearly wrong (and may be the source of my confusion):
Condition: Condition A, Clinical Status: ACTIVE, Onset Date: 2000-01-01, End Date: 2000-01-01 Condition: Condition A, Clinical Status: INACTIVE, Onset Date: 2000-01-01, End Date: 2010-02-01
Note that the UI only displays the most recent status, so in the UI it reads “INACTIVE”, onset: 2000-01-01, end date: 2010-02-01, which more closely aligns with the first of my two potential examples. Can we change the Condition List UI so that instead of adding a new row, it simply overwrites the existing row?
I feel like this is a case where we’ve overengineered thing, preventing us from getting working code out to users that meets the 95% use case.
Take care, Mark