gnumed-devel
[Top][All Lists]
Advanced

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

Re: More on: Re: [Gnumed-devel] First sample of gui function docs


From: ju0815nk
Subject: Re: More on: Re: [Gnumed-devel] First sample of gui function docs
Date: Fri, 22 Aug 2003 21:24:31 +0200 (MEST)

> > ii) capturing
> > systematic nulls is hardly any extra work, and may be clinically
> > important: it is the difference between recording "unknown because
> > question not asked" and "unknown because patient does not know answer"
> > and "nil/none".
> OK. So:
> 
> - not asked
>   - no data available
>   - NIL/NULL
As far as I undestood nil/none belongs rather to "asked and negated".

> - asked but no data obtained
>   - not known to patient
>   - patient cannot answer (unconscious, ...)
>   - patient withholds information
> - asked and negated
>   - condition *known to not apply* to patient 
IMHO better "answer is nil/none" . "Does not apply" might be mixed up with
"Do not have to ask that" - but we did ask, and got a negative answer.

> 
> Any other *important* (not *possible*) null value I forgot ?
Not to my knowledge. 

> > It is simple to implement: reserve
> > one type of null (I suggest the database back-end NULL value) to mean
> > "not asked", and assign specific values or codes for the other two types
> > of nulls.
> Any good suggestions for implementation at the database/Python
> level ?
For numeric values it might be simple, since usually numbers used are
positive, so we can use negative values to denote special cases.
For strings we might have to construct a super class (as Tim suggested) to
extract the special cases from special chars. Or even much simpler, define a
string that can't be mistaken as actual entered data. Like
"-- not answered --", "-- not asked --". This might make analysis somewhat
harder, because you have to check for (possibly translated) special strings,
but it might be feasible.
Choices (radiobuttons) might be represented by numerical values. 

On the other hand you can add one flag (number) to every SQL column that
holds the state of the column. This will bloat the tables considerably, so I
believe it's not a good solution.

We have to consider the GUI implementation of null values, too.

Strings: we might use the special strings (s.a.)
Numbers : leave field empty to denote "not asked", "?" for "not known", 0
for nil/none
Choices: we will have to add radiobuttons for "not known" and "not done/not
asked"

Hilmar

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post





reply via email to

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