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

[Jim Busser]

On 2010-08-29, at 12:42 PM, Karsten Hilbert wrote:

> On Wed, Aug 11, 2010 at 04:29:29PM -0700, Jim Busser wrote:
> 
>> 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)
> 
> This would be clin.test_result.clin_when, as per the column comment.
> 
>>      report_result_updated (or reported_or_corrected) ?
> 
> .clin_when already exists.

Oooooh... I am not happy that a table of clinical measurements should use its 
clin_when to store a potentially very delayed timestamp (days to even weeks) 
for when the measurement was achieved and resulted by the lab. At *that* time, 
the biological values in the patient could have since changed tremendously.

Using such values for .clin_when risk to greatly distort any time trend 
analysis (graphical or numeric) generated for a patient, for example, if the 
lab would correct an earlier value and send along this result *after* the 
praxis had already received the result of a specimen which had been sampled 
later.

It would also confuse and risk wrong decisions based on sequential exposures 
e.g. did abnormality X precede or follow Drug Y, and by what interval?

Lastly, while the GNUmed supports the backend and maybe even frontend creation 
of "lab requests", it does not cleanly cover the situation where measurements 
are received despite the request not having been initiated from GNUmed. 

For these reasons, the clin_when that exists in test_results should reflect the 
point in time that the measurement is supposed to be indicative of the value in 
the patient. Quality labs take pains to ensure that the measurements that they 
generate (even after a delay) are supposed to accurately reflect what they 
*would have been* in the patient at the time of collection. This has no 
reliable value in predicting what the value would (still) be at the time that 
the lab generated the result.

That is why clin_when should be preserved to reflect the specimen timestamp, 
and why I argue we need a separate field .report_when in test_results

-- Jim