Eligibility Checks & Clearinghouses

I have also contactec Officeally for eligibilty verification and the email I got was this:

Does your EMR program have the ability to send and 270 via a SOAP or MIME connection? I would need to know that information first. If your EMR can do that we can proceed with the steps for set up.

I am not sure what that means except that we do run Mirthconnect on our server for automatic document upload and I know that mirth can send over SOAP connection.
Hope it does not come to that since I would like to have Availity work. ( even if the United no longer works on Availity)

itā€™s easiest to send a batch file, sounds like theyā€™re talking about real time transaxtions

the above sql error is under review and results from not parsing out the other x12 partner appts from the batch

hereā€™s a fix to the segment count which may help with availity, edi 270 batch eligibilty fixes by stephenwaite Ā· Pull Request #2214 Ā· openemr/openemr Ā· GitHub

Stephen, thanks for the code update.
I edited the files by hand and walked through the segments with the Availity support on the phone and sent in a 270 file.
Now I got a new error. I will have to get on the phone with them again tomorrow and see where the error is.
Atleast we are through the ISA segments :grinning:

Interchange Status: The Transmitted Interchange Control Structure Header and Trailer are Rejected Because of Errors.
Interchange Note: Invalid Interchange Content (e.g., Invalid GS Segment)

the part that I think maybe the issue is just after the GS08 segment (005010X279A1) before the ~NM1 segment. The guide says it needs to be GE01 and GE02. I dont know what the values for those segments are. Should be 1/6 and 1/9 in length respectively.

ISA00 00 ZZAV09311993 01030240928 1902130032*^005010000099921P*:~GSHSAV09311993030240928 201902130032022X005010X279A1~ST270000000003005010X279A1~BHT002213PROVTest600201902130032~HL*120*1**~NM1

Sorry the spaces dont show up accurately in this post

thanks you.
i heard back from Officeally. They will not accept batch files and only do realtime eligibility verification by SOAP or MIME

@stephenwaite Do we do this interface?

I dont think we do.
Officeally sent me a bunch of guides on how to accomplish this.
Can PHP do this? I see some SOAP stuff for the ePrescribe from Newcrop.
I was going to see if there were any Mirth Connect experts here that could help develop this feature.

itā€™s only batch currently but feel free to post the guides to help start a project

lol, jesh so much to do and needs to be done. This snuggles right up next to @robert.down concerns for us shaking out interop in most all aspects of clinical workflows. We need to get more developers working on these things because as of right now, it seems iā€™m the only one doing any development(could be wrong).

@albanyeye Hopefully they offer a web service alternative to soap(yuck!). Soap lends itself to be specific to the task and any current soap code tends to not be easily repurposed. Different classes etcā€¦ in the end you will wind up dumping the batch file but just in a different way.
Not saying I have time to do this but I can take a look at how they want this interface to work. Pretty sure I know but if youā€™ll send me their specs, iā€™ll take a look seeā€¦

1 Like

think what we have currently will work with oa, https://cms.officeally.com/OfficeAlly/Forms/Forms/270_271_Companion_Guide.pdf, itā€™s just that youā€™ll have to manually upload the file, we would most likely need @sjpadgett to help us with native submission from openemr which is not a priority imho

sorry just saw this

For all real time transactions Office Ally utilizes AS2 communications, primarily Web services, HTTPS MIME and SOAP WSDL.

Yep, this doc really doesnā€™t address what their web service looks like or even a WSDL to garner what the soap looks like. Would be nice to see their interface spec docā€¦

So are ya going to share with me what Officeally gave concerning the interface. Mirth is a bit of overkill for thisā€¦

Yes I shall send them documents to you. How do I do that? Post it here?

Okay, this is fairly straightforward stuff. @stephenwaite how important is officeally and how broad is user base? How well does meeting officeally requirement relate/carry over to other clearing houses ie. is this a need for the others?

IMHO Officeally and Availity are big ones.
Nearly all insurances can be verified on Officeally.
On Availity you cannot do UnitedHealthcare or straight medicaid (atleast in Georgia)

Iā€™d love to see the docs as well and would be interesting in supporting the development. Iā€™m supporting a large practice and paying a significant amount to do this through Zirmed.

Kyle

1 Like

You guys arenā€™t the first to bring this up and I definitely see this as an immediate/useful feature worthy of 502 enhancement and a back port to 501.
I just need a little time to get a plan for best way to integrate because I donā€™t see as a very time consuming project. Iā€™d like to get it done if that is the case and will give an update here once I investigate further.

1 Like

would you like me to push my recent edits to edi.inc? was going to move this to the library/billing namespace

Iā€™d go ahead and move now @stephenwaite . Iā€™m hoping to have something to test by tomorrow. I can just patch in what I need.

@stephenwaite found a bug in the Claim.php class at L240 with sql select.
$sql = "SELECT * FROM insurance_numbers WHERE " .
"WHERE (insurance_company_id = ? OR insurance_company_id is NULL) AND provider_id = ? " .
ā€œORDER BY insurance_company_id DESC LIMIT 1ā€;
Note the dup WHERE clause.

If you havenā€™t started moving the 270 stuff yet you might hold off 'till iā€™m done. If you have then iā€™ll just fix this.

Also iā€™m assuming that iā€™m just doing the real time 270/271 eligibility interop and leaving the Billing manager batch alone right?
Iā€™m also thinking iā€™ll need to add some elements to X12 partners to indicate electronic xmit and urls

1 Like