[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Possible problem with schema table Clin.Test_type

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: Possible problem with schema table Clin.Test_type
Date: Thu, 07 Feb 2008 13:21:45 +0100

> > Also, there is a field fk_test_org which is a foreign key to the  
> > primary key which is the organization providing  
> > results. Presently, this too is defined as unique. Maybe the  
> > intention was
> >
> >     (fk_test_org + coding_system + code) UNIQUE
That's right and needs fixing.

> Maybe the purpose was to allow the table
>       clin.test_result
> to hold, in one field
>       fk_type
> a foreign key to a row in Clin.Test_Type that informs *both* the  
> organization (lab) that carried out the test AND the particular test.
Correct. It informs on the test type directly and the lab indirectly.

> If this schema is maintained, it would mean that where GNUmed is  
> being fed by "n" number of different labs, we will:
> - incur n-fold numbers of extra rows in the table Clin.Test_Type  
> (maybe n x 100 tests? I am not sure how many test types one would end  
> up storing)

(no labs) x (requested unique tests per lab)

> - avoid having to have a value for fk_test_org in every row in  
> clin.test_result

> Would this mean that before an importer could import a result, it  
> would have to test whether each instance of a lab's test code (and  
> coding system) already exists in the GNUmed table

> and, if it did not  
> already exist, to create this row in Clin.Test_Type before continuing  
> to import the data

> ... and also that if it was a new lab that was contributing this  
> result, the data could not be imported until after the lab  
> organization had been created in GNUmed?
Correct but can be autocreated in many cases.

> In other words, in addition  
> to the automatching that will need to be done to assure that received  
> data can be correctly attached to a *patient*, there must be  
> automatching done to assure that the lab organization that is  
> providing the result is also matched to an existing value in GNUmed?


Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]