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

[Luke Kenneth Casson Leighton]

On Sun, Aug 15, 2010 at 6:05 AM, Karsten Hilbert
<address@hidden> wrote:
>>  i'd go with that.  that just leaves ORC+OBR which goes into
>> clin.lab_request to be merged.
>>
>>  i'm inclined to believe it's obr.results_rptstatus_chng_datetime
>> (which goes into clin.lab_request.results_reported_when).
>>
>>  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'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?
>
> See how this encounter abuse is getting really ugly really quickly ?
>
> This HAS to go.

 ok, then that's fine - a modification to the database is required,
either adding a table linking lab_request to test_result (it's not
many-to-many it's one-to-many so this is excessive but if you decide
to do it i'll go with it) or adding fk_lab_request to test_result
(which is one-to-many and more like what's actual reality).

 remember karsten that OBXs *do not* have *any* information which
allows them to be cross-referenced to anything: they exist solely
under their OBR-ORC.  there are no fields in an OBX line telling you
what they refer to.  the information is contained in their parent
OBR-ORC record.

 l.