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: Jerzy Luszawski
Subject: Re: [Gnumed-devel] encounter edit before final save
Date: Mon, 11 Aug 2008 10:24:23 +0200
User-agent: KMail/1.9.9

Saturday 09 August 2008 06:55:44 James Busser napisaƂ(a):

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

> Are progress notes, even while not yet signed, currently "alterable"
> only while in memory i.e. until written into the database?
They are, indeed. But you cannot alter anything after hitting "Save" button.

> 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.
Data entered but not signed-off should be regarded as unreliable, so there is 
no use of them for anybody, until they are signed. I cannot imagine a case 
when clinician leaves town without finishing started consultations. (We are 
discussing encounters, not closing the issue = healing the patient 
completely)  But if this happened, I would have to recheck *every* data 
entered by this consultant for possible ommisions, so even if I had something 
in the DB, it would only save me typing a few lines of text - this is not so 
important.

I would say, we can disregard this rare cases, and not store any "temporary" 
data in the DB. 

The more likely scenario is that a patient comes in, the consultation starts, 
then the patient is sent to, say, ECG or x-ray, in this time next patients 
come in, then the first one returns, and the natural way would be to 
continue "paused" consultation. Of course you can have each procedure as 
separate encounter: first part of the consultation, lab, radiology, final 
part of thnue consultation,but this will make it difficult to analyse all 
data as a whole, to generate a report from the consultation, and to prepare 
billing data. This is my point of view. Other may have different needs and 
different formal requirements to meet.

In my opinion entering "progress note" is slightly different from eg. entering 
lab results or attaching documents. Lab results or radiology reports are 
finished, complete before they reach clinician. So entering them is only a 
matter of storing a copy, Most of the time they can be verified by others 
against "original" report. "Progress note" is the first, original data entry. 
No result leaves a lab without sign-off. Similary, no progress note should be 
made available to others without explicit save


> 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
As I mentioned above, this is not helpful, as data become unreliable, and 
possibly misguiding.

> 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?
I got the same understanding. It is interesting concept.




reply via email to

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