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

[J Busser]

At 1:21 PM +0200 9/19/04, Karsten Hilbert 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 ?

I agree with the logic though a different implementation could be 
considered (see bottom).

BTW in terms of field naming, to me "significant" implies some 
intrinsic importance, however a minor diagnosis (like a superficial 
laceration) which seldom has long-term importance, is temporarily 
notable until it's been fully taken taken care of, and any infection 
taken care of, plus must remember to take out those non-dissolving 
sutures!

So if we keep the field, I somewhat prefer "is_notable".

In the case of splenic rupture due to trauma (a diagnosis) leading to 
splenectomy, both the trauma and the operation will become 
"inactive", and neither will be "chronic", yet one or the other will 
still be worth keeping aware of (notable indefinitely). Here, 
"significant" has taken on the extra meaning of being "important". 
While it is true that an additional diagnosis could be created, i.e. 
a "diagnosis" of "post-splenectomy state" and that *will* be a 
chronic condition, it may be helpful to keep the trauma coded as 
"significant" in order to keep clear the etiology, otherwise anyone 
inheriting a data dump limited to what is "significant" will get the 
information that the patient is "post-splenectomy" but will wonder 
why... from trauma? did this person have some lymphoproliferative 
disorder (or they had infectious mononucleosis and associated 
rupture?)

Alternative:

I might be repeating myself here, about whether it may be a 
disadvantage to derive importance from field values that are 
themselves *written from* logic, when accessible source fields 
already keep the information.

If all diagnoses are automatically to be considered 
significant/notable while a problem is active, then whenever a 
diagnosis becomes active, the value is_significant must be changed to 
TRUE. Then, when the diagnosis becomes inactive, is_significant (if 
it had been FALSE) may have to be set back again. This is extra 
programming work, or takes the user extra time rethinking this when 
we have no shortage of other things to think about, and adds room for 
error.

If the reasoning is that we "always want to know about" problems that 
are active (even if not chronic), as well as problems that are 
chronic (even if they are not active), then we are really only saying 
"we need a way to identify certain diagnoses which we would always 
want to know about (i.e. remember, or be shown), even when the 
diagnosis is inactive and is not chronic, e.g. maybe it is recurrent. 
Maybe an example could be diabetes mellitus (chronic) and diabetic 
ketoacidosis (not chronic but may be recurrent, and worth coding as 
noteworthy beyond the time that it has returned to "inactive".)

So really we are saying we need a field that might be called 
"flag_always" or "show_always" or "profile_always" 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.

This field, unlike is_significant (which it would replace)  would 
have no constraints.