[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re clin_diag table (was postgres boolean checks, and
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] re clin_diag table (was postgres boolean checks, and (e.g) diagnoses) |
Date: |
Mon, 20 Sep 2004 12:32:35 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> 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