[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

From: Luke Kenneth Casson Leighton
Subject: Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message
Date: Thu, 12 Aug 2010 01:04:48 +0100

On Thu, Aug 12, 2010 at 12:29 AM, Jim Busser <address@hidden> wrote:

> I would argue for 2 new columns:
>        report_result_updated (or reported_or_corrected) ?
>        fk_lab_request (to preserve the OBR-OBX hierarchy in case of corrected 
> or otherwise-modified results)

 yes.  the updated one is also essential should a merge (of fake
patient with real patient) occur: in circumstances where the original
report goes under real patient clin.lab_request + clin.test_result and
for some silly reason the update goes into a fake-patient with a
separate clin.lab_request + clin.test_result, you now need to match up
the two sets of hierarchical data, and decide which matching entries
are going to take precedence.

this kind of merging is something that i imagine would be needed,
anyway?  or, is the fact that it's a separate encounter sufficient to
go "nope - no way, ain't gonna merge _that_"?  because if that's the
case, there's a problem: you now have patient clinical data results
and lab reports which should be merged but aren't; a doctor could then
accidentally look at "old" data, not realising it's been superseded
(because the update is in a different encounter)

could this situation occur at present; has it been catered for; has it
been thought of; do other importers cope with merging; etc. etc. ?

at least with the (multi-level!) indexing right down to OBX 004 (unit
sub-id) there stands a chance of merging the HL7 data (whew) so
encounters/clin.lab_request/clin.test_data merging can be
contemplated.  and would not be too hard.  just irreversible!

so - yah.  lovely stuff :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]