Page Comparison

...

The Bridge Network Partner Framework encompasses multiple processes to handle the end-to-end journey of health claim bills from receipt to final processing. The framework's design involves converting EDI 837 files to JSON, updating file level metadata and bill details level information in the database , and leveraging Azure Service Bus for certain flows. The framework also includes mechanisms for pricing retrieval, data aggregation, and outbound processing of the final EDI files.to send and receive json message

Design Diagram

Please refer to the diagram below for the low-level design document. This document offers a detailed overview of each component and their interactions within the system.

...

1. Start:

   • The process begins with the insertion of additional data into the FileQueue.iFileQueue [File level information] and the FileQueueDetail [EDI file in xml format]

2. Inbound EDI File Processing:

   • Inbound EDI files are processed, and an intermediate JSON is created.

3. Archiving Inbound File:

   • The inbound file is archived either in a database (DB) or a file share.

4. Insert into BillDetail Table:

   • The intermediate JSON is processed to insert details into the BillDetail table.

5. Bill Processing:

   • Bill JSONs from the inbound intermediate JSON file are placed in the LCN Location.

   • Error handling occurs during this phase.

6. Add Price Details in BillDetail:

   • Additional price details are added to the BillDetail table, updating pricing information and status.

7. ADVA Process:

   • Includes steps such as:

     • Generating a file location and price JSON.

     • Archiving the price JSON.

8. Aggregation Process:

   • Aggregates data to create an intermediate XML file.

   • The intermediate XML file is mapped from the intermediate JSON.

9. Outbound EDI Generation:

   • The outbound transaction creates an EDI 837 file.

   • A segment file is generated as per product requirements.

   • Pre ISA-GS intermediate file gets deleted.

10. Updating EDI Outbound XML File:

    • The EDI outbound XML file is updated with partner overrides and metrics are recorded.

11. Generating EDI Outbound File:

    • The EDI schema is generated from the XML and converted into a file.

12. Archival of Outbound File:

    • The outbound file is archived, and metrics are updated.

13. Outbound Metrics:

    • Metrics are recorded and used for updating the outbound details.

14. LAN File Target (Azure):

    • The final EDI XML file is transferred to the LAN file target on Azure.

15. End:

    • The process ends here.

...