I apologize for the long delay in my reply. Ubuntu glitches and a new job kept me busy.
=========================================
>> 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.
I plan for the GUI for the Physician Section to be a list of checkboxes which will allow a doctor to order a single test or an entire panel
with a single mouse click. Each checkbox will send a request for a corresponding test or panel, so that's why a list of all possible tests.
Since the Urinaysis portion is complete I should really do a GUI that
includes at least that. I guess I could hold off working on the Allergy and Hematology Lab Sections for a while longer.
>> 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.
Yeah, I was assuming it would be set to a cron job or something like that.
I'll entrust the final verdict in that to you guys.
Requests from doctors would be put into a database and be checked off upon patient/specimen arrival.
Request samples would have to be prioritizable for STAT samples.
Barcodes need to be printed off to ID and track each sample.
Then you collect and send off the results at the end of the day.
>> 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.
>> 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.
As mentioned earlier, I intend the Physician Section to be a series of checkboxes that the doctor checks off to request a corresponding test or panel.
Therefore, I need to know the number of tests/panels to make the correct number of
checkboxes.
All also include a Miscellaneous text field so they can request a test that isn't available or have special requests about the tests to be conducted.
>> 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.
Great :)
>> 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.
>> 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.
I'll leave that one in your hands since I'm certain it concerns the backend.
>> 2) SIMPLICITY. The lab section provides only what lab techs need. >Which can be done by loading the corresponding plugins only.
I'll need to learn how to manipulate plugins in GNUMed.
>> 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.
Well if they use Hakuna Matata then they'll need GNUMed so I don't think using a different database
is an option.
The secret may lie in manipulating the plugins as you mentioned earlier and making the Lab section GUI load seperately from the main GNUMed interface.
We'll probablt come back to this point in the future.
>> 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.
I'm also hoping that the Lab section can load itself as an alternative frontend for GNUMed for speed and simplicity.
As a backup, I'll also have to figure out about selectively loading plugins depending on the
user/group.
>> 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).
A plugin could be made that organizes the database log into a logfile useful for easy QC purposes.
>> Closing the window should automatically log you out. > >It does. Closing the GNUmed client logs you out.
I thought it would. If Hakuna Matata becomes a seperate GUI it would have to do the same thing.
>> ================================================================ >> >> > 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.
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.
A database template will need to be constructed with the appropriate fields.
For PDFs, a lab/clinic/doctor can even make their own PDF stationary template with
OpenOffice.
>> 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.
Good. Let me know if you have comments/questions though.
>> > 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.
True. I don't want you to make or add any new dependencies if it is not necessary.
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.
>> 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 ?
No, not 'directly' since that would be be a slow and insecure practice.
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.
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. 3) The lab's clerical department receives and decodes the database (a shared key exists between doctor and lab) 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.
Comments?
>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.
Sounds good to me. Sounds similar to what I wrote above.
>Again, technically, no problem. I'm fine with writing lab
>data directly into the EMR. Just making sure this is what >you want.
Labs should probably keep their own database of completed tasks. This will be best conducted with a template database with empty fields to be filled in as if it was a
sheet of paper. I described this in more detail earlier and really suggest you don't share connectivity into one huge databse.
>> 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.
Ah, good. You may have to use some creativity with the barcode reader support. 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?
I hope the big machines either don't need or have Linux drivers available. It would suck if the user sets all of this up only to end up with hardware issues.
>> 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
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.