[Top][All Lists]
[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: |
Karsten Hilbert |
Subject: |
Re: More on: Re: [Gnumed-devel] First sample of gui function docs |
Date: |
Fri, 22 Aug 2003 01:41:16 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> 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
- 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
Any other *important* (not *possible*) null value I forgot ?
> 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 ?
Occurs to me that currently we have no way of recording "has
no allergies". Only "no allergy data recorded". This will change RSN.
> 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.
What is your suggestion re the details of implementation ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346