We have several customers using Availtiy and this is the first time this has come up. We called Availity twice because it seemed so strange, but for this customer the representative verified that their ISA08 does in fact have 6 trailing spaces, and their ISA06 has 5 trailing spaces. I asked her the reason for this and she didn’t know.
That’s so wierd that I had to post here and see if anyone else has this issue. I can fix it, but have trailing invisible padding is going to be a little hard to ‘see’ on the config screen …. so it will need to be hard coded in some fashion.
Both of those codes (sender and reciever) are being padded out to 15 chars with trailing spaces, so I’ll need to spend some more quality time with Availty to find out the real issue.
-Tony
This is a format that works with availity. No spaces, no joy. I have modified my setup to display all header values (in order) and to show the mid-hi dot character for trailing spaces. I think isa06 in the basecode trimmed the spaces off of the value for display, so you could enter them, but then you needed to add them again later if you changed something else and needed to save.
Guys that sounds extremely frustrating. It boggles my mind why if ANSI 837 is a “standard” why the heck there are so many choices. In the drop down list of my billing software ( migrating to OpenEMR very soon), there are options for Availty, Medicare, 837 with line feed, etc. It shouldn’t be a “standard” if its not standard across the board.
Unfortunately the X12 837 “standard” is more of a formatting standard than a content standard. Content standards are left to the recievers in this case the clearing house THEN the Insurance Payor. This has been the case will all of the health care standards produced as a long as I have been in the business (30 yrs) …
-Tony
A true solution for this would be implementing 837 Companion guides. Many health insurance companies have their own Companion Guides in which they would specify how they wanted their data. In the old FreeB days we had perl scripts which allows us to choose a Processing Format for each X12 partner. The Perl Script basically allows us create an X12 file as needed for that partner. If you look at the X12 configuration page you will see that the option is still there, but the FreeB perl scripts are not.
Our current X12 model, (a great job done by rod) although far superior, lacks that flexiblity. It is basically a generic Companion Guide.
Another but cumbersum work around is to fill the gen_X12 with IF X12 o CMSID statements for adjusting it to ones needs. Neither elegant nor feasable in colborative develment for if the gen_x12 is updated one would need to track and re-incorporate all changes.
I believe that if we re-enable the Processing format system and simply create gen_X12 files per required format (Say one generic and other availity, etc…) we can then process and produce X12 files for different X12 partners. And let that library of gen_X12 processing files build, the more the merrier.
FYI: This had been posted as feature request 3289123.
Not elegant but it seems to work.
In interface/billing/billing_process.php
Change Line 11 to //include_once("$srcdir/gen_x12_837.inc.php");
Right after Line 190 _ else if (isset($ar) || isset($ar)) {_
Add this include ("…/…/library/$target");
Next go to the X12_partner table and in processing_format change Standard to gen_x12_837.inc.php and add/modify what ever other you need.
Finally create your companion guide x12 generator by copying the original gen_x12_837.inc.php and modifying it to your needs.
The file names in Processing_format need to be the same names of the companion guides. (ie gen_x12_837.inc.php)
Last but not least make sure your x12 partner is configured to the proper one.
I think we would do best by moving the gen_ files to a directory call comp_guides or something like that.
The ISA record is a fixed-length record and the standard requires padding:
Here’s from the implementation guide for 4010:
INTERCHANGE CONTROL HEADER
0100 Notes: 1. The ISA is a fixed record length segment and all positions within each
of the data elements must be filled. The first element separator
defines the element separator to be used through the entire
interchange. The segment terminator used after the ISA defines the
segment terminator to be used throughout the entire interchange.
Spaces in the example are represented by “.” for clarity.
0100 Example: ISA] 00] ……….] 01] SECRET….] ZZ] SUBMITTERS.ID…] ZZ]
RECEIVERS.ID…] 930602] 1253] U] 00401] 000000905] 1] T] :~
Availity is simply implementing the standard.
If anyone needs the PDF of the 4010 standard, I can send it to them. I don’t have the 5010 standard yet.