Re: GNUmed HL7 import - documents
Karsten Hilbert <[email protected]>
| Newsgroups | gmane.comp.gnu.medical.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jan 22, 2015 at 04:05:44AM +0000, Jim Busser wrote: > How do we handle the case where it ends up being a document that gets imported via HL7 import? We don't ATM. > I am expecting that the nature of the file There is no "nature of the file" with respect to importing hl7. > or its data format (text or non-text) or a field value in HL7 may > determine whether this "result" gets written into a text > value column or a blob column in clin.test_results. There is no blob column in clin.test_results. GNUmed tries to cast the result to a number. If that fails the result is assumed to be text. > But we expect it may be hard to properly view such > documents from inside the Measurements plug-in, perhaps > especially so if it is a lot of text (as opposed to the blob > which might be able to open up in a suitable viewer). Large amounts of text as a result are much easier to read in the by-day view (which was the second reason I wrote that). Do you have an example of a non-numeric, non-text hl7 result ? > In place of altering the import method, such that > > - some imported data would get written into clin.test_results (as current), while > > - other imported data would instead get written into the blobs. schema > > would it be a better idea to keep the import procedure as > it is, but then -- in a post-processing or on-user-demand > step -- alter the test_results so as to copy the documents > over into blobs, after which to update the test_result row? > > I like the idea of keeping (not deleting) the test_result > row so as to preserve the ability to trace the flow of the > results. But I am also thinking that if the document is > successfully written over into the blobs schema it might be > advisable to remove the document from the test_result blob > column, so as to avoid redundant (duplicated) documentation > showing up in a printout or export that should happen to > include both test_results and documents. This sounds like a good plan for that case. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346