I run a clearinghouse and I want to get more involved with openEMR, while I don’t know much about openEMR yet, I would love to work with you and help with claims. I can promise better support than availity (I send to them too and dread opening tickets). As for login errors, if you had something similar with me it would only last for as long as it took for me to figure out what went wrong, and I’m just a phone call or email away.
Brad
1 Like
Hi @brad
Good to hear from you.
Will you/ do you have automatic claim submission through an SFTP site? OpenEMR is capable of automatically uploading claims via SFTP to the clearinghouse. And that login to the SFTP site is what the OP referred to; manual claim uploads don’t make problems.
- HT
1 Like
I haven’t setup an sftp server yet, that wouldn’t be a problem if I need to. Today, I have a windows application that scans a directory and uploads the file then downloads the reports that are available. I’ve been holding off on the sftp server for the cost.
However, I’ve been considering writing a module for open emr to upload directly using my rest api’s
Let me ask you a couple questions, which may reveal my ignorance of claim file processing.
Availity (and as I recall Trizetto) have custom response files in addition to the standardized- format ERA (and other purpose) files, that talk about why claims are rejected by either the clearinghouse or the payer.
To my mind, part of the benefit of the EMR automatically uploading files from the clearinghouse could derive from automated interpretation of those INCREDIBLY obtuse response files. My questions: 1) In your clearinghouse, how do you/ would you handle those messages? And 2) why on earth can they not be written in plain English?
I can see that if a clearinghouse merely passes on response messages from the payer it wouldn’t have control over those. But what’s up with the alien language from the clearinghouse responses?
- HT
Yes, clearinghouses send really crappy hard to read reports back to the user. I’ll start with a long drawn out explanation, CMS hippa mandates the files be in X12 edi format, this is where the hardness and goodness starts.
X12 Files as follows:
999 - this is the file acceptance, and from my experience in the edi world, one of the most annoying. This file comes back as accepted or denied with a very bad message. something like. error line 21 segment nm1. Something like that not word for word but like that and terrible. It leaves the user really wondering what went wrong and kinda a helpless feeling. Especially because if you’re not an edi expert you end up calling support and waiting on hold for hours. Even edi experts have trouble seeing the problem sometimes. Me included. A rejection will make every claim in the file never make it to the payer or clearinghouse.
If the file is accepted, the 999 is short and says accepted.
277 - this file is a bit better but still hard to read, it tells you in codes what is happening to individual claims. It will tell the user if the specific claim made it into adjudication or not. Again, leaving the user with questions on what the error really means. The clearinghouse will create a 277 on it’s own, with messages and errors from their system. when the clearinghouse passes it to the payer (medicare) then they clearinghouse matches the 277 back to the claim, and resends the 277 with the updated information from the payer. Obviously the clearinghouse has no access to change those messages.
Finally, on the 277, there are certain statuses we have to pick from, so giving a good detailed information in that 277 might be difficult.
835 - this gets passed from the payer to the user, the clearinghouse does not have anything to do with the generation of this report.
So finally, alot of clearinghouses will pass back human readable files to the user via the sftp server. These reports are their attempt to make those reports readable. I would think, if the user is downloading reports, they would want to import them into their EMR and wouldn’t care about human readable reports.
Other clearinghouses (me) have a portal that lets the user see the errors in human readable format and search on claims to try to figure out what really is happening. I think that is the bridge to systems that don’t handle the reports well and customers needing to figure out what the heck is wrong with their claims. This goes to all levels from file acceptance, claim acceptance, and remittance. For me, I don’t usually send back 999 rejections, I have written the parsers so that if I can read the file, I’ll extract what claims I can and return the bad ones on 277 rejects, that way we don’t hold up an entire batch of 100 claims for only 1 claim missing a patient birthday.
so to really answer your question, the alien languages are required under HIPPA but it also gives us all a standard that the PMS, clearinghouse, and payer can read. They are not made for humans to just “read”.
2 Likes
btw, I’d love to chat and do a teams meeting explaining how my system works if you have time.
Hi HT,
Brad explained the EDI claims process very well. The EDI files come in human and computer friendly formats. And I use both of them.
I’m an old software developer turned into a psychiatric nurse practitioner and own my own practice. OpenEMR is perfect for me because I can access the data directly for things like management reporting, disabling the portal when discharged, and automatically posting those cryptic EDI files to the patient ledger.
Wring the EDI interface was not easy and some transactions still need a little manual intervention because while the EDI standard is common, the contents from each payer are not always consistent, but most transactions are clean. OpenEMR does have a feature that allows you to directly post the 835 data to patient ledgers and it works well.
I also use Windows to automatically SFTP X12, 877, 835, and 277 files to/from my clearing house. At the end of each day, I create the X12 file and copy it to my upload folder after the OpenEMR log shows no errors. Sometime I’ll forget to justify a billing CPT4 code with a ICD10 code. Then a Windows task uses SFTP to send the data to my clearing house. I also had to create that process/script. These things are not for non-IT/Development people.
If Brad can do this for you, you may want to consider it. It’s a lot of work. My work is all custom to my environment and uses older technology (I grew up in the IBM world and can only muscle through PHP/Java and have also customized OpenEMR. I use SQL server 2000 (yes it is 2000 not a typo and it still works very well) and Visual FoxPro to interface with OpenEMR to accomplish what I need), but he runs a clearing house and should be creating a module with newer languages for all to use.
Every time I automate something, my day get easier. It lets me focus on prescribing medication, not boring repetitive tasks. My programs run while I’m sleeping 
1 Like
there’s also a very nice EDI module under Fees->EDI History
it wouldn’t take too much work to parse the 999s or 277s into an understandable pass/fail type of human readable report
1 Like
I would love to demo my system to you sometime. I used to work as an architect at a clearinghouse, 6ish years ago. I decided to write this system I use today completely from scratch on my own.
I’m still a startup and completely funded by myself as well, so I don’t have money yet for business analysts or something similar. Everything, that I have in the portal today, is just from what I remember old collogues complained about or what I could glean off of a facebook group.
I wouldn’t expect you to use my system, but I would like to brag to another developer that understands what actually goes into all this. Plus I would love advice on how to work more with OpenEMR. I haven’t done PHP since college, which was when php first came out, so my php skills aren’t up to par anymore. So I have a little anxiety thinking about trying to get back into php again. Plus I would like ideas on what to add to the clearinghouse portal that would make it cool to other users that actually use clearinghouses.
My system is written in .Net Core 6 running on google cloud’s serverless environment. The portal is written in the Angular 13. I sadly went with sql server for some of the db stuff. I say sadly, because I made that decision before deciding on the cloud to use and sql server is dang expensive. I should of use Postgres or Mysql. My other reason for picking sql server was because I’m a sql server dba and know it well. I’m not sure I could manage the other options as well. Something else to learn. The processing system itself though run on a nosql database MongoDB. It’s a pretty cool database.
Brad
1 Like
Sure I’d love to see it. I see patient’s Mondays through Thursdays, so Fridays are generally good. I’m on the East Coast, so you know what time zone I’m in.
1 Like
I’m open all day Friday, send me an email with available times, brad.sharp@claimrev.com and I’ll send an invite for Friday.
1 Like
This is great! Maybe one of you could record the session and post it to YT and the link here?
If you’re not familiar with wiki markup, give me the URL of the video and I’ll add it to the OpenEMR wiki.
- HT
I have a demo/slideshow on youtube now. I put it together awhile back and it’s pretty out of date right now. I’ll try and create a new video in the next few days. I’ll post that link here when it’s done.
1 Like
V cool. We don’t recommend clearinghouses to our customers but could include any resources you may publish in the list of options they might want to evaluate when they’re picking a clearinghouse.
Plus publishing it here on the forum is really good exposure!
- HT
Thanks for helping me out, here is the link to the youtube video
1 Like
I’ve been watching videos and trying to think about integrations for the past couple of days. I know the sftp option is there to send claims from a particular folder. However, there doesn’t seem to be a way to download reports and import them automatically. I watched a video on importing the 835 and wondered if there was a way to access that api some other way.
I had a few thoughts. If I created a .Net Core web application that ran on the same server as OpenEMR. It would be configured to auto download the reports into a configurable folder. I wasn’t sure if I would be allowed to create a web app, I wanted to find out from here. I’m also not sure how hard it is to install said web application on the servers. I’m a programmer and my linux abilities are limited to making linux containers work to run my code. I’ve avoided doing direct installs, I assume it shouldn’t be difficult though.
So, if the service is there and downloading reports to a folder, then if I use an api key, is that an option? I could hit the same urls as the import 835 screens. I didn’t know if this was remotely possible. Maybe somebody has a better idea? I thought about trying to build it in the PHP code, but PHP isn’t my thing and would take me a very long time to figure out.
I’m still looking for where to import 277 files. I got distracted looking at fhir api’s.
Next, if I get any traction from users, I would like to access the appointments fhir api and build a Real Time Eligibility option. This wouldn’t be right away and if I had enough users interested in it, I’d start designing the process.
If anybody would be interested in participating, I’ll give the openEMR community unlimited professional claims at $40 per provider. I would need to talk about your payers and if sending to Medicare, I would need time to get a submitter ID from your MAC if it is not Novitas. If I was charging more a month I would just pay to send claims and then get the submitter id, but since the price is so low, I need the direct send setup first. With Novitas, it only 2 took weeks to get it.
1 Like
I have created a module now that interfaces directly with my clearinghouse.
This module will watch the x12_remote_tracker table and send the file when it finds one waiting. Then every 4 hours it will call to my api and download 999/277/835s and place those file in the respective “f” folder, for example “f277”.
There is also a menu item to view claims submitted to the clearinghouse. Today you can search by patient and send date. I can possibly add other search options as requests come in. This screen will also show you the error messages and status of the claim on my end. I have attached an image at the end to show what it looks like currently.
As I get traction and users I’ll start making regular updates and get doing more stuff. Connecting to the new appointment event is my next task, in that will get the patient and run eligibility for them.
Right now, I plan to keep the results in the module and display based on a json response I’ll send back. But I’m up for suggestions as users start using the module.
Here is the package on packageist
Roadmap will include:
- Eligibility
- Insurance Discovery (find unknown insurance)
- Prior Authorization (the automated processes can take hours to get authorization as opposed to weeks)
And here is the current picture of how claims are displayed. Again, if I get customers using it, I’ll be happy to make what changes for what you guys need.
3 Likes
Thanks for sharing with the community.
Suggest you add a minimum OpenEMR version to packagist requires. Then create package against the release version and update package version as OpenEMR releases new if required.
If I can figure out how I will. So far I haven’t found any examples that look different than what I have right now. but as soon as I figure it out I’ll make the changes.
Actually the min version of openemr does show in conflicts so not an issue.
When creating a package from main, if you add a version tag to mark the release, it should show version in packagist.
Take a look at how I manage my fax/sms git. May not be best or only way to manage but the way I ended up.
2 Likes