[Gnumed-devel] Re: Clinical Transactions

[Karsten Hilbert]

Sam,

belatedly some commentary:

> While I am not an expert at SQL it seems that a particular
> "Clinical Transaction" could could contain a field allowing the
> users to associate the "Clinical Transaction" with a specific
> "Episode".
Absolutely. Or Transaction -> Partial Encounter -> Episode.

> A drop down box could be used to select the correct
> "Episode" (or add a new "Episode").
Or rather a phrase wheel which is a drop down box that scroll
the choices as you type and adds a new entry when you run out
of choices.

> SQL queries could sort all transactions by location,
> provider, Episode and/or date. The SQL queries would be most
> useful if the end user could pick which fields fit the user's
> needs the best. A time range for the query could help users
> find particular clinical events.
We would want to avoid to bother the user with details as to
the underlying database structure. OTOH it surely is necessary
to allow for some amount of selectivity as to what information
is being displayed. Most of the time I would want to work with
the user interface part that's predefined and only in rare
cases turn to using a more generic querying frontend. (Mind
you, I can write some SQL from the top of my head but I'd only
use it if I wanted to dig deeper than what the custom frontend
offers - and for that we already got the SQL plugin in
GnuMed.)

> This working method would require one additional field in the
> Clinical Transaction table. Clinically there is little
> functional difference between a "Partial Contact" and a
> "Clinical Encounter".
Clinically, no there is not. But from a computational point of
view it makes all the difference in the world. Things would
work like this: Upon invoking GnuMed the "provider" is defined
courtesy of her logging on. Upon invoking an EMR the last
active episode is made active. If the last encounter was
within the last, say, 12 hours (configurable) the user is
asked whether this constitutes a new encounter or whether she
wants to add to the last encounter. If new encounter a new
partial contact is created else the last partial contact is
used. Now, when she switches episodes (or creates a new one) a
new partial contact is created (unless one for the other
episode exists already within this encounter in which case
it is reused - such as when switching back and forth between
two episodes within one encounter).

> Sorting the "Clinical Transaction" table
> with nested queries: (Practitioner(Episode(date))) or
> (Practioner(date(Episode))) would give two different clinical
> views. The first would give a view of the disease state for a
> specific "Episode." The second would identify what happened on
> a particular day.

Oh, wait, you mean, like, what happened in one particular
encounter and relates to one particular episode IS the
partial contact ?!?  I guess that's true enough. So the need
for the explicit partial contact becomes questionable. Good.

> The difference between "Partial Contacts" and "Clinical
> Encounter" I believe can be recognized very easily by the date
> and time stamp.
For us, yes. For the computer, no. But: all the clinical
transactions with both identical Episode IDs and identical
Clinical Encounter IDs ARE the partial contact. Sounds
reasonable.

> A lump of 8-10 transactions with the same date
> are going to be easily recognized as an Encounter.
I do see some patients twice a day. I also see patients while
across midnight :-)

Need to rethink the need for Partial Contacts and will design
some tables.

It would become:

Transaction -> Episode
          |
          `--> Encounter

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