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

[Karsten Hilbert]

On Fri, May 09, 2008 at 10:38:17AM -0700, James Busser wrote:

> Vancouver and Germany (where I presume the server to reside)
correct

> 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

That doesn't matter. The code takes into account the wire
roundtrip. The adjustment for on-the-wire delay was:

> 2008-05-09 08:14:04  DEBUG     gm.database: wire roundtrip (seconds): 
> 0.462917804718

Or, IOW, half-a-second. Possibly noticeably but well under
the 30 seconds jitter allowance.

> 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.

Not really. As you see above, Your machine took 469ms to
send the time request to the server and get a response. Your
clock really is off by about 55 seconds from atomic time.

However, Tobias raised a valid point - while requiring a
fairly close time sync is all nice and good (for the reasons
you list below) it can be unhelpful for those poor souls
running operating systems which make it a hassle to
atomic-sync their clocks online.

Hence I'll raise the allowance to, say, 5 minutes when
running in --debug mode while setting it to 1 minute while
in non --debug mode (which may be some sort of indication of
"in production"). Now, even in --debug mode the warning will
appear at > 5 minutes skew but logging in will proceed
anyways if that's desired.

> 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.
The latter is more important, methinks.

> 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.
Precisely ! The timestamps recording when data was
technically committed will still be in the correct order
because that timestamp is set by the server and hence by the
same time source for both commits but if the commit
semantically contains a "clinical time" that will have to
come from the client machines and can thus be in the wrong
order.

> 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. 
That sort of thing may have legal implications.

Imagine you signing off all pending results then going off
on holiday. *Then* a new, catastrophic result comes in and
is inserted "before" you signed. This result then somehow
fails to come to the attention of the covering doctor(s).
The patient dies. You return and a judge is going to ask
why you didn't sign that one result along with the others.

Of course, GNUmed still lets you prove (by means of the
modified_when timestamp in the auditing system) that
technically the data was inserted after you left which will
get you off the hook. But all in all it seems prudent to
encourage at least minimum due diligence (at least when not
running --debug).

> 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?
Yes. Also, the provider inbox will still display "unsigned
results" regardless of whether there are any signed results
that appear to be younger.

> 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
It wouldn't. Signed data and signatures are separate
entities. But it sure sounds bogus. I'll put it on the TODO
to check for that.

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