[Top][All Lists]

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

[Gnumed-devel] semi-automagic encounter handling

From: Karsten Hilbert
Subject: [Gnumed-devel] semi-automagic encounter handling
Date: Tue, 24 Jun 2003 00:48:56 +0200
User-agent: Mutt/

Dear all,

the first functional version is checked in. Upon selecting a
patient the GUI tries to attach to a previous encounter. If
that encounter is younger than encounter_soft_ttl
(time-to-live) it is always assumed to still be valid (say, I
switched to another patient for a couple of minutes and now
come back to the first one). If the encounter is aged between
*_soft_ttl and *_hard_ttl the user is asked whether that
encounter is still ongoing. Older encounters are considered
done and a new one is created. Defaults are 2 hours for the
soft and 5 hours for the hard limit. Those values are
configurable. If a doc never wants to be bothered by that she
just sets both limits to the same value. If it's a sane limit
such as 3 hours she'll never be asked about reusing any
previous encounter but will still get reasonably accurate
automatic encounter separation. This has been tested lightly
and appears to work as intended. The age of an encounter is, of
course, calculated from a last_affirmed timestamp, not the
"started" one. So, a long encounter of 3 hours will still be
considered ongoing if there's a half-hour gap between patient
invocations. Courtesy of the data being stored in the database
this works cross-client (if them clients implement the
"protocol" described above). This strategy also allows for
cross-midnight encounters. At appropriate times the clients
should reaffirm the ongoing state of the currently active
encounter, such as when major events take place in the EMR
(such as a script being printed etc.) This does depend on
client benevolence to some extent. Oh, and we do not deal
with id_provider and id_location in clin_encounter yet. They
default to -1 thus being easy to detect later on as they may
never meaningfully take on a negative value.

All this now allows for connecting the single box SOAP to the
backend. Code for which is in but neither tested nor known to
work so far.

Public database has been bootstrapped to reflect the relevant
schema additions.

Comments, bug reports please.

PS: No, this does not deal with setting the encounter type yet
as is selectable from the top panel combobox.
GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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