|
|
|
|
NewCrop
by Naeem - 03/18/2026 10:38 AM
|
|
|
|
|
|
|
|
|
|
Posts: 1,612
Joined: October 2011
|
|
#50157
11/20/2012 11:26 AM
|
Joined: Nov 2012
Posts: 13
Member
|
OP
Member
Joined: Nov 2012
Posts: 13 |
I tried several searches but results weren't helpful.
I am trying AC on the free trial basis. I have 10 years of patient data in a billing/scheduling program. Is there some way to export that data to AC without having to manually re-enter everything?
Also, any Psychiatrists in the group?
|
|
|
|
|
Joined: Jun 2009
Posts: 1,811
Member
|
Member
Joined: Jun 2009
Posts: 1,811 |
It will depend on the program that the data is in, but we have experience in getting data out of several different systems. Couple of questions: <>What is the system that the data is in? <>Do you know what the underlying database is? Access, Filemaker, MS SQL?
|
|
|
|
|
Joined: Nov 2012
Posts: 13
Member
|
OP
Member
Joined: Nov 2012
Posts: 13 |
I use Therapist Helper along with their electronic claim add on called Claim Advantage. Not sure about the underlying database, but happy to look if you can tell me where to look under the hood.
thanks
|
|
|
|
|
Joined: Jun 2009
Posts: 1,811
Member
|
Member
Joined: Jun 2009
Posts: 1,811 |
Alrighty - that is all I need for now - found the software and grabbed a demo to take a look. Will need to check the details, but seems that it will be do-able. 
|
|
|
|
|
Joined: Apr 2010
Posts: 1,548 Likes: 1
Member
|
Member
Joined: Apr 2010
Posts: 1,548 Likes: 1 |
Over the years, we have had to export and then import patient data several times, including into AC. The process is never perfect. There are always enough corrupt files that the data has to be individually reviewed at the first visit. When we changed billing software the last time, we found it easier to start fresh, and keep the old system going in parallel for previous charges.
David Grauman MD Department of Medicine Commonwealth Health Center Saipan, Northern Mariana Islands
|
|
|
|
|
Joined: Dec 2009
Posts: 1,210 Likes: 8
Member
|
Member
Joined: Dec 2009
Posts: 1,210 Likes: 8 |
A lot of that depends on a couple of things:
* How good your data is to begin with.
* How good your data import person is and how much time they took to get things right.
Rarely has database corruption been a culprit for me.
The person importing the data can do things like look for duplicates, provide reports on missing dates of birth, addresses, etc. Of course, I am assuming the person doing the import is using a comprehensive tool like MS Access and not just using some automated import tool like the one that comes with AC.
JamesNT
|
|
|
|
|
Joined: Sep 2009
Posts: 3,002 Likes: 5
Member
|
Member
Joined: Sep 2009
Posts: 3,002 Likes: 5 |
Tennessee, I think you can rely on Indy to get the job done, and get it done well...or tell you that it isn't worth the IT effort. On the other hand, you might want to give some thought to the value and extent of the project. When I made the transition, I was using Medical Mastermind and my intent was to bring over all of the billing data and demographics. My billing people talked me out of that. They pointed out how frequently people change addresses and phones, as well as insurance companies. It is simply too easy for incorrect information to be carried forward. It's better to make a fresh start. For historical billing data they suggested keeping information on an old computer in the old program for archival access. We ultimately decided to create a database that included names and the most basic demographic information needed to create a new patient in AC. This was easily imported into AC. At first the secretaries didn't like the idea of reentering new addresses and insurance information. Then they realized the value of updated and accurate data and we never looked back.
Jon GI Baltimore
Reduce needless clicks!
|
|
|
|
|
Joined: Jun 2009
Posts: 1,811
Member
|
Member
Joined: Jun 2009
Posts: 1,811 |
Having looked at the demo and spoken with the DBA gods, it is doable.
As JBS indicates, it depends on how much data you want to bring over. I sent you a Private Message about how to reach me if you would like help.
|
|
|
|
|
Joined: Apr 2010
Posts: 1,548 Likes: 1
Member
|
Member
Joined: Apr 2010
Posts: 1,548 Likes: 1 |
Jon restated the ideas I was trying to say in my post in a much clearer way. James has pointed out that it depends on "how good the data import person is and how much time they take to get it right." That is another way of saying the same thing; someone has to clean up the records that don't import well, and, like Jon, we found it easier in the long run to import minimal information that was easy to clean up, and then start fresh.
David Grauman MD Department of Medicine Commonwealth Health Center Saipan, Northern Mariana Islands
|
|
|
|
|
Joined: Dec 2009
Posts: 1,210 Likes: 8
Member
|
Member
Joined: Dec 2009
Posts: 1,210 Likes: 8 |
I say this with all due respect:
If you found it easier to just enter everything in manually, then I have to wonder just what kind of state your data was in. And that leads to many other questions.
JamesNT
|
|
|
|
|
Joined: Apr 2010
Posts: 1,548 Likes: 1
Member
|
Member
Joined: Apr 2010
Posts: 1,548 Likes: 1 |
James, this is not a data problem; it is a human factors problem.
Let's say the data was 99.% pure, a very generous assumption, and it imports perfectly. That means out of 5,000 records, 50 were garbage. To find those 50, you still have to look at EVERY SINGLE patient record as the patient comes through. The patient still has to fill out the questionaire form, the receptionist has to review it, question it, and where necessary enter it. Also, as Jon stated, the data that is being imported may be perfect in IT terms, but still totally incorrect. It is the usual problem of GIGO. Our data imports have gone as perfectly as one could expect in terms of the computer system; it was still easier in the long run to start fresh.
David Grauman MD Department of Medicine Commonwealth Health Center Saipan, Northern Mariana Islands
|
|
|
|
|
Joined: Dec 2009
Posts: 1,210 Likes: 8
Member
|
Member
Joined: Dec 2009
Posts: 1,210 Likes: 8 |
Dr. Grauman,
You are quite correct in that the problem truly is a human factor. Between employees having a bad day, employee turnover, and employee incompetence from that one bad apple everyone hires now and then, there will be data that is not in the best of shape. However, I must say I find your reasoning for manually re-entering all that data to be flawed. The reason is simple: mistakes do happen. A very good practice will have 10% bad data pretty much all the time. That is data not entered correctly such as misspelled names, missing or incorrect birthdates (i.e. 1/12/73 instead of 11/12/73), incorrect or missing genders, etc.
You are saying that by manually re-entering all that data that your staff cleaned up a bunch of junk along the way. Granted. But what about the fresh mistakes they made along the way? Of course, I agree that your approach my produce cleaner data, but for how long? How long before things are back the way they were? Will that short reprieve be worth the money you spent on all that employee labor?
What's the difference between your spending all that money in labor to clean things up somewhat for a short time versus me importing your data for you at a lower cost and providing you reports on patients with missing last names, missing birthdates, etc.?
At what point are we pulling the dagger out of our right leg to allow that leg to heal only to sheath that dagger in the other leg?
JamesNT
|
|
|
|
|
Joined: Apr 2010
Posts: 1,548 Likes: 1
Member
|
Member
Joined: Apr 2010
Posts: 1,548 Likes: 1 |
What we found is that the data reentry problems seem to be things like the name one letter off, or transposing two numbers in a phone number; the bad import left things unrecognizeable. And, as stated before, patient data changes so much that it was a golden opportunity to fix bad information.
I think both Jon and I did find utility in doing the import of very basic information, like name and address. But I found that, for us, launching off with imported data would have been a mistake.
David Grauman MD Department of Medicine Commonwealth Health Center Saipan, Northern Mariana Islands
|
|
|
|
|
Joined: Dec 2009
Posts: 1,210 Likes: 8
Member
|
Member
Joined: Dec 2009
Posts: 1,210 Likes: 8 |
Dr. Grauman,
I think we are reaching common ground. A proper import performed by a knowledgeable IT person should have brought over what you had the way you had it. It should not have made things worse and it sounds like it did. So, yes, in your case perhaps you did do the right thing.
May I ask what you used to do the data import?
JamesNT
|
|
|
|
|
Joined: Apr 2010
Posts: 1,548 Likes: 1
Member
|
Member
Joined: Apr 2010
Posts: 1,548 Likes: 1 |
We have done data import several times from different systems, so the techniques varied. The import to AC was 2 1/2 years ago, and don't exactly remember. Again, the issue was not so much of a bad import; it was that the data that was imported was just plain wrong or out of date.
David Grauman MD Department of Medicine Commonwealth Health Center Saipan, Northern Mariana Islands
|
|
|
|
|
Joined: Nov 2012
Posts: 13
Member
|
OP
Member
Joined: Nov 2012
Posts: 13 |
My data is very accurate, my staff member in charge is meticulous. Will let you know how it goes!!
|
|
|
|
|
Joined: Nov 2012
Posts: 13
Member
|
OP
Member
Joined: Nov 2012
Posts: 13 |
Thanks will look it over and be in touch! 
|
|
|
|
|
Joined: Jan 2011
Posts: 303
Member
|
Member
Joined: Jan 2011
Posts: 303 |
Not to belabor this ( I know, that is exactly what I am doing), but I hear the following: don't do a data transfer because the data is inaccurate, but oh by the way continue to use the very same data every single day in the extant system until you do change over. I know many "data experts" recommend re-keying. I think there is a place for data transfer and a place for real time data verification (esp med lists -what a burden keeping those straight).
Roger (Nephrology) Do the right thing. The rest doesn?t matter. Cold or warm. Tired or well-rested. Despised or honored. ? --Marcus Aurelius --
|
|
|
|
|
Joined: Sep 2003
Posts: 12,904 Likes: 34
Member
|
Member
Joined: Sep 2003
Posts: 12,904 Likes: 34 |
I find that everyone seems to underestimate James. Instead of answering his questions so he has an idea of what could be done, it always seems users try to be one step ahead and give reasons why it wouldn't work. By the way, 99% seems like a pretty good number. From the logic used, even if only one chart were inaccurate, you would have to look through every chart. 
Bert Pediatrics Brewer, Maine
|
|
|
|
|
Joined: Nov 2012
Posts: 13
Member
|
OP
Member
Joined: Nov 2012
Posts: 13 |
|
|
|
|
|
Joined: Sep 2003
Posts: 12,904 Likes: 34
Member
|
Member
Joined: Sep 2003
Posts: 12,904 Likes: 34 |
Bert Pediatrics Brewer, Maine
|
|
|
|
|
Joined: Nov 2012
Posts: 13
Member
|
OP
Member
Joined: Nov 2012
Posts: 13 |
|
|
|
|
|
Joined: Jun 2009
Posts: 1,811
Member
|
Member
Joined: Jun 2009
Posts: 1,811 |
Not to belabor this ( I know, that is exactly what I am doing), but I hear the following: don't do a data transfer because the data is inaccurate, but oh by the way continue to use the very same data every single day in the extant system until you do change over. I know many "data experts" recommend re-keying. I think there is a place for data transfer and a place for real time data verification (esp med lists -what a burden keeping those straight). I have run hundreds of millions of rows through ETL/conversion tools, and even the best tools doesn't fix bad data. The flip side is what are you going to expend to find and fix bad data? I'd recommend the hybrid solution of import the data that you want/need, then check data on returning patients - much like practices only scan records of returning patients as they switch over to an EMR from paper charts.
|
|
|
|
0 members (),
209
guests, and
32
robots. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
|