you mean goes from 000000001 to 000000002?
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.
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
is it in library/encounter_events.inc.php?
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
}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.
genID comes from the AddoDB class
In the codebase for MySQL it comes from vendor/adodb/adodb-php/drivers/adodb-mysqli.inc.php L452.
In case your unfamiliar with them, sequences are another way of doing auto-incremented ids, Oracle and other RDBMS engines use them heavily.
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.
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
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.
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.
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
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.
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
You have already done this.
It is only office ally.
1 Like
thanks. I didn’t know if I included other vendors beside Office Ally…
@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.
In the dropdown menu of ‘processing format’ of x12 partners within the practice settings, there is an option of availity elgibility. Is this functional?
The hooks aren’t honored for creating the batch request though the globals are implemented to hook from. Needs a new request developed for Availity.
Shouldn’t be hard…