Re: [Gnumed-devel] GNUmed HL7 import - documents

[Karsten Hilbert]

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