I am working on this issue right now. I'll describe what I am doing
and problems I have encountered, and it might help you.
My practice management system (PMS) has some predefined reports that
it will output. If we want to change these we have to pay for them.
Well, we found a report that will output a basic demographic set,
missing some key fields in my opinion (i.e. middle name, SSNum). It
outputs these in a CSV format, with one patient on each line of the
report. We use a AutoHotKey (freeware) scripting system to
automatically have our PMS output this report, and we established a
Windows scheduled task to run the script every night.
I then wrote a vistA program that imports the data file. I don't
think that there is a current Fileman way to do this, for some of the
reasons I outline below. I'd be happy to share my code with you if
you want. There are some functions to import an entire file into a
global variable, which one can then $ORDER() through to process each
line in turn. It is easy to separate the CSV's into data pieces using
the $PIECE() function.
The big problem I am having right now is accurately matching the name
exported by our PMS to VistA name. I have some 3000 names to be
synchronized and when I ran a short run, I ended up with duplicate
patients in the database because match attempts failed, my program
assumed they were a new patient, and a new patient record was added.
For example, these type names lead to mismatches:
Harrison, Sue 1-1-1980 vs. Harrison, Mary Sue 1-1-1980 vs.
Harrison, M Sue 1-1-1980
Filton,Bill 1-2-1950 vs, Filton,Bill Jr 1-2-50
I.e. the same person, but name not exactly the same for some reason
Add-ons such as Jr or Sr. may or may not be part of their
proper name (I'm not sure how this should be properly handled), but
are often entered as part of their name by our receptionists. Also
titles like PhD,MD, or I,II,III etc are also a problem. Another
problem I have encountered is the VistA handles names such as JOHN VAN
BUREN, with it thinks means BUREN,JOHN VAN.
Johns,Bill J 5-11-1950 vs. Johns,Bill J 5-21-1950
i.e. probably the same but someone has entered a typo of one
digit of the DOB. Which one is correct will require user interaction,
or simply assuming that the match is correct and overwriting the DOB
in VistA.
So I have a function that tries to find a match between the two
entries. Right now, I need to beef this function up. I think there
is some functionality built into vista to search for duplicate
patients. Perhaps I can use this code to find closest matches
I added a field to store the account ID from our PMS in the patient
file (#2) If you do this, make sure you get a proper namespace and
numberspace from Cameron to avoid name or number clobbering by future
VistA patches. Then, once I establish a match, I am storing the
account number so that a lookup can be done based on ID number and
avoid the name confusion.
After I have established a match between the PMS data and a record in
VistA, I then query the database for telephone number, address etc.
My PMS puts the address all on one line, which I have to split into
the three lines format used by VistA. I then compare the data, and
there is a difference, I store this in VistA's database.
I just read over my text above and I want to point out something.
VistA comes configured such that patients can't be deleted from the
database. There are good reasons for this. I had to modify the data
dictionary such that I can remove dupliate patients (being sure to
repoint all pointers to the removed record to the correct other
patient.) So if you end up with duplicate patients, we may have to
help you fix the problem.
Now, I am expecting that others will jump in and advise using a HL-7
messaging system. And on the surface I agree. The problems I see
with this approach is that 1) HL-7 is not as common as one could hope.
At least our PMS doesn't support it., and 2) when I follow the
messages posted to this board regarding HL-7 messaging, its seems to
be quite complex. and finally 3) All the HL-7 message will do is get
you the PMS data via a different data channel. You will still need to
process each entry and achieve a match as described above.
What I really should do in our site it require whoever puts a patient
in our PMS to also put them into VistA. But is perceived by some at
my site to be asking too much of already-overworked front office
staff.
So the bad news is that this problem requires some careful thought.
The good news is that I have the problem 90% solved, and I'd be happy
to work with you on this.
Kevin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
