(Sorry this took so long. I was enjoying the end of summer!)
> Why is there a redundant Patient Search area? (GNUMed already has one) > Will Hakuna Matata be integrated into the GNUMed user interface or a seperate interface altogether?
Hakuna Matata comes in 3 parts:
==============================
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.
2) The Office Section - GUI NOT ASSEMBLED AS OF SEPTEMBER 2007
This portion may or may not become apart of the GNUMed interface. This section:
- 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
GNUMed already does some of these so I will be wary of redundancies when I make it.
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.
This section MUST be completed first or else we have no idea what fields/tests to request in the Physician Section.
==============================
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.
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:
1) PATIENT PRIVACY is at risk. Limiting access to patient records prevents the leaking of patient info. 2) SIMPLICITY. The lab section provides only what lab techs need. 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.
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. This is essential for laboratory quality control so make certain a log of who logged in and who inputted what is kept.
Closing the window should automatically log you out.
1) Physician Section - Order tests for the patient (I'm not certain how the test request will find it's lab 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
GNUMed itself handles lots of these functions so when I do the Office and Physician sections I'll have to take a tally of these
functions and leave them out
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.
> Please let us know more about the intended use. We could integrate the plugin > as is and connect the fields like names and stuff. How do you want to work
> with it ? Do you want to input those tests I can see or do we get this > information somewhere ?
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.
The test result values will likely be entered manually into the GUI and then saved into the database, but some
equipment may enter these results directly into the database without need of a human intermediate. I lack knowledge about such equipment.
> on the data front there exist various machines like glucose monitor or
> urinalysis sampler for doctor's offices. for a few of them drivers for linux > exist already.
Can you compile a list or provide a location of these drivers? I should make DEBs :)
These drivers would be important in the barcode-reading function. I lack to much knowledge in this matter.
> Are you working with barcodes on sample containers ? I have played around with
> a cheap barcode scanner named qcat (10 pcs for $100) on ebay. > > there is a barcode printer which can be used to print those small labels. I > have seen two that can be used with linux.
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. I highly suggest NOT building barcode support with qcat in mind.
The 'barcode' package in the Debian/Ubuntu repos should provide some help in this matter.
Also, I only remember seeing barcode readers within the testing devices themselves and I have no idea how they operate.
In the lab, the workflow goes like this:
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