Barbara & Grahram,
Sorry for the creating the confusion on "Signature". I was referring to the forum Signature for a User. There's a Signature section under my user profile. It was this that I discovered and was referring to. As you note, I was having diffculting including my LINK. Grahram kindly let me know that that my link wasn't working. It looked like a link, but it didn't click anywhere <g>.
I went thru a couple of iteration and finally figured out how to do it. Then I discovered that under profile there is a SIGNATURE area. I then tried to put my link there. For veteran of this site, such as yourself, you probably knew this. However, because this is probably not something you mess with everyday I'm guessing you forgot and so when I mentioned "Signature" you thought I was talking about the Signature for electronic claim submission.
Phew....
When you submitt claims electronically, there really is no provision for a Signature per se (Patient or Physician) in the electronic file. When a new patient is registered, typically they are required to sign various form in the doctor's office. One of the things they sign is that they authorized payments to be assigned, i.e, it's okay for the insurance to pay the doctor directly. Therefore, on the paper 1500 (middle of the form somewhere), where you see the patient signature block, the computer might print something like "Signature on File". Electronically this may be represented as a boolean (Y/N)
In the 1500 form ( block 32? don't a form handy here), the doctor signature can be computer-generated, i.e., the computer types the name.
When doctors want to submitt their claims electronically whether that be direct to Medicare or through a clearinghouse, there is paperwork to complete. Lots of legal stuff like if you're submitting fake stuff you're going to jail (I am not a lawyer). Any case their trading partner (Medicare, BCBS, clearinghouse, etc.) assigns them unique Identifying numbers that the Trading Partner will associate with each submitting organization. These numbers are transmitted with your EDI files so when they receive your electronic claim file they will know who sent it and who they need to return various reports back to (confirmation, rejections, payments, denials, etc.) Also you will have a username and password to access their system so you can login and transmitt your claims to them. For now this may suffice as a "signature" sort, but there is no signature field in the EDI file.
HTH, and again sorry for the earlier confusion.
Ray
That's okay Ray. I was not confused .. and I don't think Barbara was either!
One of the links given above was for a Acrobat PDF 1500 form. So, I reckon with a little work, I can create an FDF file which will pre-populate the 1500 form with many of the values. However, since it is a form, the user can change the values and the emr no longer knows what was printed out.
So, my thought is to create a form that captures all the relevant data, which can be saved, and then from this data generate the final pdf for printing .. or whatever.
This way I can batch print all the 1500 forms for a period ...
Graham http://www.synapsedirect.com/ Synapse - the EMR for smart users
Grahram:
Just to be clear, you must print the 1500 on an official CMS-1500 form. Here's another link that you can add to your 1500 reference. Good luck as you proceed.
http://www.cms.hhs.gov/ElectronicBillingEDITrans/16_1500.asp#TopOfPage
How complex is billing where you're from? NZ? I hope it's easier <g>.
Wow! Gets worse .. so the official CMS-1500 form is in flint red so that the OCR software used by carriers does not see it? And if you send the form as a PDF ...is that not possible as well??
Billing in NZ is very simple ...bill the patient and they have to take the receipts to their insurance companies to get reimbursed.
Gramham:
Yep, the system in the USA is a third-party system. That is, the doctors relationship for payment is really largely with the insurance company. Here the doctor files the claims.
The 1500 wasn't always required. I remember when doctors could just sent almost anything in to get paid, e.g., Superbills. Then the HCFA-1500 became widely accepted. Medicare being the major payer in this country can set the standards for many things. When Medicare said that only HCFA-1500 could be sent in for Medicare claims, other insurance carriers, e.g., Blue Cross Blue Shied (BCBS) and others, easily fell in line and made this a requirements as well. It made sense as it created kind of a standard. Then the codes used to complete the 1500 also became standardized, e.g, long time ago, I can remember Medicare's place of service codes were different than BCBS's. Things like this also got standardarized and simplified things for the payer as well as the doctor's office.
Over the years Medicare has been promoting and successfully so in getting more and more of its claims sent to them via electronically. They offer various incentives -- faster payments and have even talked about charging the doctors if claims are sent in via paper. This was never approved.
I wonder if NZ would ever evolved into a third-party system? For your sake, let's hope not <g>.
CMS-1500 form is in flint red so that the OCR software used by carriers does not see it? And if you send the form as a PDF ...is that not possible as well??
This is where the "print image"comes in. The print image created by billing and patient accounting software creates the image only without all of the "red ink" so the information can be read. Many of the billing software companies offer this as a choice when creating the data. Some are easier to work with than others. The billing software I integrate with makes quick work out of this and will batch them to upload to a web server to scrub before sending out to the insurance carrier or Medicare. This is why in my EMR I created a superbill that creates a claim and exports the line item information to EZ Claim, so it's all done in one step and the superbill is printed as a receipt to hand to the patient right out of the scheduler before the patient leaves.
It's not always a simple process to get all of this together. I hope this helps explain why the signature box that is supposed to be a real signature, is really not. Once upon a time it was probably like any other form someone created, but as time went on things changed but the darn thing is still called a signature box. You may have heard more than you ever wanted to know about our 1500 forms by now.
Barbara Duck Ducknet Services TabletKiosk Sales Information
Blog: http://ducknetweb.blogspot.com/
The Widget Blog Site: http://ducknet.net/default.aspx
Skype Address: Ducknetservices Phone: 714-898-1917 Email: barbaraduck@ducknet.net
The palest ink is better than the best memory. - Chinese Proverb
Barbara, do you write directly the line item information to EZClaim's access tables?
As for knowing all I need to know about 1500 forms .. not heard enough yet! Anyone know what the rgb values of flint red are? Maybe I can create the form on a color laser ? ( though I read also they want the form with the original back printed data as well! ).
What I do is run SQL updates, this is easier and leaves the tables clean and provides me with a superbill as well with all the codes. If you go to EZ Claim's site you might gain a little more insight and it might be more than what I can put in a post here.
One of the reaons I like EZ Claim so much is the no-nonsense approach and GUI. You can download a 30 day trial. Everyone that I have switched from any other accounting software has been very happy. The first tab of the screen is the top half of what is filled in on the 1500, tab 2 is the 2nd half, again right to the point. They have both a simple and advanced version. I believe the current 30 day trial still has the old form, but I am working with the beta with a choice of either form thus far. Check out the "print image" and create a few and that might make more sense. This is what is batched and uploaded to a web server for claim scrubbing and processing.
I think if you download the software and go through the screens and help it will shed a lot of light on what we do here to bill. It also does EDI billing and they have clearinghouse services available too, so just download and read and see if this helps. The website has a ton of information too. This is not patient accounting, it is a "billing" software program that has a pretty simple GUI and gets the job done very well. Any practices I have trained on this software catch on real quick and have been very satifsfied. I am an EZ Claim distributor being I integrated with their software. I felt they did such a good job on the software that there was no reason for me to reinvent the wheel, but rather integrate. I know the programmer and he does a very good job.
I looked at one of EZClaim's demo movies and it showed the HCFA-1500 form on screen - not flint red but Barbie Pink!
I've download EZClaim's software and attempted an install with no luck though. Oddly, it creates an Access database which is somehow locked and can't be deleted, or even accessed by their own software!
Might give it another go on another PC.
You can go right to the program file folder and open the access data bases where the data is stored. They are not encrypted so you should be able to open and view easily, you just don't have access from the front end to the tables to keep users out for obvious reasons. I have even changed the table properties on occasion as the VB front end is not a problem in this respect with any wrapped code.
Dig around through the help and/or the website and you will find the mappings. I can't remember exactly where they are, but he has put them in there somewhere for reference. It's been a while since I have to reference the mappings so sorry I can't tell you exactly where they are. That will help you figure out the fields from the front end to where it maps to the back end. Create a print image and you'll see what I have been talking about as far as the text image without the red or pink 1500 form. You can also print the data wtih the form in black and white, which is acceptable with many carriers as well if folks are still printing them. Don't worry too much about the color and the demo software on the site may have done a little altering of the shades too. I have to watch that myself with flash when I over indulge in some of the graphic settings.
Most everyone I work with is doing the print image and uploading to a clearinghouse, so there's very little real printing going on, other than to occasionally print one for some HMO for encounter data, and most of the HMO/IPAs these days in California anyway also promote the use of a clearinghouse as well as the insurance carriers, to the point where they pay for some clearinghouse services and it's free for the physicians, just so they get a clean claim with the proper 1500 data in the right places. It is definitely not as simple here as it is in your neck of the woods.
Al Borges, M.D.
● Oncologist in a Small Group Practice in Virginia
● My website URL: http://msofficeemrproject.com/
Thanks Al for the nice comments. EZ Claim can be what you want it to be and the pricing is not bad either. For the average small office with adding the multi user module and a couple instances connected to the data base with the Advanced version, you can get started for under a thousand, so that is not bad at all. They also have the nice additional module that will export to Quick Books too. I started a few years back with EZ Claim with just a simple demograhics update to avoid redundant data entry and it has grown from there. I was the orginal integrated EMR and if you look at their website, you will find others who have followed suit. The "free" clearinghouse, Office Ally likes EZ Claim too as it is easy for them to instruct the end user on using the "print image' for uploading to their servers to scrub claims. It's a lot less hassle for their training folks and programmers to work with as well. The 30 day trial has all the modules activated too so you can evaluate and see what modules you like and/or need.
They do a real good job and keep it simple too. My orginal EMR did integrate with Medisoft and I knew there had to be something much simpler and easier than what I was doing with the ODBC drivers and the Advantage data base and EZ Claim did and does fit the bill. What I did with the superbill is run an sql query to post and update in EZ Claim with an option to "bill now" or "bill later" to allow the office staff the ability to read and review the superbill information first before committing if they want to check the coding input from the MD before sending to EZ Claim. They can always open EZ Claim directly and change items as well. I also brought in reports from EZ Claim data so when the patient is at the front desk, it's easy to check and see any unpaid or pending claims via the Scheduler module. To print a copy as a receipt for the visit I made it easy for the front desk too to open the appointment and print the superbill for the visit, so no need for the front office to have access to the EMR module or EZ Claim. This helps keep cost down too in the fact that everyone in the office does not need a copy of EZ Claim and I suggest for a small office only 2 or 3 pcs need EZ claim modules and only the MDs and MAs need the charting module.
The Scheduler module will create superbills too, but for obvious reasons, it does not input the diagnosis to the chart as does the charting module. I have been able to do some creative work here too with data transfers in the fact that I have taken the ICDs from EZ Claim and imported them into the charting too, so a new client starting with my EMR that already has ICD diagnosis codes in EZ Claim has instant diagnosis history, and demographics update both ways so the first time the charting is open all the demographics update to and from EZ Claim too, so a new patient entered in my software populates EZ Claim demographics so the biller does not have redundant data entry. It helps when starting from ground zero. I also make the CPT codes entered by billing personnel available in the charting available for look up tables in the EMR charting. I use Jet replication with a couple dlls in my EMR modules so information can be added when one is away from the office and can synchronize data upon returning and connecting to the network, but I leave the EZ Claim tables out of this and keep them in their orginal state and work with copies instead to avoid any potential corruption there. Any superbills created when one is away from the office and not on the network default to the "bill later" category so those are available for review before they are automated over to EZ Claim so this gives the physcian the opportunity to create a superbill, let's say while at a nursing home, and then return and capture the information in a process without having to rely on sticky notes or small pieces of paper and helps on not missing items that may otherwise get over looked or forgotten by the time one gets back to the office.
This is actually how some of this came about as the physician and his biller had this scenario going on with her making sure everthing was there let's say in the case of billing for extended services, so now he uses the EMR, puts in a template, modifies and adds to fit the visit, and then does the superbill and the biller can go back to the chart to make sure there is a nursing home visit on file so all bases were covered for the CPT, so there's a check and balance here. Yes, it is a little extra work to haul around a portable notebook or tablet for the physician to enter while at the nursing home, but in the long run everythng is documented as it should be and it eliminated those "coding conferences" between the 2 and everyone is much happier and all nursing home visits are documented the way they should be.
The only requirement I had to put in was to require default mappings for program installations. I tried to allow additional mapping orginally but the end users messed it up and didn't get it, thus I went back to hard code and it is actually much easier for the end user to work with. I have to lock everyone out of the back end data base tables for a client/server multi user environments on my modules of course, so there's quite a bit of code that runs when the software is opened to accomplish this so there's no way a user from a workstation can get to any data tables or the audit tables running. It's pretty much the equivalent of an MDE, but with folks using various versions of Office, I had to go with an mdb front end with beefed up permissions - almost none. I keep the automation on my side and keep EZ Claim in its orginal state but bring the information entered there into the EMR and send coding and claim information to EZ Claim from the superbills.
Overall in working with the software it has been very good. EZ Claim did such a good job with billing, there was no reason in the world for me to have to go back and re-invent the wheel. As for the reports in EZ Claim, they use a Crystal Reports module added to the software and they update the website with new available reports all the time and have a ton of pre-formatted reports to select from. They also offer support so for items that get a bit more complex from what I support in the EMR, that is also available as well as the Q and A forums too.
Ok so that's enough code talk for today, have to switch gears here and go over to Core 2 training for the day!
Graham,
Before you think the claim form is easy, you should also know that it's not a straight up and down print out. There are variations by different insurance company that you need to accommodate too. For example, in this country different insurances issue different identifiers for doctors which need to be printed based on who it is being sent to. Now, part of the form change is to accommodate the implementation of the National Provider Identifier (NPI) which is supposed to be the universal identifier which all must accept. Of course, that was the purpose of the UPin too (Universal Provider Identification Number)...but that never panned out although this time there seems to be a lot more weight and legislation behind it. Anyway, the point is that there are twists when printing depending on whom you're printing to, and also whether it is primary, secondary, etc. so you'll need to accommodate this. Think about it this way: when the HIPAA-mandated ANSI837 electronic claim standard was released it was supposed to be the one true way to achieve the less well known part of the HIPAA law, ASCA (Administrative Simplification Compliance Act). Within a year over 400 "companion" guides had been issued by insurance companies and other entities...
FYI: HCFA-1500 became CMS-1500 because of the change of the government department name. The versioning is expressed in parentheses after the form name but all of us vendors tend to like the HCFA vs CMS. The versions are: HCFA-1500 (12/90) and CMS-1500 (08/05) based on the date approved.
In this vein the UB-92 is also known as the HCFA-1450 - but it will also be updated with a new version next year.
Fun, huh?!
Patrick Hall, EVP Practice Management
e-MDs, Inc.