[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: What Can I Actually DO With Gnumed Today?
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] Re: What Can I Actually DO With Gnumed Today? |
Date: |
Sat, 05 Feb 2005 10:46:49 +1100 |
User-agent: |
Mozilla Thunderbird 0.8 (X11/20041012) |
J Busser wrote:
Maybe I asked the question clumsily. Does the current python code truly
lack patient creation and information editing? So for now the only way
to get patient information into the database is to bootstrap it?
It's there, but the demographics screen was re-designed so needs to be
re-connected
to the backend. This is next on my list, it's just a lack of time issue.
establish connection to lab to fetch lab data
fetch data (LOINC)
LOINC is a coding system, not a pathology data format. We need the full
specification
for this format (if anything like Australia, this is extraordinarily hard to
get)
> import data into staging table
I suspect you are going to have a similar problem to us in Australia, in that
you
can't guarantee all the path. results match easily to patients in the database
(for example, you have a patient "Joseph Smith", but he gave this name as "Joe
Smith"
to the path. company.
This means we need a separate table for "unmatched results" which a user then
has to go through
later. The alternative is to demand all path. result imports are manually
supervised, however this is overkill
as ~97% of all results can be matched automatically with an appropriate "fuzzy
logic" algorithm,
(I know both Tim Churches and Horst have done work on this)
While I'm on the topic, I'd like to pose the question: want do we do with
reports which are large free text reports
(histology, haematology slide reports, etc.)[1]
Should they go in lab_result.val_alpha, or in the "documents" server?
If it goes in documents, we lose all the "tracking" columns such as
fk_reviewer, test_org, etc., which we still need
(I have asked karsten about this previously, but all changes to med_doc were
rejected)
I would like to see a system where document/result tracking (reviewers, origin,
etc.) is separate from storage
(either document blob or a decomposed numeric values in lab_result)
Ian
[1] in Australia all path. results are in this category.
signature.asc
Description: OpenPGP digital signature