[Top][All Lists]

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

Re: [Gnumed-devel] server-client clock mismatches

From: James Busser
Subject: Re: [Gnumed-devel] server-client clock mismatches
Date: Fri, 09 May 2008 10:38:17 -0700

On 9-May-08, at 8:45 AM, Karsten Hilbert wrote:

The log indicates that client and server are off by roughly
one minute which isn't a whole lot.

What would people consider a reasonable boundary condition ?
1 minute, 2 minutes, 5 minutes ?

Vancouver and Germany (where I presume the server to reside) were "off" by 55 seconds, and reside at a distance (separation) of about 8,000km

Canberra / Melbourne are at a distance of about 16,000km

Therefore if the purpose is to avoid inhibiting connections to the test server from anywhere in the world, at least 2 minutes would be required, and 3 minutes would be safer.

The clinical importance of such things is in the real-time ability for people to see what is happening (which GNUmed supports, within whatever latency will allow) and also how the event was recorded. If users A and B were both accessing a single patient's record at the same time (as could happen during a phone call), it is possible both "write" to the record in quick succession (within a minute or two of each other). But what is important is not whether the timestamps were off by 2 minutes vs 4 minutes but the fact that two records committed in close sequence may get stored, and viewed, and presented in an inverse order to their real occurrence.

If I connected remotely and am recorded to have "signed" a patient chart entry at 20080509 at 11:00:00h, and shortly thereafter but unknown to me a local lab handler imports lab results, and assigns them an import time of 10:58:00 (making them appear to have been available two minutes prior to my finishing what I had done) I am still not sure I see a problem. Yes, if would come out to the main screen, I could see some message that these records are now in the system magically stamped as 1-3 minutes older than I may like. But even if I now sign them, won't the datetime stamp of signing be determined by my client, which would would maintain an audit of my activity as sequential?

I suppose if the records were assigned a later datetime stamp of creation and a person tried to sign them with an earlier datetime stamp that might trigger an error depending on the backend table constraints.

reply via email to

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