[Gnumed-devel] Re: Fwd: results handling

[Karsten Hilbert]

Hi Tim,

I have CC'ed the list...

> ok sorry i was talking much broader terms. i needed to ask otherwise i'd 
> be digging through every file trying to figure out which one related to 
> pathology/results.
Sure, tables are mostly in gmMeasurements.sql. Some more
general tables related to that (eg. results being clinical
entities) are in gmclinical.sql (eg clin_root_item,
clin_episode, clin_encounter, clin_health_issue).

> in the most broad sense does gnumed have a plan on just how we are going 
> to import results? a basic schema?
Pretty much as you suggested. Most data will be coming in as
files, be that from a floppy disc, modem transfer, email, ftp,
saved incoming hl7 stream, you-name-it. Handling will be done
in several steps: Getting the files to the local disk will be
done by software independant of GnuMed proper, say, the
proprietary download apps you mentioned as being distributed
by the labs. Same goes for eventual decompression/decryption.
All this should be handled as much as possible without user
interaction or else have a separate, standalone GUI.
Decompressed, decrypted ready-for-import files aggregate in an
"incoming-results" repository (say /var/spool/gnumed/lab/ where
they are picked up by standalone importers running from cron,
say, twice daily or hourly or something. Those importers
should also be runnable manually from within the GnuMed client
for when the user says: I want to import *that* file now.
Importers will have to understand the import format on the one
hand (PIT, HL7, xDT, ...) and how to map that to the GnuMed
tables OTOH. For that they should use the business objects in
client/business/. Tables are considered to be fairly generic for
storing "test results" (any type, also BP, height, weight,
etc). I am currently working on an importer for the LDT format
(the German PIT equivalent).

> but will i need to design 
> furhter tables or is that already mapped out
Hopefully not. We'll have to work our way towards being more
generic if need be.

>, and if so is any of the 
> coding/design for the business layer done which handles importing to the 
> gnumed database?
Only the "latent" API as found in, eg
client/business/gmClinicalRecord.py

> the way i see results coming in ( excuse me if my terminology is off i 
> am stuck in the habit of what i use at work ) is in the form of files 
> formatted to whatever the standard is for the users region.
Surely so.

> eg. for aus I will make a plug in which handles PIT.
It needn't be a plugin *for the GUI*, see above.


> the import engine will first 
> look at what providers are setup in the system.these clinical providers 
> will most likely ( this is how it works in oz ) export a certain file 
> type to the practises system. the import engine will know by these file 
> types which files to open in said directory. then by looking at the file 
> ( this will be the tricky part ) it will determine which plugin to use 
> to import the result into gnumed's holding database.
We can ease that part simply by making assumptions about what
type of file is going to appear where:

/var/spool/gnumed/incoming/PIT/
/var/spool/gnumed/incoming/LDT/
.../HL7/

On import the code should allow liberal file structures
(unless strictness mandated by law) and only verify those
things that are clinically relevant (eg. consistency, result
provider known-ness, etc). Working with Jon Postel's saying
here that emitters should be strict with the protocol while
receivers should be liberal in what they accept.

> this holding database will be viewed by either the doctors or medical 
> receptionist, in my experience it's the medical receptionist which 
> handles this, and they will be given the option to view the result 
> and/or place the result into the patients profile. this will help 
> prevent incorrect results going into the wrong patient file by forcing a 
> human check on name dob etc.
That may well be slightly different. Here in DE we label all
probes with (usually) a barcode sticker label. That number is
returned attached to the results (hence no name cross-checking
is possible). We then auto-import based on that lab request
ID (oh, we associated the patient with that ID before
importing). The ID changes every time we send off a probe.
It's not a constant association between patient and sample ID.

We currently support a reviewed and reviewed_by field on test
results as well as a technically_abnormal and a
clinically_relevant field. Those should be checked as
appropriate by the reviewing clinician (eg,
technically_abnormal is transmitted by our labs, reviewed is
set by the GUI after the very act of reviewing and reviewed_by
is set to the currently connected clinical staff, hence only
clinically_relevant needs to be set by the reviewer. defaults
are true for technically_abnormal and false for
not-technically_abnormal tests).

> Ok, for now i am only concerned with the import engine, the rest isn't 
> business layer stuff. but am i close to what you had in mind?
Seems fairly much so. I'd decouple from the standard client as
much as reasonable (but not more).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346