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

[James Busser]

On 11-Aug-08, at 2:51 PM, Karsten Hilbert wrote:

> > From this point of view,
> > "closing" means marking it "read-only". Until it is "closed" you  
> > are free to add
> > data like now, and it would be nice to be able to change data as  
> > it is
> > planned.
> OK, now *that* is an interesting point you make. It might well be  
> worth to eventually introduce
> the notion of "freezing" an encounter.
>
> This could happen at an appropriate point in time after a new  
> encounter has been started. However,
> I am not sure how much that really buys us because we are  
> essentially freezing the state of the EMR
> anyways when we dump the database, hash the dump and have the hash  
> signed by a digital notary.
> Which one of our users does on a regular basis. Such a signed dump  
> hash includes all audit trail
> information as available at the point in time of dumping.

The best answer to the above may be to be able to express the EMR as  
it existed for a particular patient at a certain point in time. If a  
patient last saw a doctor at 2PM August 5, 2008 and if the issue  
becomes what the doctor found, what the doctor advised, and what the  
doctor did as of 2PM on August 5, 2008 then it should be possible to  
provide an EMR export that expresses what was in the record at that  
point in time.

In other words, if notes which were committed at 2PM were  
subsequently altered later on the same day, or at some later point in  
time when news of a complaint or adverse outcome surfaced, it would  
be important to be able to provide an EMR export that included the  
normally-hidden audited versions, along with time stamps.

The module could optionally exclude entries altered or added after a  
certain point in time however these could be important if they  
included legitimate clarifications and could be simply ignored by the  
reviewer when irrelevant. The module could also optionally limit the  
export to certain selected issues of interest.