Page Comparison

...

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 :

   • Generating a file location and price JSON.

   Archiving the price JSON.

   send and receive json message

7. Aggregation Process:

   • Aggregates data to The Stored EDI xml file in the FileQueueDetail table gets merged with pricing recieved from adva and create an intermediate XML file.The intermediate XML file is mapped from the intermediate JSONxml file.

8. Outbound EDI Generation:

   • The outbound transaction creates an Intermediate EDI 837 file .

   • A segment file is generated as per product requirements.

   • Pre ISA-GS intermediate file gets deleted.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:

   • The EDI outbound XML file is updated with partner overrides and metrics are recordedUpdating Outbound file in XML format to OutboundXMLRecords table.

10. Generating EDI Outbound File:

    • The EDI schema is generated from the XML and converted into a file.Override the extension to remove the .temp extension

11. Archival of Outbound File:

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

    Outbound Metrics:

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

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.

...

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 file 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.