Eligibility (EDI Channel)

XEServer routes of the FHIR Bridge profile that implement the EDI channel to process medical data (eligibility inquiries) consist of inbound and outbound parts.

Inbound

The inbound route does the following:

Receives the EDI 270 transaction (the File System Inbound component).

You can submit the EDI 270 transaction to the following folder: ${XESModuleForFHIRRoot}/workspace/Runtime/Eligibility/EDItoFHIR/Inbound270 or change this path on the Common tab of the FS Inbound component. To do this, in Source folder, enter the required path. If you do not want to use the file system data transport and you need to receive data through another channel, for example, JMS, FTP, HDFS, and so on, you can create a route with data re-drop from the inbound endpoints to the file system endpoints. For more information, see Endpoints in the XEServer documentation. You can also use the XES Module for FHIR web portal to submit data.

Validates and splits the transaction into individual patient transactions (the XE Native component).
Creates a FHIR bundle of the transaction type (the XE Translator component). For more information on mapping rules, see Eligibility Mapping Rules.
Commits the bundle to the FHIR Server (the FHIR Action component).

If the FHIR bundle cannot be submitted for any reason, the whole bundle is rolled back. Typical reasons are the following:

XES Module for FHIR cannot create FHIR resources on the FHIR server (data is partly or completely invalid, there is no connection to the FHIR server, and so on).
Junk data is present in the FHIR resources.
Saves the CoverageEligibilityRequest ID that is used to identify responses (what response belongs to what request) in the data storage.

Outbound

The outbound route does the following:

Periodically (by default, it is set to every hour, but you can set a different period), the system checks if an eligibility response was received for an existing eligibility request. The system checks if there is an eligibility response that references the required request: for each saved CoverageEligibilityRequest ID it looks for the CoverageEligibilityResponse linked to the required CoverageEligibilityRequest.

In the following example, the system checks if there is a response that references the request with the ID=14.

Example

..content..

</request>

..content..

</CoverageEligibilityResponse>

Note When the required response is found, the CoverageEligibilityRequest ID that was used to find the corresponding response is deleted from the data storage. If the required response is not found, the system makes another attempt to find the required response later and the CoverageEligibilityRequest ID is not removed till the response is received.

If the CoverageEligibilityResponse is found, XES Module for FHIR takes all the available resources required to create the EDI 271 transaction and adds them to one FHIR patient's bundle.
XES Module for FHIR maps the FHIR patient's bundle into the EDI 271 transaction.
XES Module for FHIR creates the Communication resource (that is linked to the CoverageEligibilityResponse resource) with the newly created EDI 271 transaction in the payload and adds it to the FHIR server.

Back-end emulator

The sample profile contains a back-end emulator. Make sure you turn it off when you are using your back-end system. To do this, set the value of the BackendEmulatorOn profile environment variable to true. The system does the following:

XES Module for FHIR passes the CoverageEligibilityRequest ID to the emulator route, creates the eligibility response resource, and adds it to the FHIR server.
The emulator back-end system detects new eligibility requests.
The emulator back-end system emulates a look up into the internal insurer’s tables to verify eligibility and a sample eligibility response (the CoverageEligibilityResponse FHIR resource) that contains a reference to the initial request (CoverageEligibilityRequest ) is created.
Adds CoverageEligibilityResponse FHIR resources to the FHIR server with the newly generated IDs.