gnumed-devel
[Top][All Lists]
Advanced

[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 21:55:44 -0700

Sorry... I was rushed (no excuse) and had not fully thought through my last post, which (to make it worse) had mistakes. Reposting:

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?

Are progress notes, even while not yet signed, currently "alterable" only while in memory i.e. until written into the database?

Permitting a note to be committed into the back end in an unverified form --- if such a note could be viewed by others, prior to its being "verified" --- poses risks.

I understand the competing use case, which may be one in which an important clinical entry remained unsigned on account of being called away, or maybe the clinician had to leave town without fully signing- off their entries, and during their absence a "covering clinician" may truly need access to that note.

On this basis, I would suggest:

- the ability to define a time interval or event, prior to which only the author could view an an unverified (unsigned) entry, but after which others could view the entry - the caveat to the above would be the need to make clear to the user (s) which if any entries are signed - the method by which to make it clear could include, as mentioned, a filter which by default did not display unsigned entries, or maybe did still usefully display the *existence* of a note, and just did not display the content (perhaps it would just display "unsigned")

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:
        http://lists.gnu.org/archive/html/gnumed-devel/2003-01/msg00133.html

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 (i.e. not possible ***to circumvent***) --- is that right?




reply via email to

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