Comprehensive Health Insurance TPA Software

Client is a service-based organisation with offices in Hyderabad, New Delhi, Mumbai and branches across the country. It is in the business of providing third party administration services to Insurance companies into the domain of Health Insurance. ZAAX Consulting PL (ZCPL) would like to develop a comprehensive online software solution to automate its entire operations from collection of policies to underwriting, issuance of cards, claims processing, Accounts, CRM and performance monitoring. The objective of this software is to increase the efficiency of operations and to drastically cut down the response time to the policyholders as well as to the insurance companies and network hospital as these are the three basic and major entities in whole system.

The system is proposed to be built on Java Platform. This platform gives us the flexibility of speed, scalability, security, performance and allows for independence of hardware, CPU, platforms. Unlike .NET/Windows, JAVA platform does not have per user license issues and is not limited to specific operating systems. The system shall be developed using industry standard MVC architecture using a templating engine, a model, view and controller for each module and sub-module.

Oracle 11g is proposed as the database server.
Glassfish or JBoss proposed as the application server.
Intel or AMD 64bit hardware architecture is proposed.

The process starts with a contract entered with an Insurance company to provide third party administration services to its policyholders in a designated area. The contract can be with a new company for a designated area of operations or with an existing client for a new area. The Head office (HO) is the national headquarters of the insurance company. These insurance companies divide their geographical area of operations into regions, which are served by the Regional office (RO). Each regional office has a number of divisional offices (DO) under it. The divisional offices have a number of Branch offices (BO) or Direct agent branches (DAB) under it. Once the contract is signed with an insurance company the data related to the offices of the company within the specified territory assigned to ICare will be captured and maintained by the System Administrator. This will include:

• The contact details of the Head office of the company
• The contact details of the Regional offices that fall within the territory
• The contact details of the Divisional office within the territory
• The contact details of the Branch office and the Direct agent branches within the territory.

Policy Collection

Once a contract is signed, the collection team of ICare starts moving to the respective issuing offices of the insurance company in the region to collect new policies. This module covers the following activities:

• Logging all the policies collected by the collection agents from an office in a day
• Logging the details of whether the supporting documents of each life has been received by the issuing office
• Logging the time and date of receipt of each policy and its supporting document
• Generation of report of all the policies received from a specific issuing office on a pre-defined period basis
• A daily report will be generated highlighting policies which are not accompanied with the supporting document specially the photograph so that the collection agent can collect the same in the, next visit.
• Collection team will update the collection database once they obtain the missing data.

Policy Underwriting

This module basically involves capturing the entire data available for each insurance policy and each life that is insured by the underwriters. It serves as the master database from which the claims team derives all the information required for processing of claims. The main activities involved in this process are: All the policies are classified appropriately and their data is captured. The policies can be Individual policies or group policies. Individual policy parameters are standard for all the GICs while in the case of group, the policies are tailor-made though usually within predefined parameters. Now lot of policies are coming with different specification so we have to develop according to need. Individual policies may be either new policies, renewal policies or transfer policy and with individual sum insured, family floater sum insured. However group policies having Disease floater, Corporate floater and includes all the types sum insured of individual policies.

The form for feeding data for an individual policy will be a standard form which will capture data relating to issuing office, insured person, dependants, Policy type whether there is any endorsement or not, details of sum insured, net premium, details of pre existing diseases etc.

• In the case of a renewal policy, some extra details will be captured to maintain a history of the policy. These include the year of inception of policy, claims made by the insured, claims approved, cumulative bonus. This information will help ICare to maintain a database of the past history of the insured and also to evaluate the claims raised in light of the past history.
• The submission of the underwriting form will generate a unique INSURED ID No. for each of the life that is covered in the policy. This no. will be used as the identification number at ICare for each life insured. The Insured ID will remain same even if the policy will be renewed by different underwriter for the next year.
• In case of renewal policies, which have come to ICare for the second year, a provision will be made to link the past insurance history of the insured.
• In case of Group policies, certain additional information will be captured that is related to the details of the company, which has signed up, with the insurance company for a policy for its employees. Also the location of the employee covered will be captured as the groups usually go in for one policy for all their employees nationwide.
• Group policies may be standard group policies with the option of going for maternity benefits or group policies may be tailor-made with number of options from which the group can choose from. These include options like family floater, company floater and major disease floater. Certain other options may include cover for dental problems, optical problems or cover for pre-existing diseases. An effort will be made to capture all the currents options available and their different permutations and combinations so that a standard form is available for filling in the data of group policyholders.
• In the case of groups also, a unique INSURED ID no. will be generated for each life insured.
• A log will be kept as to the date and time at which the details of a policy are fed into the software. This will help in identifying when a policy was issued, when it was received by ICare and also to measure the turnaround time of feeding the policy details into the system as and when it arrives.
• In terms of feeding data for a large group we will make a suitable system where entry becomes faster like possibilities of importing data from excel sheet.

Cards and record section is involved in keeping the physical files of all the policies hat arrive and also involved in issuing cards and dispatching them to the insured. This module will cover the following activities:

• Cards team will check on a daily basis from the underwriting database as to the number of new policies that have been fed into the system along with key policy details that are required for generation of cards.
• This report will have a clear segregation of all the policies that have photographs and the other necessary information to issue a card. Cards are issued to only those policyholders who have provided their photograph.
• Reminders will be sent to the collection team for all those policyholders whose photograph has not been received.
• A card-printing interface will be present in the system for printing of the cards in the predefined format. The cards will be printed by the cards team in house and dispatched to the policyholders.
• A log will be maintained in the system to record the date and time of dispatch of each and every card that is issued.
• If any card is returned back either because of an error in the data or because of change in address etc, record will be kept of the same.
• In case of return of card because of error in data, the necessary correction will be made; card will be reprinted and dispatched.
• In case of a return of card because the courier due didn't deliver it to change in address etc., it will be forwarded to the insurance office that issued the policy for handing it over to the policyholder. A record of the same will be maintained in the system.
• If case a query is raised with the insurance company because the faulty data in the card was taken from the policy, such queries will be recorded for the date and time of the query.

Claims

The claims team is involved in authorising a claim that comes from any of the policyholders and to settle the claim. Authorisation is required in case the patient wants to avail of the cashless benefit in any of the network hospitals. In case the patient has sought treatment in a non-network hospital, the claim is raised after the patient is discharged from the hospital. However the patient may choose to intimate ICare regarding the forthcoming claim. Third option for the policyholder is to avail of the services from any hospital at his own expenses and then raise the claim for reimbursement without Intimating ICare in advance. Claims will be automatically soft adjudicated when ever possible.The following activities are covered in the claims modules:

Registration of claim

• The registration data captured will include the basic identity of the patient and the insured, the INSURED ID no., policy number, the issuing office, the disease, name of the hospital, the contact numbers and the estimated cost of hospitalisation. It will also provide interface to capture additional data, which will enable the claims team to identify the insured and to realise whether the claim is a responsibility of ICare, or not.
• The registration interface will also have the option for choosing whether it is an authorisation request or an intimation request.
• Once this form is filled in and submitted a claim control number will be generated.
• All valid policyholders are the responsibility of ICare irrespective of whether ICare has received the policy from the insurance company or not. The underwriting database will be checked for a valid INSURED ID no. to determine that the policy is the responsibility of ICare.
• In case the INSURED ID no. is not there in the database, the collection database will be checked to determine whether the policy has been received from he insurance company. If the policy has been received, then the underwriting team will be informed to enter the policy information immediately.
• In case the policy has not been received by ICare from the insurance company, a query will be sent to the company based on the data captured from the registration interface for determining whether the patient has a valid policy or not.
• If the insurance company replies back that the patient does not have a policy with them, the claim will be denied.
• For valid policyholders whose data is not in the ICare system, the information will be will be forwarded to the collection team to collect the policy from the company immediately and send it to the underwriting team.
• If the date of issue of the policy is less than 60 days before the intimation or hospitalisation request is made, it will be checked with the insurance company whether the policy is 64 vb compliant.
• In case the date of issue of policy is less than 30 days before the intimation or authorisation request is made and it is determined that it is not a renewed policy, then the claim will not be admissible.
• A daily report will be generated for all policies, which have not yet been underwritten, but a claim has been filed against them highlighting the various stages at which the policy may be at that time.

Intimation

• Once the patient is identified as a valid policyholder and it is seen that it is a case of intimation of hospitalisation, a covering letter will be issued to the insured along with a disbursement voucher and a claim form to be filled in and sent back to ICare.
• If it is determined that the patient has been hospitalised in a network hospital but has gone for intimation of claim rather than authorisation, then the system will provide mechanism for converting the claim request into an authorisation request.
• In case it is determined that the patient intimating a claim does not have any balance limit in his account from the total sum insured, a denial letter will be issued saying that the claim is not admissible as there is no balance left to avail of it.
• In case the physical claim is not received from the insured within 15 days of dispatch of the claim form, a reminder will be printed and send to the patient.
• If the letter dispatched to the patient is returned undelivered, a query will be sent to the insurance company to confirm the address of the patient.
• A record will be maintained of all the letters that have been sent to the insured, hospital or Insurance Company with the date of dispatch of the letters. A record of all undelivered letters has will be maintained.

• On Line Authorisation for Network Hospital- The total authorisation process will be online and request will be processed instantly by the system which will be the USP of ICare.
• Once a patient has been identified as a valid policyholder and it is seen that it is a case of authorisation, it will first check whether the name of the hospital is in the list of network hospitals. If so then the application will be processed further. However, if the hospital is not in the list it will be treated as an intimation rather than authorisation.
• The next step will be to check for 64vb compliance and to see whether the date of issue of policy is more than 30 days before the request for authorisation is made. If both the factors are satisfied, the request will be processed further.
• In case, the policy date is less than 30 days before the request of authorisation, then it will be checked whether it is a new policy or a renewal policy. If it is a new policy the authorisation will be denied.
• If it is a renewal policy, a search will be also made for the past claims of the insured for the medical history from the date of inception of the policy and also the details of pre existing disease when the policy was first issued. If such information is not available with ICare, a query will be sent to the insurance company.
• The Doctors will verify whether the claim is related to any pre existing disease or not. They will also verify whether the insurance regulations allow approval of claims related to the nature of the ailment for which authorisation is sought by the patient.
• The Doctors will go through the past medical and claims history of the patient to see if claims related to the similar medical history have been requested by the patient in the past and whether they were approved or denied by the insurance company or ICare previously. In case the previous history is not available in the system, then a query for the same is sent to the insurance company.
• The doctors from the claims team will then record the details related to the patient in the authorisation interface. These include the disease name, proximate cause of hospitalisation, expected duration of hospitalisation and the amount to be authorised. The calculation for the amount to be authorised can be done on the same interface.
• The Doctors from the claims panel of ICare may verify with the hospital about the status of the patient, which can be entered into the system.
• The data related to the past claims of the patient will be visible to the claims team who can ascertain if there is any balance left in the account of the patient to authorise the claim. In case there is no balance left authorisation is denied.
• If there is any balance left it will be compared to the amount authorised by the doctors and if the balance is less than the amount authorised, then the authorisation will be approved only for the amount of balance left and the hospital will be intimated that the amount of expenses over the balance has to be billed to the patient directly.
• If the amount authorised by the Doctor is less than the balance amount left in the patient's total sum insured, a letter for authorisation will be issued to the hospital for the authorised amount.
• After an authorisation is issued by ICare for a particular amount and duration of hospitalisation, it is possible that the patient may not recover enough to be discharged from the hospital and further authorisation may be sought by the hospital for the same patient and same disease. This is termed as reauthorisation. It is also possible that the hospital, which has first sought authorisation, may fail to treat the patient and may refer the patient to another hospital. The second hospital may again seek authorisation from ICare for the same patient and disease. This also falls under the category of reauthorisation.

Reauthorisation request will be treated as a part of the same authorisation and will be issued a sub claim control number if applied for within a fixed span of time. The same process will be followed for reauthorisation claims as for authorisation claims.

• A record of all the letters, queries and other communication that is carried out with the insured, hospital or the insurance company will be maintained in the system.
• A record will also be maintained of all the verification activities conducted by the claim team related to all the authorisation claims.
• In case the hospital has not sent the claim within seven days from the date of discharge of the patient from the hospital, a reminder will be sent to the hospital.

Claims Processing

Claims processing starts with the receipt of a physical claim with the bills from an insured or the hospital. This could be a claim, which has been raised directly or one, which was intimated earlier. A hospital will send claims related to the authorisations it had received.

• In case of intimation or authorisation, the system will display all existing claim info on the basis of claim control number or INSURED ID no. if the claim control no. is not mentioned on the claim form. In case no matching record is found, then it will be treated as a direct claim, which will be first registered, and a claim control number will be assigned to it.
• The claim will be then checked to see if all the supporting documents are in place. These include the disbursement voucher, the hospital bill, intimation or authorisation letter, receipt of hospital bill etc.
• If the claim form is complete in all respects and the supporting documents are in place, the claim will be entered into the system. If the documents are found to be incomplete, a communication will be sent to the patient / hospital to send the complete documentation.
• In case of a direct claim the same verification process of the policy, the past medical history and the balance limit will be done as is done in the case of authorisation.
• The completed claim information (with all supporting documents) will be reviewed by the panel of doctors. They may either approve the claim with the authorised amount to be paid, or deny the claim or raise a query with the insurance company, the insured or the hospital.
• In case the claim is approved, a letter will be generated with the details of the claim amount and the amount to be actually paid out to the patient or the hospital.
• In case a query is raised with any of the parties involved, records of all queries raised with their date and time will be maintained in the system. A record of all the responses of such queries will be maintained in the system as and when they are received.
• In case the claim has been denied, the process sheet will be printed and will be sent to the insurance company along with a forwarding letter.
• The letter of denial of claim will be issued only after the insurance company consents to it.
• Claims for hospitalisation may be followed by claims for pre as well as post hospitalisation treatment for the disease, which have the same proximate cause. These claims are admissible if and only if they are for the treatment availed of either 30 days before or 30 days after hospitalisation. Also these are admissible only if they are received after the receipt of the claim for hospitalisation.

Audit Trail

Once the claim processing is completed, the claim comes for audit purpose. The role of auditor is to cross verify all the important transactions happened in that claim. It starts from name, sum insured, balance limit, policy terms to disease and conditions and physical verification of claim file. Once auditor is satisfied then it moves to account for cheque printing. However auditor can send back the file to doctors with his remarks.

Accounts

The Accounts module covers the following activities.

• As soon as the claims team approves a claim for payment, the details will be available to the accounts team, which will prepare the cheque and enter the details of the cheque in an interface provided for this purpose. This interface will capture the amount of payment, the cheque number, the date of the cheque and the addressee in whose favour the cheque is being prepared along with the claim control no.
• Accounts people will manage the float completely.
• They also check and print cheque and despatch to the insured
• Reconciliation with bank

CRM Helpdesk

The CRM module will support the following functionalities.

• The CRM team will have access to the status of all the policies once the collection team has brought them in. They will have a search screen that will enable them to identify when the policy has come in, when the details have been uploaded in underwriting database and when the cards have been issued and dispatched. The CRM team will be able to search and identify a policy based on a number of parameters like policy no. name of insured, issuing office etc. to zero in on a policy even if the INSURED ID no. has not been issued yet.
• The CRM team will also have access to the status of all the claims that have come in including the authorisation requests, the intimation cases and the physical claims. They will be able to search and identify the claims based on a number of parameters like claim control no., the INSURED ID no., the policy number etc.
• The CRM team will also have access to the entire details of a policyholder along with the policy details, the claims filed, the claims approved and also the status of the different claims at any point of time through very effective search screens.
• The CRM team will also have an interface to log all the queries they receive through telephones, fax or emails. They will be able to capture the key information regarding the person who has raised the query along with the query. In case a query comes in for a specific policyholder the query can be linked to the policy details by capturing the INSURED ID no., policy number, claim control number etc.
• All queries will be tracked in a threaded manner so that they can be so that it can be clearly tracked as to when the queries came in and when they were resolved.
• The queries can be prioritised based on the person or organisation that raised the query so that the management can identify whether the query has come from a policyholder, a senior manager from an insurance company, an official from IRDA, an HR manager from a corporate client etc.

MIS Reports

The system will allow for the creation of a number of reports, which are for the Insurance companies, the IRDA, the hospitals, the corporate clients and for the Management.

• Separate monthly reports are created for the Branch Office, the divisional office and the regional office of the insurance companies.

Work Flow Management

In this module we will cover basically the claims part which includes queuing of jobs, allocation of jobs, escalation of jobs if not attended in a particular time limit and monitoring of job. This process involves scratch from registration of claims to despatch of cheques. Some of the functionalities of this module are

• Defining of all users and their role strictly so that jobs will be assigned by the system itself. Have to implement the logic whether the allocation of jobs will be automatic or there should be some manual intervention or to pick a job by the operator.
• Defining all process involved with certain time limit so that system can generate some alert if any jobs fails to maintain the time limit.
• Once the job will not finished in time then there will be an escalation matrix which has to be escalated to the concerned person.
• Final process will involve monitoring of each work like average TAT, user performance etc.

IVR Interface and Call Analysis

The application will be designed & developed to provide IVRS interface to allow accepting queries over phone (by dialling no.), verify the input received and extract relevant message to be played over phone as response. The numbers will come from the system database. These numbers will be converted into the audio for playing over the telephone line. To achieve this, audio recording would be carried out and stored in the database and the application server will be integrated with an Interactive Voice Recognition (IVR) card. Further we can design a report where certain statistics can be prepared However this will need further discussion to finalise the requirement.

User Role (Admin Module)

This module will assist in defining the different access levels for the employees and Management. The administrator can use the module to carry out the following functionality.

• Create unique user ids and passwords for different users
• Define different access levels for different users
• Modify the authorisation levels of different users

CRM & Grievance

Apart from CRM functionality this module will cover certain categories of caller, register their grievances and give a time to sort out the issues. The main caller categories includes

• Insured : Grievance can be of payment of claims, cards, policy received etc
• Insurance Company : Head office, Regional office, Divisional Office, Branch Office, Agents
• IRDA : Grievance for any payment, Requirement of specific report etc
• Hospital : Pre Authorisation, Payment of Claims etc

Ticket System

This is a total internal process. A higher authority can issue a ticket to his subordinates for any specific issues. This ticket can be closed by the originator only. A certain time limit will be decided so that any issue will have to sort out by the specific time only.

There will be masters for Insurance company, Insured persons, hospitals, policies, Brokers, Agents, Corporate, Disease code, Procedure Code etc. All the functionalities will be done by the permission given to users to create or modify records.

Basic Inventory Management

This module will cover designing the inventory management system. It will manage vendors, Process reorder level , masters for vendors, their rating etc.

Integrated Web site

CRM is the most expensive now a days. So in order to cut down cost and enhance performance web site is the most economical model. Website will be online and policy holder can see his / her policy details, claim details etc. Network hospital can keep a watch on his claims without bothering TPA for reconciliation and status of payment. Insurance company can take some MIS according to his needs. Apart from above we can share some information like network hospital list, our branches, contact info, general guidelines etc.

Document Management Solutions

We will provide hospital to upload the scan copy to the website for faster processing. However the physical copy can be sent to the branches every week. So the processing will be faster and there will be no movement of physical file.

Network Hospital Management

In this module, a network hospital can be added, de panelled, deleted. The networking guy will be responsible for negotiating packaged rates and tariffs and he will enter all the details to the system. The system will generate the no of claims paid, outstanding etc so that he can follow up with the hospital.

Corporate Customer Management

This module will facilitate the corporate relation manager from policy entry to claims information also maintain the claim ratio. This module will give alert before 1 month, 15 days, weeks and 3 days before expiry. It also produce a list of corporate to be renewed in next month.

Correspondence Management

This module will eliminate the physical correspondence communications. What ever the letter, query reply, cheque, grievance etc will be documented and forwarded to the designated person. This module will be acting like inward and outward register.

Performance & Efficiency Monitoring

Performance is the heart of the organisation. This module will monitor the performance of all employees. All the process will have certain time limit to finish. If there is any alteration in that then system will show the exception. For example if a claim should be processed in 3 days then it will shows all the claims which does not meet this timeline. Also it will fire a email to the supervisor to investigate the problem. This module also records the efficiency like how many has been punched by which data entry operator by how much time etc.

Dashboard with Task Push

Every user in the system will get a dashboard where everybody task is predefined by the superior or by system. User has to click and start working on that. In this was the task can be pushed and user will get a feeling of getting the work done.