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

[Karsten Hilbert]

On Tue, Aug 12, 2008 at 11:56:34AM -0700, James Busser wrote:

> Is it useful to think and talk in terms of a "fragmented" encounter?

> To interrupt a visit for missing documentation to be obtained, or for an 
> assistant to perform measurements, is one thing, but to send a patient to 
> get something done (like a test), and then come back to "continue" a 
> visit, would have been a clinical, medical management decision. Think of 
> the patient with chest pain being sent for the EKG upstairs. One can 
> imagine quite different outcomes depending on what happened to the 
> patient after you sent them out of the exam room, and what the EKG 
> showed. I would want to be able to make an entry recording what I found, 
> and what I had explained to the patient, for the pre-ECG and post-ECG 
> fragments.

Sure, no problem: write and save your progress note pre-ECG,
have the ECG done, then write another progress note
post-ECG, perhaps starting with "back from ECG, findings
are: ..."

That's entirely supported.

Rogerio and Jerzy simply ask for a way to edit existing
narrative post-hoc. I'll make that possible, most likely in
the 0.4 release. The updates (not additions which is what
your ECG example asks for) to the existing narrative are
audited, of course, so historical versions are available.

> As pointed out, it is possible that some second doctor sees 
> the patient after their return. Thus, in situations where it would be 
> desirable to document each fragment, it sounds like the doctor(s) may 
> need to decide to make 2 encounters.
Either is possible - generate 2 encounters or simply
continue the encounter and *add* new progress notes (rather
than edit the previous one). One may still want to edit the
previous note due to, say, a typo. Both are different use
cases and both want supporting.


> Other doctors may rather wait until the patient is back and add to their 
> initial SOAP note to make a single "official" note for the encounter. 
> This will only be possible after an "edit existing SOAP note widget" is 
> implemented.
No, they can do that even today - simply leave the patient
open and don't hit save until the single "official" note is
done.

If you want to work on other patients nothing (except your
workstation hardware) prevents you from opening a second,
third, ... hundredth instance of GNUmed and work with that.
I don't see a problem.

> One user pointed to the need to be able to bill unambiguously if  
> different doctors serviced different fragments of a visit.
That's a billing issue, not a medical one.

> I cannot see 
> that you could have a second doctor revising the preliminary entries of 
> the first doctor... the outcome to my mind would be as if the first 
> doctor did not make any proper (medicolegally defensible) note. The 
> "official" note would then belong to, and responsibility fall purely on, 
> the second doctor.
I agree.

> As to billing, I would point out that the audit ability should make it 
> possible for a doctor who was not the original signer to make a  
> correction in an entry, for example where the original doctor mis- 
> entered right vs left and there is value making sure that no error gets 
> perpetuated. Depending on convention the person correcting might enter 
> e.g. [correction: right]. But while this would become the new note, 
> signed by a new doctor, it would not change which doctor actually 
> provided the consultation. Billing software may therefore not rely on the 
> signer to determine under what doctor the billing is charged,
Precisely. I strongly advise against mixing billing and
medicine. I do advise to let medicine *inform* billing but a
decision needs to be made by a biller (a person, that is).

> Maybe this makes it importance for billing to intelligently piggy-back 
> without being wholly reliant on the part of the GNUmed design that is 
> needed to make the record of care to make sense.
That's the native speaker's version of what I was trying
to say :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346