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

billing

#21

@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.


#22

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.


#23

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


#24

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.


#25

@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.


#26

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


#27

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.


#28

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


#29

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


#30

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.


#31

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


#32

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


#33

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?


#34

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


#35

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