[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the G
From: |
Jim Busser |
Subject: |
Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message |
Date: |
Fri, 13 Aug 2010 14:11:51 -0700 |
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
- Re: [Gnumed-devel] Re: Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, (continued)
- Re: [Gnumed-devel] Re: Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Sebastian Hilbert, 2010/08/11
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, lkcl, 2010/08/11
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Sebastian Hilbert, 2010/08/11
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Jim Busser, 2010/08/11
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Luke Kenneth Casson Leighton, 2010/08/11
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Jim Busser, 2010/08/12
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Luke Kenneth Casson Leighton, 2010/08/13
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message,
Jim Busser <=
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Luke Kenneth Casson Leighton, 2010/08/13
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Luke Kenneth Casson Leighton, 2010/08/13
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Jim Busser, 2010/08/13
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Elizabeth Dodd, 2010/08/14
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Jim Busser, 2010/08/14
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Karsten Hilbert, 2010/08/15
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Elizabeth Dodd, 2010/08/15
- [Gnumed-devel] Show a marker when there is another patient with "same or similar" name, Jim Busser, 2010/08/15
- Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message, Luke Kenneth Casson Leighton, 2010/08/14