[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: Wed, 11 Aug 2010 16:29:29 -0700

On 2010-08-11, at 12:51 PM, Sebastian Hilbert wrote:

>> data was updated instead (because
>> i'd already added it once).

It is possible that a result which had already been looked at, and which had 
already been "signed off", becomes updated and really "on update" will need 

This makes sense when the update actually brings new (i.e. a change of) 
information however updating with identical data does little more than to 
update the datetime stamp, yet we would have created the need for such (rather 
uselessly updated) results to again be signed.

I am thinking that the field

        OBX 014 Date-Time of Observation (Test resulted by laboratory timestamp)

could be compared between the so-called new result, and the already-imported 
result, because of there had in fact been some correction to a result than the 
original value must surely have been incremented. Presently, no column exists 
for this in clin.test_result

While a related column exists in clin.lab_request


and while this is informed by

        OBR 022 Report Status Change (Report status change timestamp)

the above is metadata for the battery of tests, it is not granular and so in


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)

-- Jim

reply via email to

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