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

[Karsten Hilbert]

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

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

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

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

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