|
|||
Supported Use CasesXES Module for FHIR supported by the FHIR technology helps resolve several problems when a Payer wants to provide patients with a convenient way to confirm eligibility coverage using a web portal, a mobile application, and so on. The FHIR standard comes in handy when connecting to a server, however a majority of servers work with the EDI standard. XES Module for FHIR bridges the gap between the FHIR format and the back-end system. The following are typical cases/scenarios where you can use XES Module for FHIR:  Care coordination
Case 1:
The provider uses HL7/CCD clinical data, but the patient's health plan stores the clinical data on the FHIR server in the FHIR format. XES Module for FHIR allows interaction between the provider (practitioner) and the health plan, even though they use different formats. In this case, XES Module for FHIR:
Case 2:
The new provider needs the patient's medical history to learn what procedures/treatment the patient previously underwent, what observations were made, what allergies were detected, and so on to be able to prescribe further treatment. The doctor asks for the CCD file that contains the patient's data from the insurer's care coordinator that stores patient medical history in the FHIR format. Using XES Module for FHIR, the care coordinator can export the FHIR data to CCD. In this case, XES Module for FHIR:
Eligibility Verification
Case 1:
A patient requests eligibility information from an insurer by phone or using a web portal through the RESTful web service to confirm his/her coverage by his/her carrier. The insurer has an EDI back-end system, and the request is submitted in the FHIR format. XES Module for FHIR converts the FHIR eligibility request to an EDI 270 transaction to make it acceptable for the insurer's EDI back-end system. The insurer's back-end system responds with the EDI 271 transaction, and XES Module for FHIR creates a FHIR eligibility response based on this transaction since the front-end software (web portal or insurer’s front-end software) works with the FHIR format. Case 2:
A provider sends an eligibility request to an insurer for prior authorization that is required from the Payer before a provider goes ahead with the treatment. The provider's system is HIPAA-compliant and so the provider submits an EDI 270 transaction. The insurer's system is FHIR-compliant, and so XES Module for FHIR creates a FHIR eligibility request using the EDI 270 transaction and converts a FHIR response provided by the insurer to an EDI 271 transaction. On-Demand Claim Processing
After a patient has been successfully treated, a provider submits an EDI claim (837 transaction) to an insurer (who works with the FHIR format) to cover the cost of treatment. XES Module for FHIR creates a FHIR claim using the EDI 837 transaction to make it acceptable to the insurer. These scenarios are implemented in the XEServer Module for FHIR profile. Da Vinci ProfilesXES Module for FHIR is distributed with a set of preconfigured XEServer profiles located in the folder XESModuleForFHIR\assets\ProfileImages. The profiles serve as examples for data exchange scenarios where the provider may use HL7/CCD clinical data, but the patient's Payer stores the clinical data on a FHIR server in the form of FHIR resources. XES Module for FHIR allows interaction between the Provider (practitioner) and the Payer, even when they use different formats. The Da Vinci profiles represents four typical use cases that in combination form the following flow:
Step 1. Schedule an appointment
The scenario Da Vinci 1 Scheduling Generic Profile has the following workflow: To schedule an appointment with a Provider through the Member’s Portal of the Payer, a patient retrieves a list of available practitioners, selects a practitioner, and then requests the practitioner's time slots. The route returns a list of available slots from the Provider's FHIR server. The patient selects a suitable time slot and submits a request to schedule an appointment with the Provider. Step 2. Fetch Patient information from the Payer
The scenario Da Vinci 2 Payer Provider Ex Generic Profile has the following workflow: When the patient visits the Provider, the Provider requests the Payer for all the information on the patient. At this step, the parties exchange data in the form of CDS hooks. The Payer receives a CDS hook, processes the hook, and uploads all the patient data onto the FHIR server of the Provider. The Provider receives patient data in the form of CDS cards in a human-readable form. Step 3. Discover Coverage Requirements
The scenario Da Vinci 3-4 CRD and MRP Profile has the following workflow: Before prescribing a treatment, the Provider makes a request to the Payer to send back the coverage terms for a medication or a procedure for a specific patient. The Provider and the Payer exchange the data using CDS hooks and the Provider receives CDS cards with information on the treatment cost and a list of medical conditions that require this kind of treatment. Step 4. Reconcile Medication
The scenario Da Vinci 3-4 CRD and MRP Profile has the following workflow: The Provider sends a list of prescribed medication to the Payer's FHIR Server. |
