Re: [Gnumed-devel] Results tracking (was: gnumed ideas 0.1 and post-0.1)

[J Busser]

At 8:37 PM +0100 2/23/05, Karsten Hilbert wrote:
>  > >Karsten, you have seen this post of Ian's, but are maybe thinking about
> >  >it before replying?
> >  Probably thinking, what, not *this* again!
> Short answer: No I am not. I am rather thinking about how and
> when to accommodate your needs.

How:

reply to Ian's idea so we can talk it through
(unless you are wanting to first figure something out)

The test_result schema is already well-built, thanks to you, and 
supports a level of generalization that comes only slowly and 
painfully (I think) to some non-doctor coders. Some non-doctors that 
I know who built a lab interface for an open source emr built their 
schema to exactly accommodate a single lab data provider. They 
asserted that when a second lab data provider comes online, an import 
table should be built exactly around *those* data. And point-of-care 
tests that a doctor wished to enter, and results received on paper 
which doctors might wish to hand-enter, would also go into another 
table. To a doctor, shocking, but to them, it evidently makes sense.

Anyway, I think we are talking keeping everything good about your 
design and simply adding value by being able to aggregate an 
organization and tracking of results that have come in, in one place 
(even though the content of the results, when the data types require 
it, likely has to be split out into different tables).

Do we actually lose anything by shifting to the structure Ian contemplated?


When:

for my anticoagulation clinic pilot, the existing schema would permit 
90% of the results to be supported. However the other 10% of the data 
*are* available to the clinic as blobs so it would be nice to get 
this figured out for me, and for AU where it sounds like it reflects 
MUCH of the data.