[Top][All Lists]

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

Re: [Gnumed-devel] encounter edit before final save

From: James Busser
Subject: Re: [Gnumed-devel] encounter edit before final save
Date: Fri, 08 Aug 2008 16:56:22 -0700

On 8-Aug-08, at 2:51 PM, Karsten Hilbert wrote:
On Fri, Aug 08, 2008 at 06:13:30PM -0300, Rogerio Luz wrote:

- the impossibility to edit anything after it is done but BEFORE I close the
I expect this to be improved in 0.4 which will let you edit
the current encounter (your own notes in it, that is).

On 8-Aug-08, at 4:02 PM, Jerzy Luszawski wrote:
For now - it is almost unusable for me and my friends

Karsten - would be it much work if you were to change it?

Both of the above are important considerations. Can the challenges be broken down for better understanding?

Currently, encounter information alterable only while it is in memory, correct?

Perhaps it is a concern that as soon as any data is written into the backend database, the data may become immediately accessible to other providers and that if a decision were made on information that instants later got changed, it may be important for the person who made the decision (based on information which had changed) to reconstruct what had happened, which GNUmed does not yet assist?

The ability of providers to see information prematurely places them at risk of making a decision on information regarded by the creator as only at a "draft" (unverified) state of clinical reliability.

So maybe the first question is whether we need a control step interposed, in which something would only *normally* become visible after it has been signed, but could *optionally* be made visible if the interested provider would unfilter the default.

Do we have agreement that it must at least always be very clear, to every provider when viewing information, if notes/entries cannot yet be regarded as "signed", even to the extent of hiding unsigned entries but with the option to unhide them?

Overlapping the above is the concept of "limbo" entries which AFAIK has not yet been agreed, and therefore not yet incorporated into the schema design nor software:

If I understand the above correctly, the limbo flag would subvert the audit system until such time as set to unlimbo after which control by the audit system becomes non-optional (not possible)?

In the meantime, pending any agreement and deployment of limbo support, is the obstacle to editing (auditing) any belief that the ability to audit must be accompanied by the ability to view the audit trail, which would take extra time to develop?

reply via email to

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