Page Comparison

...

• Objective:

  • Receive individual health claim bills in JSON format from ADVA.

  • Create one EDI 837 outbound file.

  • Send the merged EDI 837 file to the supplemental partner.

  • Receive pricing from the supplemental partner in the HCP segment of the EDI 837 file.

  • Process the EDI 837 file with HCP Segment and create a JSON having multiple bills. This JSON got split into multiple individual JSON and sent back to ADVA.

Design Diagram

...

Description of the Design Diagram

The above flowchart shows an ASB (Azure Service Bus) process with two main sections: the existing and recommended workflows, and the detailed steps in processing messages from the ASB.

Existing vs. Recommended Workflows:

• Existing Workflow:

  1. ASB Topic (Individual Bill)

  2. SupplementalData Table (Individual Bill)

  3. Intermediate LAN location (Merged JSON)

  4. Insert record into FileQueue and BillDetails

  5. EDI 837 in Final Outbound Location

• Recommended Workflow:

  1. ASB Topic (Individual Bill)

  2. SupplementalData Table (Individual Bill)

  3. Intermediate LAN location (Merged JSON)

  4. Temp location (Outbound EDI 837 File)

  5. Insert record into FileQueue and BillDetails

  6. EDI 837 in Final Outbound Location

  7. EDI 837 in Outbound Archive Location

Detailed Flow Process:

1. Start: Begins with an individual calendar event for each partner.

2. Pick one message from ASB: A message is picked from the ASB topic (advapro-prod-out-supp-bill).

3. Message check: The system checks if the message exists.

   • Yes: Proceeds to validate the message.

   • No: Ends the process.

4. Validate message: The system validates the message, extracting the BillType, PartnerID, and TransactionID.

5. Insert into SupplementalData table: Inserts the extracted data (TransactionID, BillType, BillJSON, PartnerID, and status as "Price Received") into the SupplementalData table.

   • If a unique constraint violation occurs (e.g., duplicate bills based on TransactionID), an error is triggered.

6. Error Handling:

   • If there's an error in validation, the message is either:

     • Deleted from ASB and processed as an error, or

     • Appended to an error list for retrying in the main flow.

7. Abort flow: If errors persist, the flow is aborted, and an email notification is sent.

8. End: The process concludes after successfully handling the message or upon triggering an error.

2. High-Level Design Overview

...