[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Transferring/importing/bootstrapping from legacy sys
Re: [Gnumed-devel] Transferring/importing/bootstrapping from legacy systems
Sat, 21 Jan 2006 22:31:38 -0800
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
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:
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