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

2. 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

3.  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

4. 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

5. 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.

6. One of the key efforts was to work together on the technology and process changes that would
disrupt clinical docu m e ntation and coding, patient financial services and clinical research and
physician functions. The com panies’ 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 implem e ntation 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

7. 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 m ethod s to identify the providers at most risk for payment variation.
WellPoint uses the following m ethod:
• Identify provider contracts where reimburse m e nt terms are tied directly to ICD- 9 diagnosis
or procedure codes
• Identify “high-risk” DR G s, procedures, and diagnosis codes (those most likely to change)
• Create sim ulation mo d els 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 m e dical
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
mod erated, small-group exercises to tackle the issues they voted as most significant when they
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

8. driven, de m o n strate clear intent, accessible, und erstand be the single point of truth and be
able,
traceable. In addition, m e dical policies must also provide a m echanis m for clear governance, be
collaboratively developed and reviewed, be accurately implem e nted and must be tested.
While redefining m e dical policies for ICD- 10, it is valuable to review the processe s by which
policies are defined, coded and com m u nicated. There are many players – clinicians, coders and
system s engineers – currently involved in policy definition. However, in most cases, there is no
clear way to ensure that the intent of the m e dical policy was com m u nicated clearly from one
stakeholder to the next. There are also limited review processe s 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

9. 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

10. 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 testing
Partner migration testing and QA
Testing new partner boarding
Test management suite for tracking testing status, test cases, defect tracking, builds, and
resolution
User 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.

11. 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 MDE
Technical
Xpress Claimtest Pro is written using modern, highly supported .Net technology from Microsoft.

12. Although the database engine is Microsoft SQL 2005 / 2008, our products support virtually
any modern
database technology available today. Below is a summary of supported software and
technologies.
Major claims systems already mapped
AMISYS, Diamond, FACETS, MHS, PowerStepp, HealthTrio, QMACS, QNXT, OAO and others
Database support
MS SQL, Oracle, Sybase, DB2, ACCESS, AS400 ODBC and more...
Chandler, AZ Office
office: 480-839-0420
fax: 480-820-2938
Virginia Beach, VA Office
office: 757-216-9710
fax: 757-216-9711
medicaldataexpress.com
Scenario Based Testing
THE BUSINESS CHALLENGE
The transition from ICD-9 to ICD-10 represents one of the most significant changes to
healthcare information in decades. These codes are a critical component in defining the
patient’s health state and institutional procedures done to improve or maintain that
health state. They drive business processes such as payment, contracting, auditing, case
mix adjustment and many other important business processes. They are also critical in
analysis of healthcare services and conditions for the purpose of quality measures,
utilization patterns, population risk analysis, patient safety, clinical research and
multiple other reporting and analytic purposes.
ICD-10 represents far more than a simple version change. Besides the major expansion
in the number of diagnosis and procedures codes, there have been major changes in the
structure, definition and coding rules. As a result the way that healthcare conditions
and institutional procedures are described in most healthcare data will be significantly
different resulting in major changes in claims processing, business rules and analysis of
healthcare delivery patterns.
As we move into this transition, we have no historical reference for the way these codes
will be used and what the resulting impacts will be on the business of healthcare
delivery. Predicting the future without a historical reference is a challenge. Current
models that claim to predict what the future will be like after transition make
assumptions that may or may not be true. These models arbitrarily map current ICD-9
code data using a General Equivalency Mapping (GEM) type map. How providers will
code today’s conditions in ICD-10 however, cannot be determined by a simple mapping
of today’s codes.

13. Example:
We can look at a case of a patient with an open fracture of the femoral shaft that
presents in September of 2013 that will be described by a set of ICD-9 codes. If we now
assume 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 one
illustrates 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 available
to describe all of the variations in fractures of the femur where as in ICD-10 there are
over 1530 codes to accommodate significant differences in the various types of
fractures of the femur that may present for treatment.
If we look at healthcare delivery today, we can predict that in general most of the
conditions and procedures that we see prior to the transition will also be seen after
October 1, 2013. The conditions and procedures are the same, it is just the way that we
are expressing them in codes that is changing.
Assessing the transition impact and testing the feasibility of proposed solutions requires
that we use a consistent understanding of conditions and procedures today, redefine
these conditions and procedures natively in ICD-10 and model the results in an ICD-10
environment.
WHAT IS SCENARIO BASED TESTING?
When you mention the word “testing” most will think of something that system QA
professionals undertake to assure that the results of development meet business
requirements and the technical specifications for business change. The ICD-10
transition however takes us into an environment where requirements may not be
readily apparent since we have no historical reference on which to base these
requirements. In addition this change is far more of a business and informatics change
than 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 proposed
solutions 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 today
• It recreates that event virtually through some verbal or data representation
• We can then define a variety of assumptions and variables around this virtual
representation to assess potential risks under different business conditions.
Scenarios are created to establish a reference point around which we a have some
historical familiarity.
GOALS FOR SCENARIO BASED TESTING?
The goal of scenario based testing is to model todays experience to minimize risks and
leverage the opportunities of future change by:
• Identifying points of risk

14. • Identifying requirements
• Virtually applying alternative assumptions and variables
• Virtually testing remediation options
• Establishing 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 testing
by picking the scenarios that represent:
• High Volume
• High Cost/Revenue
• High complexity, or likely points of failure
• Anticipated opportunities for improvement of existing processes
It will be important to analyze your organizations data to determine where to focus
efforts by defining those scenarios that are most likely to reflect those areas that matter
the most. The following illustrates how this focus may be driven by these
considerations.
HIGH VOLUME
The distribution of the use of ICD-9 diagnosis and procedure codes in claims data is
highly concentrated to a relatively small set of codes. In analyzing a data set1 of
institutional and professional claims, 5% of the unique codes represented approximately
70% of the volume of codes submitted.
HIGH COST/REVENUE
Similar to the skewed distribution of the volume of codes there is a similar
concentration of codes that represent high revenue for providers or conversely a
disproportionate share of the medical loss ratio for payers. In an analysis of inpatient
data2 the following findings were noted:
Only 28% of the 14,432 possible ICD-9 diagnosis codes were ever used in the 3 years of
inpatient data
3% of the possible codes based on primary diagnosis accounted for 80% of billed charges
The distribution of billed charges for claims by clinical category using the AHRQ clinical
classification scheme based on primary claim diagnosis demonstrated the following top
five 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:

15. 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 a
smaller set of codes. Based on billed charges related to the primary diagnosis or
procedure 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 GEM
4 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 in
structure, 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 of
focus for the current business as well as the business road map moving forward. Some
of 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 MODEL
A Reference Implementation Model (RIM) is a method of simulating today’s processes in
a future environment by using key scenarios and virtually walking these scenarios
through existing systems and processes to test for risk, requirements and the feasibility
of potential solutions.
Reference Implementation Models are commonly used outside of healthcare to test
disaster 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 response
given some future variable.
The following is an illustration of how a scenario that was created in response to an
analysis that illustrated an area of potential business risk for a hospital based on the

16. factors mentioned above.
THE SCENARIO
• A 27 year old pregnant female is involved in an accident where she sustains
an 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 of
the femoral fracture.
• The patient had a Caesarian Section for a preterm delivery three days after
admission.
Based on this scenario, a virtual walk through of the hospital care processes provides a
visualization of potential areas of risk and creates a model to virtually test the feasibility
of proposed remediation efforts.
SUBJECT AREAS AND KEY QUESTIONS
Key questions need to be addressed in all functional areas related to the scenario. The
following is an illustration of some, but certainly not all questions that would need to be
addressed 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 of
admission?
• How are admission, eligibility and other intake processes impacted by ICD-
10?
• Do the emergency rooms systems support ICD-10 codes and the level of
documentation 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 urinary
tract infection documented?
OPERATIVE PROCEDURE:

17. • Did the operative report for the repair of the femur and the C-section include
sufficient documentation of the nature of the operation to support proper
coding under PCS?
• Do operating room systems support ICD-10?
INPATIENT CARE:
• Does the electronic medical record system include support for
documentation 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-10
requirements?
• Are systems to support coding updated?
• Is there an ongoing process in place to measure coder productivity and
accuracy?
• Is a governance model in place for oversight of coding practices?
• What is the process for querying clinicians for additional data required for
ICD-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 the
billing 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 measures
impacted?
• 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?

18. • How and when will testing with trading partners occur?
• Which payers are crosswalking submitted data and how is that crosswalking
happening in their systems?
• How will inbound transactions (eligibility, Remittance advice and other
inbound 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, during
and after the walkthrough to build ‘threads’ of the reference implementation. By using
multiple ‘threads’ based on various prioritized scenarios, organizations can create a
virtual ‘fabric’ to predict how the transition will unfold. This same process can also be
used to establish a plan for remediation and system testing post-remediation.
SUMMARY
• Testing is not just to confirm what you have done…
• Test driven assessment using key scenarios provides an effective low cost
method of reducing substantial risk early in transition.
• Selection of the proper scenarios is important to get the maximum value
from the assessment and planning effort and is critical to minimizing risk
moving into implementation
• True end to end testing starts with patient entry into the system and ends
with reconciled payment and data warehouse storage.
ACTION STEPS
1. Identity a prioritized focus by:
Using existing ICD-9 data to identity areas of high volume and high
cost/revenue.
Researching ICD-10 maps (GEM), rules, definitional changes and terminology
changes to identify areas of high complexity
Evaluating key coding domains that will impact critical business process or
analytics
2. Create a set of scenarios that will provide a historical reference for today’s
experience based on these areas of prioritization.
3. Use a Reference Implementation Model to walk these scenarios through the
organization to answer key questions around implementation, discover
requirements 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 remediation
test plan.
6. Use the same scenarios to identify variations in processing external parties given the
same 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.

19. 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 Areas
1. 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).

20. 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.
Claims
4. 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.

21. 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 Areas
9. 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

22. 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

23. 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

24. 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

25. 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.

26. 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

27. • 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.

28. Test Data:
Claim details are as follows:
ICD-9 Dx : 71536
ICD-9 Px : 8154
DRG-9 : 470
Charged Amount : $5000
Allowed Amount : $4500
Expected Output:
ICD-10 Dx : M179
ICD-10 Px : 0SRC07Z
Draft-DRG 10 : 470
Charged Amount : $5000
Allowed Amount : $4500
* Assumed Acceptable variance of +/- 3%
Possible matches with DRG shifts
ICD-9 ICD-10 Claim MDC-9Claim DRG-10 MDC-10
DRG-9
8154 470 08
0SRC07Z 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 : 2167
ICD-9 Px : 8693
DRG-9 : 578
Charged Amount : $6000
Allowed Amount : $5100
Member Deductible : $300
Member Copay : $100
Member Liability : $400
Payer Liability : $4700
Expected Output:
ICD-10 Dx : D2370
ICD-10 Px : 0JH00NZ
Draft-DRG 10 : 578
Charged Amount : $6000

29. Allowed Amount : $5000
Member 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 578 09
0JH00NZ 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

30. 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

31. 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 be
referred 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 be
referred based on the given combination of diagnosis code.
Note: Attached the sample test details file for reference.
Clinical Data Test
Details Samples.xls

32. Estimates for the Preparation of the Test Scenarios for Medical Policies
Estimated
person Total
Total CCG which hours per Estimated
have Inclusion / policy person
Policy Status Exclusion (average) hours Remark
Ready to start the test
Completed CCGs 33 3 99 scenario preparation
Completed
Supplementary Ready to start the test
CCGs 46 3 138 scenario preparation
CCGs Under Review and
the CCG number may
CCGs in Review 44 3 132 change based on review
Total Hours 369
Note: Total CCGs are 178.