Re: [Gnumed-devel] Hakuna Matata response and update

[Karsten Hilbert]

On Sun, Sep 02, 2007 at 12:21:55PM -0300, TheForkOfJustice wrote:

> I also answered the questions you guys sent to me about Hakuna Matata.
Thanks. Comments inline.

> 1) The Physician Section - GUI NOT ASSEMBLED AS OF SEPTEMBER 2007
> 
>     This portion IS apart of the GNUMed interface and is the first step in
> the process.
> 
>     I need a list of all possible tests before making this part, so I'm
> making the lab component first.

"a list of all possible tests" is an impossible task. This
approach is flawed, IMO. The "Physician Section" in GNUmed
(where a doctor may request certain tests) will be data
driven. Hence it is not going to matter which tests are
known at the time of writing this part.

> 2) The Office Section - GUI NOT ASSEMBLED AS OF SEPTEMBER 2007

>     - confirms patient/specimen arrival
>     - creates job lists and prints out the specimen barcodes
>     - provides fields to enter billing information

>     - sends out completed test results to the requester
This last point should be done by a demon working on a queue
of ready-to-go results and if at all only needs a queue
viewer inside the GNUmed user interface.

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

>     This section MUST be completed first or else we have no idea what
> fields/tests to request in the Physician Section.
Again, I believe this assumption to be flawed. There is no
way to *complete* this. However, it may be that I still
don't fully understand the needs you are addressing.

> The part I sent you is the most basic part of the Lab Section, which is used
> only to report test results and nothing more.
I understand. That's fine.

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

> 1) PATIENT PRIVACY is at risk. Limiting access to patient records prevents
> the leaking of patient info.
Sure, it may be advisable to limit patient access to those
patients which have pending requests.

> 2) SIMPLICITY.  The lab section provides only what lab techs need.
Which can be done by loading the corresponding plugins only.

> 3) A RISK OF BIAS if lab techs use GNUMed to look up the patient's history
> and change test results to better fit their likely illness.
If that's a risk you think you need protection against don't
*give* them GNUmed in the first place. Use a different
database. I am not sure it makes sense, though.

> There is also the benefit of allowing individual lab techs to log in and out
> of the program depending on who is doing the reporting.
Sure. That's what GNUmed already offers.

> This is essential for laboratory quality control so make certain a log of
> who logged in and who inputted what is kept.
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).

> Closing the window should automatically log you out.
It does. Closing the GNUmed client logs you out.

> ================================================================
> 
> > What is Hakuna Matata's workflow?
> 
> 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.

> 2) Office Section - Create job list of today's samples to be tested,
> register patients, prioritize STAT samples, print barcodes
> 3) Lab Section - Complete requested tests and record the results to the
> database
> 4) Office Section - Send out test results, handle billing
> 5) Physician Section - receive test results

OK, I understand. I believe this makes sense.

> > Do you intend to use it as a seperate program?
> 
> No.  Same backend, but the Lab Section should be it's own seperate interface
> and should be able to automatically load and connect to a
> database which has been entered into it's preferences.
Aha, I see. It might be helpful to reuse the middleware, though.

> This Lab Section has a simple purpose: take the values entered into it and
> save them to the patient database for the physician to review.
> I have mentioned that the Lab Section must be seperate from the GNUMed
> interface.  Just make certain that values entered into the
> Lab Section are saved properly into a GNUMed database.
No big deal technically. Does this mean that you assume
wherever Hakuna Matata is used the lab technician entering
values will be writing *directly* into the physicians
database ? What about values which need to be signed-off/
interpreted by a lab doctor/consultant before being handed
out to requesting doctors ?

Usually, in Germany, labs keep their own datastore, then
sign off results, batch them together and send them out. The
EMR at the doctors office is then responsible for importing
said data.

Again, technically, no problem. I'm fine with writing lab
data directly into the EMR. Just making sure this is what
you want.

> I've done some research into qcat and there seems to be some controversy
> regarding it.  Namely, a huge security issue that could expose
> patient details.
This is only true when using it on Windows with the software
provided. One can use it without that spyware just as well
like any old barcode reader without any security risk.

> 1) patients get registered out front
> 2) registration prints off barcodes onto stickers (that come out at the
> specimen collection room)
>     according to the tests the patient needs
> 3) place barcode stickers on a corresponding collection tube for that
> patient (different tests require different tubes with different
>     additives inside)
> 4) the tube is put into the devices and processed
> 5) the device reads the barcode which lists what tests are required
> 6) the device conducts the tests as indicated by the barcode
> 7) the results are printed out:
>     - to paper printouts
>     - directly into the database
> 8) lab techs enter and review results
> 9) techs save results
> 10) results are automatically sent out at the end of the day

Sounds reasonable and should be documented in a Hakuna
Matata Wiki along with some of the other descriptions you
gave above.

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