Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010

[Luke Kenneth Casson Leighton]

On Sat, Aug 14, 2010 at 12:30 AM, Jim Busser <address@hidden> wrote:
> It is only request_id (not lab_request_id) that is non-NULL, unique so we 
> just need a way to supply a unique value maybe
>
>        CONCATENATE ("gm-", NUM_TO_TEXT (pk_item))
>
>        ... or "gm-" could instead be some configurable per-praxis value.


 ok - i'll go through it again: if CONCATENATE ("gm-", NUM_TO_TEXT
(pk_item)) is to go into clin.lab_request.request_id, what do you do
when you get an observational report from the lab?  overwrite
clin.lab_request.request_id with OBR003??

 at the moment, it is my understanding that:

* OBR003 goes into clin.lab_request.request_id
* OBR004 (if given back) goes into clin.lab_request.lab_request_id but
this will be "in future" and is normally NULL.

but, in the "generate request from gnumed" case, you want CONCATENATE
("gm-", NUM_TO_TEXT (pk_item)) to go into clin.lab_request.request_id,
such that it will come back in OBR004 and thus end up in
clin.lab_request.lab_request_id??

 that doesn't make any sense.

 you see what i'm saying?  lab_request_id and request_id are being
treated the wrong way round.  request_id receives info that's
gnumed-generated side; that leaves lab_request_id as the only place to
receive info that's generated lab-side.

 surely, in the case where the incoming lab report is "unsolicited":

 * OBR003 should go into clin.lab_request.lab_request_id
 * OBR004 (if given back) should go into clin.lab_request.request_id
but if not supplied THEN you fill it in with CONCATENATE ("gm-",
NUM_TO_TEXT (pk_item))

but if it is solicited (i.e. the request was initiated by gnumed,
including a barcode)

 * either barcode (if supplied) or CONCATENATE ("gm-", NUM_TO_TEXT
(pk_item) goes into clin.lab_request.request_id
 * request is sent to lab (providing contents of
clin.lab_request.request_id as identifying info)
 * response is received (containing observational report)
 * OBR004 should be matched against clin.lab_request.request_id as the
first priority
 * OBR003 should go into that record's clin.lab_request.lab_request_id

if the lab fails to provide an OBR004 field, then we're a leeetle bit
stuffed: i'd recommend auto-create a lab request and then sort the
mess out after.

this would involve performing "merging" to match up the
gnumed-initiated lab_request record (which contains the barcode in
request_id) with the auto-import-created one, deleting the
auto-created lab_request after moving its clin.test_results over to
the one with the barcode, then updating the original with the
lab_request_id [and other required lab_request fields].

> From my understanding, the bar code (below) is determined from what is 
> available from among what German labs uniquely supply, and so we just need to 
> check with Karsten that it makes sense that this bar code should simply go 
> into lab_request_id. Notice that Karsten may have been working ahead of 
> available clarifications and use cases, since HL7 is not even yet used in 
> German test results.
>
> In an environment where multiple labs exist, and where each is able to 
> generate their own reference ID, then we cannot expect lab_request_id 
> (externally-assigned) is always going to be unique and therefore we cannot 
> require the constraint
>
>        unique(fk_patient, lab_request_id)
>
> in spite of it having been envisioned below

 ok ... then unique(fk_patient, fk_test_org, lab_request_id) can?

 there really is something wrong if the intent is to use
clin.lab_request to initiate outgoing lab_requests from inside gnumed.

 perhaps it would be better to have a clin.lab_request table for
outgoing gnumed-initiated lab requests, and a clin.lab_response table
for incoming observational reports.

 then it would be up to the praxis administrator to match up the two,
in the event where gnumed was unable to make the match / link
automatically.

 l.