[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re clin_diag table (was postgres boolean checks, and
Re: [Gnumed-devel] re clin_diag table (was postgres boolean checks, and (e.g) diagnoses)
Wed, 22 Sep 2004 17:51:44 +0200
> > > 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?
User Interface. There is GUI (graphical) and TUI (textual). I
try to avoid fields that have a meaning to a particular way of
displaying data. eg. "show_always" - what does that mean ?
Always show no matter what client is used ? Always show in
complete listings ? Always show even if tucked away in an
audit table and having been overriden by an updated version of
the row ? What about clients that don't show anything but
rather, say, export data into files ? IMO clinically_relevant
is better as it labels the clinical value of the *data* rather
than the interpretation of said data by a user interface.
No one spoke up so I'll rename is_significant to
clinically_relevant where appropriate.
> Unless you are implying:
> if (not chronic AND not active) then not significant
> (which i do not think you are)
No, I don't.
> 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
> 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
Well, that is what medicine is all about, re-appreciation of
facts at appropriate intervals and thereby re-valuation. What
you seem to be asking for here is "indefinite undo" like when
I decide tomorrow that I want back the state of a text document
the way I wrote it in 1987 - by hitting a "back button". This
isn't IMO very feasible. OTOH, versionion systems such as CVS
are just the tools for this task. OYAH the GnuMed auditing
even allows for this ...
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
No we can not. clinically_relevant is largely independant of
the state of is_active and is_chronic with the one constraint
that open problens, eg. un-closed, eg. is_active=true rows are
always significant to the clinician. Same for is_chronic=true.
> "Significant" -- as with statistical -- cannot help but carry a
> meaning of 'real" even when not clinically important.
Ah ! Now I get it. Had I named it clinically_significant no
such confusion had appeared... I left out the domain !
Richard should be happily chiding me for bad naming :-)
That's also why clinically_relevant so handily feels right.
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,
Well, the context (eg. the domain) is "clinically" ;-) eg.
"always consider in clinical decisions" - or else don't mark
it clinically_relevant if not relevant to your part of the
clinical domain ...
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346