gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Clinicians: document content date in archive


From: Syan Tan
Subject: Re: [Gnumed-devel] Clinicians: document content date in archive
Date: Sun, 07 May 2006 14:24:18 +0800

clinicians might grumble at having to use a universal date ordering ie yyyy/mm/dd , and

would rather their locale / personal habits , but I suppose anyone willing to use gnumed

because of idealistic / cost efficacy reasons will be willing to be "trained".



On Sun May 7 12:58 , Ian Haywood sent:



Karsten Hilbert wrote:
> Hello all,
>
> we allow the user to associate a point in time with any
> document in our archive. This field is later used for quick
> visual selection of the relevant documents a doctor is
> looking for, eg "8/2001 neurological discharge letter" where
> the "8/2001" is the part coming from the date field.
>
> Currently, this field is free text such as not to constrain
> whatever precision of date is known, eg 2001, 8/2001,
> 2001/8/27, 2001/8/27 @ 15:22:33 are all possible inputs.
> However, "total crap" is valid input, too, currently, which
> does not lend itself to useful post-processing.
>
> Making it a real timestamp isn't really an option due to
> medical realities.
>
> I am not sure about the stability of Ian's attempt at a
> fuzzy timestamp type.
>
> So, what do people think we should allow as input in terms
> of string parsing. I am thinking of (d=digit):
>
> dddd - year
> d/dddd or dd/dddd - month/year
> dddd/dd/dd - year/month/day
> dddd/dd/dd hh:mm:ss - year/month/day hour:minutes:seconds
>
> Do you think this will suffice ?
I think so. You can write triggers to enforce this with regular expressions.
It gets hard when you want to order entries and compare (which you often will) as doing this on free text gets slow.

The proper way is to implement a new Postgres type which holds a timestamp plus
and accuracy field (one byte). Operators for comparsion ad equality can be written, which becomes fast and easy.
This is all doable, not too hard, and I'm happy to volunteer.
The downside: AFAIK it has to be done in C, which means compiling, which is going to be a new experience
for some and potentially a right royal PITA across the board.

The 'halfway-house' is a pair of fields: timestamp and a single constrained char for accuracy. Fast
sorting on the timestamp, plus some PL/SQL functions to compare and produce a printable version.

Ian


_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel



reply via email to

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