Ok.Syan, if you're going to write a parser, please a) use python and b) talk to us about how it's going to be stored in the backend
(as has been discussed ad nausem, we still don't have a clean way of
doing this)
I would strongly suggest to put "blob style" lab results into test_result.val_alpha *for now*. This allows for a) status tracking and b) later rearrange blobs and test results as we see fit.
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. 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.
The bigger issue with test_result is that it is poorly normalised. 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.
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. This implies *two* tables, one for tracking results (and a blobs field), and one for granular numbers.
field ? Or even a field val_alpha_format ? Which could be ASCII, HTML, etc.
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)
Ian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
