Re: [Gnumed-devel] More lab test result considerations: groupings

[James Busser]

On 15-Feb-08, at 3:14 AM, Karsten Hilbert wrote:

> None of this touches on lab_request which, again, isn't really needed
> so far -- we apparently don't *have* to equate lab_request with  
> test_panel.
> Which eventually seems better to me because lab_request really should
> be a GNUmed-side thing.
>
> It may mean we need to move the test status into test_result...

Moving test status into test_result won't be any benefit with HL7 lab  
result messages.

When a test_panel has one or more components pending, the message  
sends no OBX (result) segments for these components, only for those  
components for which a result is *available*. OBX results will be  
only be able to be imported (created) after they are received as  
"final". Any that would later be updated to status "Corrected" would  
be reflected in the audit.

Populating test_results in advance of them being retrieved (say, by  
inferring from previously-received test_panels) can make the unsafe  
assumption that the lab will not redefine its panel components.

I am a bit worried...

> lab_request really should be a GNUmed-side thing.


Did we take a step back here? I think the above is too narrow, otherwise
- for those workflows where no request_id is available (like, outside  
Germany), the possibility for retrieved lab data to auto-populate our  
own request is lost
- knowledge of pending test results would then be split partly in  
lab_requests and partly elsewhere... I am not sure we want to have to  
look in too many places for both the pending and resulted values
- we will still have the problem of pendings without any OBX

I agree that we don't have to *relate* (key) lab_requests to  
test_panel. But  I am strongly convinced that remains value to auto- 
create a lab_request row when the importer could find no original  
request already created inside GNUmed (thus benefiting from the lab  
essentially entering for us, when we *were* the doctors who ordered  
the tests, what we cannot in Canada easily input), and to be able to  
keep, in this request, one text field into which to simply store the  
test codes and test status until the results go into test_result.