gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Results tracking (was: gnumed ideas 0.1 and post-0.1)
Date: Sat, 5 Mar 2005 19:10:59 +0100
User-agent: Mutt/1.3.22.1i

> 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.
Well, it all depends on what stage of it you look at.
Certainly a case can be made for setting up per-lab
import/staging tables to be used for getting data into the
database. However, from there data really *should* be massaged
into a generalized format.

> 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 
Yes.

> Do we actually lose anything by shifting to the structure Ian contemplated?
We lose doability since test_result and blobs are in
different gnumed services (and therefor likely databases).

> 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.
Let me tell you a little secret here: *Some* german lab data
is nothing but the above. It surely is shipped in the glorified
per-result LDT format but eventually it contains free-text in
the line corresponding to test_result.val_alpha. Very rarely
is that more than, say, half a page of text but still.

A lab results viewer for the anticoag clinic might work like that:

- check patient result type
- if val_num compile ASCII file displaying a table of results
- if val_alpha use that as ASCII file
- if both compile both into one ASCII file
- display ASCII file in simple scroller (not grid)

That would about cover it, no ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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