Generate claims 1-per-insurance, Billing Tracker

[ken (Ken Chapple)]

@brady.miller @stephenwaite @htuck I am working on a system where we would like to better-automate submission of x12 claims to insurance companies directly. In this case, Insurance companies will 90% of the time will act as their own x12 partner, which may have different formats and specifications. The other 10% may be paper claims. The current billing report just submits one batch, and generates one file, unless you manually go through and check the boxes to generate different files. We would like to be able to generate the proper batch in a format that is one-per insurance company, or a batch of HCFA forms in the case of no x12 partner specified for insurance. I would like to add a Billing Tracker page, where these generated claims files would show up for download, or they would be picked up on the back-end by a CRON job and sent via FTP to the x12 partner. A status would be shown the file has been downloaded, sent to x12 partner, etc.

Is this something that the OpenEMR community would find valuable, or would this be better as a module?

Are there other features that might be useful in this area?

[stephenwaite]

hi @ken, that would be a very nice addition for the community, I know @sjpadgett would really like to weigh in as well.

thinking that the most effective way is to create a batch per X12 partner since can cover many ins cos in one swipe

edit: currently the X12 selector only works on previously billed items

thank you

[ken (Ken Chapple)]

@stephenwaite

thinking that the most effective way is to create a batch per X12 partner since can cover many ins cos in one swipe

Totally. What about the case of paper claims? Shouldn’t they be batched by insurance company?

edit: currently the X12 selector only works on previously billed items

Can you elaborate on this? Is this a problem you forsee?

Thanks

[stephenwaite]

sure, paper claims could benefit by being batched

the heart of this matter is also combining appropriate services into one claim as well so that the claim form box is fully utilized and the 837s are improved

Billing multiple days of service

ok, it’s actually pretty involved since the hcfa function was simply built for 1 claim per encounter and the remodel would have to sort through all of the items in the billing manager and then see if those encounters could be on the same claim form same pid same service facility same billing provider same referring provider same accident date and accident type if appropriate and then sort the items by date of service and create a new claim if greater than 6 items

ps the X12 selector not working on new service items is a known bug in the billing manager

[ken (Ken Chapple)]

the heart of this matter is also combining appropriate services into one claim so that the claim form box is fully utilized and the 837s are improved

I guess I wasn’t thinking of batching claims, but claim files. So from a practice standpoint, every claim going to the same insurance company could be printed and faxed together, rather than manually clicking each box and generating individual files for each insco batch. I’m not clear why an OpenEMR practice would benefit from more than one encounter per claim? I get that it would be less work for the claim recipient.

I’m not sure what you mean by the “claim form box is fully utilized” or what improvements are needed in 837s?

Ken

[ken (Ken Chapple)]

OK, I just read that whole thread you posted. Makes more sense. But why not use your proposal of faxing through a service and avoid printing? I assumed that’s how it would work.

[stephenwaite]

like we only use 1 line even if there are multiple encounters that could be billed on the same hcfa

[stephenwaite]

right, it’s just more efficient and less claims which may not matter to some

[ken (Ken Chapple)]

Is it possible to render full PDF of a HCFA programmatically and fax using a service, or does it have to be printed on an official HCFA 1500 form? OpenEMR just generates the “overlay” right, so in order to automate that, there would need to be some PDF/data combining process.

[stephenwaite]

hi @ken the PDF is already built in

[sjpadgett (Jerry P)]

Many if not most insurance co. will accept this preprinted form. It’s medicare that requires the form fed preprinted to support their 1910 scanners!

[stephenwaite]

most medicare contractors don’t accept paper claims

[sjpadgett (Jerry P)]

I guess none of this matters anyway if we don’t get cert done!