gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: J Busser
Subject: [Gnumed-devel] re clin_diag table (was postgres boolean checks, and (e.g) diagnoses)
Date: Sun, 19 Sep 2004 22:57:04 -0700

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]