[Gnumed-devel] Re: Gnumed-devel digest, Vol 1 #296 - 4 msgs

[syan tan]

On Tue, 2002-04-30 at 05:05, address@hidden
wrote:
> Send Gnumed-devel mailing list submissions to
>       address@hidden
> 
> 
> Message: 2
> Subject: Re: [Gnumed-devel] Should I switch to Gnumed?
> From: Paul =?ISO-8859-1?Q?Rodr=EDguez?= <address@hidden>
> To: Karsten Hilbert <address@hidden>
> Cc: GNUmed list <address@hidden>
> Date: 29 Apr 2002 11:08:03 -0400
> 
> I apologize for having taken my time with this, and I appreciate the
> friendly help you have given me with this matter.
> 
> Some time ago, I asked about transferring the practice management
> software at the office for which I work to Free Software.  I was asked
> to describe our situation in more detail and also to explain in detail
> what our specific needs were.
> 
> 
> Our Requirements to implement Free Software
> 
> We are an optometrist's private practice in the United States.  We have
> become increasingly dissatisfied with the current proprietary system
> which we are currently using.  This closed system is currently very
> expensive, but more importantly we do not feel we have control over the
> data that is essential for the smooth running of our office.  We
> currently use a proprietary practice management system called RLI.  As
> it currently stands, we are on a forced upgrade track every couple of
> years.  If we do not continue to upgrade, the company ceases to support
> our product.  In addition, we pay for their services on a monthly basis,
> if we do not pay at the end of the month, or there is a problem on their
> end with the electronic billing (as has already happened) we cease to
> have access to all of our electronic patient records.   If the company
> changes their terms, or goes out of business, we will experience great
> difficulties we cannot currently afford.  
> 
> In addition, this program is only available for Windows.  We are trying
> to move all of our software to Linux and Free Software.  For issues of
> long-term stability we feel it is necessary to have control of our own
> systems and patient information.  We are looking for a cheaper solution
> which can meet our needs, give us more control of our practice (over the
> long run), and embrace and support Free Software.
> 
> 1)
> Our current database of patient information, currently part of a
> proprietary program called RLI, needs to be transferred to an open
> database format.  (Such as SQL.)  This information includes patient
> names, addresses, birth dates, medical history,
> medical/insurance/demographic codes, and recall dates. 
> 
> To this database we would like to add information about past and future
> appointments 
> and scheduling, and also be able to cross-link patients with family
> members.  
> 
> 2)
> In addition, we need a scheduling program to manage appointments.  This
> program needs access to certain information in the patient database
> (previous and future appointments, family members, and contact
> information).  When scheduling an appointment for a patient, the program
> needs to be able to display when the patient's last appointment was and
> when their next one is scheduled.  There also needs to be a convenient
> way to access the patient's contact information, and if necessary or
> appropriate, the contact information of their closest relatives.  
> Perhaps a simple middle or right click on a patients name (or a
> mouse-over) would display their phone number, and a small menu with
> members of their immediate family with corresponding phone numbers.  The
> program needs to automatically print a list of patients who missed the
> day's appointments and print a recall label for each of these patients
> which we'll affix to a postcard.  (We'll need templates for the
> labels.)  
> 
> The scheduling program will be run on a separate computer from the
> database.  Ideally there would be a way to restrict what information
> from the database is accessible to the scheduling program.  The program
> should automatically be able to access a patient's appointment history,
> contact information (and immediate family's contact information), and
> future appointments (and perhaps insurance and payment information) but
> not medical history.
> 
> 3)
> We need to be able to easily print out a superbill to give to the
> patient and a way of keeping track of when and how much a patient has
> paid and consequently, how much the patient owes.   We also need a way
> of printing out an invoice to mail to the patient.
> 
> 4)
> One of the most potentially difficult and important things is to be able
> to send an electronic insurance claim via a direct modem connection to a
> clearinghouse.  Our clearinghouse is currently WebMD as they have an
> exclusive contract with Aetna (and possibly Blue Cross Blue Shield
> soon).  WebMD accepts claims forms in either print image or NFS format. 
> The form that needs to be sent is form #1500.  Some of the insurance
> companies we deal with are:
> Medicare
> Medicaid
> PHS
> Aetna
> Empire Blue Cross Blue Shield
> Blue Cross Blue Shield
> AmeriHealth
> Oxford Health Plans
> 
>  
> 5)
> Once we have this system set up, we need to automatically print out
> labels to send recall letters and birthday cards to patients twice a
> month.  This requires a label template and for a program to display a
> notice to the user to insert the appropriate labels in the printer.  
> 
> 6)
> One other automated task that needs to be set up is the weekly backup of
> the database and/or entire system.  Ideally, I'd like for this to be
> done on CD-ROM.  A program would be needed to prompt the user to insert
> a CD and how to label it.  CD-RW is another viable option (perhaps a set
> that can be recycled every few months).  
> 
> 7)
> We also need a set of templates to use for writing letters to patients. 
> Right now we are using both Abiword and OpenOffice.org, but there are
> certain aspects of OpenOffice.org that may perhaps make it more
> appropriate for our environment.  What is needed is the ability to
> select a patient from the database and choose to open one of a list of
> pre-written letters in a word processor, and have the program insert the
> patient's information in the appropriate spaces.  
> 
> 
I think with such accurate requirements specification , it would be
an excellent exercise for the technical savvy manager to attempt to 
implement a prototype in the language of his choosing. This would help 
decide whether he really needs accounting professionals to improve
the bottom line, and he wouldn't get frustrated by temperamental
developers who are either just interested in exploring the limits of a
programming environment, or get bored when they wonder if the means
justifies the end after all.