LOADING HEALTH BENEFITS INTO A NEW CLAIMS PROCESSING SYSTEM. Diane E. Brown Blue Cross a Blue Shield of Indiana

Transcription

1 LOADING HEALTH BENEFITS INTO A NEW CLAIMS PROCESSING SYSTEM Diane E. Brown Blue Cross a Blue Shield of Indiana Abstract: Blue Cross & Blue Shield of Indiana evolved as a company by product. The products include Blue Cross (hospital). Blue Shield (medical/physician), Major Medical (catastrophic), Comprehensive Major Medical (catastrophic including hospital and medical/physician), Prescription Drug. Dental, and Vision. Because these products evolved at different -times and because each market had different requirements for these products, claims processing systems were developed. These systems are very complex because they must interact in order to pay a single illness or accident. The situation was further complicated by the changing environment. The original systems were continually updated to meet new requirements. A single claims processing system was purchased and adapted to meet our specific needs. This paper will discuss the methodology used for loading account benefit coverages from the old system to the new system. The methodology consists of determining the most popular combination of benefit coverages. loading those as models. finding the closest model for each account. copying the model. and changing benefit coverages that the account has which are different from the model. The Benefit Conversion System consis'ts of approximately 50 SAS* programs. reading major files. creating approximately 0 SAS data sets, and 0 reports.. Introduction ;,- The current claims processing environment at Blue Cross & Blue Shield of Indiana includes systems. The systems represent different products and different markets. The products include Blue Cross (hospital), Blue Shield (medical/physician), Major Medical (catastrophic). Comprehensive Major, Medical (catastrophic including hospital, medical. and physician). Dental, Prescription Drug. and Vision. The different markets include Consumer (individual), Commercial (local small groups). Corporate (local large groups), National (national groups), and Government (Medicare & Medicaid). This environment is very complex because: ) the systems must interact to pay a single illness or accident, ) the systems have been updated to meet new requirements, and ) some types of claims require manual intervention. The future environment at Blue Cross & Blue Shield of Indiana will be based on claims processing system. with the exception that the current Prescription Drug system will remain. The software was purchased and- is being tailored to meet our specific requirements. This single system, called Claim*Pro. will handle claims for all products except Drug and all markets except some Governement business. It will be up-to-date on all processing requirements. and reduce manual intervention significantly. Each account selects a combination of benefit coverages for each product they select. An example of a benefit would be the maximum number of hospital days covered. The coverages that can be selected for that benefit include , 80. or 5 days. Another example of a benefit would be workmans compensation. The coverages that can be selected for that benefit are yes (it is covered) or no (it is not covered). Thus benefit coverages include yes/no values. maximum values. and levels of coverage. The products and their benefit coverages as selected by each account are loaded into benefit files. Before a claim is processed. these files are accessed to determine the coverages for that account. and the claim is paid: accordingly. A new benefit file is required by the Claim*Pro system. Benefit coverages from the old benefit files must be transferred to the Claim*Pro benefit file. Seventy percent of the benefits required by the Claim*Pro system are on the old benefit files. The remaining thirty percent are only on paper. BenefIt coverages for Dental and Vision can be- loaded with little effort. but the other products (Blue cross, Blue Shield, Major Medical. and Comprehensive Major Medical) are very complex. It was estimated that it would take.5 years to load benefit coverages for those products for all accounts manualy. The benefits can not be loaded programmatically because: ) thirty percent of the- benefits are not on existing files, and ) there is not a - correspondence between benefit coverages on the old system and the Claim*Pro system. In addition it was felt that we needed to load manually as part of the education process needed to become familiar with a new system. Manual intervention was needed, but to load entirely manual would take too long.

2 j:. Approach An approach was needed where the benefits could be loaded manually, but in less than the.5 year estimate. The thirty percent of the benefits only on paper would have to be loaded totally manually, but a short cut was needed to load the seventy percent of the benefits which existed on the old benefit files. A five step approach was taken to the problem: a. Identify the benefits on the old benefit file that are required by the Claim*Pro benefit file. Using account benefit coverages for these benefits, determine the most popular combination of benefit coverages for each product. The products and the number of benefits being transferred from the old benefit file to the Claim*Pro benefit file are shown below: Product Blue CroSS Blue Shield Major-Medical Pure Compo MME Modified Compo MME Number of Benefits b. Load the most popular combination of benefit coverages into the Claim*Pro benefit file. By loading the most popular combinations, hopefully, the benefit coverages of several accounts would be loaded as a single combination. A benefit coverage combination is referred to as a 'benefit structure'. The most popular combinations of benefit coverages are referred to as 'model benefit structures' or 'models'. c. For accounts which do not aatch one of the model benefit structures exactly, determine which model the account most closely matches. d. After determining which model comes closest to each account's actual benefit coverages, determine the benefit coverages of the account which are different from the closest model. e. To load an. account benefit structure, copy the model which is closest to the account's actual benefit coverages, and key in any changes for account benefit coverages which are different than the benefit coverages of the closest model.. Model Building The model building process consists of several steps. The top ten models for each product were found, the 'approach was verified for accounts matching the models exactly, the number of models was reduced, the approach was verified for all accounts, product combination.odels were determined, and the models were loaded into the Claim*Pro benefit file. A detailed description of these steps follow: a. Top Ten Models For Each Product For each product, the ten most popular benefit coverage combinations were found. The number of accounts and the percent of ' accounts with that product was calculated for each of the ten Models for each product. The percent of accounts represented by the top ten Models for each product gave an indication of the number of account benefit structures that could be loaded by merely loading the top ten models. The following illustrates the results for the top ten Major Medical models. Model Number of Percent of Accounts Accounts With Major Medical.05%.00%.%.5% 5.0%. % 0.8% 8.% 9.8% 0.0% Total 8.", By loading the top ten Major Medical models, ten benefit structures, we could load one-third of the accounts which had Major Medical. The corresponding 'Total' statistic is shown below for the other products: Product Blue Cross Blue Shield Major Medical Pure Compo MME Modified Camp. MME Percent of Accounts Matching Top Ten Models 5.98%.%.% 8.9%.0% Anywhere from one-fourth to one-third of the account benefit structures could be loaded by loading the top ten models for each product. b. Model Reduction This step involves trying to reduce the number of models for each product from ten to some number less than ten. Lets say that model # and model #5 for Major Medical have the same benefit coverages for 50 out of the 5 benefits. This being the case, only one of these two models should be loaded. Model #5 should be the one that is eliminated because a 5

3 lesser number of accounts match it exactly. Programs were written for each product to compare the models to themselves and report the number of benefit coverages that were different between any two of the ten models. Models, which were determined to be close to other models with more accounts matching exactly, were eliminated as models. After this procedure, the following number of models remained for each product: Product Number of Models Blue Cross 8 Blue Shield 8 Major Medical Pure Compo MME Modified Compo MME This process reduced the number of Comprehensive Major Medical models significantly, from ten to only for each of the two types of Comprehensive Major Medical products. c. Model Validation Thus far. we know that anywhere from one-fourth to one-third of the account benefit structures can be loaded by loading the top ten models for each product. These percentages are now reduced because some models have been eliminated in the model reduction routine. But for this approach to work. it must also work for account benefit structures which are not represented by a model. This step takes all the account benefit structures and matches them to all the.odels for corrresponding products. The model closest to each account benefit structure is determined along with the number of benefit coverages" which are different from the closest model. Since all the account benefit structures are matched against the models sometimes the number of benefit coverages which are different will be zero. After the number of benefit coverage differences were determined for each account. the average number of changes for each product was calculated. These results are shown below: Product Number of Number of Benefits Benefit Changes Blue Cross 9 Blue Shield 9 5 Major Medical 5 5 Pure Compo MME 5 Modified Compo MME 9 The average number of changes (number of benefit coverages different from the closest model) that must be made to load an account benefit structure after copying its closest model. is small in comparison to the number of benefits. The approach will definitely reduce the amount of time required to load the account benefit structures manually! This approach also enables us to load a single benefit structure for accounts which have exactly the same benefit coverages. d. Product Combination Accounts which purchase our basic benefits (Blue Cross, Blue Shield. and Major Medical). usually purchase a combination of these three products. Accounts which purchase one of the two Comprehensive Major Medical products would not purchase one of the other three. Thus. the models for our basic coverage must be models representing combinations of the three products. rather than models for each product. The possible product combinations are: Blue Cross (BC) Blue Shield (BS) Major Medical (MME) Blue Cross-Blue Shield (BC-BS) Blue Cross-Major Medical (BC-MME) Blue Shield-Major Medical (BS-MME) Blue Cross-Blue Shield-Major Medical ( ) In retrospect. it would have been better and easier to develop product combination models initially. But that's hindsight. So the approach that was taken was to use the corresponding product models for each product combination and count the number of accounts which matched or were closest to each model. PROC FREQ was used for each product coabination. The results for the BC-BS product combination are shown in Figure #. Two models were selected for this product combination. BC model # with BS model # and BC.odel # with BS model #5. Accounts not falling in these two cells will be matched against the two models that were selected and one of those will become its closest product combination model. This process will increase the number of changes that will have to be made after copying the closest aodel. The average number of changes for each product was shown in point C. of this section. e. Final Models The following chart summarizes the results of building product combination models:

4 Product Combo BC BC BS MME BC-BS BC-BS BC-MME BS-MME BC Model # 8 8 BS Model # 5 9 MME Model # There are product combination models for the basic products Blue Cross, Blue Shield. and Major Medical. To that number add the models for PUre Comprehensive Major Medical and the models for Modified Comprehensive Major Medical. This results in a grand total of models. A model was needed for each possible product combination. but as you can see most accounts with the basic products have all three products. Blue Cross, Blue Shield. and Major Medical. You may also notice a model #9 has appeared for Blue Shield. when the number of Blue Shield models was reduced to 8. There was a special kind of Blue Shield benefit structure that we needed to load because it had to be handled differently; so it was added after the fact as a 'model.. Loading Account Benefits The aodels were loaded into the Claim*Pro benefit file. We developed a prototype function which allows these models to be copied. The copied models can then be accessed on-line and any changes that need to be made to load an account benefit structure can be keyed in by typing over the corresponding benefit coverage of the model. To load a benefit structure. two things must be known; what model to copy and what changes to make to the model. The benefit analysts who load benefit structures were given a report to supply them with this information. The report was sorted first by product combination and then by _odel within product combination. For each product combination/model, several benefit structures need to be loaded. For each benefit structure, benefit coverages which are different from the model are displayed showing the model coverage and the benefit structure coverage. These coverages are shown by the code that actually is stored in the old benefit file and this is translated to an english description. Each benefit structure within product combination is assigned a number which is merely a label to tell one benefit structure from another. After benefit coverage differences are shown for a benefit structure. all the accounts with the same benefit structure are listed. This way a single benefit structure can be loaded for more than one account. This report is shown in Figure #. Accounts are to be implemented into the Claim*Pro system in phases. The benefit loading is also done in phases corresponding to the implementation phase. but a few months Prior to implementation. Each market has selected the implementation sequence of their accounts. Thus. the Benefit Conversion System will be ran several times before the benefit structures for all accounts have been loaded into the Claim*Pro benefit file. It would be too much to load all the benefit structures in one pass. By the time they were loaded. the benefits could have changed through renewals and conversions. Thus. you must be sure to run a small enough numher of accounts so that they can be loaded in a timely fashion. It is also good to avoid loading accounts at the same time they are coming up for renewal. And speaking of renewal. particular attention must be made to accounts after they have been loaded to the new system; all renewals and conversions from that point on must be made on the new system and the old system (until the account is implemented on the new system). 5. Behind The Scenes The system was developed in months over a month period. It was written entirely with the base SAS product. with the exception of the prototyping function (copying models) which was written using SAS/FSP*. The prototyping function uses SAS/FSP screens to indicate which models the benefit analysts wanted copied; then they are copied in batch overnight. The main part of the system involves model building and matching account benefit structures to those models. The system is far more complicated than perhaps it sounds. The programs use many f e merge and manipulation techniques. and some are quite lengthy. The system consists of appoximately 50 base SAS programs, creates approximately 0 SAS data sets. and generates almost 0 reports. Many of these reports were used for model building and not distributed. Several reports are produced for management which gives them information such as the number of benefit structures that have to be loaded in each phase.

5 account implementation sequence reports, percent of accounts loaded, and the average number of changes for each benefit structure. Figure # shows a functional flow cha~t of the Benefit Conversion System. The program flow chart was much too lengthy (0 pages) to include. References: * SAS and SAS/FSP are the registered trademarks of SAS Institute Inc, Cary. NC, USA. ICII)O FRECNEJrCY PERCENT I RON PeT I COl. PeT, ACCI»ff$ MIT" au. CIlOSS AtIJ au.: SIIIUD T.uU Of IatDO IV ISItD J, _ _ _..._..._ _----. nrral, 0' I' ' '., l' 0' 8 I 0. I ~.oo I a." I ". I 0. I. I o.n I 0.00 I '.00'." n.'" 5.' 0.5'... '.00', so, 0.00'.'" ".5'. OS' ".00'...,. 00' _ _,..._-_"' , _ , ' ' '.,., I o.do t D.,. I a... I z.u I.U I. I 0.00 I o..ao I.Z I 0.00 I 5.00 I 0.00 I 5.00 I ZD.DD I ZO.OO I 0.00 I 0.00 I I 0.00 I I '.00 I. I.0 I 5.00 I 0.00 J 0.00 I I 0 0 I 5 t 0 I 0 I lot I 0.00 I 0.00 I. I 0.00 I 0.00 I I.~ 0.00 I 0.00 I 0.00 I.55 I I 95.5 I 0.00 I 0.00 I 0.00 I 0.00 I I 0.00 J 99.0 I 0.00 I " 0' 0'.,..., 0 0' 0' 8 0. I 0.00' 0.00 I. I.55 I 0.00 I 0.00 I 0.00 I 9..Z I 0.00 I 0.00 I,.,., I 9.8 I 0.00 I 0.00 I 0.00 I I 0.00 I 0.00 I.8 I eo.0 I I 0.00 I I I 0.00 I 0. I z.n I 0.00 I 0.00 I 0.00 I D.OO I Z I 0.00 I.50 I 8.50 I 0.00 I 0.00 I 0.00 I 0.00 I 0.00 I 0.00 I.00 I '. I 0.00 I 0.00 I 0.00 I 0.00 I I 0.00 f 0.00 I. I :.5 I 0.00 I 0.00 I 0.00 I 0. I.- I 0.00 I 0.00 I 5. I 5. I 0.00 I 0.00 I I 0.'00 I 0.00 I ZO.oo I 9.M I O~OO 0.00 I 0.00 I I _.._ I 0 0 ZI Z 0.00 I 0.00 I 0. I.9 I 0.00 I 0.00 I 0.00 I 0.00 I ' I 0.00 I 9.5: I 90.<\8 I 0.00 I 0.00 I 0.00 I D.OO I 0.00 I 0.00 I 8.00 I % I 0.00 I I ~ ,~ lz I' I o.ooh.9 I.99 I z.n I :.5 I 0.00 I 0.00 I I 0.00 I. I 8.8 I. :.% I 0.00 I 0.00 I 0.00 I 0.00 I 8.00 I. I 0. I SO.OO I I TOTAL Z '.:8.8.& Figure # (, 8

6 Benefit Loading Report Functional System Flow Product Combination: Matched To Model: Benefit Structure Indicator: Be-BS BCBS Number of Accounts With Same BSI: All Products-Matches out of 08: 0 -Changes out of 08: 5 Product: Be Product-Matches out of -Changes out of Benefit Coverage Code 9: 9: Be Coverage Description )----;0( YERIFY APPROACH Max Fam Oed Model=00 Acct~500 Dollar Amt Dollar Amt )----o(~ Wrkmn Comp Model=Y Acct=N Preexs t Cond Model=<A Acct==B Yes No 80 Day 0 Day """' LIJAI) RPT ETERltNE BEN 8m IN» )----;0( ACCT/BEN LOAD RPT Product: BS Product-Matches out of -Changes out of 9: 9: BS Figure # Benefit Coverage Code Coverage Description Surg Sch Model= Acct=0 Series 00 Preferred Benf Days Model=5 Acct="80 Days Amt Days Alnt Accounts With This Benefit Structure Indicator Account: 0 Name: Henry County Hospital Account: Name: Indiana State Bar Assn Account: Name: Ball State University Figure # For further information, please feel free to contact me: Diane E. Brown Blue Cross & Blue Shield of Indiana 0 W. Market St., Mailpoint D Indpls., Ind. 0 Phone ()