gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Challenges in lab test aggregation - panels


From: Busser, Jim
Subject: Re: [Gnumed-devel] Challenges in lab test aggregation - panels
Date: Sun, 8 Sep 2013 16:32:01 +0000

On 2013-09-05, at 12:20 PM, Karsten Hilbert <address@hidden> wrote:

>> 2) when creating a panel or profile, will we be able to input
>> 
>>      meta_test_types
> 
> Not ATM.
> 
>> or will the individual test_types each have to be
>> discretely defined and will this result in discrete rows
>> that do not take advantage of the aggregation?
> 
> For the time being, yes.

IOW even if a user would through the backend define a

        meta_test_type

linked to several tests which are meant to communicate the same thing, then 
GNUmed 1.4x will have no ability to use the information through the GUI?

Meaning that if my patients' creatinine levels are measured, at different 
times, by

        a branch of Lifelabs
        a branch of BC Biomedical
        a BC Cancer Agency lab
        one of 5 local hospitals

then currently GNUmed cannot show these in one row, and can only show them in 8 
separate rows?

If the above is correct, then it makes a good case IMO to target (for GNUmed 
1.5x) to be able to display meta test types.

Doing so does make me wonder how this could be handled …

IOW what will happen when a user clicks the Measurements plugin. It seems to me 
that the user would want to see a listing of clinically meaningful 
measurements. This would mean that if all measurements of serum creatinine 
meaning the same thing had been aggregated under a meta_type, then these 
various creatinines should be expressed in a single row without being 
re-expressed in additional rows. The same is true for all measurements of 
hemoglobin (from different labs) also meaning the same thing. And so on.

But what about the tests which had *not* been aggregated under a test type? Do 
these each need to be created as their own meta-type of which they would all be 
meta_types involving a single test_type? Or is it feasible for a view to 
display some union of meta_type tests with those other tests which are not 
found under meta_types?

-- Jim





reply via email to

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