gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Document parts display


From: Busser, Jim
Subject: Re: [Gnumed-devel] Document parts display
Date: Thu, 8 Dec 2011 01:47:06 +0000

On 2011-06-26, at 12:36 PM, Karsten Hilbert wrote:

> On Sun, Jun 26, 2011 at 09:14:28AM -0700, Jim Busser wrote:
> 
>> 3. when a document is imported by a primary reviewer while
>> logged into GNUmed (for example the printing of a FreeDiams
>> prescription) and despite that I agree it *might* be
>> desirable to add comment information, is it feasible to be
>> able to (configure to) allow any of these to be auto-signed
>> in the same way that we do not separately "sign" our own
>> progress notes?
> 
> Since we now have .pk_primary_provider on dem.identity we
> can now fairly sanely determine the default intended
> reviewer for a particular patient.
> 
> GNUmed now uses either that or else the logged in provider
> as the default for blobs.doc_obj.fk_intended_reviewer.
> 
> Based on that we can implement auto-signing of those
> prescriptions for which we are the intended reviewer.
> 
> Done.

Despite that I am primary provider for patients, when I

        Correspondence > Write

 a document and assign an episode no auto-signing is happening. I am not sure 
whether this is because it will not take effect until GNUmed next, or because I 
did not yet take of some configuration, or because auto-signing will not take 
care of populating whether the document is

        technically abnormal
        clinically relevant

Thoughts:

- I suppose if the Oo or Latex template was one designed to output billing 
information, then the document which would have been imported (attached) might 
be accurately predicted to deserve

        clinically relevant = FALSE
        technically abnormal = FALSE

whereas for most other imported reports,

        clinically relevant = TRUE

        technically abnormal = <---- this one really applies only to a 
diagnostic test

Is it believed these should be properties of templates wherein the properties 
may be

        TRUE, FALSE, NULL


Another related question -- where a default value for a particular template 
type would exist for

                technically abnormal
                clinically relevant

can that value be allowed to be saved with the attached document even without 
(yet) having a signature? This would cut down on human error where the desired 
value could already be known in advance, based on the document type, and the 
clinician could then, at the time of signing

        1) decide how to populate a value that was null
        2) decide whether to agree with or alter a default for document type
        3) sign it

-- jim




reply via email to

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