| CategoryET | Known Issue | Workaround | Status
| Dev Ticket |
| 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. |
Resolved - Pending Release | |
| 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 |
Terminal showing disconnected (ProPay) | Based on our investigation, the issue appears to be tied to recent Microsoft Windows updates, especially those rolled out in the latest Windows 11 spring release.
These updates have introduced changes to how Windows handles network connections, firewalls, and background services. As a result, apps like Cloudbridge, which rely on real-time communication, are getting interrupted—sometimes without any visible warning. The terminal may appear connected, but in reality, it has lost touch with the cloud. When your system tries to send a transaction, the cloud can’t find the terminal anymore, triggering a 404 (Not Found) error.
To put it simply: Windows quietly breaks the connection in the background, and no one knows until a payment fails. | Check that the Windows system is online and connected to the internet
Restart the Cloudbridge app and log in again, which re-establishes the connection to the cloud | Issue Identified | ZS-5991 |