| Category | Known Issue | Workaround | Status | Dev Ticket |
| Missing ERAs in zHealth | Description: Since the last release implemented on Thursday (10/24), we have observed that not all ERAs are being received in the zHealth.
Impact:
•Claim Processing Delays: Affected clinics may experience delays in processing claims due to missing ERA data.
•Inaccurate Financial Reporting: Discrepancies in reported income and outstanding claims may arise from absent ERAs.
•Patient Communication: Clinics may face challenges in updating patients on claim statuses.
Findings:
•The problem seems to have emerged post-release on October 24, with sporadic occurrences rather than a blanket issue affecting all clinics.
•Communication with the Managed Billing team indicated a significant drop in received ERAs, prompting a need for investigation.
•Affected clinics will be notified, and further analysis is underway to determine the root cause and potential solutions. | At this moment, we do not have any workarounds established.
We ask that you please wait for our communication regarding the resolution of the issue. | In Progress | ZS-5482 |
| JPA Transaction Rollback Exception | Description: We have encountered a recurring error message related to transaction management in the system:
Error Message:
"Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Transaction marked as rollbackOnly"
This issue was reported by the doctor at Saginaw Chiropractic and Rehab Clinic regarding claims submitted on 10/09. A total of 21 claims from this clinic are affected by this error.
Impact: This error message has impacted some claims between 10/09 and 10/10. | Please refrain from resubmitting the claims until further notice. Check for updates on the resolution progress. | In Progress | ZS-5460 |
| Box 29 Showing Incorrectly Inflated Primary Insurance Paid Amount | Description: Box 29 on the HCFA form is displaying a primary insurance paid amount that is significantly inflated, reporting values such as $135 instead of the correct amounts of $45 and $0 for different codes. The affected claim will be identified as 2E.
Error Messages:
•Secondary Claims Error:
This occurs when the total of the primary insurance paid amount, insurance adjustments, and patient responsibility do not reconcile with the total billed amount for each line item.
•EDI 837p Error:
An error is generated when the EDI 837p populates the incorrect paid amount for the billed CPT code(s).
Specific Error Message:
•SECONDARY CLAIM INFORMATION MISSING OR INVALID (LOOP 2430) - EACH LINE MUST BALANCE; LINE CHARGE AMOUNT (SV102 [HCFA]/SV203 [UB]) = LINE SUM OF ADJUSTMENT AMTS (CAS) + LINE PAYER PAID AMT (SVD02)"
Impact: This issue affects both ERA and EOB postings, leading to an inaccurate total insurance paid amount being displayed as $135 instead of the correct $45. Attempts to delete and repost the data have not resolved the discrepancy. | 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. | In Progress | ZS-5395 |
| 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. | In Progress | ZS-5394 |
| Secondary Claim Error | Description: Certain secondary claims are generating an error message due to discrepancies in Box 29 (Amount Paid) when a primary claim is posted, deleted, and then reposted. The amount displayed in Box 29 inaccurately reflects totals from the deleted posts rather than the correct, updated amount.
Error Messages:
•This issue is identified when Box 29 or the EDI 837p file contains an incorrect insurance paid amount.
Specific Error Message:
•PRIMARY PAYER PAYMENT OUT OF BALANCE (TOTAL CHARGE) - (PAYER PAID AMT) - (CLAIM LEVEL ADJUSTMENTS) - (LINE ADJUSTMENTS) SHOULD EQUAL 0
Impact: This error undermines the accuracy of secondary claims and can hinder proper claim processing, as Box 29 does not match the actual amount paid. | 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. | In Progress | X |
| 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. | In Progress | 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. | In Progress | X |