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

[Sebastian Hilbert]

Am Donnerstag 22 Juli 2010, 01:52:39 schrieben Sie:
> 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.
> 
It sounds like you are talking about a systems that covers all steps in a 
hospital. GNUmed was never designed for that. I recommend you look at VA 
Vista. You can write your own software for that but given how much ressources 
it took to create GNUmed I doubt that you can write and maintain a software 
that all users will be happy with. Each of the clients will call for special 
features which take time to implement.

Nevertheless I can tell you what would be possible with GNUmed. Coding the 
missing features is up to you mostly if you need them in a reasonable 
timeframe.

> We anticipate running a 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 where the doctor's system is, so it knows where to send the
> results to.

This is standard operating procedure. A patient can have multiple numbers in 
GNUmed, e.g. one for the lab software and one for the EMR. Patients are only 
logically connected to one or more physicians. You can specifiy who has been 
seeing a patient and who signs off on results but there is no way to limit a 
patient to a certain physician and hide it from another.

> When they are done and file the record, it will look up the
> doctor's info, and forward the record on to the office.

From what I reason from this workflow I assume that right now all is done by 
sending paper ?
For GNUmed they would simply input data in the patient's corresponding record 
and the doctor could pull it up. Their is an inbox for the doctor where one 
can see what new results there are.

> Ditto with the
> hospital; 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.

There is only one database which gets accessed by the doctor in the office and 
the care team in the hospital. Having multiple database would mean you will 
need to write some sort of mechanism to send database records or exported 
files from a to b. 

> 
> I anticipate this communications aspect will be outside the scope of any
> package I deal with, so I'd have to write that functionality 100% on my
> own.

Partly so. GNUmed can export and import records of various types. However you 
would have to extend that to cover export and import to/from a common standard 
such as HL7 records. For lab results have a look at MIrth. For the 
communication aspect you could write an XMPP-based data transfer (think chat 
client with file transfer).  This is  a completely seperate project and is 
very ressource intensive (money or time).

> No worries -- we'd want to have all of the needed security issues
> under very tight control.
> 
I am not worried at all. You would have to implement end to end data 
encryption and be HIPAA compliant.

> Each site would have a stand-alone system, that they worked with.

I guess you are talking about logically and physically seperate networks and 
databases in the hospital and the offices. If yes then you need the above.

> 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.
> 
That seems logical.

> 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.
> 
Umm. No. I mean I don't understand the above. For GNUmed you could open ten 
GNUmed windows at the same time so you could be dealing with 10 patients 
concurrently. Since this is access controlled by the database virtually 
unlimited users could access the patient/record at the same time apart from 
accessing/writing the same table row at the same time. This is postgresql. We 
do not lock records or files. We lock only parts of a patient record. 

> 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.
> 
Yeah that is covered by design. I would be interested what you find out on 
this when you evaluate other EMR.

> 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.
> 
It is not only possible but alreaday there.

> 2a) One module that we'd need would be for scheduling. 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.

Scheduling has not been implemented short of using Korganizer for that. So 
whatever you can do in Korganizer you can see in GNUmed. Everything else is up 
to you. What you are talking about however is something different. It is order 
mananagement and is often confused with scheduling. GE Centricity Carddas 
(costs big money) is one such system.

> 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.
> 
Some scoring systems are implemented in GNUmed. You could add that one I am 
sure.

> 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.
> 
You would have to see about that and extend any given EMR/EHR if neccessary. 
There is quite a bit information out there on how to write a plugin for 
GNUmed.

> 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.
> 
Labs tend to have very special requirements and they mostly use special 
software. What the lab needs is a lab information system (LIMS). I believe 
there is even a software for that available. But that is outside the scope of 
GNUmed and never will be in the scope. GNUmed simply accepts the results in 
different formats and tries to make the most of it by displaying it. It will 
never aid in the production (from e.g. blood samples) of these results.

> 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.
> 
You are talking about patient tracking and I guess you want some sort of time 
tracking. Pulling up the chart from a scan of a wrist band can be implemented 
(depending on the info of the wrist band) but if you are talking about time 
tracking there are suddenly a whole lot more complex concepts. GNUmed operates 
in terms of episodes. The minute a scan is done an episode could be started or 
continued. An episode of an health issue. If you are interested you can read a 
lot ant our wiki (http://wiki.gnumed.de - health issues, episodes)
For pulling up the notes plugin on the second scan we have a hooks system. A 
hook can be defined to act on the scan-out event. But still this only emulates 
the check in, check out stuff. It is not naturally supported and if you want 
this you will have to check the hospital oriented EHR.

> 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.
> 
This is not supported and will be up to you to implement. GNUmed is targeted 
at office settings not wards and stuff. You should be looking at VA Vista for 
that.

> 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.
> 
There is a progress notes plugin or you would habve to write your own.

> 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.
> 
See above. Given the work needed to implement #2 it is always wise to check 
all EMR to see if maybe another one covers what you need already.

> 3) We'd need hospital/clinic type information added. Things like room
> number, date checked in, 

Outside the scope of GNUmed unless someone implements it. Again I am sure VA 
Vista has this already.

> 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.
> 
Demographics is 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.
> 
I did not understand that part. Can you give examples ?

> 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.
> 
Once you have evaluated your other options I would be glad if you could share 
your findings on what works in what software and what does not.

Sebastian