> >Ian, do you think it an acceptable solution for now to add a > >flag is_blob (or similar) to test_result > IMHO display can be inferred by length. Fine by me. I was just attempting to make some "concessions" to "lure you into the trap" ;-)
> If it is a few chars, it can > be displayed in Sebastian's grid-based viewer (I'm assuming this > was this original purpose.), if longer we need something else. Sounds OK. > The bigger issue with test_result is that it is poorly normalised. You mean over-normalized ? > So in an FBE, I can track the Hb, you can track the MCV, someone else can be > responsible for the WCC, and so on, which (to me) doesn't make any sense. I see your point but I wonder whether that level of business logic should really be enforced at the database level ? Our widget allows for signing off groups, btw. > My idea is for split viewer, with a listbox at the top listing the > transmissions. > (so FBE such a date, U&E the next, and so on), when you click, it is shown: > either a textbox for blobs, or the grid view for granular numeric results. Well, this is what we would do with "profiles" - groupings of related tests selectable to be shown together. Liz is working on the clinical side therof. > This implies *two* tables, one for tracking results (and a blobs field), and > one for granular numbers. I should rather think the clean solution would be to completely factor out status tracking from either of the two. Which might eventually show that *all* clinical content should have such tracking. Which just might result in it being folded into clin_root_item at some point ... > Maybe. AFAIK the only formats in use are ASCII (HL7 allows some basic > markup) and Word (which I would just pipe through "antiword" to return > plain ASCII anyway) I am fine with assuming everything to be ASCII. I do see how HTML might come into play (eg generated from PIT). 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
