Eligibility Checks & Clearinghouses

sjpadgett · February 28, 2019, 3:07pm

Yep, nothing wrong with the the 270 batch except I want to give some control over segments back to the partner set up. We also need to setup for SFTP delivery to companion what will now be batch download, RealTime MIME/SOAP and the SFTP. I suppose if we are going to do this we should probably do it all the way. Agree?

sjpadgett · February 28, 2019, 3:09pm

Yes. Assuming you are using the Request Eligibility button. Download should show the entire transaction.

sjpadgett · February 28, 2019, 3:30pm

@albanyeye
This is a log from a failed OA transaction: elig-271_officeally_2019-02-28_10_24_58.txt (1.8 KB)

And this one is where I emulate a successful transaction: elig-271_officeally_2019-02-28_10_23_32.txt (5.4 KB)

The first is what i’m trying to figure out why the AAA 79 error. Think has something to do with NPI’s or NMI id’s…

albanyeye · February 28, 2019, 4:07pm

That looks great!
My donwload does not look like that.
I ran this on 5.02 after upgrading database and application from 5.01
Here is a my file. I changed the paient name and ID etc.elig-271_officeally_2019-02-28_11_03_59.txt (12.9 KB)

sjpadgett · February 28, 2019, 4:47pm

That’s a bug that I fixed with flushing the buffers before a return. You should have the fix but may be something to do with Windows vs Linux.
Let me revisit and i’ll post another patch.

sjpadgett · February 28, 2019, 5:50pm

@albanyeye Try this new patch although not sure why the buffers were over run in previous but sometimes I try to get too clever and shoot myself in the foot So let me know if this fix works.
eligibility-patch-2.zip (15.7 KB)

sjpadgett · February 28, 2019, 5:52pm

@robert.down Is it okay to do this in this forum category or do you want to move to the Development forum thread?

albanyeye · February 28, 2019, 6:07pm

No problems
This time i got up to IEA segmentelig-271_officeally_2019-02-28_13_05_05.txt (518 Bytes)

This seems incorrect?
ISA001234567
infact the whole ISA segment is different for me
You have: ISA001234567 00 ZZ155214 ZZOFFALLY
I have: ISA001234567 00 ZZ123456789 ZZ330897513

Even if I replace 330897513 with OFFALLY, it does not make a difference

sjpadgett · February 28, 2019, 6:32pm

You’re x12 partner is most likely missing user and password in the ISA02 and ISA04. I’ll PM a screenshot.

sjpadgett · February 28, 2019, 8:45pm

Some Fyi’s
When using the new oeHttp client you can turn on a debug proxy port for tools like Fiddler (a great Http debug tool for watching Http with cURL or sockets). It is used by including setDebug(proxy_port) in your request chain and is set in edi.inc around L-918. To use just uncomment as below.

$response = oeHttp::bodyFormat(‘body’)
->setDebug(‘5000’)
->usingHeaders($headers)
->post(‘https://wsd.officeally.com/TransactionSite/rtx.aspx’, $mime_body);
$formBody = $response->body();
Remember the proxy port must be available or request will fail…

Also the following settings in X12 Partner setup now have meaning again in 270 message.

ID Number (ETIN): defaults to 46 but can require something else like PI for Payer NMI
Sender ID Qualifier (ISA05) and Receiver ID Qualifier (ISA07)
Acknowledgment Requested (ISA14)
Usage Indicator (ISA15)

stephenwaite · March 1, 2019, 1:07pm

with slight edits to the 270 as mentioned above and referring to the guide was able to receive a 271 (batch submission means next day report)

one bug is that filtering by X12 partner doesn’t work so you get a corrupted file with other insurances mixed in, is that something you’ve noticed?

albanyeye · March 1, 2019, 1:45pm

Stephen
Will your 270 work with 5.01?
Can I try it with Availity? Georgia Medicaid?
I’m trying to find 270 /271 Georgia Medicaid companion guide

albanyeye · March 1, 2019, 1:51pm

stephenwaite · March 1, 2019, 2:01pm

sure, the batch method will work once the edi.inc and 270 files are updated to the specs

looks like georgia medicaid specs are similar

sjpadgett · March 1, 2019, 2:09pm

Hi @stephenwaite

From where? OA.

Not sure I understand. The x12 partner filter can result more than one insurance company depending on what insurance companies are assigned to any given partner.
I have noticed that duplicates are being resulted which shouldn’t happen unless we plan to check eligibility by say procedures and/or other specific criteria.
Medicare, Medicaid and commercial insurances will need to be handled differently and using a pass through service like OA will require adjustments to the 270 depending on service type and company so in the end, yes i’ve noticed filtering needs to be addressed and plan on sorting that out once i’m successful resulting some RealTime transactions. I’m assuming you want to filter by insurance companies as well, where batch will consist of single partner and single insurance company. Which makes sense.

I’d love to see the 271 resulted file so I can test against new and old 271 parsing and combine into one engine.
Also will need to add to the eligibility tab all the eligibility info returned besides just co-pay and deductibles and allow a report to be generated from the tab.

Right now i’m trying to get past a specific AAA error code 79 using OA. Something to do with 2100A NMI03 and/or NMI09

albanyeye · March 1, 2019, 2:14pm

it wont mess with the X12 files for billing ?
ill try on test machine while i wait for Jerry to sort out Office Ally

stephenwaite · March 1, 2019, 3:29pm

this is for vt medicaid which supports 270/271 batch method with the specs posted above

in the library directory edi.inc (26.8 KB)
in the interface/reports/directory edi_270.php (16.4 KB)

it would take some work to deidentify the 271 @sjpadgett

caveat is that it has to be a report with only one insurance visits since even though the delete the row feature works for the visible report the 270 generated still grabs the other records

sjpadgett · March 1, 2019, 6:08pm

Okay Haven’t heard from OA but I think i’ve identified this issue. Turns out, at least for Aetna, they need the payer Id. However the AAA 79 has now turned into a 999 reject validation(the submitted 270 does not pass HIPAA validation). Jeez… Probably issue with loop 2100B. And I bet the payer id for Aetna with OA will be different for say Availity and on… So there will be lookups in our future.
My life would be so much easier if I simply had the T3/X12 spec. This hunt and peck is annoying

sjpadgett · March 1, 2019, 7:21pm

@albanyeye, @stephenwaite
You’ll may be happy to know i’ve figured out the OA interface. Now we need to plan how we want to make the Eligibility interface as universal as possible. Needs everyones thoughts on this.

Best way to configure for different interchanges.
When using batch, is it everyone’s experience the the provider NM1 (loop2100B) will use the facility for provider(FA)?
Should we maintain a separate insurance payer id table to cover different interchanges?
If we support OA, Availity and maybe Zirmed, is there a reason to even do batch? (We can emulate batch with RealTime).
What do we wish to display to the user concerning EBs? There is a ton of information available in the 271 not only for service type 30 but others like Hospital, outpatient, home health and on. This would require changing the 270 ask (EQ) to provide a list of service types to report back in 271.

Or, is everybody content to just make OA and batch work with minimum 271 reporting? I do know we can’t keep hard coding for specific interchanges.

albanyeye · March 1, 2019, 7:24pm

WoW!!!
Excited Im excited!!
Can I try it?

“f we support OA, Availity and maybe Zirmed, is there a reason to even do batch? (We can emulate batch with RealTime).”

I know that my staff sometime has to go do medicaid directly on the medicaid website because medicaid HMO details are sometimes not complete on OfficeAlly and Availity

What do we wish to display to the user concerning EBs?

IMHO CoPay, deductible, and secondary (if there is one) are important.