| Category | Known Issue | Workaround | Status | Dev Ticket |
| Issues with ERA Posting Screen | Description:
Issues with the ERA Posting screen, specifically with certain ERAs. These include unapplied claims not showing in the APPLIED section, missing claims in the POST ERA PAYMENT screen, non-functioning ACTION dropdowns, and duplicate claims appearing in the POST ERA SCREEN despite being listed once on the ERA.
Impact:
•Some claims do not appear on the POST ERA PAYMENT screen, which can cause delays in payment posting and reconciliation.
•The ACTION dropdown field is not functioning for some claims, preventing actions from being completed properly.
•Claims are displayed multiple times on the POST ERA screen, even though they are listed only once on the ERA, which may cause confusion and errors during processing.
Findings:
•The issue with missing and duplicated claims is caused by how claim information is fetched from the database. Multiple calls are made, leading to some claims being sent multiple times or not being sent at all.
•A fix has been scheduled for the next release on Thursday, February 13, 2025, which will resolve these issues. | Post any unapplied (missing) claims as EOBs based on the view/download file. If the clinic needs any help identifying which claims are not available to post, please create a ticket, and zHealth's engineering team can help provide a comparison and let the clinic know.
The fix will be included in the upcoming release. In the meantime, clients are advised to manually verify claims and ensure that affected claims are handled correctly. | Resolved - Pending Release | ZS-5600 |
| Duplicate Rendering and Billing Provider Taxonomy Information | Description:
Some payers require the rendering provider taxonomy information in box 24ij (shaded box) and the billing provider taxonomy information in box 33b. In the EDI file, the rendering provider taxonomy is transmitted in Loop 2310B, Segment PRV03, and the billing provider taxonomy is transmitted in Loop 2000A, Segment PRV03. However, due to a configuration issue in the system, when the rendering provider taxonomy information is forced in 24ij, it is incorrectly passed in Loop 2310B, Segment REF02, causing a duplicate. This results in the clearinghouse sending a parsing error.
Error Message:
Null Unexpected Segment Null Null
Impact:
The incorrect duplication of the rendering provider taxonomy in the EDI file causes the clearinghouse to reject the file with a parsing error, which may delay claim processing and payment. This issue only affects the EDI file. If the claim needs 24ij to show up when printed, it must be selected.
Findings:
•When taxonomy is manually forced in 24ij, the taxonomy information is being incorrectly placed in multiple segments on the EDI file, resulting in the null error.
•This issue only affects the EDI file. If a claim is printed and requires 24ij to be displayed, the selection must be made manually. | •In the Facility Tab, use the "Provider Taxonomy" to put in your group or billing taxonomy code. This will go in 33b if you are billing as an organization.
•In the Provider Tab, use the "Provider Taxonomy" to put in your Individual/Rendering Provider Taxonomy code. This will go in 24ij (and 33b) if you are billing individually
•Ensure that the provider taxonomy is entered under the "Update Info > Provider" tab and the billing provider taxonomy is entered under the "Update Info > Facility" tab.
•EDI: If taxonomy is needed via EDI in both 33b and 24ij, ONLY choose to to put it in 33b (24ij will automatically populate via EDI). It won't be visible in 24ij if you view or print the claim, but it WILL be on the EDI file.
•Paper Claims: If taxonomy is needed on a printed claims, you must choose to to put it in BOTH 33b and 24ij. | Identified | |
| Incorrect or Blank Box 29 Values in EDI 837p Files | Description: Box 29 on the HCFA form is either displaying an incorrect primary insurance paid amount or is left blank, resulting in erroneous payment details or "null" values in the EDI 837p file. This issue will be identified with the error code 9E.
Error Messages:
•The error occurs when two claims are generated for the same payer, particularly when using the Batch Generate Claim feature.
•The error is also triggered when Box 29 is either blank or contains "null" in the EDI 837p file.
Specific Error Message:
•Issues with Other Claims Amount Paid. Segment has data element errors. nullnull
Impact: This problem leads to errors in EOB and ERA postings for primary claims and disrupts secondary claim submissions. Attempts to repost the EOB/ERA do not resolve the issue, with Box 29 remaining blank and "null" values persisting in the EDI 837 file.
Findings: The investigation revealed that the system is generating two primary claims in the database: one with correct payment details and another showing $0 or "null" values. The system is mistakenly using data from the second claim to populate Box 29 for secondary claims. | Please refrain from submitting secondary claims until further notice. Check for updates on the resolution progress.
In the meantime, we have an alternative solution. Please create a ticket in our system, including the names of affected patients along with their dates of service, so we can attempt to apply this solution from the backend. While it is not a guaranteed fix, it has been effective in most cases. | Identified | ZS-5394 |
| Merging Accounts – Memberships, Conversations, and Stored Credit Cards | Description: Currently, memberships, conversations, and stored credit cards do not merge properly when accounts are combined.
Impact:
•Memberships: Membership details such as payments, visits, and stored credit cards do not transfer to the merged account.
•Conversations: Conversations are not included in the merge and must be manually handled.
•Stored Credit Cards: Credit card information from the second account does not merge. | Avoid Merging: Do not proceed with merging accounts if you want to retain memberships, conversations, and credit card details.
Alternative Actions:
•Delete the Second Account: Instead of merging, consider deleting the second account.
•Re-add Membership Details: Manually add the membership, payments, visits, and credit cards to the primary account after deletion of the secondary account.
•Handle Conversations: Since conversations do not merge, take screenshots of important conversations and upload them to past notes manually.
There is no current workaround for merging conversations other than manual documentation.
Please follow the outlined steps to ensure all relevant information is preserved. We are working on improving the merging process and will provide updates when a solution is available. | Awaiting Action | ZS-3881 |
| Split ERAs | Description: When multiple ERAs are received for a single claim, each corresponding to different CPTs, the system currently only calculates the latest ERA or the one updated most recently on the invoice. This does not align with zHealth's expectation of processing one ERA per claim.
Impact: This issue leads to incorrect calculations on the invoice, as only the most recent ERA is considered, potentially omitting important details from other ERAs. | •Close Without Applying: Close the claim without applying the ERA/CPT in the system.
•Manual Entry: Manually add the ERAs as an EOB (Explanation of Benefits) and process each CPT accordingly.
•Follow-up Actions: Take the necessary actions based on the manually added EOB to ensure accurate processing and accounting. | Awaiting Action | X |