|
|||
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 (${XESFHIRRoot}\assets\ProfileImages). The profiles illustrate typical 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 and the payer, even though they use different formats. The Da Vinci profiles include four typical use cases, which in combination, constitute the following flow:
Step 1. Schedule an appointment
The scenario Da VInci 1 Scheduling Generic Profile has the following workflow. A patient visits a primary care physician (PCP), and the PCP redirects the patient to a cardiologist for further examination. By using the Member’s Portal of the Insurance company, the patient makes a request to the Payer's FHIR server to get a list of available cardiologists. Then, the patient requests and receives a list of the cardiologist's available time slots from the FHIR server. The patient selects a suitable time slot and submits a request to schedule an appointment. 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 cardiologist, the Provider makes a request to the Payer for all the health records of the patient. At this step, the parties exchange data in the form of CDS hooks. The Payer receives the hook, extracts it, and uploads all the patient-related data onto the FHIR server of the Provider. The Provider receives the patient information in the form of human-readable CDS cards. Step 3. Discover Coverage Requirement
The scenario Da Vinci 3-4 Coverage Requirement Discovery and Medication Reconciliation Profile has the following workflow. The Provider makes a request to the Payer's FHIR server to inform the patient about co-payment. Then, the Provider prescribes a certain type of treatment, and notifies the patient about additional requirements, if any. Here the Provider and the Payer exchange the data using CDS hooks and the Provider receives CDS cards as a response. Step 4. Reconcile Medication
The scenario Da Vinci 3-4 Coverage Requirement Discovery and Medication Reconciliation Profile has the following workflow. After the treatment (within a 30-day period after the discharge), the Provider (PCP) schedules a visit with the patient to comply with HEDIS measures by analyzing the prescribed medication and the medication the patient has actually consumed during the treatment period. As a result, the Provider submits a Medication Reconciliation report to the Payer's FHIR server. A failure to submit this report negatively affects the HEDIS measures compliance and may impair future payment distribution |
