> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
