Medical Billing Software > Medical Billing Software Reviews
Office Ally
RichardP:
--- Quote from: Billergirlnyc on April 02, 2013, 01:23:48 PM ---I passed on your second reply to my brother ...
--- End quote ---
Thanks. If he knows SQL, perhaps something useful will come of this.
Billergirlnyc:
--- Quote from: PMRNC on April 02, 2013, 02:06:25 PM ---I apologize, I had seen this:
--- Quote ---I agree sometimes having a software that does it all isn't sufficient either, but paying someone yearly fees for 3 different programs isn't cost efficient, and that's what I'm doing now. If I can at least incorporate 2 out of the three, I'll be happier and so will my staff.
--- End quote ---
and with the annual fees mentioned so I thought you were coming out of pocket. I do same as you even with the ones who are web based and how I work it is they have whatever software (web or not) licensed through their own practice and such and I receive administrative access (separate of course to preserve audit trail). I do this because when I have to terminate a client it's just so much less of a headache and any data conversions/capture/backups is all their responsibility. It's not an added cost at all because if they had in-house staff they would need their own system anywhere and I've never had this an issue because either they already had a solution/software in place or like you, I offer suggestions and then they go and do what they have to do.
--- End quote ---
Gotcha and agree doing it this way is definitely less of a headache if and when contracts aren't renewed. :)
Loyal Servant:
Sorry to necro, I got pointed at this thread.. don't thrash me too hard ;D
I have seen a lot of the ePCR vendors over the years start billing services then steal our clients that were using their ePCR system. >:(
Thing is.. they come in and do it for virtually nothing to get the customer base.
Then they do a bad job collecting....
Now as far as the interface aspects.... I may not be completely understanding what the discussion is about but if I
am reading this correctly that's something I have more or less in place now.
Data is extracted in a standardized format (NEMSIS) and then imported into the system.
It's scrubbed and passed thru several sets of eyes, coded, washed again by another person then the claims
are transmitted to [insert trading partner here].
The glue between these systems is XML data.
The user enters the data in the web interface or other ePCR system and then our system if i can do so will extract
the data my itself, batch it and show up in a list of ready batches to one of the users in our office.
If there is no mechanism to get the data in an automated fashion a user does it by hand with an extract feature
in the ePCR system the provider uses.
Is this what you guys and gals are eluding to?
The problem on my side of things is that very few of the ePCR system support such a featureset unless it's into their
own billing system.
Very few of the ePCR vendors play nicely with third party billers and usually fight us.
Is that the same issue you are seeing in the practice management systems or are the various vendors playing nice?
RichardP:
My conversation is about specifically sitting at the computer and having to log into 10 different Practice Management systems over the course of the day, each with their own data input screen. Each data input screen is organized differently. The clerk typing in patient demographics and insurance information has to reorient themselves each time they switch PM's.
A desired situation is to have one data input screen for inputting patient demographics and insurance (two at the most) - that could be hooked up to each of the 10 PM systems the clerk is working with. As the clerk logs onto different PM systems, the data input screen(s) of each would be identical. I argued why this is desireable in my posts above.
This is coming from the governments push for "interoperability" - the requirement that any part of any medical system should be able to "talk to" any other part through the HL7 Standard. PM systems, EMR systems, perscription systems, lab results systems, all should be able to talk to each other (through the HL7 interface), regardless of who the vendor is. This led to the thought that perhaps a customizable data input screen could be developed. Each office could customize the screen(s) to their most favorite screen layout, and that screen(s) could then be connected to any PM system (since we are talking billing here) - either through an HL7 interface, or the front end / back end technology of SQL servers (regardless of vendor), or some other method.
This idea is not about passing data from one system to another. It is about the raw interface between people and machine - the initial point where data is input to the computer, either by the doctor (EMR) or the clerk (PM).
tallmanusa:
Quote
" I have seen a lot of the ePCR vendors over the years start billing services then steal our clients that were using their ePCR system. >:(
Thing is.. they come in and do it for virtually nothing to get the customer base.
Then they do a bad job collecting...."
Kareo started doing billing about six months ago; they are doing billing for 3-4% and include their EHR and PM in that price; of course all the providers who were paying for software and paying another 6% to the biller moved to Kareo billing.
Kareo promptly outsources its work to India.
How do I know?
Karoe rep would admit it, but besides that the outsourced company is a member of several organizations where they advertise " If we are good enough for Kareo, we are good enough for you".
I would like to know how the small biller is going to compete with likes of Kareo, ECW, Advanced MD, Care Cloud and a whole bunch of others who do billing at discounted prices, include their software, and then outsource offshore the actual work.
So you would hire staff at $10 an hour and make a profit and in addition make the doctor pay for the software? Of course it is all good, if you can find clients for whom money is no object.
I think the small biller ( less than ten clients) would be extinct, like the horse and buggy.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version