Re: [Gnumed-devel] So you want to gain some with GNUmed ?

[Lee Crites]

On Wed, 2010-07-21 at 07:09 +0200, Sebastian Hilbert wrote: 
> There really isn't much US centric functionality in GNUmed. You would have to 
> look into connection billing to it. Another thing missing is coding systems 
> (ICD-9,ICD10) so you would have to add that as well. It would be beneficial to 
> all if you could post a list of minimal requirements for your tests/client.

I'd love to. I'll try to be succinct, so if something makes no sense, just let me know. Some of what I'm saying will be outside the scope of GNUmed, but you need to see how it all fits together.

First off, the big picture: The complete system we are envisioning will work from a doctor's office all the way through to a hospital environment. What that means is that Dr Schmoe can use the software in his office for his practice, the labs can use it in their environment, the hospital can use it in it's environment -- and everyone is using the same software and database setup, so records can xfer from one to the other with impunity.

We anticipate running a type of centralized clearing house system so that when the lab does work on a patient, that the doctor's "system number" and the patient's "patient number" are on the form, and so the lab's system knows how to find the doctor's system, so it knows where to send the results to. When they are done and file the record, a module/process/standalone program will look up the doctor's info, and forward the record on to the office. Ditto with the hospital; ditto with clinics; ditto with other doctors the patient is sent to. This way, the doctor's office has the full true-and-ungarbled word, updated in "quasi-real-time" as things are added to respective individual databases.

I anticipate this communications aspect will be completely outside the scope of any package I deal with, so I'd have to write that functionality 100% on my own. No worries -- we'd want to have all of the needed security issues under very tight control.

But each site would have a stand-alone system, that they worked with (a GNUmed based system). The bulk of the records (in theory) would come from their own work. If any were sent out and/or added outside of their work, it wouldn't matter.

So what about GNUmed? Here's my initial thoughts on that:

1a) From the VERY LIMITED tinkering I've done with GNUmed, it appears that it is set up for one doctor to do the work with one patient at a time. I guess the assumption is that there probably wouldn't be more than one person dealing with any one patient at any one time, and that one person would be the doctor.

In a clinic or hospital environment, it is quite possible that multiple people will be dealing with the same patient's records. The doctor is putting in progress notes, the lab is adding results, the occupational therapist could be putting in their progress notes, the pharmacy is making a notation on potential medication interactions, and the nurse is adding details on the last bowel movement. I'd need to make sure that this could happen without a problem. 

1b) Also, the login seemed to be doctor oriented, and we'd want to add a lot of other types of people: nursing staff, other medical staff, pharmacy, therapy, front office, etc. Probably limiting each type of person to a (sub)set of functions (e.g. business office staff not changing medications). I have done zero checking into the security aspects of the software, so I have no clue if what I'm talking about here is even possible. 

In the system we were putting together, it was all table driven. What kinds of people there were, and what menu options they could execute was all defined in a SQL database. So if we wanted to add a new kind of person, it was easy to clone one type, change the name, and voila, you're in business.

2a) One module that we'd need would be for scheduling services performed on a patient. 

In the rehab hospital, there are several different kinds of therapy staff: occupational, physical, speech/language, etc. Each patient is scheduled for a certain amount of each therapy a day. So we'd need to have a list of who is when for today, check-in/check-out, therapy notes, schedule for tomorrow, etc. The thing that drives all aspects of a rehab hospital is something called a FIM Score. It is basically a set of numbers that identify how much help a patient needs in a series of daily tasks. 

If we built this in a table-driven manner, then I can see how we could generalize all of this. How often does a doctor want to schedule a patient for some procedure outside of his/her practice? It is frequently enough that having a module that could let the staff enter the schedule info for a patient for that procedure could be a good thing. And the doctor would expect the results from the procedure returned to the office, and a way of recording them in place.

On the other side of the deal, if the lab is using this software, then they'd have to check the patient in, do the work, check the patient out, and somehow deal with the results of the test.

So what I'm asking for is probably already "in there" somewhere -- or at least already being thought about by some of y'all. It's just in a different format than I'm describing.

2b) Even if it is already there, then a few changes might need to be made to the check-in/check-out process. The physical therapy staff member, who is logged in as such (see above comment about different kinds of people logging in), would have a screen where they could enter/scan in the patient info from their wrist band: thus the checkin. Then when the patient is checked out (via another scan), it would open up a screen for the therapist to enter notes on the session.

2c) A nurse's station monitor would need to display a screen with "departure/arrival" information -- sort of like you see at the airports, giving the names of the patients that are coming and going, sorted in time order. When the patient checks out of therapy, it would be flagged at the nurse's station, so they'd know to expect them to arrive. When they arrive back in their room, a final check-in would clear the flag. Thus "lost" patients could be identified quickly.

2d) A database for FIM Scores and/or a way to add these to the existing database will be needed. There is a weekly ITM Meeting (interdisciplinary team meeting), where a representative of each staff area involved with the patient gets together to go over the patient, their progress, make plans, etc. This will have to be thoroughly noted and documented. While this is a non-trivial document, it is virtually all text. As things develop on this, there might be more "stuff" added, but we could start with just a large blank text form for now.

My assumption is that if the rest of the software meets our needs, that the bulk of the module dealing with #2 is something I'd probably contribute.

3) We'd need hospital/clinic type information added. Things like room number, date checked in, etc. And that would need to be on the screen when a patient's record is up. It would be nice if a picture could be added to help with security issues, but at least demographics would need to be there.

The database we currently have has a "generic" data type, and we overlay a template based on the record type in question -- so adding new kinds of records was a no-brainer. We were using LAMP, so I could just make a new instance of the database object with the new layout, and voila, we were okay. I have no idea what it will take to add new record types to GNUmed -- but I can tell you that if we go with this option, we'll be adding quite a few of them.

So how was that? I tried to make it as short as possible, so there are a lot of details I only scratched the surface of.

Why am I looking at GNUmed?

It is open source; I like that. Except for my security module, everything I write can be added to the open source code.

Is works on my Ubuntu system -- and, indeed, I can (and did) install it like any other module.

I liked the way it looked when I was testing it.

If we can pull this off, then I'm a happy dude. I'll move from LAMP to Python, and not loose a moments sleep over it.

Thanks muchly,

Lee

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lee Crites / address@hidden / www.TBFed.com
Everything Counts: Everything you do is either taking you towards
your goals, or away from them!


CONFIDENTIALITY NOTE:
This e-mail and any attachments are confidential and may include proprietary or trade secret information. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lee Crites / address@hidden / www.TBFed.com
Everything Counts: Everything you do is either taking you towards
your goals, or away from them!


CONFIDENTIALITY NOTE:
This e-mail and any attachments are confidential and may include proprietary or trade secret information. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation.