X12 2310B Loop missing after upgrade to 5.0

Management and Administration
#21

Facility info for the office checked. It looks fine. Everything is filled in as it should including Facility NPI # (for group).

#22

Note I am pretty clueless on this stuff. Taxonomy support was added for OpenEMR 5.0 and it sounds like medicare won’t accept that until end of the year. Is it possible that this is breaking the medicare stuff?

#23

Hi Brady,
Thank you for joining the fray. It doesn’t seem logical to me that pending claims before the upgrade are being created with the proper info in the X12 files generated, while those created after the upgrade are missing it. It would lead me to think that the X12 script is not at fault, but rather that the database after the upgrade doesn’t have the info that the X12 script is trying to pull. I looked at the form_encounter part of the database and do not see rendering physician info. Where does the X12 script pull that info from? Do you think I should give mysqlcheck a crack at a copied appliance? Do you think I should back up the present appliance and rebuild the appliance, understanding that l might be putting a faulty database into the new one? I’m really unsure as to how to proceed.

Thank you,

Henry

#24

hi @hamd,the field in form_encounter is provider_id, could you check your 2010AA loop, billing provider info to see if it differs between x12 from encounters prior to upgrade and now? thank you

@brady.miller taxonomy could be the prob but it looks like it’s only included if medicaid ins

#25

IHi Stephen,
Sorry for the delay, but I wanted to really take apart the X12 output line by line and compare it to the X12 wiki reference file so that I could understand it better. There is no difference between the before upgrade and after upgrade 2010AA output. Both show the group/facility address and NPI #. The only difference between the old and new are the missing 2310 B NM1 segment as well as the PRV segment.

Since I modified the gen_x12_837.inc.php file to fix the Availity Florida BCBS “no sender id” issue, as I have done in the past, I changed it back to what it was originally on the off chance that it might have something to do with this present problem of not outputing 2310B (the rendering physician), but that didn’t change a thing.

While comparing my output to the Openemr Project Wiki X12 837p reference as well as another (ANSI X12. 837 field mapping) at hosinc.com/products/ascendhi/help/billing/ansi837_field_mapping.html), I found that both the old claim as well as the new are also missing the 2310C and 2400 loops.
The 2310B PRV segment output shows the following;(PRVPEPXC*207W00000X). It appears it should have ZZ instead of PXC, according to both references, but it was working that way before. There also appears to be confusion as to whether the 2000B HL segment should start with a 1or a 2. Both old and new claims are identical they have a 2.
There are some discrepancies between the wiki and the output with regard to segment 2010AA NM1 in that the NPI # is what is present in both the old and new claims yet what appears that it should have is the Federal Tax ID # instead. Also the 2000A PRV segment is also missing in both the the old and new outputs.
For what it’s worth that’s what I found.
Thank you,
Henry

#26

hi @hamd, thank you. there are 2 problems

probably easiest to call your medicare contractor’s edi department to ask what values are missing/incomplete/invalid and then we can properly evaluate the software if it’s at fault.

#27

Ok. Will let you know.

#28

Hi Stephen,
I know why the 2310B loop is missing. I checked the database for the same pt before and after and found that the provider_id field in the database as of 4/17/17 ( upgrade date) = 0, whereas before it =2. Thus it seems it doesn’t have any info to pull. Now why is it showing 0?

Thank you,
Henry

#29

hi @hamd, are these autogenerated encounters by the calendar? thank you

ps did you view the log in the billing manager to confirm it’s skipping 2310B?

#30

Hi Stephen,
Not sure what auto generated by the calendar means. The encounters are generated by the front desk when the pt shows up. The fee sheet is showing the rendering physician.

Thank you,
Henry

#31

Sorry, but I don’t understand. Please explain what you mean by the above.
I’m sure it’s missing 2310B because there is nothing outputting in the claim batch file.
Where do you set the rendering physician that’s picked up by the form_encounter / provider_id? Is there a file where it can be be set ?
Thank you,
Henry

#32

hi @hamd, there’s a view log link on the billing manager page

it seems like the checked in created encounter is not setting the provider id in the form_encounter table (aka a bug) - will research some more to offer a fix

so you will need to reopen the fee sheets and make sure that the rendering provider is chosen and then confirm on the encounter summary page

of course you could write some sql to update all occurrences of provider_id = 0 in form encounter to your provider_id of 2 if you are the only provider in your group

#33

Hi Stephen,
Yes, what is happening is that the fee sheet Rendering physician defaults to my name not --Please Select–. Thus the employees were leaving it that way as I am the only physician. Even when you select --Please Select-- and click save it defaults back to my name. A work around is to click on Screening, Visual ( a fake physician user that I created to help with the scheduling calendar ) then click save, then go back and select my name and save again, then the database changes and places a 2 in provider_id field. I have looked at the X12 generated output for a claim changed in this way and indeed the 2310B segments NM1 and PRV are correct. Thus your right, it is a bug in the Fee Sheet script.

Thank you,

Henry

#34

Don’t really understand why this wasn’t picked up by others before, as it should be happening to everyone?

#35

hi @hamd, thanks for the report. I believe the bug in the auto generated encounters through the calendar has been there all along. I’ll take a closer look.

The new bug in the fee sheet was inadvertently introduced when the default provider option was added with the intent to minimize the number of clicks on the fee sheet process.

#36

GREAT!!! Very happy it’s not a corrupt database!!

#37

Hi Stephen,
Might a better workaround be to turn off the default Rendering Provider. If so how is that done?
Thank you,
Henry

#38

hi @hamd, don’t think there’s a global for that. i’ll continue trying to find a fix and will post here when appropriate

#39

Ok. Wonder how it was set to default to my name to begin with?

Thank you,

Henry