>>>> 1) The Physician Section - GUI NOT ASSEMBLED AS OF SEPTEMBER 2007 >>>> 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. >>>> >>> 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. >> >> No you don't. You could just read the (number of) known >> tests from the database and loop over them creating an >> appropriate checkbox in every iteration. Things like
>> checkbox label, tooltip string, target field for the request >> etc can be made configurable alongside the test itself right >> in the database. Just loop over the data and create >> checkboxes and don't worry about how many there are.
>> (I agree wxPython isn't the easiest tool for this and, >> yes, wxGlade doesn't support this sort of thing.)
I didn't understand a word of that :P
I'll just make the prototype 'proof of concept' GUI for the physician's section and you can
make all the necessary tweaks that wxGlade won't allow (and explain the changes to me in lay terms).
> *Only IF* you want to group certain tests *semantically* > together in special ways you will need a list of known tests
> beforehand. And even that could potentially be done by > configuring metadata about tests in the database (such as > "Urinalysis profile" linking certain tests).
I believe this was what I was talking about.
> Additionally it will make sense to have a section "Other" > displaying tests in a simple list of labelled checkboxes > which aren't grouped together in any specific way. > > Even then it still makes sense to have this:
> >> All also include a Miscellaneous text field so they can request >> a test that isn't available
Then I'll keep the plan on making a tab dedicated to a 'Miscellaneous' section.
>> or have special requests about the tests to be conducted. > >This should be a field next to each test, no ?
Actually, that's a good idea. More obvious that way. I hope it will not make the
interface look too bulky.
>>>> 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.
Tell me how to complain. Use Launchpad?
>> 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).
Got a HOWTO in the wiki? I'd like to include this info on our website. Maybe some day we can get someone to make a plugin to set up workplaces like that (if one doesn't exist already).
>>> 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.
As long as another plugin isn't needed for it. I'll try and remember to add that tidbit on our webpage in case sysadmins want some extra security auditing tools.
>>>> 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.
I'll leave that bit up to you then. I'll just have to add it to the wiki.
>> 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.
Well as long as you understand both that's all that matters. The decision will
be totally dependent on your opinion of both transport methods. Choose the one that is the best fit for our needs and has the most longevity.
>> 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.
It may be a best to send them the electronic version of the results and have the
user decide whether to print off a copy at their end. Using paper is regressive and should probably be used as a backup.
>> 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
Whichever is best. I'll side with whatever path you choose.
>> 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.
That's what I meant. Like how we use keys to access repositories.
I apologize if got the terminology wrong.
>> 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.
Using encryption will be a nice selling point once the main code is finalized. I hope all it will need is a simple bash script.
>> 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.
If we get enough requests from users in our forum we may have to list the locations
of these drivers. But that can wait.