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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
