Re: [Gnumed-devel] chart accesses (was Storage and and representation (formatting?) of past history items)

[Karsten Hilbert]

On Sun, Jan 13, 2008 at 03:48:53PM -0800, James Busser wrote:

> Is the encounter created when a patient is selected for example from the 
> search box?
Whenever the clinical record class is instantiated. In the
dead-tree world this is akin to opening a folded up paper
chart to actually see what's inside as opposed to simply
taking it from the drawer to perhaps put somewhere else for,
say, archival.

> Might it be desirable / acceptable to not auto-delete empty encounters 
It might, yes :-)

> (maybe just filtering them)?
They are filtered already (at least in the current
incarnation of the EMR tree).

> There is a use case that is not edge, but may in fact be core for some 
> groups, to be able to audit the accesses of a chart. Even though clinical 
> people will be mostly interested about entries in the chart, not caring so 
> much about read-only activity, patients (even ignoring regulatory demands) 
> want to be able to know, if they should ever be concerned, who has been 
> viewing their chart.
This is impossible by technical means short of videotaping
physical access points. However, the encounter table is
audited just like any other table, so, even if empty
encounters are deleted from the "proper" encounter table
there is still a track record of them in the audit log table.

> There is even a functional advantage to being able to see who accessed a 
> chart.
It is only possible to give some indication as to under
which system account a chart was accessed. It is not
possible to say "who" as in flesh-and-bone. Read-access logs
are more feel-good than really helpful. And they tend to
become gargantuan in size. Read-access control is usually
advised to be carried out with proper credentials handling
and implementation of social security measures. Effective
access control measures include a social component such as
split-secret or counter-signing or videotaping under the
"threat" uhm assertion of random tape review.

> For example a patient seems to have failed to show for an 
> appointment. They are contacted and warned they should give better 
> notification if they will, in future, miss an appointment. But they explain 
> that they did in fact phone the practice the day before. In the scenario 
> that I describe, the secretary who may have been part-time, or away when 
> the dispute arises, might have activated the patient during the phone call 
> and intended to make the change to the appointment but then got distracted 
> and before they made a change to the appointment, handled the next phone 
> call for a different patient. This log (or some kind of log if it is 
> desired to record somewhere other than in the encounters) can at least show 
> that secretary X activated the patient record the afternoon before the 
> missed visit. This would support the patient's story and permit any 
> clarification to be done with secretary X if it was needed.

Yep, this particular use case can be solved via the audit
table. Also, currently, the encounters aren't deleted before
a weeks time has passed sinced their inception when the
patient is activated. I added a configuration option for
that timeout. Setting it to, say, '1000 years' will
effectively disable deletion of empty encounters.

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