[Top][All Lists]

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

Re: [Gnumed-devel] limbo table entries

From: Hilmar Berger
Subject: Re: [Gnumed-devel] limbo table entries
Date: Mon, 20 Jan 2003 18:43:58 +0100 (CET)

On Tue, 21 Jan 2003, Horst Herb wrote:

> > Oh, you want to apply the limbo flag to semantically new
> > records only ? That is to original (not rewritten-to) INSERTs
> > only and not to original UPDATEs ? Must have misunderstood
> > that somewhere.
> Yes. Otherwise the audit trail would be pointless.
> The point in having the limbo is to allow the author of a record some time to
> finalize his thoughts and to edit his narrative without subjecting him to the
> perils of a volatile platform, user interface or connection. But, once a
> record exists outside of the limbo, the author should make his mind up
> *before* he starts changing records. After all, health records are not
> something that is changed on a regular basis, isn't it?
Maybe I'm wrong, but I could see some use for a limbo state on
updates, too. Imagine a user starting to enter a new form (prescription
etc.). The client might want to prefill all fields with a default value.
A subsequent update of this prefilled fields could be securely limboed
until the action of filling the form will be finished. A signal
"update_finished" could be sent by the client clearing the limbo flag
thereby enabling auditing this version.

IMHO the semantics of INSERT and UPDATE are a little bit confusing here.
At database level it means the creation or change of a single row in a
table or view. At user level it means the creation or change of complex
objects. That's why we might need a little bit more communication between
client and backend to confirm that the client object (whatever that be)
has been finished and should be inserted as a whole.

At work we are using software to log all information entered by medical
personal and data coming from medical devices in the operating theatre.
As far as I know this software uses a similiar approach to store the data:
entered/received data must be first validated before it is written to the
audit trail. This validation can be achieved by either user confirmation,
automatic validity checks, saving the whole patient related log,
proceeding to the next protocol page etc.
Once the data has been validated and written to the audit trail, you must
confirm every change.


reply via email to

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