James Busser wrote: > > > I confess I lost sight of whether some incoming data --- reports that > might have been sent through secure messaging rather than faxed --- > will be going into some other storage area that better lent itself to > searching... will it be going into a different storage area in the > schema? >
That's a good question. PostgreSQL can do text-searching well, but we would waste a lot of time searching through big radiology JPEGs that will never have the text we want. Syan Tan wrote: > the prelim au importer in client/importers/au can now also import text based > PIT format pathology, radiology and discharge summaries into gnumed > blobs.doc_med , under the respective types "referral report pathology", > "referral report radiology" and "discharge summary other". I had thought clin.result.val_alpha was the proper place for PIT-type results. (i.e. a single unparseable blob of plain ASCII text) No, wait, we've got doc_obj.fk_intended_reviewer now, cool. This means clin.result and friends will be empty on AU systems (we simply never get any atomic results data to put in there, and so don't need it's other meta-data) Is blobs.doc_obj.fk_intended_reviewer set to NULL when someone has reviewed the document? (otherwise the query may get slow checking against blobs.reviewed_doc_objs for every new document. IMHO we could use doc_desc for PIT documents (which was originally for OCR of scans) so searchable text data and non-text-searchable binary data are separate. This means PIT files would have a doc_med and a doc_desc entry, but no doc_obj. But, there is no doc_desc.fk_intended_reviewer :-( can we have this, or a doc_med.fk_intended_reviewer? (I understand why you many want blobs.reviewed_doc_objs so you can track reviewers of individual pages, but surely you would not direct different pages of one logical document to different reviewers?) Ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
