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.
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
