Re: [Gnumed-devel] Transferring/importing/bootstrapping from legacy systems

[J Busser]

At 8:48 PM +0100 1/21/06, Karsten Hilbert wrote:
>  > 0) create patient
> >  1) create encounter            (perhaps date of import or other if available)
> >  2) create episode              (perhaps named after the diagnosis)
> >  3) create soAp row in clin.clin_narrative with narrative = diagnosis
> >  4) create row in clin.clin_diag pointing to the 
> > clin.clin_narrative row in 3)
>
> BTW, is this going to be an ongoing thing, eg you keep data
> in the legace FoxPro app and more or less occasionally sync
> it into GNUmed ? Or do you intend to make The Switch on this
> at some point in time ? Being clear on this definitely has
> an impact on how one would design the importer/transformer.

Right now, my "system" (which is no system at all) involves 
admitted-inpatient work at two hospitals, outpatient clinic work at 
one of these hospitals (previously both), also "private" office work.

- hospital 1 has a partial hospital info system (HIS) and sends some 
paper to my office
- hospital 2 also has a partial info system (HIS), and also sends 
some paper to my office
- both hospitals also fax information (some of this sent to me as TIFF images)
- I do some outpatient work in the above hospitals' clinics
     -> their HIS holds a copy of these dictations but sends my 
office paper or fax copies
- my office generates, stores and mails out paper reports
- my wife bills all the above activity from home after patient 
creation in my legacy FoxBASE app
- I see a small enough number of patients that I use a paper booking system

I am now under a bit of time pressure, because my legacy app will not 
run above Mac OS 9 and my current machines will reach end-of-cycle in 
1-3 years, whereas Macs that can boot natively under OS 9 are already 
out of production, and so too will be the Motorola-based Macs that 
could run the Mac "Classic" (older OS 9.2.2) emulator --- Apple has 
already begun migration to Intel processors.

But for now I must continue to use my billing app.

So for the time that I remain in "solo practice", I may as well 
create patients in the legacy billing app. That means transferring 
patients multiple times, on a semi-regular basis. It would seem that 
once I start, I must not alter any patient keys already in the EMR, I 
should try to only add patients (or identities) that did not already 
exist.

However, several local colleagues and I are being uprooted and are 
likely to move in together in August-September so at minimum we are 
likely to need some common scheduling.

So I am thinking now to move my data into OSCAR, and to use OSCAR to 
drive GNUmed, and at the point that any of my local colleagues should 
want to join in, to only create new patients inside OSCAR (at which 
point Oscar2legacyBilling can still be useful on an interim basis). 
Here are my further thoughts:

- OSCAR can already be accessed from anywhere, via web browser.
- OSCAR seems to have pretty good (at least reasonable) scheduling
- OSCAR makes it easy to check remotely things like
   -- a person's demographics / contact information
   -- an individual patient's past or future appointments
   -- the schedule of any of the doctors, or of the office/surgery overall
   making the above useful, even without it handling any clinical content!
- the above becomes even more useful / important, for a group
- OSCAR is, in my region, able to submit electronic billing.
   People in my group are likely to continue to want to do their own, but
   at least we would have the option of using OSCAR if it be useful
   (it may be ill-suited for billing that is not office/surgery oriented)
- an OSCAR-driving-GNUmed hybrid may be of value & interest to others

Thanks to Adrian for mentioning dbf2mysql :-)
- found a Debian package here:
        http://packages.debian.org/stable/misc/dbf2mysql

So my task list will be
- arrange local programming scripts, to get my legacy billing into OSCAR
   (OSCAR is already set up and running on my server)
- include ways to re-run the process, adding new patients
- completion of setting up a GNUmed v2 database
- setting up the OSCAR-driving-GNUmed
- (later) setting up Oscar2legacyBilling demographics
- evaluate the satisfactoriness of OSCAR's billing & alternatives