Advanced Billing UB04/CMS-1450/837I Claims. This will release in version 5.0.1

Well maybe not final! I put up the restyled Billing Manager so @robert.down maybe would want to look at so you may see results while reviewing styling code.
Unfortunately bootstrap tables do not lend well to page layouts and I had to strike a compromise between html tables and bootstrap (Should convert to grid but ran out of steam). I can add a container responsive div if we want the billing detail table(bottom) full screen but, I landed on entire form in one container. Just looks better to me. I also set up button groups for the three action areas(X12,HCFA and UB04). Consolidating these seemed reasonable.
Code is cleaned up and ready for PR hopefully tomorrow.
Thanks

Hope you guys don’t mind that I looked at it considering I’m new to OpenEMR. I looked at “patient” Jason Binder DOS 7/22/17 and clicked edit on the UB04. I’m assuming that certain fields will auto populate (name, DOB, etc) but some other fields should have an optional default setting (ie box 4 should default to 831). I’m sure you’re aware that you will need a table for Revenue Codes. In box 6 the through dated auto populated to today and would not accept a change of another date. I noticed the Total did not auto calculate. The date field in box 74 needs 2 more characters for a full date. When I clicked on either PDF the claim did not show. After I clicked save, exited out of the claim, then went back in, the changes I made were gone.

I assume you have access to the NUBC standards for filling out a UB04? The newest standard came out 7/1/2017.

I liked see the whole form. I haven’t noticed yet but does OpenEMR have a CMS1500 viewer?

1 Like

@MFCmanager Not at all and I look for any suggestions. Concerning totals, the edited form does not total charges because charges come from the billing fee sheet so any changes there are up to the user as I don’t intervene.
I have made provisions for a default claim by payer which is set up in insurance company under Practice menu. Though I don’t do anything with it now it is intended to pre-populate those vendor specific blocks when claim is generated. I’m not sure if it is needed or not.
Depending on browser setup a pdf may or may not open automatic but will simply save it where you chose. This is Chromes default behavior and I.E can be troublesome but, I’ve tested the pdf yesterday on all browsers with no issues.
When generating pdf from the claim edit it should not mark claim as cleared or create a new version of the claim and I have not had an issue with claim edit persistence, however, if claim is generated using billing managers ubo4 (or x12) pdf and you select to clear the claim then the claim will need to be reopened and a new claim version is created and the previous claim version is archived thus losing edits.
Based on Medicare Claims Processing Manual rev2017 the date field is only 6 digits for a date format of mmddyy on paper claim but, x12 requires yyyymmdd which I allow for, not sure what I should do here.
I will add the revenue codes and your other concerns before I commit.
Thanks for your input.

1 Like

Just seems I’m working the wrong end of the line! I’m trying to do institutional billing w/o the core institutional support that leads to billing. So for revenue codes I think I will modify codes setup to allow adding the appropriate revenue code to the HCPCS code it belongs with.This way a fee schedule can be created for different charges per code and relieves the coder from deciding at claim time the revenue code. Or could put lookup in fee sheet!
Any thoughts?

1 Like

@MFCmanager Sorry forgot to answer your other question concerning CMS1500. You can create a pdf with the preprinted form but to add/edit some various blocks for 1500, encounter claims need to be enabled and then you can create an encounter form for the misc billing options.

1 Like

WOW…NICE (Would love to see a 1500 form too)
But I see what I think might be an issue.
Some fields should either be not editable or if Editable should sync back to Patient demographics or point of origin . For example Name, Address, Insurance, Record, Payer etc…
If not careful the Billing Coder might inadvertently make changes that might get rejected.

1 Like

1500
http://www.nucc.org/images/stories/PDF/1500_claim_form_instruction_manual_2012_02-v5.pdf
http://www.nucc.org/images/stories/PDF/1500_claim_form_map_to_837P_v3-2_2012_02.pdf

UB
http://highered.mheducation.com/sites/dl/free/0073520896/836077/ub04.html

1 Like

The 1500 is a possibility. I envision form edits will be controlled by a master template, setup in Practice->Insurance Companies that will allow setting defaults and restricted blocks for each payer. This will help with validation due to different claim procedures by various payers.

Also my form is html so thanks for the links though.

1 Like

@MFCmanager Just wanted you to know there was a bug with a new claim edit that I will sort out. Thanks for bringing it up.

Just so you all know, this thread/project is linked in the core roadmap: http://open-emr.org/wiki/index.php/Roadmaps#OpenEMR_Project_Roadmap

If you’d like to, you can adjust the top post in the thread to be similar to the other linked projects. This is a great example: Intelligent Chart Summarization

-m

I’ve put up on my demo server a version which I feel comfortable enough to release soon. I’m sure there are particulars that hard core billing folks may find wanting but, I am open for any suggestions to improve use. Not much that can’t be edited in claim form to make module usable.

Some points of interest in this version:

  1. Fee sheet has been modified to allow assigning revenue codes to items.
  2. Codes/superbill also allow adding a revenue code to items with intent of auto populating fee sheet/charge sheet.
  • Looking to add auto save of revenue code to codes when assigned in fee sheet but doesn’t exist for code in codes.
  1. Claim form edit now has lookup hints for most all codes needed in UB04 i.e. value codes, occurrence codes, revenue codes, status codes and others. These are accessible by typing search term or double clicking appropriate blocks.
  2. Edit version histories are maintained with claim version history.
  3. Claim edit now will allow reset of edited claim to current fee sheet version. Looking to maybe allow overwrite/update of current edited copy from fee sheet.
  4. Form highlights any fields edited in current edit session. In case one forgets:).
  5. Help button with form general help items.

More work could be done in fee sheet for save and persistence of items. The way the form is designed, DOM is not updated when new items are added via html thus, until refresh, DOM events are out of date.

Patient Jason Binder has a fee sheet set up.

1 Like

Thanks to OEMR and @brady.miller we have a beginning for Institutional billing. I hope this proves to be useful and there will be more enhancements to this module. Below is commit:

Jerry

1 Like

Thank you @sjpadgett for this awesome feature!!
-brady

Update status for testing.
Initial X12 837I professionals test claim for a series of home health visits was submitted and accepted by clearing house. Looking to do outpatient surgery next so if anyone has a scenario in mind or a different bill type, let me know.

2 Likes

Add me to the bucket list. I want this update!!!

Ahh I see, coming in the next version!!! awesome… Waits patiently!!!

1 Like

Hi Anthony, curiosity leads me to ask if you have a certain practice discipline in mind? Besides billing, what other institutional piece would make an immediate impact on OpenEMR in your use case?

TO be honest, I need to put some thought into that BUT I have also thought about a wrapper for the application in mind. We currently use an application that makes php apps into exes. We have ours pointed to our server and which we will no longer be using soon do to us just learning our server is not HIPAA complaint.

But what this positive effect for many practices and other facilities brings is NO SHOWN LINKS, no right-clicking and selecting view source and view other sources. It’s fully encrypted and keeps data safe from within the openEMR software for those running local servers as we probably will be.

Not to say “CLOSED SOURCE” but just like earlier, I needed some info off a website for a certain set of words but couldn’t copy it, I right-clicked, viewed the source and copied from within the code of the little section I needed. Can’t have that in openEMR and for sure can’t have that kind of access on dozens of computers in an office other than IT needing chrome access to test pragmatics. So it’s still open source available but with a bit better security to the application overall. Meaning do your testing but production should be from the wrapper app. Looks a lot better and professional for a workplace than browsing through looking at links at the top.

I also find that some sort of integration with at the least Office Ally is much needed. Some sort of SFTP connection for when you generate your claims, it can automatically submit via sftp without even having to click on anything else. Thus this is AFTER you review and assure the claim is ready

You could wrap the software like RocketChat does with Electron, but I am seeing more and more web-based EMRs these days for reference!

See GitHub - openemr/wkhtmltopdf-openemr: Dependencies for wkhtmltopdf support in OpenEMR for addition install needed to use this feature.