Re: [Gnumed-devel] How to display your results

[Jim Busser]

On 2011-07-07, at 2:46 AM, Karsten Hilbert wrote:

> On Wed, Jul 06, 2011 at 05:23:39PM -0700, Jim Busser wrote:
> 
>> … of course, as soon as you would entertain to create one or more documents 
>> by way of an automated (batch) importer, the table would inherit some 
>> properties in common with the test_ result table which can include the need 
>> to support a
>> 
>>      .lab_request_id
> 
> It already does:
> 
>       blobs.doc_med.ext_ref
> 
>> so that the 'state' of the request, or consultation, or received result 
>> (which might include a later retraction or correction) could be able to be 
>> tracked.
>> 
>> Maybe the table
>> 
>>      .lab_request
>> 
>> should be considered to serve a more general purpose than to track *just* 
>> lab requests and (even unrequested copy-to) returns.
> 
> Yep, this should eventually be folded into a generic
> 
>       clin.request
> 
> table, wherein lab requests are but one type, indeed.
> 
> Karsten

Can we tidy these up in v16? Renaming

        clin.lab_request
        --> clin.request

        clin.request.lab_request_id
        --> clin.request.request_id

Can we also make consistent the naming among

        clin.request.request_id

        blobs.doc_med.ext_ref

because, as I understand it, "request_id" was conceived to be able to hold such 
entities as the barcode on the German lab-supplied labels which are to be 
affixed to probes. So it would be reasonable to consider the "request_id" to be 
able to hold something that is to some extent externally-determined, despite 
that it might get manually-entered in GNUmed?

So

        clin.request.request_id

could in v16 be

        clin.request.ext_ref

??

-- Jim