Several Azure services are used to ingest and forward X12 EDI messages to their respective parties along with extracting FHIR resources and storing them in Azure FHIR Service.

1. Azure Storage Account - Ingestion container for X12 files.
2. Azure Logic App (Standard) - Workflow engine.
3. Azure Integration Account - Business artifacts such as schemas, trading partners, and agreements.

TODO : Include diagram

TODO : Discuss scenario. Discuss workflow ingestion vs outbound messages and ack.

The high level logic flow is as follows:

ingest > resolve agreement > decode > process ack > process bad/good messages > cleanup and archive

1. Ingest 837(p|i) from provider
2. Send TA1
3. Extract FHIR data
4. Forward message to payment agency

1. Ingest 999/227/835 from payment agency
2. Extract FHIR data
3. Forward message to provider

cd deploy

az deployment group create -g 'hdpa-edi-poc' -f main.bicep --name ("main-" + (Get-Date -Format "s").replace(':', '-')) --parameters `@main.parameters.demo.json

• 835
• 837p

DotLiquid is used as the template engine to transform the decoded EDI X12 XML data into FHIR resource types. The Azure Logic App Transform JSON connector is used for the transformation process.

The template files should be stored under /logic/Artifacts/Maps when deploying them to Azure Logic Apps. The name of the file will be used as the reference id in the workflow definition. Consider including a version in the file name.

• X12Message835ToFhirClaim.liquid

• An SFTP enabled Azure Storage Account can be used to as the drop location for incoming files from external payors. A security container per payor will allow secure access to files specific to the payor. SFTP enabled accounts do not support Event Grid subscriptions to file actions.

• Two common acceptable file extensions for EDI files are .edi or .txt. The incoming file must be all in 1 line versus each segment per line. This will be treated as a warning and can fail the request.