aperezcrespo wrote on Tuesday, June 02, 2009:
Hi
Has anyone anything on these X12 types? Currently most clearinghouses offer some type of webservices to generate eligibility reporting.
Some even offer XML files as a response to make parsing easier.
Just wondering.
Thanks
cfapress wrote on Tuesday, June 02, 2009:
I’ve had to parse some response files that are in relation to the 270/271 requests. The files come back from EDS in Connecticut. They’re not XML and I had no idea about X12 at the time so I had to reverse engineer the encoding used in the response text-file.
What are you looking to accomplish?
Jason
aperezcrespo wrote on Tuesday, June 02, 2009:
Well lots of clearinghouses provide some form of Eligibility verification. Some provide a web page others provide a webservices interface.
Information returned: Insurance comany,Plan Date, Effective Date, Cancelation Date, Patient Name and Address, Coverage information.
I think it would be a benefit for any provider to obtain Eligibity info directly through OEMR. Or at least be able to parse these file and create a user readable result.
ideaman911 wrote on Tuesday, June 02, 2009:
Guys;
I concur completely. ANYTHING which can be used to verify eligibility prior to providing service would be a VERY valuable function. We are nearing the state of philanthropy here.
That is not to say that I have the needed programming skills to accomplish same. But if I can help in any way (other than money, which I need more of myself 
please let me know. Thanks.
Joe Holzer Idea Man
http://www.holzerent.com
ideaman911 wrote on Tuesday, June 02, 2009:
To put some flesh around this, I would envision the desire to use this function for any X12 partner at least once per week. It would look at any patient shown to have an insurer who uses that partner, and post the particulars to a 270 file for submit to that portal. Ideally it would then read the 271 response and would automatically find and note in the patient demographics the date of any change from last status, flagged in RED. Ideally, we would link that status ALSO to the patient list report and to the patient search print so as to immediately indicate of the patient might have a problem with billing. Similarly, that 271 would post the date of that change, if known, or the date of the 271 at least, within the patient record. It would seem the logical place for those would be within the Insurance sections, for EACH section, as any of them can be affected.
It would also probably be prudent to think in terms of added Insurance listings beyond the current three, such as "Prior Primary", "Special" (as in the case of accidents or other, with default override for "Misc CMS 1500 settings"), etc. Ideally, these "extra" would have a drop-down selectability which would define their functionality and logical linkages on top of the current data these contain. In fact, it might even be useful to have such selectivity for ALL insurance, as the current setup allows instant change of insurance anyway.
Joe Holzer Idea Man
http://www.holzerent.com
mmfsystems wrote on Wednesday, June 23, 2010:
See here:
https://sourceforge.net/tracker/?func=detail&atid=493004&aid=3019716&group_id=60081
mmfsystems wrote on Wednesday, June 23, 2010:
See here:
https://sourceforge.net/tracker/?func=detail&atid=493004&aid=3019716&group_id=60081
mmfsystems wrote on Wednesday, June 23, 2010:
See here:
https://sourceforge.net/tracker/?func=detail&atid=493004&aid=3019716&group_id=60081
mmfsystems wrote on Wednesday, June 23, 2010:
See here:
https://sourceforge.net/tracker/?func=detail&atid=493004&aid=3019716&group_id=60081
mmfsystems wrote on Wednesday, June 23, 2010:
See here:
https://sourceforge.net/tracker/?func=detail&atid=493004&aid=3019716&group_id=60081
bradymiller wrote on Wednesday, June 30, 2010:
hey,
Thanks for the contribution, and is a great start at a very useful
feature. Here’s my review. Overall, need to work on theme, formatting,
organization issues for first revision. Then can give more specific recs.
RECS:
–Remove wordwrap functions, since this is not compatible with UTF-8
character set.
–Ensure xl() all strings (a significant number are not enclosed by the
xl() function).
–Combine the php,js,css stuff into one file (see rest of openemr code
for lots of examples; especially other reports). This is very important to
ensure full internationalization support.
–Use same theme, formatting, and calendars as the other reports
(currently used calendar has already been hacked to support full
internationalization)
–Migrate majority of the edi_270.php functions into a separate library
file.
–I’ll show how to implement new security mechanism (stop sql-injection
and xss attacks) when it’s near completion (guessing several more revisions
left)
thanks,
brady
bradymiller wrote on Wednesday, June 30, 2010:
also,
here’s a link to your patch/branch on my github repository:
http://github.com/bradymiller/openemr/commits/edi-270_1
-brady