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

[Busser, Jim]

On 2012-04-01, at 4:00 AM, Karsten Hilbert wrote:

> I understand the scenario but the concern ("the importer pulls in ... data
> which does not relate clinically to today's encounters") does not line up
> with what an encounter is in terms of GNUmed.

My concern is that imported lab data may not get dealt with (even acknowledged) 
in the time frame in question.

It is even clearer if the patient did not return immediately after their X-ray 
at 1145, since the clinician might not even reactivate the chart until the 
x-ray report would come back to the praxis. Surely the educator may not deal, 
between 1000h and 1100h, with what the importer brought in at 1010h.

Looking at it a different way, when a user would open up the list of known 
encounters using EMR > Add / Edit > Encounters, what would it be useful or 
desirable to see?

- the various encounters which represent interaction with the patient
        - seen in praxis
        - seen elsewhere
        - phone discussions which get documented

- chart reviews

- imported documents / labs

If I am understanding correctly, suppose GNUmed is configured via Preferences > 
EMR to have minimum / maximum durations of 1.5 hours and 4 hours. Suppose also
- patients A, B, C are seen in praxis at 0900-0915h, 0915-0930h, 1100-1115h 
respectively
- the lab importer imports results for these patients (and others) at 1320h

Patient A's results came in more than 4 hours after their visit was last 
affirmed. Maybe it will be assigned the default new encounter type "review 
chart" although in my view it would be bad because it will incorrectly 
represent the nature of that encounter. Hopefully an importer can assign a type 
"imported results", overriding what is defined in the postgres table as the 
default.

Patient B's results came in between 1.5 and 4 hours. If the lab result would be 
entered into GNUmed manually via its client GUI, the user would be prompted and 
asked whether they wished this new interaction with the chart to continue the 
old encounter or begin a new one. While this behaviour could theoretically be 
replicated by an importer (which checks the configuration and then prompts some 
user before the transaction will continue) it would be madness to make the 
import depend on a user to manually judge every impacted scenario. I would 
further point out that it is possible that different users in the praxis may 
have different work flows, which result in different min / max values. Let us 
set aside B for a moment as "complicated" if we would try to deal with this min 
/ max during importing.

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? 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?

I will also set aside for now the question of whether an importer should be 
created so as to have its own preferences for min / max encounter duration. If 
it creates an encounter of type "imported results" then I can imagine that if a 
user happens to look in their inbox and to deal with this result before "min" 
time has passed, the progress notes might be nested under "imported results" 
but if the results had come in during the morning while the clinician was in 
the hospital and so get signed in the afternoon, we would presumably have a new 
encounter "review chart". Even so, the user is logged in under themselves and 
so I would think it is the user's own preferences that will determine how the 
encounter typing / prompting will be handled.

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") and even if we figured out a way for the importer to handle "min" / 
"max" in the same way the GUI handles them and the problem of different users 
having different preferences, we would see

        Patient A
                seen in praxis

        Patient B
                seen in praxis
                ???

        Patient C shows
                seen in praxis
                imported results

If we instead created an "imported results" encounter for each of A, B, C it 
makes it possible to see what happened with each patient's records.

I agree that each encounter has the possibility of an "end", but its value 
cannot be predicted in advance and that may explain why we instead use the 
concept of "last_affirmed"

I think the idea of min / max is a helpful fuzzy prediction tool to try to nest 
entries as much as possible under the single (or separate) encounters under 
which they perhaps more-logically relate, and in a way that tries to reduce the 
nagging of users by accepting user configuration of what is *likely* the same 
or a new encounter 

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

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
        - if a human interaction, then some other encounter type assigned

I also think that user prompting should be based not on the most recent *start* 
timestamp but by somehow taking into account the min / max setting and any 
"last_affirmed" timestamp. Supposing in the case of a patient who was

        seen in praxis 0900-0920
        (visit interrupted -- say patient had to go somewhere
                or do something with a plan of return at 1100h)
        imported results 1017-1017

When the patient returns at 1100h, and the user re-activates the record, I see 
no harm (and it might actually be helpful, in the notes editor) to see that the 
most recent encounter was "imported results". 

There is no getting around the fact that if your EMR supports automated results 
import, you are going to have some patients whose data import events are going 
to be more numerous then your direct patient contacts. You will have not only 
the results of the tests that you ordered, which will be likely to come back at 
multiple and different times, but you will also get copies of results of tests 
ordered by other clinicians.

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.

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

I might rather see, for each patient, a single encounter of type "imported 
results" by allowing it to be re-used each time the importer runs, and it would 
simply update the value of last_affirmed.

I would even suggest to sort encounters by last-affirmed, which could then (as 
in this example):

        visit
        visit
        visit
        visit
        import
        visit

allow you to see that there there has been no new results imported since the 
last visit. An alternative would be for the importer to set (update) the 
encounter's "started" to carry the value of when the importer last ran... the 
previous values would still be preserved in the audit tables.

??

-- Jim