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

[Luke Kenneth Casson Leighton]

On Fri, Aug 13, 2010 at 10:52 PM, Jim Busser <address@hidden> wrote:
> On 2010-08-13, at 2:37 PM, Luke Kenneth Casson Leighton wrote:
>
>> uhn?  err... ah.  rrright.  then what's clin.lab_request_id for??
>>
>> hmmm, i think i might have this the wrong way round, perhaps.  or,
>> somebody has.
>
> I lost sight there GNUmed has two distinct fields in that table, supporting 
> two different values as you pointed out.

> request_id can be purely "owned" by GNUmed and returned by whichever path 
> labs will handle it.

 in which field? ORC002 or ORC004?

> lab_request_id is perhaps what is on the German labels and perhaps allows the 
> clinician at the point of blood/urine-taking to know what the path lab's 
> "internal id" is going to be. This maybe achieves to gain the exact same 
> value (if Germany would adopt HL7) in ORC 002.
>
> Way to go, Germany!

  ok, then the wiki page needs updating with the correct logic, taking
into account that lab_request.lab_request_id is the "first priority"
to check (being gnumed-generated and ending up in ORC002 or is it
ORC004?  need to know!  i know you say ORC 002)  but then the "second
line of defense" is to check ORC003 - against
clin.lab_request.request_id.

 if the entry already exists (with the right lab_request_id) then its
request_id field gets updated/overwritten... whoops can't have even
_created_ the lab_request because it has a non-NULL field and has a
unique key constraint on it.

so we're screwed.

 i believe that the names / purposes of
clin.lab_request.lab_request_id and clin.lab_request.request_id are
the wrong way round.  or, more to the point: see gmMeasurements.sql

create table clin.lab_request (
    unique (fk_test_org, request_id)
    -- FIXME: there really ought to be a constraint like this:
--  unique (fk_patient, request_id)

* request_id should be what the barcode goes into.  if there isn't a
barcode, a unique number less than 20 digits needs to be created.
* ORC 003 should be going into lab_request_id.
* unique(fk_test_org, request_id) is wrong
* unique(fk_patient, request_id) is right
* unique(fk_patient, lab_request_id) is right *IF* lab_request_id is
not-NULL.  i assume postgres can do conditional constraints like this?
 if lab_request_id not NULL, check it's unique?

l.