ProviderOne
Managed Care Organizations (MCOs) and Regional Support
Networks (RSNs)
Frequently Asked Questions (FAQs)
Last Updated 10/15/09
Why are we getting 834 updates transactions without the HD04 segments?
Confusion between the trading partner agreement (TPA) and the custom report
Carriage returns to separate rows in the 837P
Encounter Transaction Results Report (ETRR)
834 Eligibility and 820 Payment Files
Q: Why are we getting 834 updates transactions without the HD04 segments?
A: In case of Address Change (Maintenance Code “001” and Maintenance Reason Code “43”) and Demographic Change (Maintenance Code “001” and Maintenance Reason Code “25”), the Health Coverage loop (loop 2300) will not be sent for these change transactions.
Q: Confusion between the trading partner agreement (TPA) and the custom report: The initial 837 file testing resulted in a “success”; however, the custom report made it appear that following the TPA caused an error. Subsequent testing resulted in the custom error reports indicating ProviderOne did not have a TPA with the RSN when that was not the case (the ProviderOne system did not recognize the RSN as a trading partner). These errors delayed our RSN continued testing.
A: This confusion was identified early in testing and a system update was implemented to resolve the confusion. The Companion Guides indicated that files will only be rejected for HIPAA level 1, 2, and 7 errors, but we understand the potential for confusion. The custom report will now only include the identification of HIPAA error levels 1, 2, and 7.
Q: Testing/production confusion: The TPA does not state that testing data should be placed in the ProviderOne Production folder and contain a “P” indicator. This is somewhat confusing. We want to ensure that testing data placed in this folder will not be stored as production. We have been told that it is necessary to treat test files as production data in the ProviderOne system to enable full cycle testing process.
A: The required reporting specifications are detailed within the ProviderOne 837 Professional and Institutional Encounters Companion Guide. During preparatory meetings leading into the testing phases, instruction was provided regarding the use of Test and Prod root directories for SFTP submittals. Our apologies if the communication was not adequate. We can confirm that the “Production” data submitted to support testing will not impact future Production activities. Further communication is forthcoming that will detail future testing activities. Also, all data submitted during testing will be deleted prior to the system go-live.
Q: Carriage returns to separate rows in the 837P: We have always used carriage returns to separate lines in the 837 file as this makes the file easier to read and to troubleshoot if there are issues. Our ProviderOne 837 test file contained carriage returns and ultimately padded EDI testing. While the Encounter Data Companion Guide (version 7) and the 837 Encounter Data Reporting Guide (version 1.0, released May 2009) make no mention one way of the other about carriage returns at the end of each line, it was stated only in the “EDI FAQs and Common Problems” document released on 6/24 that carriage returns could not be used. After we raised the questions with ProviderOne staff that our file passed EDI but also used carriage returns, they stated that carriage returns after segment terminators do not pose a problem as long as an “EOF” marker is at the last segment in the file. This additional information should be included in the “EDI FAQs and Common Problems” document to reduce confusion.
A: We apologize for the confusion. This issue was rapidly acted upon once notification of the error came to light. We have applied an update to the system that allows for carriage returns to be included.
Q: 837P File Name: The initial 837 Encounter Data Companion Guide did not state that RSNs had a different file name convention than did other trading partners. The Encounter Data Reporting Guide was released and states on the RSN-1 page that the original file name begins with 2000000 (7-digit number) and that it must be the same number derived from ISA13. ISA13 is a 9-character field; this document defines a 7-character field. RSNs have still not received clarification on this.
A: We think that the confusion arose in that the example in the Encounter Data Reporting Guide is incorrect, while the description is correct. The example should have stated that the sequential number should begin with 200000000, and should have showed:
Example of file name: HIPAA.101721502.122620072100.200000001.dat
We will amend the Encounter Data Reporting Guide to reflect this correction.
Q: 837I Facility Code: The 837 Encounter Data Companion Guide Version 7 documentation states that RSNs should use Facility Code 11 – Outpatient when submitting 837I encounters where the facilities that are licensed as 56 Psychiatric Residential Treatment Facilities. If it is believed that place of service 11 Outpatient is needed, then these files should be submitted as 837P files, as opposed to 837I files.
A: We believe there was some confusion about this field. The field in the 837I is “facility” code, which, in the UB04 manual Form Locater 4, indicates as follows – “Type of Bill: 011X = Hospital Inpatient (Including Medicare Part A).” Instead, the question seems to refer to the CMS Place of Service codes which are not used on 837I Encounters.
Q: Encounter Transaction Results Report (ETRR): The ETRR final edit reports from ProviderOne have not yet been made available (although promised for 7/6 and 7/17) which prevent full testing and wastes RSN staff time to keep coming back to the same encounter submission to analyze nuances of feedback as it is delayed and eventually becomes available. This “hurry up and wait” scenario creates an awkward and frustrating testing process. This report is required to test resubmission of claims since ProviderOne requires that resubmission includes the ProviderOne transaction ID number for each encounter.
A: Please remember that we are in a testing phase intended to identify, diagnose and solve any problems that are uncovered. Additionally, this testing phase also serves the purpose of EDI certification, i.e. RSNs will be prepared to submit production encounters when ProviderOne goes live. Several other problems were uncovered during testing that required immediate action and caused necessary shifts to schedules. The release of the ETRR has been shifted to accommodate necessary fixes and will be released when creation processes are complete. Although the lack of delivery of the ETRR prohibits RSNs from completely testing their systems, it does not prohibit the completion of EDI certification processes for all transactions.
Q: ProviderOne File Access Issue: Testers report various issues ranging from the inability to access the ProviderOne SFTP site, or specific folders within the site, to receiving a TA1 but not a 997 or vice versa.
A: The problems identified have been noted and are being worked through with the vendor on a case-by-case basis. This is normal testing activity on a system implementation of this size.
Q: 834 Eligibility and 820 Payment Files: The 834 files have been significantly delayed. Although testing began at the end of June, the 834 files were not available until last week in a usable format. The files were initially posted to the ProviderOne SFTP site on 7/15; however, they were not readable. The 820 files were posted on the SFTP site on 7/16.
A: The files were produced per the distributed schedule. However, several issues arose about readability, and the vendor was engaged to fix the problem. Internal review of the content also took a bit longer than predicted, but did surface issues that the vendor was able to fix before the files were released.
Q: ProviderOne ID: RSNs have been requesting for at least a year to get a crosswalk file from the current TXIX PIC to the new ProviderOne ID for current RSN customers. The first test file sent out by the MHD in December 2008 requested feedback about content and format. The second file was sent out by MHD on 5/8, but was missing significant fields. The third file at the end of June was better, but has multiple issues that must be resolved. Feedback was given to MHD staff with specific examples, but we are still awaiting feedback and/or new ProviderOne ID crosswalk file.
A: We apologize for the delay in providing these files. The first delay was with the vendor. Further delays occurred when HRSA IT agreed to respond to the RSN’s request to link each record with the CIS consumer ID. The result was problematic and needed revision of programming code to resolve. New files have been distributed and are being reviewed now by RSNs.
Q: 837P Timestamp: In the encounter Data Reporting Guide, the date time stamp format example in the file name is not the same date time format that the ISA segment uses (MMDDYYYYHHMM vs. YYMMDDHHMM in the ISA), but we are told that this needs to match the ISA.
A: We are not aware of how or where RSNs were told that the two formats need to match. To clarify, the date must be the same in both the file name and in the ISA segment. RSNs may use the YYMMDDHHMM format in their file name.
Q: 837I Principal Procedure Code: The 837 Encounter Data Companion Guide states that the Principal Procedure Code should be used by RSNs. This is confusing because RSNs are not performing “procedures” during the E&T visit. Principal procedures are generally used for submission of surgical procedure information during an inpatient episode, not an E&T visit during an E&T episode. If RSNs are to use the Principal Procedure Code segment to transmit something such as the H2013 code (psychiatric health facility service, per diem), there is no clarification as to how to submit a date range as opposed to one single date (D8). If RSNs are just to report one date, which date should be reported (admit date or discharge date)?
A: See Companion Guide: http://hrsa.dshs.wa.gov/dshshipaa/attachments/pdf/837%20Encounter%20C.G.%205-19-09.pdf , in the 837 Institutional Encounters section, page 84: “Note: Not used on RSN Submitted Encounters.” Therefore, principal diagnosis is not to be reported.