Re: [Gnumed-devel] Encounter overlaps in GNUmed in future 1.2

[Karsten Hilbert]

On Sun, Apr 01, 2012 at 04:49:11PM +0000, Jim Busser wrote:

> Patient C's results came in after the patient departed,
> but inside the min = 1.5 hrs interval. It is theoretically
> possible that the importer would respect the settings and
> assign the most recent encounter type of "seen in praxis".
> This too is actually complicated, because if there exists in
> the praxis clinicians whose individual preferences for "min"
> are { 1hr 1.5hrs 2hrs } then which one of these does the
> importer use?

It simply uses the preferences of whichever user it is
running as - if so desired. Or it could have it's own idea
about the whole thing.

> Should it be so complicated that the importer
> should try to match the doctor who ordered it, or the doctor
> who is being sent a copy, against their individual user
> preference? What if User X has *two* preferences (a
> different one for each of two workplaces)? What does the
> importer do then?

Those questions clearly don't have a single answer. They
simply need a decision.

> Now we come back to the question I started with. What
> would a user wish to see on reviewing the patient's
> encounters?


> Despite that all are in the same situation (results
> imported after they left the praxis, and we do not by the
> way in GNUmed explicitly record when they "departed")

Staff *could* make a note if so desired.

>       Patient A
>               seen in praxis
> 
>       Patient B
>               seen in praxis
>               ???
> 
>       Patient C shows
>               seen in praxis
>               imported results

Why are you worrying about encounters or encounter types in
relation to newly imported results ??

Simply look at the inbox ?

Or else look at the episode "new lab results" (or some such)
which the importer likely created (because it cannot know
which episode(s) the incoming lab results actually belong
to).

> I think that importers should import results under an "imported results" 
> encounter.

Well, so, why not do it ?

> I suggest that the kind of encounter (same or different)
> to be assigned at the *next* chart interaction should depend
> not on any min/max time since the result was imported but
> rather on whether the next chart interaction is an automated
> import or a human interaction
>       - if a lab import, the same encounter type could be used and the 
> "last_affirmed" re-timestamped

That would put all imports under one encounter, which is simply wrong.

> I also think that user prompting should be based not on
> the most recent *start* timestamp

It isn't.

> We already have in GNUmed a special health issue which is
> a holder of "Unattributed episodes" because we see the value
> to next together multiple things under such a construct. I
> am thinking that a similar concept apply to imported data.

"Unattributed episodes" aggregates by content while an
"import encounter" would aggregate temporally distinct data.
Now, the whole idea of the Primary Care EMR is longitudinal
care so this doesn't make sense to me.

> Say a patient, in a time period of 8 weeks, had 5 visits but 14 discrete 
> imports of results which looked like
> 
>       visit
>       import
>       import
>       import
>       import
>       import
>       visit
>       visit
>       import
>       import
>       import
>       import
>       import
>       import
>       visit
>       import
>       import
>       visit

An argument can *perhaps* be made for someone writing
support to suppress "display" of undesired encounters (in
certain places).

Another argument can be made for importers to be written to
re-use encounters as in one-per-day or so.

OTOH, all those "import" encounters would likely link to an
episode "result imports" which (if you do see the above) you
are obviously explicitely viewing.

There is, within GNUmed, simply no place where you would see
the above - unless you chose to ignore episodes (and thereby
problem list management) - except in the static list of
encounter - which is a data management tool, not a health
care visualization tool.

> I would even suggest to sort encounters by last-affirmed,

1) Within which widget ?

        -> this defines the purpose of the display and thus any
           sane sort order

2) the EMR tree sorts by .started, latest top-most

3) so does the encounter list

4) other places sort differently (EMR journal, journal view in tree)

I think you need to be more specific on this.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346