Test Scenario Approach Document

Successful enterprise-wide testing ensures that business functions will continue normally throughout the transition from ICD-9-CM to ICD-10-CM.

Payer will be required to complete extensive testing of business and system modifications.

A key component for testing will be the analytics needed to validate the results from test transactions and impact to business processes. If crosswalks are involved, your organization will need to analyze the results in greater detail.

Payer will need to process ICD-9 and ICD-10 codes simultaneously throughout the transition and it will be important to test your organization’s ability to dual-process.

Plan and document your test strategy prior to the implementation of reimbursement, utilization, underwriting, and other critical operations.

Below are the testing considerations that are recommended for payers in anticipation of ICD-10 testing and include test types, test plans, test cases, test data, as well as testing key considerations.

Unit testing/basic component testing: Confirms that updates meet the requirements of each individual component in a system. Payers will first need to test each component updated for ICD-10.

Unit testing should verify that: Expanded data structures can store the longer ICD-10 codes and their

qualifiers. Edits and business rules based on ICD-9-CM codes work correctly with ICD-10

Since reports frequently use diagnosis and procedure codes, testing report updates are critical. Critical report elements to evaluate include:

Input filters: Do all filters produce the anticipated outcome? Categorization: Do categories represent the user’s intent as defined by

aggregations of codes? Calculations: Do all calculations balance and result in the anticipated values

considering the filter applied and the definition of categories? Consistency: Do similar concepts across reports or analytic models remain

consistent given a new definition of code aggregations?

System testing: Verifies that an integrated system meets requirements for the ICD-10 transition. After completing unit testing, payers will need to integrate related components and ensure that ICD-10 functionality produces the desired results.

Plan to test ICD-based business rules and edits that are shared between multiple system components

Identify, update, and test all system interfaces that include ICD codes

Regression testing: Focuses on identifying potential unintended consequences of ICD-10 changes. Payers should test modified system components to ensure that ICD-10 changes do not cause faults in other system functionality.

The complexity of ICD-9-CM to ICD-10 code translation may result in unintended consequences to business processes.

Identify these unintended consequences through varied testing scenarios that anticipate risk areas.

Nonfunctional testing – performance: Performance testing includes an evaluation of nonfunctional requirements such as transaction throughput, system capacity, processing rate, and similar requirements. A number of changes related to ICD-10 may result in significant impact on payers’ system performance, including increased:

Number of available diagnosis and procedure codes Number of codes submitted per claim Complexity of rules logic Volume of re-submission due to rejected claims, at least initially Storage capacity requirements

Nonfunctional testing – privacy/ security: Federal and state legislation defines specific requirements for data handling related to 7conditions associated with mental illness, substance abuse, and other privacy-sensitive conditions. To identify these sensitive data components or conditions, payers often use ICD- 9-CM codes.

Update the definition of these sensitive components or conditions based on ICD-10-CM

The definition of certain institutional procedures that may fall under these sensitive requirements will be significantly different under ICD-10-PCS

Internal testing (Level I): The ICD-10 Final Rule requires Level I compliance testing. Level I compliance indicates that entities covered by HIPAA can create and receive compliant transactions.

Transactions should maintain the integrity of content as they move through systems and processes

Transformations, translations, or other changes in data can be tracked and audited

External testing (Level II): The ICD-10 Final Rule requires Level II compliance testing. Level II compliance indicates that an entity covered by HIPAA has completed end-to-end testing with each of its external trading partners and is prepared to move into production mode with the new versions of the standards by the end of that period.

Trading-partner testing portals need to be established Transaction specification changes should be defined and communicated Inbound and outbound transaction-related training may be required

A certification process may be needed for inbound transactions

Rejections and re-submissions related to invalid codes at the transaction level are handled

Parallel test systems to test external transactions

Test Plan Implications

The test plan documents the strategy and verifies that a business process and system meet future design specifications. The test plan should:

Identify acceptance criteria based on the business and system functional requirements that were defined during the analysis and design phase

Determine the business sponsor responsible for approving the scope of test plans

Test Case Implications

Define test cases to ensure that the system updates meet your business requirements and that the system components function efficiently. Test case design should include both anticipated and unexpected outcomes. Test cases should also include high-risk scenarios.

Test Data Implications

Test data ensures that several key system functions are producing data as expected and include data to:

Validate (data validation) Trigger errors Test high risk scenarios Test volume Test all types of domains and categories Simulate a standard environmental model over time Test comparisons, ranking, trending variation, and other key analytic models

Error Testing

All testing will result in errors. Correcting the errors before the go-live date is the objective of the testing phase. Payers should include the following in their error testing plan:

Multiple testing layers to support various iterations of re-testing in parallel tracks

Effective detection and repair of blocking errors that limit testing activities An error tracking system with standard alerts to report to stakeholders Prioritization model for error remediation designed to focus on business-

critical requirements Set of acceptance criteria Model for reporting known issues Developing a schedule for fixing known issues in the future

Internal Testing

Many payers develop and maintain internal systems that are not traditional commercial, off-the-shelf (COTS) products. In these cases, the payer takes on the ICD-10 implementation responsibility. Payers that choose COTS products, should work directly with their vendor to monitor the testing process for their system. When creating testing scenarios, consider all of the usual testing requirements for any internal system undergoing significant architectural and system logic changes and focus on testing key business risks.

Evaluate each technical area individually but also conduct integration testing across components including:

Database architecture User interfaces Algorithms based on diagnosis or institutional procedure codes Code aggregation (grouping) models Key metrics related to diagnosis or institutional procedure codes All reporting logic based on diagnosis or institutional procedure codes

Coordinate with your vendors as necessary to support testing execution and issue resolution. Identify testing workflows and scenarios for your organization that apply, including use cases, test cases, test reports, and test data

Identify a target date when your organization will be able to run test claims using ICD-10

Develop a project plan that recognizes dependencies on tasks and resources and prioritizes and sequences efforts to support critical paths

External Testing

Your organization should create an inventory of external entities with whom you exchange data and the testing you will need to coordinate with each to ensure timely, accurate ICD-10 implementation. Examples of external testing areas include:

Physician offices: Ensure that all condition- or procedure-related information exchange is handled appropriately throughout the ICD-10 transition.

Hospitals: Test information exchanges to ensure appropriate handling. Health information exchanges: Test all information exchanges for critical

operations. Outsourced billing or coding: Use defined clinical scenarios to ensure

outsourced business operations continue as expected. Government entities: Local and national government entities may require:

Public health reporting Quality and other metric reporting related to meaningful use Medicare and Medicaid reporting and data exchange Other mandated or contractually required exchange of information around

services and patient conditions

Payers should work to maintain its operational status quo, however, by targeting six key dimensions of neutrality:

• Payment (Provider): Neutrality is based on identifying shifts of DRG payments and working to minimize their effect

• Benefit (Member): Neutrality is based on no expansion or reduction in benefits or out-of-pocket costs as a result of the ICD-10 implementation

• Revenue (Payer): Neutrality is based on no significant increase or decrease in reimbursement

• Clinical (Programs): Neutrality is based on having approximately the same number of candidates in their wellness and care management programs that they have today

• Operational (Servicing): Neutrality is based on a lack of increase in payers key performance metrics, such as first pass, pend rate, etc.

• Financial (Overall): Financial neutrality refers to the cumulative effect of the variance in the previous neutrality dimensions. Acceptable levels of variance across other dimensions could result in an unacceptable overall variance. Extensive statistical modeling will be required to address this dimension

Because interruptions to payment models would have potentially negative repercussions for provider relationships, payers should work to define the business stratifications of payment neutrality and acceptable ranges for being considered “payment neutral.” His team also developed a baseline for BCBSM’s existing book of business using defined business stratifications, identified and anticipated payment differences with conversion to ICD-10 and modified criteria in order to categorize anticipated payouts within “acceptable” ranges.

Using Data to Anticipate Payment Differences

In doing so, payer should develop three steps for identifying anticipated payment differences:

• Creating ICD-10-based equivalent claims using a third party tool for claims creation and using historical data

• Manually re-coding ICD-10 claims to document probable DRG shifts

• Asking external providers to re-code targeted ICD-10 claims from existing medical records

The last step is critical because it leverages partners to help identify high-risk, high-sensitivity claims and demonstrates which claims are likely to be submitted. It helps both parties agree on the definition of neutrality. Payers can then better understand the information that providers will likely send when using ICD-10 code sets, and providers can identify gaps in medical record documentation standards. This is the key to testing and proofing concepts that help payers evaluate and validate payment neutrality with their partners.

Collaboration among trading partners is critical to success and the need for prioritizing clinical documentation, preauthorization procedures and coding policies because they affect business operations and the ability to achieve financial neutrality.

A Joint Discovery Mission

Cleveland Clinic identified its largest trading partner, Medical Mutual of Ohio, as one of its key ICD-10 partners. The two organizations agreed to embark on a “discovery” mission together to gain a collective understanding for how both companies’ processes worked and how ICD-10 would affect each of them. This shared knowledge was instrumental in helping the two organizations set expectations, define work requirements and commit to project “sign off” obligations—the elements necessary for successful migration.

One of the key efforts was to work together on the technology and process changes that would disrupt clinical documentation and coding, patient financial services and

clinical research and physician functions. The companies’ objectives were to evaluate the way the organizations currently used ICD-9 codes and to identify specific gaps in clinical and business operational readiness regarding the implementation of the new ICD-10 code set.

A Common Project Plan and Joint Testing Matrix

Cleveland Clinic mapped out two ICD-10 project budget proposals spanning the course of three years; one reflected an aggressive approach, while the other was more conservative and factored in higher health information management and billers costs for the 2013 and 2014 financial years. The difference between the two was more than $7 million dollars. Through revenue cycle training, strong clinical documentation, physician integration and technology advancements, Cleveland Clinic sought to reduce its budget targets.

More importantly, Cleveland Clinic knew that strong cooperation with Medical Mutual regarding finance, reimbursement and contracting strategies would be instrumental in lowering costs. The two companies resolved to define and set project priorities that would involve key business and IT personnel as appropriate – and then share them as a framework for creating a joint roadmap. The companies worked together to develop the project plan, including a crosswalk approach for bi-directional ICD-9 and ICD-10 mapping. Their joint strategy also called for an ICD-10 crosswalk analytics tool to simulate and assess the potential revenue impact on both sides.

Dennis Winkler from Blue Cross Blue Shield of Michigan, emphasized that testing should focus on maintaining the operational status quo. This means keeping the business neutral with respect to key performance indicators such as claims acceptance rates, support inquiries, electronic claim adjudication rates and aggregate claim reimbursement amounts.

He suggested that neutrality testing begin with a systematic approach to internally creating ICD-10 test claims, including the use of certified coders to create claims from existing medical records. These claims should reflect high-risk scenarios affecting payments, benefits, revenue, clinical programs (wellness and care management) and operations. Blue Cross Blue Shield of Michigan is creating internal test data targeted at testing this processes. However, the ultimate goal is to obtain test claims from external trading partners who have created ICD-10 claims from existing medical records.

In his Summit presentation, Sid Hebert of Humana explained the process Humana is using to develop their internal testing data. He emphasized that payers must develop test scenarios that reflect use of high-risk codes, specifically claims that use codes expected to have high volumes or high dollar values. Humana analyzed historical claims to identify their high-risk scenarios. Like any enterprise technology project, the time allocated to testing for ICD-10 is finite, while the code-mapping permutations created by ICD-10 are not. As Humana has learned, the key is to minimize the risk to the business by focusing effort on testing scenarios that could have the most impact. By doing this Humana was able to reduce the number of ICD-10 testing scenarios from several hundred thousand to just a couple of hundred.

Payers and Providers agree on the necessity of a collaborative testing effort Several presentations at the ICD-10 Summit focused on how to start collaborative testing between payers and providers. Lyman Sornberger of the Cleveland Clinic and Annette Melda of Medical Mutual of Ohio discussed their anticipated testing process. Later this year Cleveland Clinic will begin coding claims in both ICD-9 and in ICD-10. Medical Mutual will adjudicate and pay the ICD-9 claims, while also processing the ICD-10 claims in their test system so the two entities can compare results and variances of high-risk claims. The analysis will focus on compliance and neutrality in key risk areas to both Medical Mutual and Cleveland clinic.

WellPoint is focusing its testing on those claims at greatest risk of payment variation

WellPoint, the largest payer in the United States, is also taking a collaborative, risk-based approach to external testing. Florentino Buendia, Provider Contract Director at WellPoint, noted that WellPoint uses several methods to identify the providers at most risk for payment variation.

WellPoint uses the following method:

• Identify provider contracts where reimbursement terms are tied directly to ICD-9 diagnosis or procedure codes

• Identify “high-risk” DRGs, procedures, and diagnosis codes (those most likely to change)

• Create simulation models that re-price using ICD-10 language/terms

WellPoint has targeted eight hospital facilities for its first phase of external testing. WellPoint gives the providers high-risk ICD-9-based claims (those with high potential for significant variation in payment) and asks providers to recode them into ICD-10 claims based on the original medical records. WellPoint manually processes the claims and then jointly reviews the results with providers. Future phases will include a more complete end-to-end processing of claims and an expansion to the general provider population.

Taking a risk-based approach to testing based on analysis of historical data is a common element to the testing approaches these ICD-10 leaders are taking. This includes identifying high-risk codes, as well as identifying providers most likely to bill payers using these codes. Successful external testing will require new levels of collaboration and information sharing among providers and payers. While it may be uncomfortable to collaborate on such testing, the consequence of big surprises in payments after the transition date will cause even greater discomfort for payers and providers alike.

Key Takeaway #5: For Successful Implementation, the Devil is in the Details

Throughout the two-day event, strategies for success took center stage during both formal presentations and informal networking discussions. On Thursday, attendees broke into moderated, small-group exercises to tackle the issues they voted as most significant when they registered.

Readiness is a major concern; traditional change management strategies need to go external

Whether they were concerned vendor, partner, or organizational readiness, virtually all attendees expressed concern that their implementation would suffer from a lack of preparedness. A common thread running through all the various recommendations and best practices was to adopt a “communicate early, communicate often” approach.

From a vendor readiness standpoint, the key recommendation was to conduct a baseline survey of all vendors and then use the results to prepare a full assessment of each, including criteria to gauge their readiness. By stratifying the list and creating a dashboard to understand the current state of each vendor, entities could then develop specific communication plans to work with each one.

Both payers and providers cited partner readiness as one of their biggest concerns and agreed that deliberate, enhanced communication among all internal and external stakeholders had to be a priority. Entities will need to manage multiple work streams (technology, business, vendor, etc.) and ensure internal groups (such as contracts) are involved. The strongest recommendation was to evaluate and determine the specific impact and risk of each partner to ensure the right level of communication and coordination takes place.

There are no shortcuts to remediating medical policies

Dr. Joe Nichols of Health Data Insights discussed the challenges and best practices around remediating medical policies. His presentation focused on the fact that while most payers are probably considering using crosswalks or maps to remediate medical policies, they might end up with medical policies that are incomplete, or in some cases completely wrong. This will take payers further away from their goal of financial neutrality.

The key, Dr. Nichols of Health Data Insights pointed out, was to step back and take a grounds-up view of medical policies natively in ICD-10. Medical policies must incorporate the level of specificity included in ICD-10 while prescribing actions in the delivery of healthcare services based on medical rationale. Remediation must also incorporate the key objectives of medical policies, i.e. policies must be clinically driven, demonstrate clear intent, accessible, understandable, be the single point of truth and be traceable. In addition, medical policies must also provide a mechanism for clear governance, be collaboratively developed and reviewed, be accurately implemented and must be tested.

While redefining medical policies for ICD-10, it is valuable to review the processes by which policies are defined, coded and communicated. There are many players – clinicians, coders and systems engineers – currently involved in policy definition. However, in most cases, there is no clear way to ensure that the intent of the medical policy was communicated clearly from one stakeholder to the next. There are also limited review processes to ensure that the end product (medical policy) reflects the clinician’s original intent.

Code-mapping efforts need to encompass more than the GEMs

By far, the biggest undertaking for ICD-10 will be mapping the ICD-9 codes in use today to the ICD-10 codes that replace them. It’s a far-reaching effort that will affect several areas of every healthcare entity’s business.

While the GEMs are a good start to code-mapping efforts, most Summit attendees acknowledged that they wouldn’t solve every need. Most healthcare organizations will use ICD-10 code maps for a variety of purposes, such as identifying which codes will define a specific policy, disease management area, or benefit category—always important for native updates to back-end systems. Another use is identifying the specific codes used to analyze data before and after the implementation date to ensure accurate conversion of historical data to a consistent code set.

Besides the possibility of not having all the codes an entity must consider, the GEMs simply provide a list of related codes without providing critical details that explain how and why the codes are related, or where they differ. For healthcare entities, this means they will have to spend a significant amount of time and effort to evaluate those differences.

During the small-group discussions, attendees recommended that mapping be tailored to specific policies and edits, rather than relying on a single master map, and then sharing those maps with external partners. Moreover, because mapping won’t be a “one-and-done” process, there was a consensus that it will be important to consider the iterative nature of mapping to manage rework and the inevitable ripple effects each may cause.

Managing ICD-10 transition across the enterprise requires attention to people, processes and technology

Summit attendees all agreed that ICD-10 will have a far-reaching impact of ICD-10 on people, business strategy, operational processes and technology infrastructure. In one presentation, Deloitte and Blue Cross and Blue Shield of Tennessee (BCBST) discussed the importance of identifying and engaging an executive sponsor throughout the ICD-10. The discussion also centered on the significance of program structure and provided a snapshot of BCBST’s ICD-10 team structure, which includes chief compliance, actuary, finance, IT, provider network, chief medical and application representatives.

Other presentations and small-group discussions around internal readiness noted that existing best practices around corporate governance could be ideal for ICD-10 projects, particularly to ensure increased collaboration among business and technology groups. One of the strongest recommendations was to structure the ICD-10 Program Management Office (PMO) along the same lines as traditional IT PMO organizations, because of the proven capabilities of such a structure. However, if an organization’s existing IT PMO takes on ICD-10, its KPIs and associated metrics should be redefined to focus on the objective of ICD-10, rather than the business or technology group it usually supports.

Both Deloitte and BCBST stressed the importance of bringing all internal stakeholders into the conversation early on and emphasized that “compliance” often has different meanings to people and across departments. One team in the small-group exercise discussed compliance challenges and recommended that the definition of ICD-10 compliance be different from HIPAA 5010. Instead of “compliant” transactions being interpreted between entities, the team said the rule of law must have a hard cutover date for compliance, meaning parallel submissions for the same date of service is not an option. The team also noted that paper claims should be treated the same as electronic ones.

And from a people perspective, Summit participants agreed that the biggest inhibitors to internal readiness are resource constraints, lack of in-depth training, and deep knowledge of code sets across the organization. This team recommended role-based training delivered right when specific constituencies need it, a comprehensive knowledge base with easy-to-use look-up tools, improved processes for collaboration, and potentially outsourcing work that requires specific skill sets.

What should be the strategy or planning or readiness for ICD 10 Testing?

It depends upon overall strategy for ICD-10 remediation. You might need to start at high frequency, high impact, high dollar amount claims. Identify high risk providers, claim scenarios. You might need to perform historical claim data analysis to determine your risk and define testing strategy.

Your Medical policies and benefit remediation will be the starting point. Look at the business rules impacted. Check for change in IT process due to MP or Benefit configuration (accumulators, member liability) changes and then determine your priority.

In a nutshell following will be the types of testing:

(a)Financial Neutrality Testing (b)Benefit Neutrality Testing (c)Dual Process Testing(Parallel testing of the changes in business and clinical editing rules with respect to ICD 9 Environment to achieve clinical equivalence)

(d)Technical remediation Testing - Testing of screen level, database remediation changes, workflow changes, datawarehouse changes etc)

A suggestion for testing is to look at the highest volume of claims submitted over the past 5 years if that data is available and within that assess which of those claims were processed with a Medical Policy, Benefit or Contract rule that required matching of an ICD code. Remediation these first. My research shows that more than 50% of the professional claims submitted over that period of time map one to one from ICD-9 to ICD-10 for the Top 100 Diagnoses billed and the remaining map relatively one to 6. Remediate these first. This reduces operational impact for the volume of claims for professional providers. Your highest volume will most likely be professional claims, that's just logical.

Then, look at the facility claims in the same manner. These are more complicated due to the sheer number of data elements on a UB04 claim (paper or electronic). Building test cases and claims for the impacted benefits, contracts and Medicap Policy rules is the first step.

Only about 20-30% of all benefits a payer administers will be managed by an ICD code, the claims for the remaining benefits should process without stopping if the master file for ICD-10 is loaded. One could assume that the first pass rate will drop accordingly, provided all configuration of impacted claims is remediated and properly tested. Let's be optimistic and realistic about the work effort required to complete this work by 10/1/2013 and build plans accordingly.

A payer's impacted benefit and contract rules are a top priority in test plan development. Any medical policy changes that add new benefit or contract rules or modify them need to be incorporated into your test plans as well. Your 5-year claim history will give you a good perspective on how big of a ICD9 to ICD10 mapping challenge you have in terms of your top 80th and 90th percentile claim volume and most common DX and PCS occurrences. If your test plans cover DX and PCS scenarios in these percentiles, you should be well situated.

work done on ICD-10 remediation should be analyzed on HOW (via ICD codes) in a benefit, contract administered including any overlying Medical Policy rule. Some benefits are complex and are restricted by multiple levels of criteria and run across lines of business for things like diagnosis, age, sex, type of provider, location of service, etc. Usually, these are services that are for conditions that need to be managed (example: heart disease, diabetes, asthma or other lung related diseases, kidney diseases, brain and tumor conditions) for which the cost to deliver these services is high and for the plan to overcome higher costs, the claims are managed to the degree that Disease Management Plans can be developed to improve the patient's condition. Hint - if a service requires authorization, it is also likely to be managed for a condition (diagnosis). Authorization rules play a role in this too.

As for QNXT specifically, the Medical Policy rules often conflict with benefit and contract configuration, so documentation of what the intention of the management restrictions is key to the appropriate configuration options. Remember also that QNXT processes claims by hierarchy rules and they were originally designed to make payment decisions leaning toward what is best for the 'member'. Take a look at the adjudication steps on a claim and you can see where the hierarchy is and when the claim processes what rules. The manual will be of value to you if you are new to QNXT,

ICD-10 Testing Services

Automated field validation enabling quick testingPartner migration testing and QATesting new partner boardingTest management suite for tracking testing status, test cases, defect tracking, builds, and resolutionUser acceptance testing

Clinical Neutrality:

Clinical neutrality will mean to convert all the ICD-9 to ICD-10 codes and ICD-10 to ICD-9 codes in an absolute 1:1 relationship with respect to the code descriptions for both the form of code sets. This will help the systems to convert all the incoming ICD-10 claims to ICD-9 claims and process in the legacy systems without the need to completely remediate the mainframe systems.

This can be achieved by a crosswalk which will contain both the ICD-9 codes and ICD-10 codes in the form of a map and the map will be 10 to 9 for the same. The goal of Clinical Neutrality is based on having approximately the same number of candidates in a wellness and care management programs as they are today (with ICD-9), so there should be no impact of the code change.

For example, ICD 733.82 (non-union of fracture) is only one code for fracture of any site, but in ICD-10, it has ~2000 codes describing different locations. So clinical integrity can be established by picking the right code according to the location.

The Clinical Integrity Rules placed in iCRM are already achieving some level of clinical neutrality which can be further fine-tuned by adding more clinical variables where unspecified or other specified code is mapped.

For the other artifacts such as medical policy, benefits, and provider contracts; each of the artifact need to be reviewed and mapped to ICD-10 codes and further tested with respect to the test case scenarios in the form of ICD-10 claims and process to achieve clinical neutrality in the ICD-10 environment.

Benefit neutrality: This means that the use of ICD-9 or the equivalent ICD-10 codes results in the same member coverage with no increase in the member premiums or out-of-pocket expenses. Currently, the benefits are mapped in the form of LMRP/MCD which are released by CMS for ICD-9, but for ICD-10 – No LMRP/MCDs have been published.

To help further understand these topics there is a webinar (CD available at a cost), which talks about how these neutralities can be achieved. What are BCBSM's six dimensions of neutrality and how the payor's transition plan incorporates these aspects into ICD-10 readiness, what is BCBSM's code mapping strategy to achieve the neutrality.

http://store.hin.com/Mapping-the-way-to-ICD-10-Readiness-Blue-Cross-Blue-Shield-of-Michigans-Approach-a-45-minute-webinar-on-January-18-2012_p_4302.html

http://www.amazon.com/Roadmap-ICD-10-Readiness-Practices-BCBS-Michigan/dp/193722967X

As discussed, tried to find out how the codes are being mapped in the industry so as to achieve the best possible clinical neutrality.

In the iCRM, we already have rules which are based on Clinical Integrity Rules which have been made by using physician’s inputs. In certain rules where codes are being mapped to other specified or unspecified code those scenarios can be fine-tuned by adding more clinical variables from the data.

Had a discussion with some of my friends who are working in this industry suggested me an approach which is listed in the document and also provided the inputs that they have subscribed to certain services (mentioned down below) which help them achieve the required neutralities:

http://store.hin.com/Mapping-the-way-to-ICD-10-Readiness-Blue-Cross-Blue-Shield-of-Michigans-Approach-a-45-minute-webinar-on-January-18-2012_p_4302.html

http://www.amazon.com/Roadmap-ICD-10-Readiness-Practices-BCBS-Michigan/dp/193722967X

Also – as of now there are no LMRP/MCD available for ICD-10 which is released for ICD-10 world. At the moment, we just have these LMRP/MCDs for the i9 world.Please let me know if you have any questions.

Wedi – need to be a member for the following papers:

http://www.wedi.org/snip/public/articles/dis_publicDisplay.cfm?docType=6&wptype=1

Automated Claims Testing Software

Xpress Claimtest Pro from MDETechnicalXpress Claimtest Pro is written using modern, highly supported .Net technology from Microsoft.Although the database engine is Microsoft SQL 2005 / 2008, our products support virtually any moderndatabase technology available today. Below is a summary of supported software and technologies.Major claims systems already mappedAMISYS, Diamond, FACETS, MHS, PowerStepp, HealthTrio, QMACS, QNXT, OAO and othersDatabase supportMS SQL, Oracle, Sybase, DB2, ACCESS, AS400 ODBC and more...

Chandler, AZ Officeoffice: 480-839-0420

fax: 480-820-2938

Virginia Beach, VA Officeoffice: 757-216-9710fax: 757-216-9711medicaldataexpress.com

Scenario Based Testing

THE BUSINESS CHALLENGE

The transition from ICD-9 to ICD-10 represents one of the most significant changes tohealthcare information in decades. These codes are a critical component in defining thepatient’s health state and institutional procedures done to improve or maintain thathealth state. They drive business processes such as payment, contracting, auditing, casemix adjustment and many other important business processes. They are also critical inanalysis of healthcare services and conditions for the purpose of quality measures,utilization patterns, population risk analysis, patient safety, clinical research andmultiple other reporting and analytic purposes.

ICD-10 represents far more than a simple version change. Besides the major expansionin the number of diagnosis and procedures codes, there have been major changes in thestructure, definition and coding rules. As a result the way that healthcare conditionsand institutional procedures are described in most healthcare data will be significantlydifferent resulting in major changes in claims processing, business rules and analysis ofhealthcare delivery patterns.

As we move into this transition, we have no historical reference for the way these codeswill be used and what the resulting impacts will be on the business of healthcaredelivery. Predicting the future without a historical reference is a challenge. Currentmodels that claim to predict what the future will be like after transition makeassumptions that may or may not be true. These models arbitrarily map current ICD-9code data using a General Equivalency Mapping (GEM) type map. How providers willcode today’s conditions in ICD-10 however, cannot be determined by a simple mappingof today’s codes.

Example:

We can look at a case of a patient with an open fracture of the femoral shaft thatpresents in September of 2013 that will be described by a set of ICD-9 codes. If we nowassume that the same case presented after October 1, 2013 the condition is the same,but how we describe that same case in ICD-10 has substantially changed. Figure oneillustrates the difference in how the same event is described very differently in ICD-10

vs. ICD-9. In addition it can be seen that in ICD-9 there are a total of 16 codes availableto describe all of the variations in fractures of the femur where as in ICD-10 there areover 1530 codes to accommodate significant differences in the various types offractures of the femur that may present for treatment.

If we look at healthcare delivery today, we can predict that in general most of theconditions and procedures that we see prior to the transition will also be seen afterOctober 1, 2013. The conditions and procedures are the same, it is just the way that weare expressing them in codes that is changing.

Assessing the transition impact and testing the feasibility of proposed solutions requiresthat we use a consistent understanding of conditions and procedures today, redefinethese conditions and procedures natively in ICD-10 and model the results in an ICD-10environment.

WHAT IS SCENARIO BASED TESTING?

When you mention the word “testing” most will think of something that system QAprofessionals undertake to assure that the results of development meet businessrequirements and the technical specifications for business change. The ICD-10transition however takes us into an environment where requirements may not bereadily apparent since we have no historical reference on which to base theserequirements. In addition this change is far more of a business and informatics changethan it is an information technology change. “Testing” takes on a new meaning in ICD-10. “Virtual testing” is needed to discover risks and to assess the feasibility of proposedsolutions by modeling what we know today with what we anticipate tomorrow.

WHAT IS A SCENARIO?

A scenario has the following characteristics:It identifies some event or condition that we are familiar with todayIt recreates that event virtually through some verbal or data representationWe can then define a variety of assumptions and variables around this virtualrepresentation to assess potential risks under different business conditions.Scenarios are created to establish a reference point around which we a have somehistorical familiarity.

GOALS FOR SCENARIO BASED TESTING?The goal of scenario based testing is to model todays experience to minimize risks andleverage the opportunities of future change by:Identifying points of riskIdentifying requirementsVirtually applying alternative assumptions and variablesVirtually testing remediation optionsEstablishing the test plan and test cases for post-development systems testing

PICKING THE RIGHT SCENARIOS?It will be impossible to identify every process and potential area of risk, but we can

greatly minimize risk and improve the efficiency of assessment, remediation and testingby picking the scenarios that represent:High VolumeHigh Cost/RevenueHigh complexity, or likely points of failureAnticipated opportunities for improvement of existing processesIt will be important to analyze your organizations data to determine where to focusefforts by defining those scenarios that are most likely to reflect those areas that matterthe most. The following illustrates how this focus may be driven by theseconsiderations.

HIGH VOLUME

The distribution of the use of ICD-9 diagnosis and procedure codes in claims data ishighly concentrated to a relatively small set of codes. In analyzing a data set1 ofinstitutional and professional claims, 5% of the unique codes represented approximately70% of the volume of codes submitted.

HIGH COST/REVENUE

Similar to the skewed distribution of the volume of codes there is a similarconcentration of codes that represent high revenue for providers or conversely adisproportionate share of the medical loss ratio for payers. In an analysis of inpatientdata2 the following findings were noted:

Only 28% of the 14,432 possible ICD-9 diagnosis codes were ever used in the 3 years ofinpatient data

3% of the possible codes based on primary diagnosis accounted for 80% of billed chargesThe distribution of billed charges for claims by clinical category using the AHRQ clinicalclassification scheme based on primary claim diagnosis demonstrated the following topfive categories of charges:

17.5% = Diseases of the circulatory system 13.8% = Diseases of the musculoskeletal system and connective tissue 9.7% = Injury and poisoning 8.9% = Diseases of the digestive system 8.8% = Neoplasms

Based on MDC categories of DRGS, the top 5 MDCs included the following:

17.3% = Diseases& disorders of the musculoskeletal systems & connective tissue 16.6% = Diseases and disorders of the circulatory systems 8.7% = Diseases and disorders of the digestive system 8.5% = Pregnancy, child birth & the puerperium 7.1% = Newborns and other neonates with conditions originating in the perinatal period

HIGH COMPLEXITY

The complexity of mapping between ICD-9 and ICD-10 is similarly concentrated to asmaller set of codes. Based on billed charges related to the primary diagnosis orprocedure on this same data set3, the following findings were noted.

1.4% of billed charges were related to claims where the primary diagnosis code (ICD-9)required more than one ICD-10 code for mapping purposes

7.6% of billed charges were related to claims where the primary procedure code (ICD-9)required more than one ICD-10 code for mapping purposes

23% of billed charges were related to claims where the primary diagnosis code (ICD-9)mapped to one ICD-10 code, but there was more than one choice in the GEM4 mapping.

85.3% of billed charges were related to claims where the primary procedure code (ICD-9)mapped to one ICD-10 code, but there was more than one choice in the GEM mapping.A limited set of other codes represent high complexity because of significant changes instructure, definition, coding rules and terminology.

POTENTIAL IMPACT TO CURRENT KEY BUSINESS OPERATIONS AND FUTURE OPPORTUNITIES

The above mentioned areas will generally address many of the current business risks,but there may be other business activities where scenarios will help identify areas offocus for the current business as well as the business road map moving forward. Someof these areas might include:• Quality measures• Case mix/severity adjustment• Hospital acquired conditions• Fraud, waste and abuse detection• Contracting scope• Capitation and carve-outs

REFERENCE IMPLEMENTATION MODELA Reference Implementation Model (RIM) is a method of simulating today’s processes ina future environment by using key scenarios and virtually walking these scenariosthrough existing systems and processes to test for risk, requirements and the feasibilityof potential solutions.

Reference Implementation Models are commonly used outside of healthcare to testdisaster responses, security measures and a variety of other situations where we may

have limited historical experience, but we anticipate the need for a change or responsegiven some future variable.The following is an illustration of how a scenario that was created in response to ananalysis that illustrated an area of potential business risk for a hospital based on thefactors mentioned above.THE SCENARIOA 27 year old pregnant female is involved in an accident where she sustainsan open fracture of the right femur as well as a skull fracture.She has a chronic history of urinary tract infection.At the time of admission the patient has an MRI and a spinal tap performed.The patient is taken to the operating room where a debridement of the

wound is accomplished as well as an open reduction and internal fixation ofthe femoral fracture.The patient had a Caesarian Section for a preterm delivery three days afteradmission.Based on this scenario, a virtual walk through of the hospital care processes provides avisualization of potential areas of risk and creates a model to virtually test the feasibilityof proposed remediation efforts.

SUBJECT AREAS AND KEY QUESTIONSKey questions need to be addressed in all functional areas related to the scenario. Thefollowing is an illustration of some, but certainly not all questions that would need to beaddressed in this example of a Reference Implementation Model.

FIRST ENCOUNTER:Has assessment and documentation included information about:

The patient’s level of consciousness? The anatomical details of the skull fracture? The nature of intracranial injury and/or bleeding? Trimester of pregnancy? Anatomical location of the Femur fracture? Type of fracture (transverse, oblique, comminuted)? Size of the wound? Muscle, nerve and vascular damage at the fracture site? Details on the nature and cause of the accident? … multiple other parameter need to code in ICD-10

What diagnostic procedures (MRI, Spinal tap, etc.) where done at the time ofadmission?How are admission, eligibility and other intake processes impacted by ICD-10?

Do the emergency rooms systems support ICD-10 codes and the level ofdocumentation needed?Are triage procedures or documentation impacted by ICD-10?Is public health, disease surveillance or external reporting impacted?Are present on admission conditions such as the history or recent urinarytract infection documented?OPERATIVE PROCEDURE:Did the operative report for the repair of the femur and the C-section includesufficient documentation of the nature of the operation to support propercoding under PCS?Do operating room systems support ICD-10?INPATIENT CARE:Does the electronic medical record system include support fordocumentation of the new parameters required by ICD-10?Does nursing documentation support ICD-10 documentation?

HEALTH INFORMATION MANAGEMENT / MEDICAL RECORDS/CODING:Do templates and documentation requirements/guidelines support ICD-10requirements?Are systems to support coding updated?Is there an ongoing process in place to measure coder productivity andaccuracy?Is a governance model in place for oversight of coding practices?What is the process for querying clinicians for additional data required forICD-10?How is coding segmented (specialty, diagnostic, procedures)?BILLING:Have billing systems been updated to support ICD-10 codes?Can the increased number of codes supported by ICD-10 be supported by thebilling systems?Have DRG groupers been updated to support ICD-10?

PAYMENT:Are AR days impacted?Are denials impacted?How are present on admission and preventable admissions measuresimpacted?Are there impacts related to pay for performance?Are HCC or other case mix adjustments impacts?

COMPLIANCE AND AUDITS:How is external reporting impacted?

State reporting Accreditation Quality measures

How will audits change?Fraud and abuse detection changes?Are codes valid and are documentation requirements for codes met?VENDORS:Besides internal systems are there external vendors that will be impacted?CONTRACTING:How is contracting impacted?EXTERNAL TRANSACTIONS:How will the outbound 837 transaction change?How and when will testing with trading partners occur?Which payers are crosswalking submitted data and how is that crosswalkinghappening in their systems?How will inbound transactions (eligibility, Remittance advice and otherinbound transaction change?)How will prior authorizations change?How will external provider communications change?ANALYTICS:How is ICD-10 data managed in the data warehouse?

How are categories going to be redefined?These and other subject areas are defined and key questions are applied before, duringand after the walkthrough to build ‘threads’ of the reference implementation. By usingmultiple ‘threads’ based on various prioritized scenarios, organizations can create avirtual ‘fabric’ to predict how the transition will unfold. This same process can also beused to establish a plan for remediation and system testing post-remediation.

SUMMARYTesting is not just to confirm what you have done…Test driven assessment using key scenarios provides an effective low costmethod of reducing substantial risk early in transition.Selection of the proper scenarios is important to get the maximum valuefrom the assessment and planning effort and is critical to minimizing riskmoving into implementationTrue end to end testing starts with patient entry into the system and endswith reconciled payment and data warehouse storage.

ACTION STEPS1. Identity a prioritized focus by:

Using existing ICD-9 data to identity areas of high volume and highcost/revenue.

Researching ICD-10 maps (GEM), rules, definitional changes and terminologychanges to identify areas of high complexity

Evaluating key coding domains that will impact critical business process oranalytics2. Create a set of scenarios that will provide a historical reference for today’sexperience based on these areas of prioritization.3. Use a Reference Implementation Model to walk these scenarios through theorganization to answer key questions around implementation, discoverrequirements and virtually test the feasibility of proposed solutions.4. Based on this discovery define the plan for remediation.5. Use these scenarios to create test cases that will be part of the system remediationtest plan.6. Use the same scenarios to identify variations in processing external parties given thesame scenario describe in ICD-9 vs. ICD-10.

Humana has analyzed historical claims based on claim volume and dollar value and has reduced the number of internal test scenarios to just a couple of hundred.

Flo Buendia of WellPoint discussed external testing and noted that WellPoint uses several methods to identify which providers are at the most risk for payment variation. WellPoint uses the following method:

Identify provider contracts where reimbursement terms are tied directly to ICD-09 diagnosis or procedure codes

Identify “high-risk” DRGs, procedures, and diagnosis codes (those most likely to change)

Create simulation models that re-price using ICD-10 language/terms

WellPoint has targeted 8 hospital facilities for its first phase of external testing.  The payer gives the providers claims that are high-risk (potential for significant variation in payment) and asks them to recode them into ICD-10. WellPoint manually processes the claims and then jointly reviews the results with providers. Future phases will include a more complete end-to-end processing of claims and will be expanded to the general provider organization.

ICD-10 testing will soon become a major activity for payers and providers. The experience by Humana and WellPoint both reflect the importance of developing test scenarios based on analysis of historical claim data. 

Areas to Consider When Testing ICD-10 Impact to Payer Business Processes

Remediation of payer systems is not complete without performing adequate testing of revised software applications and business processes. The following are some of the areas that should be considered when creating and defining ICD-10 test plans.

All Areas1.       Internal and external systems may use an ICD version code so downstream logic can discern code type. This code type must be recognized on an effective dated basis: either date of service or discharge date, depending on setting (inpatient vs. outpatient.)

Logic needs to distinguish version code, date and setting to decide code path.2.       Logic in many areas will be based on configured and cross-walked ICD-10 codes back to a corresponding ICD-9 code(s), or to crosswalk ICD-9 codes forward to the corresponding ICD-10 code(s).

New ICD code crosswalk tables and new cross-walking logic will need to be added at various points throughout the system.3.       Member benefit, provider contract and other configurations will change for ICD-10. Internal and external systems must coordinate their configurations and mapping algorithms to ensure equivalent codes.

Code configuration and assignment logic must be clearly defined, configured and coordinated between source and target systems.

Claims4.   Payers claims entry/correction will use DOS (or discharge

date) to determine whether claim ICD version code should be set to ICD-9 or ICD-10 and whether diagnosis codes are interpreted in ICD-9 or ICD-10 format.            Modify claims adjudication engine to base diagnosis edits on the claim's ICD Code version throughout.

5.   DRG pricing for ICD-9 claims will continue to use ICD-9 format input for grouper. DRG pricing for ICD-10 claims will use ICD-10 format input for grouper.Logic must be added to DRG pricing so claims will use DRG grouper appropriate for their ICD format.

6.   Incoming ICD-10 claims must be matched to ICD-9 history claims. Payers must backward convert ICD-10 codes to ICD-9 equivalent code prior to comparison with history claim.ICD-10 to ICD-9 reimbursement crosswalk logic will need to be factored into diagnosis related edits that involve historical claim data.

7.   Payers cost center assignment logic will use either ICD-9 or ICD-10 codes to determine assignment.All existing configuration must be enhanced to accommodate ICD-10 codes.

8.   Payers will differentiate EOB selection and reporting based on ICD version code and effective date.All existing configuration must be enhanced to accommodate proper code version and effective date.

Other Areas9.   Prior authorization detail edits will allow only ICD-9 &

ICD-10 codes based on dates before or after 10/1/2013.

PA edits will use claim's ICD version code to determine if ICD-10 code on the PA needs to be backward converted to ICD-9 for comparison purposes.

10. Due to expected increase in volume of new ICD-10 codes, manual code update processes will increase significantly.Automated and manual processes will have to be reviewed with additional time allocated to run times and manual correction activities.

11. Retro third party liability (TPL) mass adjustment claim selection processes must be modified to use either ICD-9 or ICD-10 diagnosis codes for TPL billing determinations based on ICD version code. All existing configuration must be enhanced to accommodate proper code version and effective date

Magnitude of ICD-10 Testing Purpose of slide: To convey that the changes that ICD-10 requires have significant impact to payers (SMAs). In order to achieve compliance standard test strategies must be performed but they must be modified to capture the difference due to ICD-10. Talking Points: The impact of ICD-10 is huge and impacts payer operations • Testing for ICD-10 will be significantly different from previous HIPAA transitions • Most of previous testing focused on whether a transaction could be created, transmitted, received, understood, and moved to processing system. • For ICD-10 most /critical changes focus on business rules associated with processing the codes • Crosswalks are needed to accommodate both code sets • Payers need to be able to process both code sets during the transition period • Equally important is the need to link/retain the original code in the crosswalk strategy and perhaps even for historical data • Redefinition of medical policies, processing rules and analytical categories – need to be reviewed and revised to ensure accuracy and to ensure the intent is met • Technology – assess hardware, increase storage, modify interfaces, data dictionary, etc

Coordination with vendors and trading partners – need to know plans and ensure crosswalks, mapping are compatible These are just some of the high impact changes. All changes impact testing Testing should include: • A means to perform validation of format and content • Provide visibility into and accountability for transaction flow through multiple process steps including transformation and crosswalking and the linking of results/response transactions to the original transaction • Provide a means to validate the redefinition of business rules and policies, • Provide analysis for management of risk models used by payers to determine business outcomes)

The differences with ICD-10 will require new test cases and more cases

Migration to ICD-10 changes the foundation or “building blocks” of the business process More complex due to ICD-10 (i.e., change in validation logic, redefinition of rules, redefinition of policies, crosswalking, retention of original code, changes to technology, etc.) Standard testing will not suffice Testing needs to support the magnitude of this initiative

Testing Progression from Level I to Level II Purpose of the slide: To convey that overall, there are two types of testing; level I (internal) and level II (external). Convey that level I testing must satisfy goals before moving to external or level II testing Talking Points: • There are two (2) recommended testing types for ICD-10; internal or level I and external or level II. • Internal testing is to be conducted first and consists of many different levels of testing that validates internal operations. Includes end-to-end testing

External testing is subsequent to internal testing and is just as critical as its predecessor and tests the sending and receiving of transactions that include ICD-10 with business associates; ensuring interoperability amongst trading partners Successful completion of internal and external is essential. The next step is “move to production or “go live”. However, SMAs should consider that there are other tasks/deliverables that may require assessment/review before transitioning to “live”. In a post production environment, some re-testing may occur as issues/problems are identified and solutions reached Successful testing will minimize problems in transaction processing and claims payment after October 1, 2013. Major challenge for all of the participants Consider the following: ICD-10 testing should include the following, which is different than routine testing: • Provide the means to perform validation of format and content • Provide visibility into and accountability for transaction flow through multiple process steps including transformation and crosswalking and the linking of results/response transactions to the original transaction • Provide a means to validate the redefinition of business rules and policies. • Provide analysis for management of risk models used by payers to determine business outcomes

Internal Testing – Level One Purpose of the slide: Explain/define level one testing Talking Points: • One of the critical components of ICD-10 transformation and compliance • There are two types of testing recommended for ICD-10 testing • This chart illustrates internal or level one testing • Indicates that a covered entity can create and receive compliant transactions, resulting from the completion of all design / build activities • Internal testing is done to determine if the programming or software changes for the ICD-10 code set have been installed correctly and the systems are functioning properly • Completing internal testing will allow SMAs to identify and resolve any internal systems issues that may occur with creating or receiving the different transactions that include ICD-10 codes. • This is the time that SMAs will want to test any manual processes and work and work flow processes used to collect and report diagnosis codes

SMAs need to consider: Do transactions maintain integrity of content as they move through systems and processes? Are transformations, translations, or other changes in data tracked and audited? If vendor supports MMIS, SMAs will need to inquire as to whether or not they will assist the SMA with internal testing

External Testing (Level Two) Purpose of the slide To convey that the transition to ICD-10 is based on exhaustive testing amongst all the external organizations that do businesses with the SMA ICD-10 Testing 4 April 26, 2011

Talking Points: • Major challenge for all of the participants. • There must be coordination and transparency between SMA and trading partners • Coordination of testing requires awareness on the part of all, and leadership from the SMA • Each covered entity should have its own schedule of implementing and testing each transaction • To conduct business-to-business testing, all parties have to be ready to test the same transaction at the same time • The success of ICD-10 depends on testing; simple testing to verify changed formats and contents will not suffice

SMAs need to consider: • Have trading partner testing portals been established? • Have transaction specification changes been defined and communicated? • Will inbound and outbound transaction related training be required? • Is there a certification process in place for inbound transactions? • How will rejections and re-submissions related to invalid codes be handled at the transaction level? • Will parallel testing systems be created to test external transactions?

Slide 8: What do you need to know as the Test Lead for ICD-10? Purpose of the slide: To begin a discussion on the topic of “I know how to test so what is different about testing ICD-10?” Talking Points: Standard testing for compliance with format and content will not be enough What is important is end-to-end testing with trading partners and the review of response transactions that ensure business intent and reimbursement requirements are met

Testing: What’s Different about ICD-10? Purpose of the slide: To convey that the standard testing approach and methodology works for ICD-10 but also convey how ICD-10 makes testing different Talking Points: Standard testing approach categories (i.e., performing a needs assessment, developing a test strategy, developing test plans, developing test data, and developing test scenarios) are steps/activities that need to be performed for ICD-10 but, Standard testing approach needs to be modified to include the differences that ICD-10 offers

Preparing for ICD-10 includes: Speak briefly to each of the items: Examples below Architectural Changes Testing needs to occur to ensure that the system will accept the increased field length and alphanumeric character place holders as well as ensure recognition of the ICD-10 during the adjudication process to ensure accurate payment or non payment of claims.

System performance testing will be key in determining the appropriate data base size to accommodate the new code set. Significant testing will need to occur to ensure that during dual processing the MMIS recognizes the ICD-9 codes versus the ICD-10 codes and accesses the appropriate benefit string based on dates of service. Testing needs to occur to ensure that the correct code type is riding with or is accompanied by the correct I9 or I10 code. Linking the translated code back to the original code will require new processes to be developed and tested so that history accurately reflects the code originally submitted on the claim. Maintain original as well as new code

New Format Testing to ensure that MMIS recognizes all codes submitted and that the new format is recognized during adjudication and downstream processing. Testing to ensure that the data dictionary is updated appropriately .

Business rules and Edits Testing needs to occur to ensure that the revisions made to business rules related to clinical editing, claims adjudication, fraud detection , and care management are appropriate and align with SMA objectives. Testing to ensure that during equivalent aggregation, the intent of the rules are met. Basically all existing logic requires testing to determine if the revisions satisfy SMA guidelines and operating procedures. SMAs will need to test to determine if the revisions made to re-coded edits are appropriate. For example, the edits to ensure proper payment or nonpayment for services will need to be tested to ensure accuracy.

Algorithms SMAs will need to test to determine if the revisions made to risk stratification and predictive modeling algorithms are appropriate/meet SMA guidelines. SMAs will need to test the changes to AP-DRG and MS-DRGs support accurate claims processing; consider impact to provider contracts.

Code Conversion – Crosswalks, GEMS mapping Given the dramatic increase in codes from ICD-9 to ICD-10 and the increased specificity of ICD-10 have created more many-to-many matches than exact matches. With so few exact matches, SMAs will need to redefine their policies and procedures and ensure that their trading partners’ rules align. SMAs need to test to ensure accurate claim payments. Revisions made to clinical policies require testing to ensure appropriateness of care and accurate adjudication.

Scope:

Test scenario approach document elaborates the preparation of the test details for clinical test scenario.

Following are the steps which are pursued in preparation of Test details for a Policy.

Created CCGs are reviewed and finalized with the included ICD 10 codes. Based on the reviewed CCGs, the included ICD codes and excluded ICD codes

will be determined. Included/excluded codes are ICD 10 codes which were decided to include/exclude for a medical policy.

Medical policy document will be reviewed for the given CCG. The predetermined conditions in the medical policy and the ICD 9 codes based

on which the medical policy is referred will be noted. The grouping of the diagnosis codes for a procedure code will be listed. Based on created CCG, the ICD 10 codes will replace the given ICD 9 codes. Test detail will contain the information that, the predetermined conditions and

the ICD 10 codes will be the major criteria to refer a medical policy. ICD 9 codes will be excluded from the criteria list to refer a medical policy.

User Interface Revisions User screens are updated to accommodate new format, structure and ensure the correct definition of the code displays.

System Interface

internal interfaces and external interfaces require update to accept and send transactions correctly Historical Data Typically SMA’s require at least three years of historical data for trending and analysis purposes. All history prior to the compliance date will be encoded in ICD-9 nomenclature. Oct 1, 2013 for claims submitted with ICD-10 history will start to be encoded in ICD-10. Testing will need to include accurate adjudication taking into consideration benefit limits/accumulators, etc. Consider converting historical data; crosswalk

Operations Management Purpose of the slide: nTo explain the operations management business requirements, the ICD-10 testing impact, and the level of testing required Talking Points (Applies to each business area following this slide) When business requirements are defined, the business unit has the information needed to begin defining how IT can be used to fulfill the business requirements identified. Speak to the impacts Explain how the level of testing will support the need Note: list includes high level impacts New 5010 New format Redefined rules, policies, etc. Code type support Code translation Link/retain original code Claim pricing/DRG Dual processing

Testing Levels Impact- Remediation Strategies Purpose of the slide: Discuss ICD-10 testing impact to the remediation strategies Talking Points: Maximum Upgrade Strategy

Testing is focused more on validating the newly developed /changed business processes, workflow, and interfaces, integrating the re-designed workflows/processes/interfaces with the existing testing for desired outputs • High priority is given to unit, integration, system, and external testing. Crosswalk Strategy • Crosswalk testing should include the following: • Verify the conversion and validate the new format • Test for where and how the crosswalk is implemented • How dependable/accountable it is for transactions that touch downstream processes • Financial implications of crosswalks

• Clinical accuracy of the converted code (specific to the line of business, i.e., disease mgmt, case mgmt) • Accuracy of audit trails that account for what is crosswalked • Ability to track back the source code and validate the financial aspect of the crosswalked date (applicable for reimbursement) thru DRG

Test Cases Purpose of the slide: To explain the importance of test case for ICD-10. Talking Points: • 5010 transactions with 60 or less codes • Test Cases should include high volume claims • High risk cases • PCS claims since these codes are new / test with CM • Test the crosswalk • Test cases should include known problematic issues and special consideration issues • Test cases assure that the system updates meet every business requirement and that the system components function efficiently to support business requirements; the results detail/report system readiness • The design of test cases includes both anticipated outcomes and scenarios that relate to exception processing and errors

Structured Test Governance Objectives: To convey that a strong, well structured governance / management is required for testing. Talking Points: Governance establishes: Clear roles and responsibilities for each testing group Comprehensive communication between the relevant teams; bring all the teams to a common ground of understanding Clearly defined quality gates for each stage of testing Minimum testing overlap between testing teams / vendors Test environments are available for each stage of testing Better information on overall testing activities and quality of the application Allows top management to make informed decisions

Scenario based Testing

Payment Neutrality

Scenario: Validate that the Medical Claim is processed successfully (same as in the existing ICD-9 based systems) by a PCP in the new remediated systems for a subscriber suffering from Osteoporosis and treated with total knee replacement given as ICD10 code and who is enrolled in HMO Plan where referral is mandatory.

Test Data:

Claim details are as follows:ICD-9 Dx : 71536ICD-9 Px : 8154DRG-9 : 470 Charged Amount : $5000 Allowed Amount : $4500

Expected Output:

ICD-10 Dx : M179 ICD-10 Px : 0SRC07Z Draft-DRG 10 : 470Charged Amount : $5000 Allowed Amount : $4500 * Assumed Acceptable variance of +/- 3%

Possible matches with DRG shifts

ICD-9 ICD-10 Claim DRG-9

MDC-9

Claim DRG-10 MDC-10

8154 0SRC07Z

470 08 470 08

0SRT07Z 469 08

0SRT0JZ 469 08

Benefit Neutrality:

Scenario:

Validate that the Medical Claim is processed successfully (same as in the existing ICD-9 based systems) by a PCP in the new remediated systems for a subscriber suffering from Other benign neoplasm of skin of lower limb, including hip and treated with Insertion of tissue expander given as ICD10 code and who is enrolled in HMO Plan where referral is mandatory.

Test Data:

Claim details are as follows:ICD-9 Dx : 2167ICD-9 Px : 8693DRG-9 : 578 Charged Amount : $6000 Allowed Amount : $5100Member Deductible : $300 Member Copay : $100 Member Liability : $400 Payer Liability : $4700

Expected Output:

ICD-10 Dx : D2370 ICD-10 Px : 0JH00NZDraft-DRG 10 : 578Charged Amount : $6000 Allowed Amount : $5000Member Deductible : $305 Member Copay : $102 Member Liability : $407 Payer Liability : $4593

* Assumed Acceptable variance of +/- 3%

Possible Matches with DRG shifts

ICD-9 ICD-10 Claim DRG-9 MDC-9 Claim DRG-10 MDC-10

8693 0JH00NZ

578 09 578 09

0JH03NZ 573 09

0JH10NZ 573 09

ICD-10 Testing tools

iDPC - Test Claims Data Setup/ Mgmt, Statistical validation of test claim data

iCRM - Historic data analysis, Risk Pool Identification, Cross-walk, Comparison & Analysis of Claims data

ICD-10 Test Management

Test Scenario and Test Case Management Test Data Management Traceability Management Defect Management Metrics Management Test Environment Mgmt

ICD-10 Testing Framework

TFiB Enabled Testing Approach Reusable test assets (Scenarios, Automation Framework and Scripts)

Pre-Remediation• Data Analysis• Create Test Scenarios• Create Test Cases• Customize HCL’s Reusable Test scenarios • Create Test Data• Test case Management

Data Analysis Reports

Risk Scenarios

High Risk Dx/Px Codes by Occurrence High Risk Dx/Px Codes by Paid Amounts High Impact Dx/Px Codes with DRG Shifts High Impact Dx/Px Codes with DRG Shifts by Provider High Risk Providers by Paid Amounts High Risk Providers by frequency of Dx/Px codes

Medical Policy Configuration Test Scenario/case

Scenario Description: Validate that the Medical Policy has been configured successfully in the ICD-10 environment when mapped from the equivalent ICD-9 environment for the policies of CT scan and Para vertebral Facet Joint Nerve Block for the same code(s) 73382 i.e., nonunion of fracture.

CT Scan

Paravertebral Facet Joint Nerve Block

Recommendation

As per the intent of the policy "Para vertebral Facet Joint/Nerve Block", the policy is specific to procedures performed on the cervical, thoracic and lumbar joints and their coverage is also specific to the same anatomical

regions. When the nonspecific code 73382 (as part of the coverage) is mapped to ICD-10 codes, it has several codes which are specific to the policy but other codes are not specific to the policy, hence the highlighted codes will be removed from the custom code group created by the user.

Sample Test details:

Test details which can be prepared for Policy- “Breast Implant Management”

Steps: The following are the steps which will be used to prepare test detail for

“Breast Implant Management” policy.

The CCG and medical policy for “Breast Implant Management” will be reviewed and the predetermined condition will be noted from the policy.

“Include Exclude Codes” in the spread sheet will be created based on the ICD codes which are included and excluded in the CCG.

Test detail will contain information that the medical policy will bereferred based on the pre determined conditions and the included ICD 10 codes, excluding ICD 9 codes.

Test detail will also contain information that the medical policy need to bereferred based on the given combination of diagnosis code.

Note: Attached the sample test details file for reference.

Estimates for the Preparation of the Test Scenarios for Medical Policies

Policy Status

Total CCG which have Inclusion /

Exclusion

Estimated person

hours per policy

(average)

Total Estimated person

hours Remark

Completed CCGs 33 3 99Ready to start the test scenario preparation

Completed Supplementary

CCGs 46 3 138Ready to start the test scenario preparation

CCGs in Review 44 3 132

CCGs Under Review and the CCG number may

change based on review

    Total Hours 369  

Note: Total CCGs are 178.