> > > 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 thereof. > I am actually talking about *transmissions*, I know.
> which are a "natural" grouping provided by the path. lab, if you like. They are not if you go by what a transmission may contain over here. Suppose you ordered a bunch of tests which could be assembled into two "natural" groups. Assuming some are completed earlier than others and preliminary transmission occurs inbetween we have no guarantee (spelling ?!?) whatsoever that those that are transmitted are forming a natural group. > > > This implies *two* tables, one for tracking results (and a blobs field), > > > and > > Which might eventually show that *all* clinical content should > yes. > > have such tracking. Which just might result in it being folded > > into clin_root_item at some point ... > hmm, I'm not sure. Notice the "just might". I am not at all convinced it should. > If a path. result is entered out-of-hours by a cron > daemon or e-mail listener, what episode and encounter does it have? True enough. However, it could create an encounter - perfectly valid as long as one doesn't think an encounter requires personal interaction. As for episode it might link to an episode "unreviewed inbox" forcing the reviewer to attach results to a health problem (that is, an episode). Which appears to make sense. > (remember in AU we can't link back to the request) I tend to forget that at times. > > I am fine with assuming everything to be ASCII. I do see how > > HTML might come into play (eg generated from PIT). > Should be converted to ASCII IMHO. Fine by me. Just trying to offer flexibility. Note that I don't try to shoot down your improving of how all this works. I think you are pretty much correct. I just try to non-destructively re-schedule it's endeavour. 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
