This page is part of the IHE ITI Finance and Insurance Services (v1.0.0: Publication) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
The Finance and Insurance Service (FAIS) Profile stores, categorizes, and facilitates the administration of centralized claims and finance data for patient care. The service receives claims/financial data from Point of Service (POS) applications (including financing applications acting as a point of service interface outside of other POS systems) and curates the management of them.
This profile is initially focused on a greenfield implementation, a new system without relying on existing infrastructure or code, in low resource settings. This isn’t to say it can’t be applied in other areas, but this is the initial scope. Implementations with existing infrastructure or more available resources may want to review X12N - Insurance, DaVinci Payer Data Exchange (PDex), and/or DaVinci Prior Authorization Support (PAS).
This collection of workflows allows an external system to save and retrieve Finance and Insurance Information. The workflows are designed to support the following types of data exchanges with systems.
A point-of-care system can search for insurance plans to be used for enrolling a beneficiary, the patient whose health care expenses are being covered by the policy.
A point-of-care system can enroll a beneficiary.
A point-of-care system can check a beneficiary’s eligibility for a given healthcare service.
A point-of-care system can run a pre-determination, pre-authorization and claim.
A pre-determination is to determine what services may be covered and to what amount.
A pre-authorization is to receive approval for a service before it happens.
A claim is to request payment for services that have been rendered.
A point-of-care system can track a claim’s status.
1:57.1 FAIS Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this profile.
Further information about actor and transaction definitions can be found
in the IHE Technical Frameworks General Introduction Appendix A: Actors
and Appendix B: Transactions.
The Beneficiary Manager processes requests from the Beneficiary Requestor actor. It follows internal business processes to enroll beneficiaries from the Beneficiary Requestor that are beyond the scope of this profile and will return the result of the enrollment. It also responds to queries about insurance plans.
The Claims Manager processes claims requests from the Claims Requestor and coverage requests from the Coverage Requestor. It follows internal business processes to create the claim that are beyond the scope of this profile. It also responds to claim tracking requests to return the status of the requested claim.
The transactions in this profile are summarized in the sections below.
1:57.1.2.1 Query Insurance Plan Transaction [ITI-121]
This transaction is used to search for available insurance plans. The InsurancePlan resource describes a health insurance offering with a list of covered benefits, costs associated with those benefits, and any additional information about the offering.
This transaction is used to enroll a beneficiary. It is to request linking the beneficiary with a given Coverage that is associated with an InsurancePlan. Once successfully enrolled, the beneficiary can receive covered health care services.
This transaction is used to check the coverage eligibility for a given beneficiary. This can be used to query if a given service is covered by the insurance plan the beneficiary is enrolled in.
These use cases can be combined in an overall workflow for handling beneficiaries and claims. First a beneficiary will be enrolled due to a qualifying life event. When visiting a new doctor or updating an existing one, that office would query the beneficiary details. Before starting a procedure, the provider’s office can check coverage eligibility for the patient and procedure to make sure it’s covered. If the office needs to know the amount that would be covered, they can submit a pre-determination claim. If the procedure needs a pre-authorization, the office would submit a pre-authorization claim. Once the procedure has been completed, the office would submit the claim. If any of the three types of claims aren’t approved immediately or to see where the claim is in the process, the office can track the status of the claim.
Figure 1:57.4.1-1 shows the enrollment workflow.
Figure 1:57.4.1-1: FAIS Enrollment Workflow
Figure 1:57.4.1-2 shows the claims workflow.
Figure 1:57.4.1-1: FAIS Claims Workflow
1:57.4.2 Use Cases
1:57.4.2.1 Use Case #1: Enroll Household or Beneficiary
A field agent of the national insurance provider registers the members of a household into a specific insurance scheme.
1:57.4.2.1.1 Enroll Household or Beneficiary Use Case Description
Amara Nwosu is a field agent for the National Health Insurance Scheme (NHIS)
and is registering a household into the scheme. Amara uses a tablet
to input the beneficiary information in the Financing and Insurance System.
Amara arrives at the home of the beneficiaries who identify themselves with their national ID card(s).
Amara queries the central Finance and Insurance System (FIS) for the appropriate Insurance Plan.
Amara captures all additional data needed for enrollment into a specific insurance scheme and submits it to the central FIS.
The eligibility of the beneficiary for this specific scheme is verified by either manual or automatic processes using the FIS.
If the eligibility criteria are fulfilled, the beneficiary / household is being enrolled into the scheme in the FIS by creating a policy.
Optionally: The FIS updates the insuree or policy number to the client register.
The FIS returns a status notification about the successful enrollment back to the enrollment app.
Amara adds any additional data needed to the beneficiary record.
1:57.4.2.1.2 Enroll Household or Beneficiary Process Flow
App - The point of service system is a Beneficiary Requestor that captures an enrollment request.
FIS - Financing and Insurance System is a Beneficiary Manager that manages data on beneficiaries and their coverage.
Figure 1:57.4.2.1.2-1: Enroll Household or Beneficiary Process Flow in Profile FAIS
1:57.4.2.2 Use Case #2: Check Coverage
A patient is diagnosed with cancer and needs chemotherapy. The hospital inquires about coverage for chemotherapy.
1:57.4.2.2.1 Check Coverage Use Case Description
A patient is diagnosed with cancer in the local hospital. The responsible doctor want to apply a chemotherapy to the patient and needs to know whether the costs are covered by the insurance of the patient.
The patient arrives at the hospital and is diagnosed.
Optionally: the doctor queries the needed procedures and medical items from a product catalog in the Hospital Information System.
Optionally: the hospital information system verifies the product codifications from the FIS.
The doctor selects the needed procedures and items in the POS and sends a coverage eligibility request to the FIS.
In a manual or automatic process, the eligibility for the requested procedures and items is verified in the FIS.
An eligibility response is sent from the FIS to the POS.
The doctor and the patient agree on the further treatment based on the eligibility response.
1:57.4.2.2.2 Check Coverage Process Flow
POS - The point of service system is a Coverage Requestor that captures a patient clinical encounter.
FIS - Financing and Insurance System is a Claims Manager that manages data on beneficiaries and their coverage.
Figure 1:57.4.2.2.2-1: Check Coverage Process Flow in Profile FAIS
1:57.4.2.3 Use Case #3: File a Claim
A patient was treated in the hospital and the hospital requests reimbursement of the incurred costs.
1:57.4.2.3.1 File a Claim Use Case Description
Claiming: a POS system (e.g., Hospital) sends a request for reimbursement of costs incurred for a certain treatment to the FIS
A patient was treated with chemotherapy in their local hospital and cured.
The hospital wants to prepare a hospital bill to reclaim the incurred costs.
Optionally: the hospital admin queries the applied procedures and medical items from a product catalogue in the Hospital Information System (POS).
Optionally: the hospital information system verifies the product codifications from the FIS.
The hospital admin builds a claim with the applied procedures and items in the POS which sends a claim to the FIS.
In a manual or automatic process, the claim is adjudicated in the FIS.
Optionally: a payment request is sent from the FIS to the payment system.
A claim response is sent from the FIS to the POS.
In some instances a claim request may need to be canceled or re-submitted for re-processing. The POS system can send a follow up request to cancel a previously submitted claim. If the claim was rejected and it needs to be re-adjudicated, then the POS can also re-submit the claim to be re-processed.
1:57.4.2.3.2 File a Claim Process Flow
POS - The point of service system is a Claims Requestor that captures a patient clinical encounter and sends the formatted claim.
FIS - Financing and Insurance System is a Claims Manager that manages the claims processing and scrutinization.
EXT - An external payment layer
Figure 1:57.4.2.3.2-1: File a Claim Process Flow in Profile FAIS
1:57.4.2.4 Use Case #4: Pre Determination
An expensive treatment is needed and the Hospital wants to estimate the inputs they can apply.
1:57.4.2.4.1 Pre Determination Use Case Description
Pre-determination: A POS system (e.g., Hospital) requests an estimation of the expected reimbursement for a beneficiary’s specific treatment from the FIS (e.g., Insurance).
A patient needs to be treated with chemotherapy in their local hospital.
The hospital wants to inquire whether the expected reimbursement will cover the expected costs.
Optionally: the hospital admin queries the planned procedures and medical items from a product catalogue in the Hospital Information System (POS).
Optionally: the hospital information system verifies the product codifications from the FIS.
The hospital admin builds a pre-determination with the planned procedures and items in the POS which sends it to the FIS.
In a manual or automatic process, the pre-determination is adjudicated in the FIS.
A pre-determination result is sent from the FIS to the POS.
1:57.4.2.4.2 Pre Determination Process Flow
POS - The point of service system is a Claims Requestor that captures a patient clinical encounter and sends the formatted claim.
FIS - Financing and Insurance System is a Claims Manager that manages the claims processing and scrutinization.
Figure 1:57.4.2.4.2-1: Pre Determination Process Flow in Profile FAIS
1:57.4.2.5 Use Case #5: Pre Authorization
A costly treatment is needed and has to be pre-approved by the insurance before it can be done.
A patient needs to be treated with chemotherapy in their local hospital.
The hospital wants to confirm from the insurance that the costs for the treatment will be covered.
Optionally: the hospital admin queries the planned procedures and medical items from a product catalogue in the Hospital Information System (POS).
Optionally: the hospital information system verifies the product codifications from the FIS.
The hospital admin builds a pre-authorization with the planned procedures and items in the POS which sends it to the FIS.
In a manual or automatic process, the pre-authorization is adjudicated in the FIS.
A pre-authorization result is sent from the FIS to the POS.
1:57.4.2.5.1 Pre Authorization Use Case Description
Pre-authorization: A POS system (e.g., Hospital) requests an approval for a specific treatment from the FIS (e.g., Insurance). At the FIS a manual intervention is needed to authorize the requested
1:57.4.2.5.2 Pre Authorization Process Flow
POS - The point of service system is a Claims Requestor that captures a patient clinical encounter and sends the formatted claim.
FIS - Financing and Insurance System is a Claims Manager that manages the claims processing and scrutinization.
Figure 1:57.4.2.5.2-1: Pre Authorization Process Flow in Profile FAIS
1:57.4.2.6 Use Case #6: Claim Tracking
Request the current processing status of a claim in the FIS.
1:57.4.2.6.1 Claim Tracking Use Case Description
A hospital has sent an electronic reimbursement claim to the insurance company. After a waiting period the hospital wants to verify if the claim was processed.
A patient was treated with chemotherapy in their local hospital.
The hospital has sent a claim to the insurer a few days ago and stored the queued claim ID in the hospital IS (=POS).
The hospital wants to confirm the processing status from the insurance.
The hospital admin sends a claim response query with the claim ID from the POS to the FIS.
In an automated process, the FIS looks up the claim status.
A claim response is sent from the FIS to the POS.
1:57.4.2.6.2 Claim Tracking Process Flow
POS - The point of service system is a Claims Requestor that has formulated a claim and waits for a response from the FIS.
FIS - Financing and Insurance System is a Claims Manager that manages the claims processing and scrutinization.
Figure 1:57.4.2.6.2-1: Claim Tracking Process Flow in Profile FAIS
The resources exchanged in this profile may contain information which pose a privacy risk. This includes PII for the beneficiaries as well as information about performed procedures.
There are many reasonable methods of security for interoperability transactions which can be implemented without modifying the characteristics of the transactions in this profile. The use of TLS is encouraged, specifically the use of the ATNA Profile (see ITI TF-1: 9).
User authentication on mobile devices and browsers is typically handled by more lightweight authentication schemes such as HTTP Authentication, OAuth 2.0, or OpenID Connect. IHE has a set of profiles for user authentication including Internet User Authentication (IUA) for REST-based authentication. The network communication security and user authentication are layered in the HTTP transport layer.
1:57.6 FAIS Cross-Profile Considerations
1:57.6.1 Patient Demographics Query for Mobile – PDQm
A Beneficiary Requestor or Beneficiary Manager could be grouped with a PDQm Patient Demographics Consumer to look up or validate beneficiary demographic details.
1:57.6.2 Patient Identifier Cross-reference for Mobile – PIXm
A Beneficiary Requestor or Beneficiary Manager could be grouped with a PIXm Patient Identifier Cross-reference Consumer to look up additional beneficiary identifiers. The Beneficiary Manager could also be grouped with a PIXm Patient Identity Source to add the beneficiary identifier using the Patient Identity Feed FHIR [ITI-104].
1:57.6.3 Patient Master Identity Registry – PMIR
A Beneficiary Requestor or Beneficiary Manager could also be grouped with a Patient Demographics Consumer or Patient Identifier Cross-reference Consumer in PMIR to perform the same queries as the previous sections on PDQm and PIXm. The Beneficiary Manager MAY be grouped with a PMIR Patient Identity Consumer to subscribe to updates from the PMIR Patient Identity Registry. The Beneficiary Manager could also be grouped with a PMIR Patient Identity Source to update patient details in the Patient Identity Registry using Mobile Patient Identity Feed [ITI-93].
1:57.6.4 Mobile Care Services Discovery – mCSD
Any of the actors in this profile may need to look up other resources using mCSD, for example, for Practitioners, Facilities, or Organizations. The Requestor actors could also look up the correct Endpoint for submitting the Beneficiary or Claims transaction from the Manager actors.
|
Propose a change