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

[Karsten Hilbert]

> 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!
Well, wouldn't marking that laceration "is_active=True"
suffice ? If I were to write a frontend I would surely default
to present all "problems" that are active and/or significant
indifferent to whether they are chronic or not.

> In the case of splenic rupture due to trauma (a diagnosis) leading to 
> splenectomy, both the trauma and the operation will become 
> "inactive",
Agree.

> and neither will be "chronic",
Agree.

> yet one or the other will 
> still be worth keeping aware of (notable indefinitely).
Agree. In case of, say, polytrauma both may be worth keeping
aware of. I would mark both of them "is_significant=True". I
am not 100% sure if "significant" is the best term. However, I
just used what Richard introduced in his GUI design.

If at all I would rename the field to "clinically_relevant".

> Here, "significant" has taken on the extra meaning of being "important". 
What other meaning would "significant" carry ?

> 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,
Sure.

In that case I would create a health issue (eg. problem)
"post-splenectomy state (trauma)" or even "post-polytrauma
(...)" and attach further episodes of bad health due to WBC
undulations, increased frequency of minor and major infections,
OPSI syndrome etc. to that health problem. A classic case, IMO.

> it may be helpful to keep the trauma coded as 
> "significant" in order to keep clear the etiology,
Sure, but this ...

> 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?)
... manifests a case of insufficient documentation.

Of course, it is also possible to keep the "significant" state
for the trauma diagnosis, which makes perfect sense in this
case. I fail to see the problem here, though ?

> 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.
Can you expand on that ?

> If all diagnoses are automatically to be considered 
> significant/notable while a problem is active
Sounds reasonable. There may, however, be insignificant
diagnoses indirectly attached to a problem at some point.

> then whenever a 
> diagnosis becomes active, the value is_significant must be changed to 
> TRUE.
That depends on the point of view. "My" client would list the
active problems and list all attached diagnoses, emphasizing
the active/significant/chronic ones over those that are not.

This may all resolve into nice white smoke IF we decide to not
let issues/episodes carry distinct names but rather link them
to one of their clin_narrative rows which in turn will
(should) carry the information of active/significant/chronic.
We would then have no duplication of those states between
episode/issue and linked narrative. And obviously, if a linked
narrative goes inactive/insignificant but the issue/episode
does not (due to other linked narrative still being
active/significant) that very much warrants a re-linking of
the key to clin_narrative the carries the naming power.

> 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.
Sure. The background consistency checker should check for such
incongruities.

> If the reasoning is that we "always want to know about" problems that 
Well, the "problem" list is two (or three)-fold in our case:

1) health issues
   - episode
     - "diag"
   - episode
     - "diag"
2) unlinked episodes
   - "diag"
   - "diag"

That is sort of how I would display it. The view
v_problem_list carries 1) and 2).

> are active (even if not chronic), as well as problems that are 
> chronic (even if they are not active),
AND those that are deemed significant no matter whether they
are non-chronic and/or inactive.

> 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)
I am trying to attach *clinical* meaning void of any kowtow to
how a given client might display that, eg. which ones it
thinks the user wants to be shown.

>, even when the 
> diagnosis is inactive and is not chronic, e.g. maybe it is recurrent.
Sure. If it is known to recur in some patients and I suspect
it to be likely to recur in *this* patient I would mark it
significant :-)

> 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".)
Well, so mark it significant ?

> So really we are saying we need a field that might be called 
> "flag_always" or "show_always" or "profile_always"
This I am trying to avoid. The naming suggests that the field
has meaning to a UI which it should not.

> 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.

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.

Note, how the current constraint is names
"if_active_then_significant" - and not vice versa. I believe
*this* is sensible, no ? Any active diagnosis is also
significant (for now, anyways). The backend constraint forces
the programmer to do it right, eg. when changing from inactive
to active to *also* change to significant unless it already is
significant. Code failing to do that is faulty and will quite
obviously not work (since the database will throw an error -
that is what the constraint is for, after all ...).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346