Finance and Insurance Service (FAIS)
1.0.0-comment - ballot International flag

This page is part of the IHE ITI Finance and Insurance Services (v1.0.0-comment: Publication Ballot 1) 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

1:XX Finance and Insurance Service (FAIS)

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 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 in emerging markets. This isn’t to say it can’t be applied in other areas, but this is the initial scope.

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.

  1. A point-of-care system can enroll a beneficiary
  2. A point-of-care system can check a beneficiary’s eligibility
  3. A point-of-care system can run a pre-determination, pre-authorization and claim
  4. A point-of-care system can track a claim’s status

1:XX.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.

Figure 1:XX.1-1 below shows the actors directly involved in the Finance and Insurance Service Profile and the relevant transactions between them.

  BeneficiaryRequestorCoverageRequestorClaimsRequestor BeneficiaryManagerClaimsManagerBenefitsCoverageClaimsBenefitsClaimsClaimsQuery Insurance Plan ITI-YY2Enroll Beneficiary ITI-YY1Check Enrollment Status ITI-YY3Check Coverage Eligibility ITI-YY4Check Coverage Eligibility Status ITI-YY7Submit Claim ITI-YY5Cancel Claim ITI-YY8Re-process Claim ITI-YY9Track Claim ITI-YY6
Figure 1:XX.1-1: FAIS Actor Diagram


Table 1:XX.1-1: FAIS - Actors and Transactions

Actors Transactions Initiator or Responder Optionality Reference
Beneficiary Requestor Query Insurance Plan Initiator O FAIS TF-2: 3.YY2
  Enroll Beneficiary Initiator R FAIS TF-2: 3.YY1
  Check Enrollment Status Initiator O FAIS TF-2: 3.YY3
Beneficiary Manager Query Insurance Plan Responder R FAIS TF-2: 3.YY2
  Enroll Beneficiary Responder R FAIS TF-2: 3.YY1
  Check Enrollment Status Responder R FAIS TF-2: 3.YY3
Coverage Requestor Check Coverage Eligibility Initiator R FAIS TF-2: 3.YY4
  Check Coverage Eligibility Status Initiator O FAIS TF-2: 3.YY7
Claims Requestor Submit Claim Initiator R FAIS TF-2: 3.YY5
  Cancel Claim Initiator R FAIS TF-2: 3.YY8
  Re-process Claim Initiator R FAIS TF-2: 3.YY9
  Track Claim Initiator O FAIS TF-2: 3.YY6
Claims Manager Check Coverage Eligibility Responder R FAIS TF-2: 3.YY4
  Check Coverage Eligibility Status Responder R FAIS TF-2: 3.YY7
  Submit Claim Responder R FAIS TF-2: 3.YY5
  Cancel Claim Responder R FAIS TF-2: 3.YY8
  Re-process Claim Responder R FAIS TF-2: 3.YY9
  Track Claim Responder R FAIS TF-2: 3.YY6

1:XX.1.1 Actors

The actors in this profile are described in more detail in the sections below.

1:XX.1.1.1 Beneficiary Requestor

The Beneficiary Requestor can enroll beneficiaries and optionally query insurance plans from a Beneficiary Manager.

FHIR Capability Statement for Beneficiary Requestor

1:XX.1.1.2 Beneficiary Manager

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.

FHIR Capability Statement for Beneficiary Manager

1:XX.1.1.3 Coverage Requestor

The Coverage Requestor can check the coverage eligibility of beneficiaries from a Claims Manager.

FHIR Capability Statement for Coverage Requestor

1:XX.1.1.4 Claims Requestor

The Claims Requestor submits and tracks claims from the Claims Manager.

FHIR Capability Statement for Claims Requestor

1:XX.1.1.5 Claims Manager

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.

FHIR Capability Statement for Claims Manager

1:XX.1.2 Transaction Descriptions

The transactions in this profile are summarized in the sections below.

1:XX.1.2.1 Query Insurance Plan Transaction

This transaction is used to search for available insurance plans.

For more details see the detailed transaction description

1:XX.1.2.2 Enroll Beneficiary Transaction

This transaction is used to enroll or update a beneficiary.

For more details see the detailed transaction description

1:XX.1.2.3 Check Enrollment Status Transaction

This transaction is used to check the status of an enrollment.

For more details see the detailed transaction description

1:XX.1.2.4 Check Coverage Eligibility Transaction

This transaction is used to check the coverage eligibility for a given beneficiary.

For more details see the detailed transaction description

1:XX.1.2.5 Check Coverage Eligibility Status Transaction

This transaction is used to check the status of a coverage eligibility request.

For more details see the detailed transaction description

1:XX.1.2.6 Submit Claim Transaction

This transaction is used to submit a claim. This can be either a pre-determination, pre-authorization, or a final claim ready for payment.

For more details see the detailed transaction description

1:XX.1.2.7 Cancel Claim Transaction

This transaction is used to cancel a previously submitted claim.

For more details see the detailed transaction description

1:XX.1.2.8 Re-process Claim Transaction

This transaction is used to re-process a previously submitted claim that was denied.

For more details see the detailed transaction description

1:XX.1.2.9 Track Claim Transaction

This transaction is used to return the status of a given claim.

For more details see the detailed transaction description

1:XX.2 FAIS Actor Options

No options.

1:XX.3 FAIS Required Actor Groupings

No required actor groupings.

1:XX.4 FAIS Overview

1:XX.4.1 Concepts

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:XX.4.1-1 shows the enrollment workflow.

Enroll Beneficiary Workflowcollect beneficiary dataquery insurance plansITI-YY2build enrollment requestsubmit enrollment requestITI-YY1query response updatesITI-YY3queuedprocess results ?completedprocess enrollment response
Figure 1:XX.4.1-1: FAIS Enrollment Workflow

Figure 1:XX.4.1-2 shows the claims workflow.

Claims Workflowpatient makes appointmentsubmit coverage eligibility requestITI-YY4query response updatesITI-YY7queuedcheck results ?completedprocess eligibility responseeligibility ?coverednot coveredpatient clinical visitservice needs pre-determination ?yesnosubmit pre-determination claimITI-YY5track claimITI-YY6queuedcheck results ?completedprocess pre-determination responsecontinue serviceservice needs pre-authorization ?yesnosubmit pre-authorization claimITI-YY5track claimITI-YY6queuedcheck results ?completedprocess pre-authorization responsecontinue serviceservice completesubmit claimITI-YY5cancel claimITI-YY8yesclaim is cancelled ?track claimITI-YY6queuedcheck results ?completedre-process claimITI-YY9track claimITI-YY6queuedcheck results ?completedyesclaim is denied ?process claim responsenotify patient
Figure 1:XX.4.1-1: FAIS Claims Workflow


1:XX.4.2 Use Cases

1:XX.4.2.1 Use Case #1: Enroll Household or Beneficiary

A field agent of the national insurance provider registers a household into a specific insurance scheme.

1:XX.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.

  1. Amara arrives at the home of the beneficiaries who identify themselves with their national ID card(s).
  2. Amara queries the central Finance and Insurance System (FIS) for the appropriate Insurance Plan.
  3. Amara captures all additional data needed for enrollment into a specific insurance scheme and submits it to the central FIS.
  4. The eligibility of the beneficiary for this specific scheme is verified by either manual or automatic processes using the FIS.
  5. If the eligibility criteria are fulfilled, the beneficiary / household is being enrolled into the scheme in the FIS by creating a policy.
  6. Optionally: The FIS updates the insuree or policy number to the client register.
  7. The FIS returns a status notification about the successful enrollment back to the enrollment app.
  8. Amara adds any additional data needed to the beneficiary record.
1:XX.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.
AppBeneficiary RequestorPatient Demographics ConsumerPatient Identity SourceFISBeneficiary ManagerClient RegistryPatient Identity Registryopt[Demographics Lookup][1]Query for beneficiary demographicsITI-78 Mobile Patient Demographics Query request[2]Return Demographics DetailsITI-78 Mobile Patient Demographics Query response[3]Capture additional data[4]Search for Insurance PlansITI-YY2 Query Insurance Plan request[5]Return Insurance PlansITI-YY2 Query Insurance Plan response[6]Compile Enrollment Request[7]Submit enrollmentITI-YY1 Enroll Beneficiary request[8]Verify eligibilityalt[Success][9]Process enrollment[10]Return positive enrollment responseITI-YY1 Enroll Beneficiary response[11]Add details to patient recordopt[12]Add beneficiary ID to registryITI-93 Mobile Patient Identity Feed[Validation Error][13]Return negative enrollment responseITI-YY1 Enroll Beneficiary response
Figure 1:XX.4.2.1.2-1: Enroll Household or Beneficiary Process Flow in Profile FAIS


1:XX.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:XX.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.

  1. The patient arrives at the hospital and is diagnosed.
  2. Optionally: the doctor queries the needed procedures and medical items from a product catalog in the Hospital Information System (POS).
  3. Optionally: the hospital information system verifies the product codifications from the FIS.
  4. The doctor selects the needed procedures and items in the POS and sends a coverage eligibility request to the FIS.
  5. In a manual or automatic process, the eligibility for the requested procedures and items is verified in the FIS.
  6. An eligibility response is sent from the FIS to the POS.
  7. The doctor and the patient agree on the further treatment based on the eligibility response.
1:XX.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.
PoSCoverage RequestorFISClaims Manageropt[Get code lists for Medical Procedures & Items][1]Lookup Medical Procedures & Items codes[2]Verify codes[3]Confirm codes[4]Submit Coverage Eligibility QueryITI-YY4 Check Coverage Eligibility request[5]Process Insuree Query[6]Process Policy Query[7]Return Coverage Eligibility ResultITI-YY4 Check Coverage Eligibility response
Figure 1:XX.4.2.2.2-1: Check Coverage Process Flow in Profile FAIS


1:XX.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:XX.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

  1. A patient was treated with chemotherapy in their local hospital and cured.
  2. The hospital wants to prepare a hospital bill to reclaim the incurred costs.
  3. Optionally: the hospital admin queries the applied procedures and medical items from a product catalogue in the Hospital Information System (POS).
  4. Optionally: the hospital information system verifies the product codifications from the FIS.
  5. The hospital admin builds a claim with the applied procedures and items in the POS which sends a claim to the FIS.
  6. In a manual or automatic process, the claim is adjudicated in the FIS.
  7. Optionally: a payment request is sent from the FIS to the payment system.
  8. 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:XX.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
PoSClaims RequestorFISClaims ManagerExternal Payment SystemFisopt[Get code lists for Medical Procedures & Items][1]Lookup Medical Procedures & Items codes[2]Verify codes[3]Confirm codes[4]Build claim[5]Submit claimITI-YY5 Submit Claim request[6]Process claimalt[accepted]opt[Payout][7]Send payment request[8]Process payment[9]Return positive claim resultITI-YY5 Submit Claim response[rejected][10]Return negative claim resultITI-YY5 Submit Claim responseopt[Re-process claim][11]Re-submit claim for re-processingITI-YY9 Re-process Claim request[12]Return claim re-process responseITI-YY9 Re-processUpdate Claim response[queued][13]Return queued status notificationITI-YY5 Submit Claim responseopt[Cancel claim][14]Cancel claimITI-YY8 Cancel Claim request[15]Return claim cancellation responseITI-YY8 Cancel Claim response
Figure 1:XX.4.2.3.2-1: File a Claim Process Flow in Profile FAIS


1:XX.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:XX.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).

  1. A patient needs to be treated with chemotherapy in their local hospital.
  2. The hospital wants to inquire whether the expected reimbursement will cover the expected costs.
  3. Optionally: the hospital admin queries the planned procedures and medical items from a product catalogue in the Hospital Information System (POS).
  4. Optionally: the hospital information system verifies the product codifications from the FIS.
  5. The hospital admin builds a pre-determination with the planned procedures and items in the POS which sends it to the FIS.
  6. In a manual or automatic process, the pre-determination is adjudicated in the FIS.
  7. A pre-determination result is sent from the FIS to the POS.
1:XX.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.
PoSFISopt[Get code lists for medical procedures & items][1]Submit medical procedures & items query[2]Process query[3]Return medical procedures & items[4]Build pre-determination[5]Submit pre-determinationITI-YY5 Submit Claim request[6]Process pre-determiniationalt[accepted][7]Return positive pre-determination resultITI-YY5 Submit Claim response[rejected][8]Return negative pre-determination resultITI-YY5 Submit Claim response[queued][9]Return queued status notificationITI-YY5 Submit Claim response
Figure 1:XX.4.2.4.2-1: Pre Determination Process Flow in Profile FAIS


1:XX.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.

  1. A patient needs to be treated with chemotherapy in their local hospital.
  2. The hospital wants to confirm from the insurance that the costs for the treatment will be covered.
  3. Optionally: the hospital admin queries the planned procedures and medical items from a product catalogue in the Hospital Information System (POS).
  4. Optionally: the hospital information system verifies the product codifications from the FIS.
  5. The hospital admin builds a pre-authorization with the planned procedures and items in the POS which sends it to the FIS.
  6. In a manual or automatic process, the pre-authorization is adjudicated in the FIS.
  7. A pre-authorization result is sent from the FIS to the POS.
1:XX.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:XX.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.
PoSFISopt[Get code lists for medical procedures & items][1]Submit medical procedures & items query[2]Process query[3]Return medical procedures & items[4]Build pre-authorization[5]Submit pre-authorizationITI-YY5 Submit Claim request[6]Process pre-authorizationalt[accepted][7]Return positive pre-authorization resultITI-YY5 Submit Claim response[rejected][8]Return negative pre-authorization resultITI-YY5 Submit Claim response[queued][9]Return queued status notificationITI-YY5 Submit Claim response
Figure 1:XX.4.2.5.2-1: Pre Authorization Process Flow in Profile FAIS


1:XX.4.2.6 Use Case #6: Claim Tracking

Request the current processing status of a claim in the FIS

1:XX.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.

  1. A patient was treated with chemotherapy in their local hospital.
  2. The hospital has sent a claim to the insurer a few days ago and stored the queued claim ID in the hospital IS (=POS).
  3. The hospital wants to confirm the processing status from the insurance.
  4. The hospital admin sends a claim response query with the claim ID from the POS to the FIS.
  5. In an automated process, the FIS looks up the claim status.
  6. A claim response is sent from the FIS to the POS.
1:XX.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.
PoSFIS[1]Submit claim response query (Claim ID)ITI-YY6 Track Claim request[2]Process queryalt[accepted][3]Return positive claim resultITI-YY6 Track Claim response[rejected][4]Return negative claim resultITI-YY6 Track Claim response[queued][5]Return queued status notificationITI-YY6 Track Claim response[not found][6]Return not found notificationITI-YY6 Track Claim response
Figure 1:XX.4.2.6.2-1: Claim Tracking Process Flow in Profile FAIS


1:XX.5 FAIS Security Considerations

See ITI TF-2x: Appendix Z.8 “Mobile Security Considerations”

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:XX.6 FAIS Cross-Profile Considerations

1:XX.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:XX.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:XX.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:XX.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. They Requestor actors could also look up the correct Endpoint for submitting the Beneficiary or Claims transaction from the Manager actors.