gnumed-devel
[Top][All Lists]
Advanced

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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