Paradigm: Supplemental Partner Framework

Owned by Subrat Sandilya
Last updated: Oct 17, 2024
1 min read

Use Case Overview

  • 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

SupplimentalFlow_V3-ASB Consumer.jpg

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

A. ASB Consumer

  • Functionality:

    • Read bill JSON from Azure Service Bus (ASB).

    • Store the bills in the solution database named supplementaldata.

B. MergeJSON Process

  • Trigger:

    • A calendar event triggers this process.

  • Process:

    • Pick all bills with the status "price received" based on partnerID and bill type.

    • Once bills got picked, it also update the status as "Bill Merged" for all the bills that are merged

    • Each partner has a different calendar event with respect to bill type, ensuring one merged file is created for each partnerID with a particular bill type (HCFA and UB).

    •  

C. Outbound Process

  • Process:

    • The outbound transaction picks the merged JSON to create an EDI 837 file and the Custom Flow got triggered through the API used in the Outbound data mapping that is storing file level information in the filequeue table and bill level information in the SUPPL_BILL_DETAIL table.

  • Transmission:

    • The EDI 837 file is sent to the supplemental partner through LAN.

D. Inbound Process

  • Reception:

    • The supplemental partner sends pricing for the bill in the HCP segment of the file.

  • Conversion:

    • The inbound process picks the EDI 837 file and converts it into JSON. It also insert the file level information in the filequeue table for all the EDI file recieved with HCP Segment

E. Split JSON Process

  • Process:

    • Intermediate JSON files are picked using a file event and got split into individual JSON, if the entry exists in the SUPPL_BILL_DETAIL table then we will update the price information and set the status as "Bill Returned" for that bill in the SUPPL_BILL_DETAIL table

  • Split:

    • The JSON is split from that file and individual JSON files are sent to ADVA through ASB.