About the data

The available data corresponds to anonymized openIMIS insuree and claims response data from the Health Insurance Board (HIB) in Nepal. The data helps understand the claim adjudication process in Nepal and forms the basis for the learning of the AI algorithm for claim adjudication. The dataset is an extraction of the HIB openIMIS database from 06-2016 up to 09-2020.

The process of creation and definition of the dataset described here is concatenated from several openIMIS tables/respective FHIR resources. This dataset combines necessary information related to a medication or activity definition, thus a row in the dataset will correspond to a ClaimItem or ClaimService and its associated information like:

• Numeric fields:

  • IDs:  ClaimItemID, ClaimID, Item or Service ID, InsureeID, HFID, ClaimAdminID, ICDID, ICDID1, FamilyID, LocationID, PolicyID, ProdID

  • Quantities or prices: QtyProvided, QtyApproved,PriceAsked, PriceAdjusted, PriceAproved, PriceValuated, Claimed, Approved, Item/SericePrice

  • Statuses: ClaimStatus, ReviewStatus, ClaimItemStatus, RejectionReason 

  • Other numeric fields: Item/ServPatCat, Item/ServiceFrequency, Relationship, IsHead, Poverty

• Categorical variables:

  • UUID: related to the numeric IDs

  • Datetime: DateFrom, DateTo, DateClaimed, DateProcessed, DOB

  • Character fields: Item/ServiceType, Item /ServiceCareType, Item/ ServicePackage, Item/ServCategory, VisitType, HFCareType, HFLevel, HFSublevel, HFCareType, LocationType

  • Text labels: Item/ServiceCode, Item/ServiceName, Item/ServiceType, HFCode, LocationCode, LocationName

  • Text fields: Explanation (in tblClaims and tblClaimItems), Justification, Adjustment

These are some examples of fields and a non-exhaustive list of the types of fields that are analyzed in the data gathering and processing stage.

Selection from Tables

In order to prepare the final dataset for use, the following selection of fields were made from the existing tables and resources (see Table 1):

1. concatenation of tblClaims and tblClaimAdmins based on ClaimAdminId : 5’953’640 entities and and 24 fields selected (11’965 claims have no value for the ClaimAdminId, therefore they were excluded in the concatenation process)

   1. tblClaims: 5’965’605 claims with 20 selected fields (from a total of 46 fields in the table)

   2. tblClaimAdmins: 913 entries with 5 selected fields

2. the information related to insurees, families and their location is then concatenated to the previous dataset (based on InsureeID), resulting in 5’953’640 rows and 48 columns

   1. the information related to the insurees, families and their location is obtained through the merging of the tables Insurees and Families (based on FamilyID) and with the Location table (based on LocationID), resulting in a dataset with 3’790’789 rows and 25 columns (from a total of 51)

3. the information related to health facilities and their locations is concatenated to the previous dataset (based on HFID column), resulting in 5’953’640 rows and 57 columns

   1. the information related to the health facilities and locations tables are concatenated (based on LocationID column) resulting in a set of 780 rows and 10 columns (from a total of 37 columns)

4. concatenation of the diagnosis information to the previous dataset (based on ICDID column), resulting in a dataset of 5’953’640 rows and 61 columns.

   1. the information related to the tblDiagnosis: 1’959 rows and 5 selected fields

5. concatenation of tblClaimItems and tblItems based on ItemID: 12’414’014 medication items and 28 fields selected

   1. tblClaimItems: 12’414’014 medication items with 17 selected fields (from a total of 30 fields in the table)

   2. tblItems: 1’528 rows and 12 selected fields (from a total of 17)

6. concatenation of tblClaimItems/tblItems to the previous dataset based on ClaimID : 12’371’992 rows and 82 fields (in the previous of concatenation 42’022 entities were excluded, they were related to the claims without any value for ClaimAdminId)

7. the ClaimServices and Services data is then concatenanted to the claim related dataset, resulting in 16’655’364 rows and 28 fields

   1. tblClaimServices and tblServices – are concatenated in a similar manner as the tblClaimItems and tblItems tables, based on ServiceID; the selected columns in the tblServices are renamed to be similar to those in the tblItems; The resulting dataset is composed of 16’655’364 rows and 28 fields

8. the fields related to the tblClaimServices/tblServices is concatenated to the dataset related to the claims, based on ClaimID column, resulting in a dataset with 16’600’273 rows and 82 fields

9. the resulting datasets related to medication and activity definition items are appended, resulting in a dataset with 28’972’265 rows and 82 fields.

All the necessary data for the development, training and testing of the AI categorization algorithm was regrouped in a single table with 28’972’265 rows and 82 columns, corresponding to :

• 5’953’640 claims: 12’371’992 medication and 16’655’364 activity definition entities (see Fig.1)

• 3’790’789 insurees

• 780 health facilities

• 1’959 diagnosis items

Open

Open

Open

As it can be observed in the previous figures, in 2019 and 2010 the openIMIS system has allowed the submission of more then 10’000 claims per day (respectively more then 20’000 medication items and more then 30’000 activity definition items per day). This illustrates also the need for an AI categorization step which can support the HIB reviewers.

Data cleaning

Before applying the Machine Learning algorithm, a large effort was made to check and clean the dataset obtained from the previous step, which includes large inspections of the dataset from different dimensions. The sanity check of the data corresponds to checking the coherence of the data in terms of values, dates and statuses, filling missing values, handling categorical data (datetime, char or text variables existing in the dataset).

Coherence analysis

In the process of data cleaning, several exclusion conditions were defined and are mainly related to the defined adjudication workflow.

Exclusion conditions

Condition 1

All the medication and activity definition items with a ClaimStatus ‘Entered’ (the claim was entered but not submitted, so not yet checked by the RuleEngine) were excluded from the analysis: corresponding to 201’402 records (83’986 medication and 117’416 activity definition items) and respectively to 40’393 claims with date of submission of the claim between 05-12-2017 and 29-09-2020.

For this project, the input to the AI model will be corresponding to a medication or activity definition item accepted by the Rule Engine. An item rejected by the Rule Engine will not be reviewed by the AI model or by a Medical Officer and will be automatically rejected. For this reason, the items, which were not yet verified by the Rule Engine, are not considered. In Fig 4, we can observe the distribution of claims in terms of claim status and review status.

Open

Condition 2

All items rejected by the Rule Engine, were excluded from the analysis: 209’210 records, corresponding to 78’289 claims.

Condition 3

Missing values in the ClaimAdminID, PolicyID, ProdID, VisitType columns will be excluded: 1’451 records corresponding to 578 claims.

Condition 4

Inconsistency with respect to the values in the ClaimItemStatus, ClaimStatus, ReviewStatus, RejectionReason, PriceValuate: 145 records corresponding to 74 claims.

• Records where the ClaimItemStatus is Rejected and RejectionReason is Accepted;

• Records where the ClaimItemStatus is Accepted and RejectionReason is Rejected;

• Records where ClaimStatus is Rejected and RejectionReason is Accepted;

Condition 5

Inconsistency in terms of status and PriceValuate: rejected item, but with positive valuated price: 33 records corresponding to 24 claims.

Condition 6

Inconsistencies in terms of date fields in the DateFrom, DateTo, DateClaimed or DOB: 6’199 records corresponding to 1’340 claims.

• DateFrom or DateTo before 16-05-2016;

• DateClaimed before DateFrom;

• DOB before DateClaimed

A total of 418’440 records were excluded in this step, resulting in a cleaned dataset of 28’553’825 rows and 82 columns.

Summary

The next step included a check of the medication and activity definition records that were reviewed by a Medical Officer, as these records will be included in the labeled dataset. For this, we checked the value in the ReviewStatus field: a ReviewStatus == 8 (Reviewed by a MO) indicating that the claim was revised by a Medical Officer. To summarize, we can say:

• 23.99%  (6’851’424 records) of all the data can be considered as labeled (reviewed by a Medical Officer), whereas 3.78% of the labeled records were rejected (259’075) and 96.22% were accepted (6’592349 records)

• 76.01% (21’702’401 records) of all data is not labeled (accepted without any manual reviewing)

Code and results: 5-SaniyCheck.pdf

Selection of fields

From all the 82 columns selected in previous steps, some were necessary only for the sanity check process. For example, the DateProcessed (the date and time of the processing of the claim), ValidityFromReview and AuditUserIDReview were used to check is a claim was reviewed. On the other hand, there are other field which are null over the claim review process and are initiated only after the valuation process (like RemuneratedAmount, LimitationValue, DeductableAmount, ExceedCeilingAmount, ExceedCeilingAmountCategory, PriceOrigin, PriceAdjusted, PriceValuated) and therefore were not considered useful information for the AI categorization process. All the information related to the field selection is included in the Table 2.