Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message

[Jim Busser]

On 2010-08-13, at 1:30 PM, Luke Kenneth Casson Leighton wrote:

> the only thing that leaves me "uncomfortable" is the fact that the
> encounters themselves are obviously going to have to be merged, too.
> perhaps... perhaps it is enough that the clin.lab_request data and
> clin.test_result is going to be moved away from one of them, and
> merged into the other.

I don't think they *have* to be merged but agree that within any one import 
"run", there is no need (within each patient) to have a distinct encounter for 
each individual test result imported within the "run". To my view, multiple 
encounters per-patient of type

        automated data import

should be merged or (if manageable) not even created.


> i'm inclined to say that the priority is first by encounter_type -
> i.e. if it's "lab import data" then it's the lowest priority; if both
> encounters are "lab import data" or if both encounters are _not_ "lab
> import data", then the oldest of the two should be selected ...
> probably by clin.encounter.started?

I would also challenge the auto-attachment of daemon-imported test results to 
other than

        automated data import

because despite that some other human-interactive encounter (doctor visit) 
could have been recently created, we are making assumptions here whether the 
results even:

1) relate semantically to the most recent encounter
2) relate operationally (workflow wise) to the most recent encounter

It would be different if, within an encounter (visit) I *manually create* 
measurement entries such as a blood pressure reading or a result which had been 
received only on paper (requiring the so called human importer). Such entries 
are human-actioned within the relevant encounter.

But it is different for what had been imported by a daemon. 

Say I saw you for high blood pressure, and I decided with you our plan, without 
the knowledge of related results.

Say these were imported during the visit, or afterward) but I did not even look 
at them until after you had left. (If I had, I could easily associate to this 
encounter a multiple selection of the results actually reviewed with you).

Let us suppose the results would cause me to change our plan. but that you had 
already left. Say I needed to phone you after-the-fact. I might easily rather 
make a new encounter of type "voice call to patient".

Alternatively, I might decide to not deal with them until the *next* encounter.

Accordingly, I think any results that are imported by script ought to be linked 
to a single in-common (or optionally different) encounter type that is distinct 
from human-interactive encounters. Re-categorization (re-association) is to my 
view too prone to mal-prediction. 

-- Jim