[Top][All Lists]
[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.
- [Gnumed-devel] Re: Gnumed-devel Digest, Vol 69, Issue 17, Rogerio Luz, 2008/08/08
- Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 69, Issue 17, Karsten Hilbert, 2008/08/08
- Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 69, Issue 17, Karsten Hilbert, 2008/08/08
- [Gnumed-devel] encounter edit before final save, Jerzy Luszawski, 2008/08/08
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/15
Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, Rogerio Luz, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/13
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/13
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/13