Re: [Gnumed-devel] re clin_diag table (was postgres boolean checks, and (e.g) diagnoses)

[J Busser]

> > So really we are saying we need a
> field that might be called
> > "flag_always" or "show_always" or
> "profile_always"

At 12:32 PM +0200 9/20/04, Karsten Hilbert wrote:

> This I am trying to avoid. The naming
> suggests that the field
> has meaning to a UI which it should not.

UI (unique identifier) for the diagnosis under debate?

> > so that we may
> > know about diagnoses that remain of interest, even when the
> diagnosis
> > is not chronic, and happens not to be active at the time of the
> chart
> > review.
> We could know about them even if not chronic and not active
> by
> simply marking them
> significant.

You wrote:

> > >clin_diag table
> BTW, there is another constraint on that
> table:
>
>  if active then significant
>     or
>  if inactive then either significant or
> not
>
> And there is potentially one more:
>
>  if chronic then significant
>     or
>  if not chronic then either significant or
> not
>
> What do you think ?
>

Unless you are implying:

>  if (not chronic AND not active) then not
> significant

 (which i do not think you are)

So you want anything that is either "active" or "chronic" always considered significant BUT you also want anything that may be inactive, and nonchronic to ALSO be able to be is_significant.

This means new items (if they default to is_active) must be written as is_significant, as must items that become is_chronic. So far so good.

At the point in time that an is_active item becomes inactive, and is set FALSE, a decision must be made whether to let it remain is_significant, or whether to "downgrade" this to FALSE. A clinician who makes the decision to keep it is_significant even though it is inactive and not chronic is very likely to want to keep it TRUE.

Suppose now a patient had two items, neither chronic, which become inactive, and suppose one had  been decided by the clinician to be kept "significant", and the other not. Next, say both diagnoses become active and therefore, under the constraint, both must be written as "significant".  When the time comes to set these items as inactive, do we wish to force the user to have to decide each item again (even though they previously decided to KEEP an item significant)... I am just worrying that is_significant is being used for 2 conflicting purposes, one to record a "state" whose fact we can already derive from the values of is_active and is_chronic so here is_significant adds no additional useful information while the reactivation of a diagnosis overwrites what HAD been a meaning of "this diagnosis *is* significant even when it is inactive".

> As I said, if others agree it would be
> better to name the
> field "clinically_relevant" I
> am open to that. We already have
> that name for test results,
> too.

"Significant" -- as with statistical -- cannot help but carry a meaning of 'real" even when not clinically important. So I agree clinically_relevant is better and like the added consistency. It is only that "relevant" has a contextual feel to it, which one cannot know in advance what that context will be, so I might have liked "important" (as carrying more value intrinsic to the item) but am happier with clinically_relevant than is_significant. Picky, admittedly, but hoped it might improve field usage with less dependance on discussion documents.