I am running Openemr version 6.0 Patch 3, PHP 8, Ubuntu 20.04. I am U.S based and looking to add automated patient verification to my billing work flow.
I have been using Availity for batch billing, but would like to add a more automated way of Patient Verification. I know the Office Ally one works for patient verification, but since I use Availity as my X12 partner for batch billing, I thought it might make more since to use Availity for patient verification to keep everything on one platform. Has ayone got this to work for Availity?
If not, would a mixed solution like using Office Ally for Patient Verification and Availity for Batch Billing be compatible?
We use Kareo for billing and associated tasks such as patient verification. We keep the billing separate from OpenEMR because it’s a heckuva big application in and of itself and billing is crazy complicated. I will probably do more with OpenEMR on billing to prepare the information going to Kareo to take advantage of new and revamped billing features in OpenEMR as I learn how these features work and how they can be utilized efficiently.
–RBL
I appreciate the information. I think I will continue with Openemr billing. I am able to verify ~ 50 patients at a time with Availity. I basically take a spreadheet adding the information in tabular form with the columns arranged the way availity likes them. Each value for a patient is separated from the next piece of information by a comma. I then paste them into the availity tool for multiple patients. It then shows me all the eligibility which I compare to the EHR for accuracy. Once confirmed I just have to make sure that each patient is correctly set to the the insurance company for the primary insurance. Hopefully, I will soon be able to automate this portion of the process for an easier and less time consuming workflow.
Thanks. Sorry one more seperate error came. The claim went thru due these recommendations for one payer but another one Aetna rejected -Reject Message:
The HL ID is not sequential. Segment HL is defined in the guideline at position
0010.
Reject Message:
The HL segment with ID=2 is marked as having children, but no children found. Se
gment HL is defined in the guideline at position 0010.
This is a pediatric practice with the patient being 2 months old. I can’t even find documentation in Availity EDI guide about HL segments. Any insight would be greatly appreciated.
HL segments are hiarchial levels. An HL segment will state in it’s elements if it has a child HL. For the type of practice you’re working with you’ll have mainly a patient loop (rather than just a subscriber loop). You’ll see an HL32230
The 3 means the 3rd HL in the EDI. The 2 goes back to the parent HL and says this HL is under the parent, and the 23 says it’s a dependent. Finally the 0 tells the parser if there are children as in other child loops with-in the HL area.
Because it’s talking about HL 2 I know that it’s the 2nd HL in the EDI, you’re Segment probably looks like this:
HL21221
the 22 says it’s the subscriber and the last element being 1 says there are children. So the parser is expecting this HL to have a child which would be the start of the 2000C loop.
Now in insurance terms, this patient is probably not the subscriber to the insurance, so you should see the subscriber being the mom or dad and then patient being the final loop or the 2000C loop.
Now, if the patient is the subscriber, you won’t have a patient loop 2000C and that HL I spoke of with the 22 should end in 0.
I like to brag about my parsers for my system. I believe this would be allowed in the system because I don’t care if an HL is saying there are children or not, I see the 23 and handle it as it should. Then I rewrite the HL segments properly before going out. I have a process that counts the HL’s to make sure they are numbered properly and fixes the child element to reflect properly.
To me it sounds like something isn’t setup right when create the claim. I’d look closely at your 837 and see what’s missing. If a patient loop really was supposed to be created, you might be lacking a claim loop too. Or it simply could be your HL loop was created wrong. That would surprise me though because more people would have this exact same issue.