gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] restrictions vs. conventions (uncertain date-time)


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] restrictions vs. conventions (uncertain date-time)
Date: Sat, 24 Aug 2013 12:26:28 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Aug 24, 2013 at 11:54:46AM +0200, Jerzy Luszawski wrote:

> To the point of date-time data with uncertainty:
> I currently do not use medications plugin. But if I had to, I would
> probably develop such a "convention":
> 1. if the date is less than DOB - the date is totally unknown (=DOB is
> not a good idea, as it could be exact date)

That is a brilliant idea (and the database doesn't even
protect against that just yet :), however, DOB can be NULL
so we may need to convert this idea to "now-or-date-of-death
- 150 years" or so.

> 2. if the date has day or day and month as 01 or Jan-01 respectively,
> this part of date is unknown, unless non-zero hours are entered (the
> hours part is ignored in any case, but entering non-zero value means
> that Jan-01 date is exact)

While a good idea - the columns in question being timestamps
they cannot have invalid (did you mean invalid ?) hours. In
case you did mean valid-but-numerically-zero hours then,
yes, that may work as a convention for many people and it is
a practical idea again. For me, personally, it wouldn't
because I regularly work 24h shifts meaning I regularly
prescribe (and thus start people on - at least as far as
GNUmed is concerned) drugs in the wee hours of the morning
or even just after midnight.

HOWEVER, taking a step back and looking at the big picture
two things come to mind:

Does it even matter whether what time of day a drug was
started ?  For most people it won't so the time part can get
used for storing other things (yes that IS MIGHTY UGLY).

Also, in case a drug had been started within the last, say,
2 months or so (to be agreed on) it may actually matter
which exact day as to be able to find out whether a
guidelines recommended duration has been reached. In that
case it is very well discoverable (if not then the exact
start is STILL important and the .started turns into
.started_on_or_before for all practical purposes).

In cases a drug has been started somewhere within the last
12-15 months it may be important to know the number of
months (think TBC treatment). This will be discoverable to a
degree of uncertainty of, say, 2 months.

In some drugs it may matter which year they've been started
as patient benefits have only been proven for a duration of
intake on the order of 3 years of 5 years (think
Alendronate).

In cases a drug has been taken for many years it doesn't
matter in the least which day or even month it started.

So, why not teach GNUmed this morsel of clinical knowledge ? 
This is AFAICT what Jerzy hints at with "client side
handling".

> My point is that sometimes it is much easier to adopt a convention (by
> you and your co-workers) than to design a program which will satisfy
> all present and future needs including all possible exceptions.

Nonetheless, having a datatype "timestamptz with given
accuracy" supported along the entire stack of PostgreSQL,
psycopg2, Python, wxPython and GNUmed would be much
desirable.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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