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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.