gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Busser, Jim
Subject: Re: [Gnumed-devel] GNUmed HL7 import - documents
Date: Thu, 22 Jan 2015 04:05:44 +0000

On 2014-08-13, at 6:24 AM, Karsten Hilbert <address@hidden> wrote:

> On Wed, Aug 13, 2014 at 03:04:01AM +0000, Jim Busser wrote:
> 
>> But one of my limitations to be throwing HL7 at it (even
>> just locally) is that my data broker will not provide
>> anything more than a few tests cases until the requesting
>> clinicians can provide screenshots of the test data which
>> they had supplied, imported within the EMR.
> 
> Here is one example (re-associated from "A Adult A" to Kirk,
> however).
> 
> This leaves much to be desired as far as the display of
> complex textual results go (for which a compound,
> report-style presentation as per Richard will be more
> suitable) but it DOES allow for unambigous identification of
> data (and so is the minimum necessary functionality).
> 
> Note a) the "Grouping" which ties together related entries
> and b) the OBX raw data being stored with the result for
> somewhat easier access to missing details.

How do we handle the case where it ends up being a document that gets imported 
via HL7 import?

I am expecting that the nature of the file 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.

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).

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.

??

-- Jim


reply via email to

[Prev in Thread] Current Thread [Next in Thread]