Re: [Gnumed-devel] Handling of time hh:mm:ss in dob (date of birth)

[Karsten Hilbert]

On Sat, Aug 23, 2008 at 11:07:52AM -0700, Jim Busser wrote:

> Can we work from the purpose(s) that the date of birth serve(s)?
>
> 1. It could be possible to specify exactly the moment of birth, but does 
> anyone argue a need to reference that exact moment?

It is needed to correctly store Apgar scores. It can become
a need to know in managing legal estate.

I can see no valid argument against storing it *somehow* IF
it is known.

> 2. What are the downsides of maintaining a time field in a separate  
> field, only for those patients for whom the information is (a) available 
> and is (b) of any actual interest?

Semantically there is no downsides AFAICT. There is a
downside in somewhat increased complexity in coding.

> 3. If a dob field is maintained as date-only, the time zone would (I  
> think) be moot.
It may appear so but it is not. It's perhaps not so much
about things visible to the user but rather more about
computability of instances of time. Think about a neonate
being helicoptered to a speciality center across a time zone
boundary. Now, admittedly, that isn't the first place one
might imagine GNUmed being in use.

I also think it's just plain wrong to not properly store the
correct information when it is know. I agree it is also not
correct to make up times of birth when they are NOT known.
Hence I argue for enabling storing the time of birth and
also recording the time zone of it but agree that it
warrants improved modelling in the backend.

> It is true that at any one moment, the date can have  
> either of two values in the world. But date of birth is used primarily as 
> an identity and reference check
No, it is also used as a base for doing date/time calculations.

> However, in all 
> instances, I expect the record of birth would always want the date of 
> birth to be captured and to stand permanently as August 23. In other 
> words, for the purpose of recording, the date of birth yyyy mm dd at 
> whatever time the birth happened to occur locally is supposed to stand as 
> the date of birth irrespective of UTC. (*)
There's no question about that. It seems imprudent to throw
away, however, the whereabouts (which is, what a time zone
really is, sort of) of the birth event and to make it
impossible to go back and find out.

The time zone of birth hardly is of any technical difficulty
because it simply defaults to the local time zone which is
correct in most cases.

The argument "well, but I *know* my local time zone" is of
similar quality as "I got nothing to hide so I need no
privacy". It is, IMHO, short-sighted.

> GNUmed has been mostly careful about not permitting the storage of  
> information that is ambiguous or not truthful. Therefore, within data of 
> birth, the storage of a time that is not the actual time of birth  
> creates a problem. It sounds like it is being argued that a fabricated 
> time (despite that it bears no relation to the patient's reality) must be 
> entered in order to assure desired behaviour.
That is the current behaviour which is an unfortunate
consequence of enabling storage of true birth time at all
w/o going to the trouble of explicitely modelling it.

> I think we need a clearer exposition of the problem.
At the minimum we need a cleaner solution. My version of
which I outlined in another post.

> (*) if we ever got worldwide agreement that date and time of birth were 
> important and therefore important to coordinate with UTC we could revise 
> GNUmed. I suspect such worldwide agreement would frighten me !

Such things get ever more packed with importance (not truly
more important) with the advent of RFID'd (hence remotely
forgable) biometric IDs. The world's frightening enough
already these days.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346