Eligibility Checks & Clearinghouses

sjpadgett · February 23, 2019, 5:40pm

@stephenwaite Any clue as to why most of the X12 Partner setup/configuration is hard coded?

stephenwaite · February 23, 2019, 7:26pm

looks like it was setup for just one customer a long time ago

sjpadgett · February 23, 2019, 7:34pm

Yep, that’s not going to work. Do you have a spec that covers the 270/271? I didn’t find any that were worth much. Going to have to do some rewrite. I though at least the batch worked or if it does I doubt it works with very many clearing houses…

sjpadgett · February 23, 2019, 7:43pm

I have the interface working on a button where I can tell if i’m sending good data or not so we at least have that to troubleshoot with. It works for sample data be then I bumped up on bugs in the 271 parse so … nuts is the most polite way to express myself

stephenwaite · February 23, 2019, 8:03pm

was working on these http://www.vtmedicaid.com/#/hipaaTools

sjpadgett · February 23, 2019, 8:19pm

Thanks, much better than what I have and it appear currently we are close to what this doc is saying. Somehow we’ll have to set up some hooks to handled the various approaches different clearinghouses interprets the spec. The Office Ally spec goes back to 2011 Prob need to give more control back to the partner config.

robert.down · February 23, 2019, 10:05pm

@sjpadgett if we’re rewriting that screen let’s break it out into a proper namespace. library/insurance/eligibility/src/ and if you can get the classes done I’ll get the UI setup on Twig.

sjpadgett · February 24, 2019, 2:34pm

Hi @robert.down, I think Stephen has been and is making his way through moving much of billing over to classes and I believe this module is in his plan. Terry wrote this feature and it is pretty clean code and should not be too difficult to move to classes.
My concern for now is that the X12 config is locked down in code and very little config comes from the partner ui. One can config away to no avail, drove me nuts.
So while i’m adding the realtime eligibility checks i’m going to open the ui back up because we’ll have capability to now do both, realtime and batch.

On that note I could use some recm for integration of real time. I’m thinking because eligibility checks are somewhat immediate a better implementation would be to do an auto check when an appointment is made/changed and add a button in the Eligibility tab in Insurance Demographics. For Reports i’m having to emulate batch by making a series of real time requests. Plus batch drill downs to qualify for a check needs to be improved.
In the end the UX needs some TLC just I don’t have plans to do now.

sjpadgett · February 24, 2019, 2:47pm

FYI: Here’s a response from real time

–8d699ac8acc9d25
Content-Disposition: form-data; name=“ProcessingMode”

RealTime
–8d699ac8acc9d25
Content-Disposition: form-data; name=“TimeStamp”

2019-02-23T16:32:46Z
–8d699ac8acc9d25
Content-Disposition: form-data; name=“PayloadID”

3b8c13f5-11e2-43bf-bc47-737cca04f3fe
–8d699ac8acc9d25
Content-Disposition: form-data; name=“CORERuleVersion”

2.2.0
–8d699ac8acc9d25
Content-Disposition: form-data; name=“PayloadType”

X12_999_Response_005010X231A1
–8d699ac8acc9d25
Content-Disposition: form-data; name=“SenderID”

OffAlly
–8d699ac8acc9d25
Content-Disposition: form-data; name=“ReceiverID”

XXXXXXX
–8d699ac8acc9d25
Content-Disposition: form-data; name=“Payload”

ISA00 00 ZZOFFALLY ZZxxxxxx 1902240032*^005011264500150P*:~TA10000000011902231932A000~GSFAOFFALLY155214201902240032426450015X005010X231A1~ST99910001005010X231A1~AK1HS2005010X279A1~AK2270000000003005010X279A1~IK5R4~AK9R110~SE610001~GE1426450015~IEA1126450015~
–8d699ac8acc9d25
Content-Disposition: form-data; name=“ErrorCode”

Success
–8d699ac8acc9d25
Content-Disposition: form-data; name=“ErrorMessage”

None
–8d699ac8acc9d25–

sjpadgett · February 24, 2019, 3:52pm

@stephenwaite Is this what you guys were chasing and what your mods covered?

ISA, GS, ST Control Number	Segment	Error Type
000000001,2,000000003	SE	EE - Envelope error
Error Message	Data Value	Expected
SE has wrong number of included segments.	15	12

stephenwaite · February 24, 2019, 5:27pm

thought this fixed the segment count

sjpadgett · February 24, 2019, 5:37pm

Maybe I blew the patching. I’ll check again and let ya know. That edi.inc library is begging to have some class
I hope to have a PR today so you guys can do some testing. I’m a little unsure about the x12 generation still so, hoping you can help me out with that.

sjpadgett · February 27, 2019, 7:27am

@albanyeye @stephenwaite @KyleNave
I’ve got this to the point of integrating with the UI which I planned to change how tab and report work.
The attached patch is for testing. It will allow you to initiate a Request from Reports->Eligibility in real time. At this point i’m not writing to database but instead gives a download of the 270/271 X12 requests and responses with the 271 logs after parsing. Without real insurance data to send I can’t be sure about parsing so, that’d be your guys mission. Note also that i’ve rewritten the 271 parse and it now resides in the edi.inc library. The old 271 inc is left as is for now. Eventually it will all become a single class.
Logs will show any AAA segments errors or an eligibility array if successful transactions. The batch Report upload is still the old stuff and the new real time is automatic where app will send the selected patients 270 x12 to OA, get the responses and then parse them and give you a results debug log to download.
Credentials for OA go into the X12 Partner plus the ISA05/07 and Testing/Production config items are turned back on.
Looking forward to some real time feedback especially concerning the X12 transactional with OA.

here’s patch. two files.
eligibility-patch.zip (14.9 KB)

albanyeye · February 27, 2019, 6:16pm

Excellent. I will try it out today
EDIT:
just tried it. got an error

PHP Fatal error:  Uncaught Error: Call to undefined function xlj() in /var/www/openemr/interface/reports/edi_270.php:194
Stack trace:
#0 {main}
  thrown in /var/www/openemr/interface/reports/edi_270.php on line 194, referer: http://172.20.1.186/openemr/interface/main/tabs/main.php

rmagauran · February 28, 2019, 11:57am

I believe xlj() is a 5.0.2 function…

albanyeye · February 28, 2019, 1:58pm

Thanks Ray…
I ran eligibility on 5.02 this morning and got a text file to download. Unsure how to get the 271 file. Do I download it from Officeally?

270 Requests Sent:
ISA001234567 00 ZZ123456789 ZZ330897513 1902280850*^005010000000010P*:~
GSHS123456789330897513201902280850282X005010X279A1~
ST270000000003005010X279A1~
BHT002213PROVTest600201902280850~
HL1**201~
NM1PR2*AETNA MEDICARE

sjpadgett · February 28, 2019, 2:32pm

Ray’s right, I’m working from 502 master. Much easier to port back to 501. Hopefully you guys can setup a dev local branch to test. Otherwise will have to wait till i’m done and back port. (not real hard really).
I went into this thinking this feature at least worked to some extent but sadly no. One issue is that the parse engine is using the wrong delim’s and even then it only looks for the MSG segment to glean eligibility. In the end, old has to go.
Anyway i’m trying to get this up in a PR so we can work there. It’s just that now I have all this eligibility information collected from the new parsing, I have to decide what and how to get to the UI…
It’s never easy, is it:).

sjpadgett · February 28, 2019, 2:52pm

Missed this post. I automatically send to OA. If you look further in the log you will see the 271 response from OA and also any AAA errors and/or the EB segments parsed in to an array…

stephenwaite · February 28, 2019, 2:59pm

can’t help with testing OA, but the old batch method produced a 270 that was accepted but likely won’t deliver any 271 without the missing details in the specs above.

albanyeye · February 28, 2019, 3:07pm

Sorry, I dont understand.
Where is the log? Is it part of the file I downloaded?