aethelwulffe wrote on Wednesday, June 01, 2011:
Using mmf systems code for 270 batch creation, I have discerned a number of errors. I am confident that there is a possibility that the original code might work for *someone*, but I have not discovered anyone who claims that this is so.
The following items require modification:
ISA01- Must be configurable via x12 partner configuration interface and draw values form there.
ISA02- Must be configurable, and have the default all spaces. Currently, it is hard coded to all zeros (not universally acceptable).
ISA03- Must be configurable
ISA04- Must be configurable, and have the default all spaces. Currently, it is hard coded to all zeros (not universally acceptable).
GS02- Not using the correct variable from x12 partner configuration
GS03- Must be configurable in x12 partner and echo values from there, removing trailing spaces.
BHT05- Time format error, perhaps needs configuration formatting options, but my partners require the following formats:
$GS[4] = str_pad(date('Ymd'),8," "); // Date [CCYYMMDD]
$GS[5] = str_pad(date('Hi'),4," ");
Original code (I believe) used ‘His’ and ‘ymd’, even though the REM statements stated the correct requirements.
GS06 and ST02 could also use configuration options, and perhaps incrementing. I can see uses for reporting in the EMR, and of course some B2B partners may require it’s configuration
The upshot?
To fully support all EDI formats as well as hcfa we simply need to make all header and tail element configurable in x12 Partner setup, and draw values for those elements from the DB. The current implementation of EDI exports is crippled by hard-coded and erroneous classes and file generators. This is a pretty simple fix really, and a huge time saver.
The next issue:
Some clearing houses offer 837/835 exchange without supporting 270/271 data. For instance, we can use Availity to do Medicaid claims in a batch with BCBS, but we must submit 270’s to Payspan or directly to Medicaid. For those very common, possibly normal cases, we need to support configuration of insurance data to indicate which x12 partner to use based on the file type exported. This simply requires another value added to the insurance information to indicate a second x12 partner to whom 270’s a sent.
Finally, we need a eligibility report that operates in a totally different manner, more like the billing module. Currently, the report does not seem to use any filters other than date. Picking an x12 partner only sets the values (and badly/incompletely at that) for the header, and requires you to manually remove incompatible patients from the report before creating a batch. The data displayed for the patients does not show a visit date or other discriminating data. Picking future dates, and selecting specific providers does not create a list either.