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

[Tim Churches]

On Mon, 2003-08-18 at 04:22, address@hidden wrote:
> > That's the difference between the use of systematic nulls and a mess.
> > When capturing information, it is vital to distinguish between "unknown"
> > and "nil/null". When collecting infomation to be used in aggregate
> > analyses, it is also important to further subdivide "unknown" into a)
> > "unknown because question not asked", b) "unknown because answer not
> > given by subject" and c) "unknown because answer not known by subject".
> > a) should be generally be excluded from the denominator when calculating
> > rates or proportions, but b) and c) should be included in the
> > denominator.
> I agree absolutely that a detailed information on missing data is essential
> for statistical analisys. However, Gnumed will be used primarily as an tool
> for
> documentation of patient data by medical practitioners. Although it might be
> 
> desirable to enable a finer grained coding of missing data at the backend,
> we 
> might not want to enforce this coding at data entry (at least, this should
> be configurable). 
> Some medical doctors that are less interested in analysis of their data will
> probably
> prefer speed of data entry to scientific correctness of information entered.
> 
> If the user asks questions and enteres data always in the same order it
> might even be
> acceptable to treat a missing information as b) / c). This will not be true
> if the data should be used 
> by others (say, in a controlled study). But than, more effort will be
> necessary in order to 
> ensure the correctness and validity of the data (queries, source data
> verfication). 

Yes, I agree that GNUmed is not a tool for collecting data for
epidemiological studies. But I would make two observations: i)
examination of one's own practice and management patterns is likely to
be a big part of primary care medicine in the not too distant future,
and it it is almost impossible to go back and collect systematic nulls
if they were not captured in the first instance; and 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". If the data element is "current medications" or
"allergies" or even "family history of XYZ", then distinguishing those
three **is** clinically important. 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. Data elements should default to NULL, and the user interface
should not cause this NULL default value to be changed unless the user
actually enters something or choses a code or value for a particular
field. Nothing difficult about that, and it will make a huge difference
if the data are every to be analysed in an aggregate sense. It does
presuppose that there are reserved codes or values for every field that
indicate  "answer not known by patient" and "nil/none" - but that can be
done by creating a super class for input fields which provide this as
default behaviour.

-- 

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0

signature.asc
Description: This is a digitally signed message part