5010 Updates

February 20, 2012

Auto Accident Validation—If the client sends an auto accident indicator without the auto accident state, we will fail the claim.

Altius Outputs—Altius does not want the service facility location when the location is the same location found in the billing provider loop. We made a change so that we do not output the service facility location when it is the same as that found in the billing provider loop.

Dental Web Form and Missing Teeth—The website now displays the missing teeth on the web form when the value is found in the database.

‘NO’ Other Insured Information 4010 Edit—When a dental claim carries a ‘No’ in box 4 (other coverage), we no longer fail the claim for missing other insured information.

Report Sorting—We made changes to the sort routine. Some reports were being sorted to the wrong provider.

ERA and ERAM—Clients that are set up to receive both the ERA and ERAM should now receive both.

Paper Output—We were mishandling the date of service on paper outputs when the imported file was a 4010 file. This is now fixed.

ASK 277CA—We added ‘A8’ to the list of 277CA errors codes so that when a report that carries this code sorts, the report shows the claim as ‘Rejected’.

February 16, 2012

State Code Validation—The state code “SP” was slipping through the validations and causing claim failures in the NM1*85 Segment. We have tightened up the state code detection and only allow valid state codes.

Pre-Authorization Number—The Preauthorization Number that is required for Spectera claims is now validated correctly and the correct fields are being highlighted

Invalid NDC Unit Type—If an invalid NDC unit type is entered One Touch no longer crashes. We now set the default valid to “UN” and continue merrily on our way.

Property Number—The “Property Casualty Claim Number” that worked so well in the 4010 output format, has accepted a starring role in the same position for the new 5010 format.

NDC Unit Quantity—The 5010 standard definitions for Gram “GM”, and Milligram “ME” now will also handle the ANSI standards that have been used for decades, (I.E. “g” and “mg”) with equal efficiency.

Exception Errors—A myriad of Exception errors have been handled smoothly throughout the code to make everything work better. Thanks Troy.

NDC Code Validation—We no longer validate the NDC codes on the OneTouch website. This had become a major irritation to providers so this has ended.

Highlighting corrections—The validations surrounding the Auto Accident fields on the OneTouch Website were highlighting field incorrectly. These issues have been corrected, correctly.

WA Premera—Washington Premera has requested that all claims being output to them have the Zipcode verified against the City that it is applied. If the zipcode does not match the city coverage listed, the claim will fail until this issue is corrected. This is against the 5010 specifications, but it is what Premera wants. So this is what they are going to get.

OutputException—The “Output Exception” label that appears in the status column of claims that have “Output Exceptions” will no longer appear in the status column when claims have “Output Exception” problems. When Claims have “Output Exception” issues, instead of “Output Exception” listed in the Status Column for claims that have “Output Exception” issues. We will now be listing “Pending Output” for claims that have “Output Exception” issues. This has been concluded as a kinder, friendlier Status label then the previously used “Output Exception” label that was displayed when a claim had a “Output Exception” issue.

Gender changes—If the relationship between Subscriber and patient is self and the gender is female, we have incorrectly been outputting “M” in the patient gender field. We don’t anymore.

License number—Delta Dental of Minnesota has requested that the provider License number (different from the NPI) be included with all claims output to them. We asked them if they were sure about this, and they said, “Yes”.

February 15, 2012

Service Facility Validation—The Validation of the Service Facility will only be enforced when at least one field of the Name, City, State, and Zip are filled in.

Bad NPI Value—Under certain circumstances we were outputting an invalid NPI Value in the NM1*82 segment. This practice has come to a halt.

Prior Authorization # Missing—The Prior Authorization Number was not being imported correctly. Corrections have been made and Prior Authorization Number is now being imported correctly.

Claim not output to correct Payer—Forced Output now outputs claim to the correct Payer.

Rendering Provider—If the Rendering Provider NPI is the same as the Billing Provider NPI we no longer output the Billing Provider Segment.

February 14, 2012

Other Subscriber Address—If Other Subscriber address is empty and relationship to patient is self, we now fill the Other Subscriber Address fields from the Patient address fields.

5010 Force Output—The Force Output ID function in 5010 importing is now working correctly.

PWK Segment (Attachment Numbers)—The attachment numbers in all cases are now at the beginning of the NTE segment.

Missing Service Facility NPI—The Service Facility NPI is now correctly being included to avoid the validation error.

P.O. Box. Not Allowed in Address2—The Billing Provider and Service Facility Address fields are not allowed to have a P.O. Box in Medical and Dental Claims.

Days or Units—The Days or Units field in the service line item record now writes out a “0” for the required output segment.

NM109 in the 2330A Loop—is no longer the same as the SBR03 value.

February 13, 2012

NPI Length Validation—The Length of the Service Facility NPI was not triggered when a NPI of less than 10 digits was entered. This validation has been corrected.

Service Facility Information—If Place of Service is not Nursing Home, Air, or Water (values 12, 41, or 42) then the Service Facility information is output even if the Billing Service Provider Information is the same. This is contrary to the 5010 specifications, but has been requested by several payers.

Billing Provider Address cannot be a P.O. Box—The Billing Provider Address that has a P.O. Box is replaced with the Provider Address record on file in the Apex Database.

Scion Dental Paper claim procedure codes—The procedure codes were output with a D120 instead of a E0120. This has been corrected.

4010 Service Line Unit Values—The service line Items were displaying the incorrect values for the Units field. This has been corrected in the 4010 output.

February 8, 2012

Diagnosis Pointers—When the diagnosis codes are not reported in a contiguous fashion (i.e. client give diagnosis code 1 and 3 but do not give diagnosis code 2), we make them contiguous on the output. We now also adjust the pointers so they point at the adjusted diagnosis code.

Service Facility NPI Validation—This NPI is situational so we removed the validation.

Facility Address—If the place of service is something other than ‘office’ and a facility address is submitted in the remarks field, and, we will not fail the claim. We also fixed a highlighting issue related to the place of service box 56.

Outputting the Facility Address—We will output the facility address to all Medicare payers and Medicare Molina if the facility address is provided, unless the place of service is 12 (home). We have plans to expand this

Paper Claims—We made a fix so that we do not send paper claims for clients who have their account set to reject all paper claims.

Other Subscriber Validation—If the claim carries an adjudication date and a primary paid amount or has ‘SECONDARYCLAIM’ in box 19, then we require the other subscriber information (last name, member id).

Tax Id—We fixed a problem with a Tax ID edit.

Procedure Codes E vs. D—Procedure codes were output with an ‘E’ instead of a ‘D’; this is now fixed.

Line Level Service Date—The service date at the line level should not be output unless it is different than what is sent at the claim level. We made a fix for this on the dental side.

DTP Qualifier—If the client provides us with a D8 qualifier and supplies a range, then we will output an RD8 qualifier with the range, that is if the range supplied by the client, is actually a range of dates (i.e. 20120201-20120204 vs. 20120201-20120201)

ERA—We made a fix to an ERA sort that was not catching the procedure info, dates, and amounts.

SV107-01—We made a fix to limit the expected value to 1 to 3 inclusive.

Anthem Report Sort—We are now exposing the detailed rejection messages that are provided by Anthem’s TX reports.

February 2, 2012

Group Policy Numbers—We made a significant change to our logic that decides if we will output the SBR03 or SBR04 (as they are mutually exclusive). If the client sends a group policy number and a group name, we will output the group policy number in the SBR03. Previously, if both were present, we would output the group name SBR04.

DSHS/Medicaid WA—We now can send the procedure code T2035 without formatting into a dental code.

Spectera Authorization Numbers—We had a validation that was faulty because it was expecting 1 alpha + 8 numeric instead. We checked with the payer and it should actually be 1 alpha + 7 numeric.

Ambulance Claims—We relaxed a validation so that we do not require a Service Facility Location if the POS is 41 (Ambulance Ground).

Date of Current—If the date of current is required for a claim and it is not provided, we will not use the service date as the date of current.

Leading Zeros—We cleaned up some more problems with leading zeros in the CTP04 (NDC Unit Count).

Crashes Viewing Failed Claim—Fixed this so that when the client navigates to the claim form, the website does not crash.

January 23, 2012

Multiple Remarks Segments—We are able to import and render to the website multiple claim-level remark segments.

Pend Attachments—We removed the “Pend For Attachments” button from the statements listing page.

Secondary Claim Edits—We fixed an edit that was erroneously failing claims for secondary amounts not summing up.

Blue Care Network—When the PayerId_VC = SB711, the Payer Name contains “BCN”, and the Insurance Plan Name holds “BCN”, then we will output an HM qualifier in the SBR09 of the 2000B Loop.

DSHS and Taxonomy Codes—As per DSHS’s companion guide, we now send the taxonomy code both in the billing provider loop and the rendering provider loop (only if the rendering provider loop is required).

NDC—We created a Unit Price database field on ClaimMedicalServiceLine_T.

NDC—We created a Unit Price field on the medical claim form at the service line level which will only display if the destination payer is receiving in 4010.

NDC—We now step-up the NDC Unit Price on import.

NDC—We created an edit to ensure that the unit price is sent when the client sends the NDC number.

NDC—We are now able to step-down 5010 NDC info into a 4010 format.

January 20, 2012

Payer Update—UHIN is having an issue with 5010 file transfers. Educators Mutual (EMI Health) is a asking that all 2012 files be resent in 4010 format.

January 18, 2012

NTE—The notes in “Reserved For Local Use” (Box 19) now output to a NTE segment.

Lower-Cased Text—City fields were failing because of some code that was only considering upper-cased values. This has been corrected.

Patient Zip—If the patient relationship code is not ‘self’ and there is a patient last name and patient first name and no other address information, we will grab the subscriber address and output it in the Patient Loop.

Box 33 NPI—Changes made to box 33 NPI will now be saved.

NDC—We adjusted the validations on NDC codes to allow for the sundry types of acceptable hyphenation.

January 17, 2012

Accept Assignment—We made a fix to the web form so that the accept assignment indicator (box 27 on HCFA) displays.

24 J NPI—If we receive an invalid NPI in 24J, we will not output it and we will not set a validation, so be careful when selecting a mapping. If we do receive a valid NPI in 24J, we will output the NPI with the name and taxonomy code found on the provider record.

Rendering Provider—If the Billing Provider is a non-person entity (2010AA Loop NM102 = 2) then we will always output a rendering provider loop.

Notes and Attachments—We corrected saving issues in the Note Type and Notes field found at the line level under the Notes and Attachments section.

Adjusted Amount—We corrected saving issues with the secondary claim adjusted amount field.

Referring Provider—On the medical form, we will always display box 17 (referring provider). It is not a configurable field.

Amounts—We adjusted the Amount Class in the code to strip out leading zeros on amounts that are reporting amounts less than a dollar that have a zero in front of the decimal point (i.e. AMT*F5*0.22)

REF 1G—We will not output the referring provider secondary id when the primary id (NPI) is present.

Auto Accident State—We no longer submit the accident state unless the accident was an auto accident.

NDC Codes—We now parse the NDC info when it is sent in box 19.

Innovations—Clients can now add a line item to their claims and the data will save.

Search—The search bar on the website is now functional.

Box 33 Crossover Issues—We fixed a problem where the drop-down list was populating values across provider records that carried the same billing tab information.

Web Form Saving Issues—To our knowledge, all saving issues one the web form are resolved. Please let us know if you see something different.

EIN/SSN—The display issue has been corrected.

January 13, 2012

Referring Provider—Altius, Nevada Medicare, and Southern California were rejecting files because we were sending referring provider secondary id segments. They are not needed when we send the NPI. We have corrected this problem.

Apex Payer ID—We put the Apex Payer ID field back on the form and hooked up the logic that sets the electronic payer destination based off the Apex Payer ID. If the client puts a value in the Apex Payer ID field, we check our list of valid Apex Payer IDs to see if there is a match. If the value does not match, then we look at the Payer Address to determine the electronic payer destination.

Medical Web Form—We made a fix to the zip code field in section 9d on the medical form so that it only allows numeric character.

January 12, 2012

Claims Listing—The claims listing page now correctly displays the payer, the correct date, and the claim amount.

Medical Paper Outputs—We fixed a host of issues with the medical paper outputs. We no longer drop the Units or Days on the paper outputs, Box 10D, Patient Similar Illness Date, ID qualifier for 24I, Physician Signature, Auto Accident State, Line Items, Subscriber Employer Name, Billing Provider Secondary ID (Box 33b), and the Other Insured Employer’s Name. We also are mismatching the Payer Name.

Patient Zip Code—For dental claims, we turned on an existing validation that sets when the patient zip code is not 5 or 9 digits.

Other Subscriber Name—We no longer output the Other Subscriber Name when we don’t have all the required elements for the Other Subscriber Loop and Other Subscriber Payer Loop.

Leading Zeros—Leading zeros are not allowed on amounts. We made a fix to handle leading zeros on amounts like ‘0.01’ .

Saving Issues—Made a change so line item changes are saved to the database.

Website Performance—We were logging exceptions tied to validations no longer in use. We removed the validations from the database so we are logging about a million less exceptions per day.

Referring Provider NPI—We added validations that set when the referring provider last name is present but the referring provider NPI is missing and vice-versa.

Secondary Claim Procedure Code Description—We no longer send the description in the SVD segments.

Secondary Claim Validation—A validation will be set if a claim has one but not all four fields which are required for a secondary claim, namely the Adjudication Date, the Primary Paid Amount, the Adjustment Amount, and the Patient Responsible Amount.

Web Saving Issues—We fixed an issue where all of the web form’s fields were not saving. All fields should save data except for two obscure fields on the medical side. These will be fixed soon.

January 11, 2012

Payer Address Validation—We have made some changes so that we are not erroneously failing payer addresses. Also, when you update the payer address to a valid payer address, the electronic payer destination will update.

December 28, 2012

Previous/Next—We added back in the previous claim/next claim functionality to the 5010 medical and dental web forms.

Claim Status—We fixed a problem where the claim status displayed as failed on the home, track, claims listing pages and then switched to ready on the load of the web form.

Add Claim—The add claim functionality is available once again.

NEA Attachment—There is now a convenient Attachment Number field on the dental claim form, which is located below the Box 35 remarks field.

Bread Crumb—We have put in a bread crumb on the web forms so the client can navigate back to the batch; more improvements to follow in the future.

January 9, 2012

THANK YOU FOR YOUR PATIENCE

At Apex EDI our foremost goal is to get you paid fast and easy. Furthermore, we want to be available quickly to help resolve any problems you face. Our goal with the 5010 transition was to make the transition completely transparent to you despite the massive changes required. However, even with all of our preparations, the transition has not met our standard of being completely transparent. We apologize for any inconvenience you may have experienced and we want you to know we are aggressively working to provide you the high level of service we aim to provide.

WHAT WE’RE DOING TO PROVIDE THIS SERVICE

1. We have added additional phone capacity
2. We have “loosened” data validations in order to allow more claims to move through the system
3. We have augmented our website hardware to make the system more responsive
4. We have had our programmers working around the clock to speed our system
5. We have increased our customer support staff to improve phone responsiveness

WHAT HAPPENED WITH THE UPDATE

January 1, 2012 brought the requirement to use the new 5010 claim standards mandated by the federal government. Compared to the previous 4010 standard, 5010 is greatly expanded and requires completely new programming for insurance companies and clearinghouses alike. Like most companies, Apex has been working on the 5010 transition for over a year. Still, the insurance claims industry as a whole has been bracing for the January 1 cut over date recognizing that switching everybody to a new standard all at once would create a host of problems for all parties.

Now that we are there, the “pain” of 5010 conversion is widespread across the industry. Some insurance companies were unable to complete the 5010 readiness requirements and are still operating under the old 4010 standards. We are being notified that many insurance companies are experiencing 5010 delays in claim and report processing. Delays are widespread and we encourage you to plan accordingly.

With the changes we have implemented we anticipate that this week responsiveness will improve and that by January 16 we will be back to the level of service you have come to expect. We encourage you to email your questions to support@apexedi.com. We appreciate and ask for your patience and understanding as we complete the significant 5010 transition.

Sincerely,
Apex Client Services Team