Re: [Gnumed-devel] Hakuna Matata Plugin (2nd reply)

[Karsten Hilbert]

On Mon, Sep 17, 2007 at 02:02:31AM -0300, TheForkOfJustice wrote:

> >> 3) The Lab Section - GUI Submitted (Base, Urinalysis sections so far)
> >>
> >>     Takes the requested tests and patient info entered in the registration
> >> part and save the values requested.
> >
> >In other words, lab techs enter values here which will later
> >be sent to physicians.
> 
> Bingo! The lab section is very simple and this should be a good opportunity
> to figure out how the database will look like.
I am not sure about simple but it is certainly fairly well
defined and feels like a fairly enclosed part. It's a good
starting point, I guess.

> >> The Lab Section needs its own Patient Search area because giving a lab
> tech
> >> access to all of GNUMed's functions can be harmful because:
> >Giving lab techs access to the standard GNUmed patient
> >search doesn't at all mean they have access to all
> >functions. Simply don't load the plugins you don't want them
> >to see (such as the patient EMR). OTOH, we cannot know which
> >data a lab physician may need to properly interpret certain
> >lab values.
> 
> I'll have to learn more about GNUMed and it's plugins later.  For some
> reason the
> GNUMed in the Ubuntu Gutsy repos didn't run when I installed it, even after
> rebooting.
They are not keeping up with our releases. It may make sense
to file a bug report with them to show they do have "users"
for whom to upgrade it may make sense.

> I'm also hoping that the Lab section can load itself as an alternative
> frontend for GNUMed for speed and simplicity.
Sure, this sounds doable.

> As a backup, I'll also have to figure out about selectively loading plugins
> depending on the user/group.
What one does is to define a workplace by name (in the
backend), configure which plugins to load for that workplace
(again, in the backend), and then start GNUmed using that
workplace (by setting it in the config file).

> >We already audit which user ID entered data as well as
> >changes. If you want to add logging of which ID logged in
> >and when, well, that's easy enough to do. Unfortunately, it
> >is impossible at the database level per se (apart from the
> >fact that PostgreSQL itself *already* logs logins in its log
> >files).
> 
> A plugin could be made that organizes the database log into a logfile useful
> for easy QC purposes.
The audit information is easily available right from the
GNUmed database (gnumed_v7, currently). The logfile
information isn't so easily accessible as it may contain
sensitive data not intended for the user in question. Also,
it's a text file on the server, so needs means other than
SQL for being accessed. But it is surely available for
scrutiny. If I were to implement auditing of who logged in
when I'd setup something like snort or logwatch etc to
monitor and mail out selective log file reports to an admin
user.

> >> 1) Physician Section - Order tests for the patient (I'm not certain how the
> >> test request will find it's lab
> >In Germany by paper form which are scanned in the lab. We
> >also do have a electronic format for it but hardly anyone
> >uses that.
> 
> Perhaps you should include an option to print out the test requests to
> paper. They can have it both ways: electronic copy that is syncable to the 
> database and
> a PDF (signed to prevent forgery?) that is printable.
That is how the system works in Germany. As GNUmed (from my
side of things is concerned with the physician part I'll be
interested in importing/displaying lab values first.

> A database template will need to be constructed with the appropriate
> fields.
I believe you are talking about a data transport format for
lab data. Several such exist, more or less well-defined.
Look up hl7 and LDT, at least. The latter is particularly
well-defined -- but specs are available in German only.

> That just makes sense, especially when you consider that some places don't
> have reliable internet service and can't afford to get them fron the
> repositories.
> We're trying to bring Linux to the world so we have to be mindful of such
> things.
If that's a priority for you you'll have to put lab data
into a text format, encrypt that and email it to users.

> I was thinking of generating a seperate database per patient via a template
> and then sent to the lab to be filled out
> and merged with the doctor's database.
Well, yeah, or just have the lab software generate a file
according to the data format specs

> I would suggest a workflow like this:
> 
> 1) Doctor sends out the empty database with the fields requiring completion
> (as well as relevant patient identification information)
> 2) The database is automatically signed by GNUMed with the doctor's key.
Yes.

> 3) The lab's clerical department receives and decodes the database (a shared
> key exists
> between doctor and lab)
No. They don't share a key. They use public-key asymmetric
cryptography. Think GnuPG.

> 4) The database is queued for completion in the lab when the patient/sample
> arrives.
> 4) The lab fills out the database's blank fields.
> 5) The finished database is re-encrypted and sent back to the doctor (over
> ssh more than
> likely) but the lab retains a copy.
> 6) The database is decoded and imported into the doctor's main database.
> 
> Easier said than done, I know, but I think something like this is probably
> the best way
> to go about it.
That is certainly the way. We do it like that (no
encryption, though) all day long here in Germany.

> The only scanners I've seen in use are built into the lab equipment itself.
> I've never seen and anyone use a handheld.
> Are there handheld drivers available for linux?
Yes.

> I planned to get your input before doing such a thing.  I think I got a good
> idea of how it's going to work from our conversation here so I'll type out a
> detailed plan soon and send it to you in an email.
> 
> Hopefully, we will go live in October without a hitch and all of this will
> be viewable on our webpage.

Sounds good.

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