gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Tim Churches
Subject: Re: [Gnumed-devel] First sample of gui function docs
Date: 16 Aug 2003 20:50:44 +1000

On Sat, 2003-08-16 at 18:40, Karsten Hilbert wrote:
> > a) Age should be in expressed in days up to one month, in months and
> > days up to perhaps 4 or 6 months, years and months up to perhaps 5
> > years, and in completed years after that (not rounded to integer years).
> client/business/gmTmpPatient.py:
> 
> def get_medical_age(dob):
>       """format patient age in a hopefully meaningful way"""
> 
>       age = mx.DateTime.Age(mx.DateTime.now(), dob)
> 
>       if age.years > 0:
>               return "%sy%sm" % (age.years, age.months)
>       if age.weeks > 4:
>               return "%sm%sw" % (age.months, age.weeks)
>       if age.weeks > 1:
>               return "%sd" % age.days
>       if age.days > 1:
>               return "%sd (%sh)" % (age.days, age.hours)
>       if age.hours > 3:
>               return "%sh" % age.hours
>       if age.hours > 0:
>               return "%sh%sm" % (age.hours, age.minutes)
>       if age.minutes > 5:
>               return "%sm" % (age.minutes)
>       return "%sm%ss" % (age.minutes, age.seconds)
> 
> This has been discussed with a Pediatrician. It is used in the
> top panel.

Sure, in that case Richard's specs just need to state that the above
function will be used for the age display. A very minor point, but
display of months for ages > than say, 3 or 4 or 5 years is probably
unnecessary (but who cares?). 

> 
> > b) Address history?
> > Does the demographic back-end capture address history (if not it should).
> Address tables are fully audited.

Audit tables are one way of maintaining an address history, but how can
they distinguish a minor correction to an incorrectly recorded address
from a completely new address? Explicit modelling of important data
elements which are likely to change in the course of the relationship
with the patient is probably warranted. However, not important enough
for Version 1.0 - but worth considering for a future version.

Briefly, how does the GNUmed table auditing mechanism work?

> 
> > If so, then at least the previous address (if recorded) should be shown,
> > and the (approximate) date of last move.
> Shown where ?

On the demographic summary screen which I was commenting on.

> 
> > c) Occupational history? Patient might be a bus driver now but was a
> > boilermaker in the past - which may be more relevant to his current
> > dyspnoea. 
> Will add tables.

Hmmm, I can't stop you, but could I suggest a more considered approach
to design and implementation? Haste makes waste... Although my
suggestion of capturing an occupational history is doubtedly sound,
there are a number of things to consider before implementing a table to
hold it. Such as: Is it important enough to be implemented in Version
1.0? What level of detail of occupation is desirable - a general
practice seeing many occupational injuries might need more than other
setting? Is a coding system or controlled terminology desirable? If so,
which one(s)? If just free text, how much - a how mini-essay on each
job, or just a single line? Finally, could other input be sought before
implementation?

> 
> > d) Highest educational level. Increasing evidence that on a population
> > level this is even more strongly associated with health outcomes than
> > income. Of course, not necessarily true for any individual, but a useful
> > indicator.
> Will add tables.

Likewise.

> 
> > e) Ethnicity! Country of birth, first language, language spoken at home,
> > English (or local dominant language) proficiency - perhaps just as a
> > flag ". Essential.
> Will add tables.

This one I think should go into Version 1.0, but again, think about how
to implement it - certainly for country of birth and language, a coding
system is very desirable - here in Australia the Australian Bureau of
Statistics codesets are the ones to use. No idea about Germany or
elsewhere.

> 
> The last three might as well be put into clinical history,
> backend-wise.

Personally I am not sure language details belong in clinical
history...they seem like socio-demographic characteristics to me. But
many such distinctions are arbitrary anyway, so it is fruitless to
argue, although it would bother me if I saw language in a clinical
history table.

-- 

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


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


reply via email to

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