Report - Eligibility 270 Inquiry Batch

Management and Administration
#41

I may be wrong but that line does not look like it changes at all. I looked up str_pad and all it does is add padding to the 000000001 that never changes.

$input = “Alien”;
echo str_pad($input, 10); // produces "Alien "

This may be an easy fix. What if there was a

  use OpenEMR\Common\Database\QueryUtils;

Inside the createISA() add

  public static function ediSenquence() 
  {
        //Query the edi_sequence number and return that value
     $sql = "select id from edi_sequence";
    return QueryUtils::fetchRecords($sql);
   }

   $control = self::eidSequence();
   $ISA[13] = str_pad($control['id'], 9, " ");      // INTERCHANGE CONTROL NUMBER

Question, does the sequence number have to be nine digits?

How does this look to you?

#42

looks good @juggernautsei, yes 9 digits

#43

@stephenwaite how does the edi_sequence get updated?

#44

you mean goes from 000000001 to 000000002?

#45

My apologies, I mean what is going to update the database table with a new number? The table is not auto-incremented.

I am going to have to think this one out. i will look through the code to see how generate_id is used.

image
image1039×654 81.6 KB

it looks like we would have to go into the sql.inc and create

 function edi_generate_id()
  {
        $database = $GLOBALS['adodb']['db'];
        return $database->GenID("edi_sequence");
  }

Maybe @adunsulag can shed some light on how this GenID or where the GenID class is located.

1 Like
#46

is it in library/encounter_events.inc.php?

#47

It is used in that file but that is not where the class originates. I am looking for the

public function GenID($table)
 {
       make and ID and store it in this table that was passed in
 }
#48

Unsure why we need to track ISA13 anywhere but the generator. Isn’t that control increment only needed within the request?

Can’t reference Office Ally real time because Office Ally doesn’t support batch request. I emulate batch by sending request one at a time.

#49

genID comes from the AddoDB class

In the codebase for MySQL it comes from vendor/adodb/adodb-php/drivers/adodb-mysqli.inc.php L452.

#50

In case your unfamiliar with them, sequences are another way of doing auto-incremented ids, Oracle and other RDBMS engines use them heavily.

#51

I believe it’s the GS segment that has the control number that should be tracked. Say your submission fails and you have to find out what batch it was with the returned transaction set, like a 999.

#52

Okay but believe that’s in the response. I thought the problem is that they use the ISA13 control id within the batch request to delimit a new request so must be unique within the session. Simply increment in the generator.
Anyway, I can’t read Sherwin screenshot of spec. If I could I’d have a better understanding of issue plus, while fixing this we should add to the eligibility tab in demographics to allow a single request to update patients eligibility status or user can view the status.

1 Like
#53

Here is the guidebook

The pages referenced are 56 -57

IEA02 and ISA13 must be the same number

They suggested that there be one entry for claims and one entry in the x12 partners’ settings for eligibility. We should not be using the one entry for both types of requests.

#54

Ok, it is in the vendor folder and I don’t have that loaded in my dev environment. No, I not familiar with the sequence generators but now I know.

#55

Okay looks like you guys have the solution. Still don’t understand why the need for a new table to create ids to track throughput of workflow. Should be part of the response and openemr parsed record.

1 Like
#56

It’s more for the 837s I guess then since you want to match your 999s with the 837s to create acceptance tracking down the road.

#57

Okay sure maybe as I haven’t looked at that possibility however, IMO, we should do it then and not have the table hanging around until then.
For this issue, I’d assume you can create the ISA13 in generator as an incremented PHP var based on the request session iteration.
If I remember right, it’s done in code but doesn’t populate the ISA13.

2 Likes
#58

You have already done this.

It is only office ally.

1 Like
#59

thanks. I didn’t know if I included other vendors beside Office Ally…

#60

@juggernautsei You’ll have to develop/modify the current workflow for Availity in batch to send a single request with all the 270 patient segments.

Are you currently trying to enable OA with an Availity x-12 partner to send an electronic batch request or downloading the batch file and sending the batch to FTP or such?

At any rate, you’ll need to set up the workflow. I can explain in a call if you need.