Most Recent Posts
Retirement
by Wendell365 - 04/03/2026 6:16 PM
Ambient Scribes
by ChrisFNP - 03/24/2026 9:27 AM
NewCrop
by Naeem - 03/18/2026 10:38 AM
Searches
by Bert - 03/18/2026 7:39 AM
Missing Photographs
by Bert - 03/18/2026 7:34 AM
R codes -- answers for billers and coders
by Bert - 03/18/2026 7:31 AM
New NP - Looking for tips & tricks
by Wendell365 - 03/11/2026 12:01 PM
Member Spotlight
jimmie
jimmie
Montana
Posts: 1,612
Joined: October 2011
Newest Members
Denton13173, BPeds, PMG Care, KeepingItAnon, AspiringPro101
4,608 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
#50157 11/20/2012 11:26 AM
Joined: Nov 2012
Posts: 13
Member
OP Offline
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?


Tennessee #50158 11/20/2012 11:32 AM
Joined: Jun 2009
Posts: 1,811
Member
Offline
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?


Indy
"Boss"

Indy's Blog

www.BestForYourPractice.com
Our Name is Our Creed
Indy #50163 11/20/2012 2:19 PM
Joined: Nov 2012
Posts: 13
Member
OP Offline
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

Tennessee #50165 11/20/2012 2:56 PM
Joined: Jun 2009
Posts: 1,811
Member
Offline
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. smile


Indy
"Boss"

Indy's Blog

www.BestForYourPractice.com
Our Name is Our Creed
Tennessee #50167 11/20/2012 5:46 PM
Joined: Apr 2010
Posts: 1,548
Likes: 1
Member
Offline
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
Tennessee #50168 11/20/2012 6:53 PM
Joined: Dec 2009
Posts: 1,210
Likes: 8
Member
Offline
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


James Summerlin
My personal site: http://www.dataintegrationsolutions.net
james@dataintegrationsolutions.net
Tennessee #50169 11/20/2012 7:47 PM
Joined: Sep 2009
Posts: 3,002
Likes: 5
JBS Offline
Member
Offline
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!
Tennessee #50178 11/21/2012 11:33 AM
Joined: Jun 2009
Posts: 1,811
Member
Offline
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.


Indy
"Boss"

Indy's Blog

www.BestForYourPractice.com
Our Name is Our Creed
Tennessee #50209 11/23/2012 7:29 PM
Joined: Apr 2010
Posts: 1,548
Likes: 1
Member
Offline
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
Tennessee #50230 11/24/2012 9:12 PM
Joined: Dec 2009
Posts: 1,210
Likes: 8
Member
Offline
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





James Summerlin
My personal site: http://www.dataintegrationsolutions.net
james@dataintegrationsolutions.net
Tennessee #50233 11/25/2012 4:47 PM
Joined: Apr 2010
Posts: 1,548
Likes: 1
Member
Offline
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
Tennessee #50236 11/25/2012 10:58 PM
Joined: Dec 2009
Posts: 1,210
Likes: 8
Member
Offline
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


James Summerlin
My personal site: http://www.dataintegrationsolutions.net
james@dataintegrationsolutions.net
Tennessee #50238 11/26/2012 1:14 AM
Joined: Apr 2010
Posts: 1,548
Likes: 1
Member
Offline
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
Tennessee #50239 11/26/2012 10:09 AM
Joined: Dec 2009
Posts: 1,210
Likes: 8
Member
Offline
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


James Summerlin
My personal site: http://www.dataintegrationsolutions.net
james@dataintegrationsolutions.net
JamesNT #50241 11/26/2012 5:56 PM
Joined: Apr 2010
Posts: 1,548
Likes: 1
Member
Offline
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
dgrauman #50244 11/26/2012 8:35 PM
Joined: Nov 2012
Posts: 13
Member
OP Offline
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!!

Indy #50245 11/26/2012 8:37 PM
Joined: Nov 2012
Posts: 13
Member
OP Offline
Member
Joined: Nov 2012
Posts: 13
Thanks will look it over and be in touch! grin

Tennessee #50359 12/02/2012 12:28 PM
Joined: Jan 2011
Posts: 303
Member
Offline
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 --
Tennessee #50369 12/02/2012 8:29 PM
Joined: Sep 2003
Posts: 12,904
Likes: 34
Member
Offline
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. smile


Bert
Pediatrics
Brewer, Maine

Tennessee #50372 12/02/2012 10:39 PM
Joined: Nov 2012
Posts: 13
Member
OP Offline
Member
Joined: Nov 2012
Posts: 13
Well said!!

Tennessee #50373 12/02/2012 10:40 PM
Joined: Sep 2003
Posts: 12,904
Likes: 34
Member
Offline
Member
Joined: Sep 2003
Posts: 12,904
Likes: 34
Thanks Tennessee


Bert
Pediatrics
Brewer, Maine

Bert #50375 12/02/2012 10:42 PM
Joined: Nov 2012
Posts: 13
Member
OP Offline
Member
Joined: Nov 2012
Posts: 13
lol, yw!!

Nephros #50380 12/03/2012 1:29 AM
Joined: Jun 2009
Posts: 1,811
Member
Offline
Member
Joined: Jun 2009
Posts: 1,811
Originally Posted by Nephros
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.


Indy
"Boss"

Indy's Blog

www.BestForYourPractice.com
Our Name is Our Creed

Moderated by  ChrisFNP, DocGene, JBS, Wendell365 

Link Copied to Clipboard
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Who's Online Now
0 members (), 209 guests, and 32 robots.
Key: Admin, Global Mod, Mod
Top Posters(30 Days)
Bert 5
Naeem 1
Top Posters
Bert 12,904
JBS 3,002
Wendell365 2,370
Sandeep 2,316
ryanjo 2,084
Leslie 2,002
Wayne 1,889
This board is dedicated to the memory of Michael "Indy" Astleford. February 6, 1961 -- April 16, 2019




SiteLock
Powered by UBB.threads™ PHP Forum Software 7.7.5