Re: [Gnumed-devel] unsafe operations

[Karsten Hilbert]

Please keep posting to the gnu.org list.

> Is the meaning usafe for the patient, or medical legally unsafe for the
> practitioner?
Both.

> An example of usafe for the patient:

> - patient has obsolete address or phone number, and is uncontactable
> after an abnormal result comes back.

1) the patient has left, the result comes back, is associated
with the patient's demographics which turn out to be wrong.
This can happen if the patient changes place of residence
without dutifully reporting that to his doctor. Unlikely,
particularly since the patient will have left a forward-order
with his erstwhile post office.

2) the request has left, the patient changes his demographics
at the front desk and leaves, the result comes back and is
associated with the updated demographics. Nothing goes wrong
here.

3) the result comes back while the patient is still changing
his demographics at the front desk. the result is associated
with the patient (and only on demand with his demographics
[as, of course, in scenario 1 and 2]). Now either I notice the
result and call the front desk to ask whether Mrs. Smith is
still here so I can tell her about it in which case a change of
demographics does not matter. Or she has now left in which
case the new demographics will have been committed and any
letters will go to the right place.

The only window for inconsistency would be if an incoming
result triggers automatic notification of the patient while
said patient is updating his demographics at the front desk.
Here MVCC may send the letter to the wrong address.

> A system could contribute to this
> problem if  a clinician or para-clinician enters a change in demographic
> details , and believes the system has recorded the change , when in fact
> it hasn't.
This is a bug.

> - a clinician works part-time , or is away on holidays, and an urgent
> abnormal result arrives electronically . The system could contribute to
> the problem if  the sender of the message thinks the system has received
> the message and recorded it , when in fact it hasn't. The system could
> contribute to the problem if it advertises the ability to alert other
> other parties , when it doesn't.
Two more bugs. The second bug constitutes vaporware.

> - a system is supposed to keep a record of clinician entries , and no
> lost updates should be allowed , especially in an environment where
> there is more than one clinician involved in the management.

> No clinician should assume a system records all observations if in
> fact it doesn't, especially in an environment where there is off-site record
> keeping,
I must admit I fail to understand the meaning in this that
goes beyond the obvious. I particularly don't understand the
connection with off-site record keeping.

> however one would like the system to record all data
> aknowledged as recorded.

> There should also be no dirty reads, where
> another clinician reads updates which later are aborted because of
> system failure.
Uhm, huh ??

What I read from the database has been committed. It can only
vanish through direct deletion (which we disallow by
update-only triggers) or disk drive hardware failure (which we
better guard against with RAID and backups).

> - if each field of the record system is allowed to insert into the
> database as it changes, then transaction boundaries have to be
> maintained.
They are to be maintained. Anything else clearly is a bug.

> A record system which commits only at the end of an entry
> session can still be compatible with client restarts , assuming that a
> transaction start and end  only occurs at the end of a session.
> Exclusive read-write locks , also prevent someone else reading obsolete
> information whilst a record is being made during a long session. 
Well, one could also argue that information only becomes
obsolete the moment it is known to be obsolete. The
non-obvious part in this statement: This happens at different
times for different clients. She who enters the new
information knows of it earlier than she who uses the
still-current data in the database. Tough luck. In cases where
incoming results are crucial the clinician(s) will poll for
their arrival due to medical diligence anyways.

>       On the other hand, read only access could be allowed for others who
> have not opened the clinical record for writing, as long as it was made
> clear  to the reader that someone else has it open, and updates are
> pending and occur only  when the record is 'returned'.
I do not believe in the scenario "me have the record now and will
return it all new tomorrow evening".

> Demographic information could have a separate transaction boundary to 
> clinical information, which would allow e.g. the front desk to update
> the record whilst the clinician is updating the clinical record.
Uhm, aren't we aiming for BEGIN..COMMIT/ROLLBACK cycles much
smaller than this ?

> However, if any action that depends on demographic information is
> attempted, the clinician could be blocked from doing that action until a
> pending update to demographics occurs.
Like what ?

> If a clinician executes an action
> that depends on demographic information, and another staff updates  the
> demographic information LATER within a reasonable time after the
> demographic-dependent action, then all system users should be alerted to
I guess not.

> If this is detected after the patient leaves, then several remedial
> actions could be taken: 
> in case of referral or test ordering,
You mean, like, me referring a patient to, say, to neurology
assessment AFTER the patient left ?? Surely I would have
talked this over with the patient and told him to wait for the
referral note at the front desk. If the patient then leaves
without it (that DOES happen) -- tough luck. I jot down a
short blurb to that effect in my notes.

> Failure and re-start of clients shouldn't be such a problem if
> transactions don't start at the start of a consultation , but start and
> begin when the consultation is ending, and the clinician is mindful that
Uh, no. My patients regularly forget what I told them when to
come back on the way to the front desk (about 10 meters through
2 doors). If so the staff looks up what I wrote down in the
notes. I may not have finished entering other things.

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