Paradigm: Use Cases - Bridge Network Partner Framework

Objective

• Facilitate the seamless integration and processing of health claim bills.

• Convert incoming EDI 837 formatted health claim bills into JSON.

• Process these claims through various custom flows.

• Update the relevant databases with the processed information.

• Ensure efficient and accurate handling of health claim data.

• Enable partners to manage their billing processes effectively.

Overview

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 level information in the database and leveraging Azure Service Bus 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.

Description of the Design Diagram

This diagram provides a detailed view of each component and its interactions within the system. Here's a breakdown of the process flow:

1. Start:

   • The process begins with the 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 in a file share.

4. Insert into BillDetail Table:

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

   • Bill Processing:

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

   • Error handling occurs during this phase.

5. Add Price Details in BillDetail:

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

6. ADVA Process:

   • Includes steps such as send and receive json message

7. Aggregation Process:

   • The Stored EDI xml file in the FileQueueDetail table gets merged with pricing recieved from adva and create an intermediate xml file.

8. Outbound EDI Generation:

   • The Intermediate EDI file gets created with .temp extension. Once the processing will get completed this .temp ext file gets converted into EDI file with required extension (e.g. .837 , .001 etc)

9. Updating EDI Outbound XML File:

   • Updating Outbound file in XML format to OutboundXMLRecords table.

10. Generating EDI Outbound File:

    • Override the extension to remove the .temp extension

11. Archival of Outbound File:

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

12. LAN File Target (Azure):

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

13. End:

    • The process ends here.

This diagram illustrates the comprehensive flow and intricate interactions among different components in processing inbound and outbound EDI files within the system.

Use Case: Key Process

The use case involves several key processes:

1. Inbound Process:

   • Trigger: Health claim bills are received in EDI 837 format from the client.

   • Action: The received EDI files are converted to JSON format and stored with metadata in the solution database.

   • Database Updates: File-level information is stored in the FileQueue table and EDI XML data is stored in the FileQueueDetail table, with the status set to "File Sent".

2. Bill Submission Process:

   • Trigger: A file event based on the partner initiates this process.

   • Action: The intermediate JSON file is split per bill and sent to ASB (Adva Pro). Bill-level information is updated in the BillDetails table with the status set to "Bill Sent".

3. Consume Adva Pro Response Process:

   • Trigger: A calendar event based on the partner triggers this process.

   • Action: Pricing data is fetched from ASB and inserted into the BillDetails table. The status for these bills is updated to "Price Received".

4. Aggregation Process:

   • Trigger: A calendar event based on the partner triggers this process.

   • Action: Data with status "Price Received" is fetched from the BillDetails table. Source file XML is merged with pricing data to create an intermediate XML. The status is updated to "Aggregate Ready".

5. Outbound Process:

   • Action: Intermediate XML files are processed to create an intermediate EDI file. This file is then picked up and sent to the Azure LAN Location, updating the necessary fields and ensuring the processed data is correctly formatted and sent.