[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gnumed-devel] GNUmed HL7 import - documents,
Busser, Jim <=