Test scenario preparation_approach_document & estimates
Test Scenario Approach DocumentSuccessful enterprise-wide testing ensures that business functions will continuenormally throughout the transition from ICD-9-CM to ICD-10-CM.Payer will be required to complete extensive testing of business and systemmodifications.A key component for testing will be the analytics needed to validate the results fromtest transactions and impact to business processes. If crosswalks are involved, yourorganization will need to analyze the results in greater detail.Payer will need to process ICD-9 and ICD-10 codes simultaneously throughout thetransition 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 anticipationof ICD-10 testing and include test types, test plans, test cases, test data, as well astesting key considerations.Unit testing/basic component testing: Confirms that updates meet the requirementsof each individual component in a system. Payers will first need to test eachcomponent 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-10Since reports frequently use diagnosis and procedure codes, testing report updatesare 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 theICD-10 transition. After completing unit testing, payers will need to integrate relatedcomponents 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 ofICD-10 changes. Payers should test modified system components to ensure thatICD-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 ofnonfunctional 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 requirementsNonfunctional testing – privacy/ security: Federal and state legislation definesspecific requirements for data handling related to 7conditions associated with mentalillness, substance abuse, and other privacy-sensitive conditions. To identify thesesensitive 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-PCSInternal 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 receivecompliant 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 auditedExternal testing (Level II): The ICD-10 Final Rule requires Level II compliancetesting. Level II compliance indicates that an entity covered by HIPAA has completedend-to-end testing with each of its external trading partners and is prepared to moveinto production mode with the new versions of the standards by the end of thatperiod. 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 transactionsTest Plan ImplicationsThe test plan documents the strategy and verifies that a business process andsystem 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 plansTest Case ImplicationsDefine test cases to ensure that the system updates meet your businessrequirements and that the system components function efficiently. Test case designshould include both anticipated and unexpected outcomes. Test cases should alsoinclude high-risk scenarios.Test Data ImplicationsTest data ensures that several key system functions are producing data as expectedand 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 modelsError TestingAll testing will result in errors. Correcting the errors before the go-live date is theobjective of the testing phase. Payers should include the following in their errortesting 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 TestingMany payers develop and maintain internal systems that are not traditionalcommercial, off-the-shelf (COTS) products. In these cases, the payer takes on theICD-10 implementation responsibility. Payers that choose COTS products, shouldwork directly with their vendor to monitor the testing process for their system. Whencreating testing scenarios, consider all of the usual testing requirements for anyinternal system undergoing significant architectural and system logic changes andfocus 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 pathsExternal TestingYour organization should create an inventory of external entities with whom youexchange data and the testing you will need to coordinate with each to ensuretimely, 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 sixkey 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 dimensionBecause interruptions to payment models would have potentially negativerepercussions for provider relationships, payers should work to define the businessstratifications of payment neutrality and acceptable ranges for being considered“payment neutral.” His team also developed a baseline for BCBSM’s existing book ofbusiness using defined business stratifications, identified and anticipated paymentdifferences with conversion to ICD-10 and modified criteria in order to categorizeanticipated payouts within “acceptable” ranges.Using Data to Anticipate Payment DifferencesIn 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 recordsThe last step is critical because it leverages partners to help identify high-risk, high-sensitivity claims anddemonstrates which claims are likely to be submitted. It helps both parties agree on the definition ofneutrality. Payers can then better understand the information that providers will likely send when usingICD-10 code sets, and providers can identify gaps in medical record documentation standards. This is thekey to testing and proofing concepts that help payers evaluate and validate payment neutrality with theirpartners.Collaboration among trading partners is critical to success and the need for prioritizing clinicaldocumentation, preauthorization procedures and coding policies because they affect business operationsand the ability to achieve financial neutrality.A Joint Discovery MissionCleveland Clinic identified its largest trading partner, Medical Mutual of Ohio, as one of its key ICD-10partners. The two organizations agreed to embark on a “discovery” mission together to gain a collectiveunderstanding for how both companies’ processes worked and how ICD-10 would affect each of them. Thisshared knowledge was instrumental in helping the two organizations set expectations, define workrequirements 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 woulddisrupt clinical docu m e ntation and coding, patient financial services and clinical research andphysician functions. The com panies’ objectives were to evaluate the way the organizationscurrently used ICD- 9 codes and to identify specific gaps in clinical and business operationalreadiness regarding the implem e ntation of the new ICD- 10 code set.A Common Project Plan and Joint Testing MatrixCleveland Clinic mapped out two ICD-10 project budget proposals spanning the course of three years; onereflected an aggressive approach, while the other was more conservative and factored in higher healthinformation management and billers costs for the 2013 and 2014 financial years. The difference betweenthe 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 companiesresolved to define and set project priorities that would involve key business and IT personnel asappropriate – 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 analyticstool 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 onmaintaining the operational status quo. This means keeping the business neutral with respect to keyperformance indicators such as claims acceptance rates, support inquiries, electronic claim adjudicationrates and aggregate claim reimbursement amounts.He suggested that neutrality testing begin with a systematic approach to internally creating ICD-10 testclaims, including the use of certified coders to create claims from existing medical records. These claimsshould reflect high-risk scenarios affecting payments, benefits, revenue, clinical programs (wellness andcare management) and operations. Blue Cross Blue Shield of Michigan is creating internal test datatargeted at testing this processes. However, the ultimate goal is to obtain test claims from externaltrading 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 theirinternal testing data. He emphasized that payers must develop test scenarios that reflect use of high-riskcodes, specifically claims that use codes expected to have high volumes or high dollar values. Humanaanalyzed historical claims to identify their high-risk scenarios. Like any enterprise technology project, thetime allocated to testing for ICD-10 is finite, while the code-mapping permutations created by ICD-10 arenot. As Humana has learned, the key is to minimize the risk to the business by focusing effort on testingscenarios that could have the most impact. By doing this Humana was able to reduce the number of ICD-10testing scenarios from several hundred thousand to just a couple of hundred.Payers and Providers agree on the necessity of a collaborative testing effortSeveral presentations at the ICD-10 Summit focused on how to start collaborative testing between payersand providers. Lyman Sornberger of the Cleveland Clinic and Annette Melda of Medical Mutual of Ohiodiscussed their anticipated testing process. Later this year Cleveland Clinic will begin coding claims in bothICD-9 and in ICD-10. Medical Mutual will adjudicate and pay the ICD-9 claims, while also processing theICD-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 andCleveland 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 toexternal testing. Florentino Buendia, Provider Contract Director at WellPoint, noted that WellPoint usesseveral 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/termsWellPoint has targeted eight hospital facilities for its first phase of external testing. WellPointgives the providers high-risk ICD- 9-based claims (those with high potential for significant variationin payment) and asks providers to recode them into ICD- 10 claims based on the original m e dicalrecords. WellPoint manually processes the claims and then jointly reviews the results withproviders. Future phases will include a more complete end- to-end processing of claims and anexpansion to the general provider population.Taking a risk-based approach to testing based on analysis of historical data is a common element to thetesting approaches these ICD-10 leaders are taking. This includes identifying high-risk codes, as well asidentifying providers most likely to bill payers using these codes. Successful external testing will requirenew levels of collaboration and information sharing among providers and payers. While it may beuncomfortable to collaborate on such testing, the consequence of big surprises in payments after thetransition date will cause even greater discomfort for payers and providers alike.Key Takeaway #5: For Successful Implementation, the Devil is in the DetailsThroughout the two-day event, strategies for success took center stage during both formalpresentations and informal networking discussions. On Thursday, attendees broke intomod erated, small-group exercises to tackle the issues they voted as most significant when theyReadiness is a major concern; traditional change management strategies need to go externalWhether they were concerned vendor, partner, or organizational readiness, virtually all attendeesexpressed concern that their implementation would suffer from a lack of preparedness. A common threadrunning 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 allvendors and then use the results to prepare a full assessment of each, including criteria to gauge theirreadiness. By stratifying the list and creating a dashboard to understand the current state of eachvendor, 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 thatdeliberate, 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 ensureinternal groups (such as contracts) are involved. The strongest recommendation was to evaluate anddetermine the specific impact and risk of each partner to ensure the right level of communication andcoordination takes place.There are no shortcuts to remediating medical policiesDr. Joe Nichols of Health Data Insights discussed the challenges and best practices around remediatingmedical policies. His presentation focused on the fact that while most payers are probably consideringusing crosswalks or maps to remediate medical policies, they might end up with medical policies that areincomplete, or in some cases completely wrong. This will take payers further away from their goal offinancial neutrality.The key, Dr. Nichols of Health Data Insights pointed out, was to step back and take a grounds-up view ofmedical policies natively in ICD-10. Medical policies must incorporate the level of specificity included inICD-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, 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, becollaboratively 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 whichpolicies are defined, coded and com m u nicated. There are many players – clinicians, coders andsystem s engineers – currently involved in policy definition. However, in most cases, there is noclear way to ensure that the intent of the m e dical policy was com m u nicated clearly from onestakeholder 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 GEMsBy far, the biggest undertaking for ICD-10 will be mapping the ICD-9 codes in use today to the ICD-10 codesthat replace them. It’s a far-reaching effort that will affect several areas of every healthcare entity’sbusiness.While the GEMs are a good start to code-mapping efforts, most Summit attendees acknowledged that theywouldn’t solve every need. Most healthcare organizations will use ICD-10 code maps for a variety ofpurposes, such as identifying which codes will define a specific policy, disease management area, or benefitcategory—always important for native updates to back-end systems. Another use is identifying the specificcodes used to analyze data before and after the implementation date to ensure accurate conversion ofhistorical 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 ofrelated codes without providing critical details that explain how and why the codes are related, or wherethey differ. For healthcare entities, this means they will have to spend a significant amount of time andeffort to evaluate those differences.During the small-group discussions, attendees recommended that mapping be tailored to specific policies andedits, 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 beimportant to consider the iterative nature of mapping to manage rework and the inevitable ripple effectseach may cause.Managing ICD-10 transition across the enterprise requires attention to people, processes andtechnologySummit attendees all agreed that ICD-10 will have a far-reaching impact of ICD-10 on people, businessstrategy, operational processes and technology infrastructure. In one presentation, Deloitte and BlueCross and Blue Shield of Tennessee (BCBST) discussed the importance of identifying and engaging anexecutive sponsor throughout the ICD-10. The discussion also centered on the significance of programstructure 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 bestpractices around corporate governance could be ideal for ICD-10 projects, particularly to ensureincreased collaboration among business and technology groups. One of the strongest recommendations wasto structure the ICD-10 Program Management Office (PMO) along the same lines as traditional IT PMOorganizations, because of the proven capabilities of such a structure. However, if an organization’sexisting IT PMO takes on ICD-10, its KPIs and associated metrics should be redefined to focus on theobjective 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 theconversation early on and emphasized that “compliance” often has different meanings to people and acrossdepartments. One team in the small-group exercise discussed compliance challenges and recommended thatthe definition of ICD-10 compliance be different from HIPAA 5010. Instead of “compliant” transactionsbeing interpreted between entities, the team said the rule of law must have a hard cutover date forcompliance, meaning parallel submissions for the same date of service is not an option. The team also notedthat paper claims should be treated the same as electronic ones.And from a people perspective, Summit participants agreed that the biggest inhibitors to internal readinessare 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, andpotentially 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 highfrequency, high impact, high dollar amount claims. Identify high risk providers, claimscenarios. You might need to perform historical claim data analysis to determine yourrisk and define testing strategy.Your Medical policies and benefit remediation will be the starting point. Look at thebusiness rules impacted. Check for change in IT process due to MP or Benefitconfiguration (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 editingrules 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 past5 years if that data is available and within that assess which of those claims wereprocessed with a Medical Policy, Benefit or Contract rule that required matching of anICD code. Remediation these first. My research shows that more than 50% of theprofessional claims submitted over that period of time map one to one from ICD-9 toICD-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 forprofessional providers. Your highest volume will most likely be professional claims,thats just logical.Then, look at the facility claims in the same manner. These are more complicated due tothe sheer number of data elements on a UB04 claim (paper or electronic). Building testcases and claims for the impacted benefits, contracts and Medicap Policy rules is the firststep.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 filefor 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. Lets beoptimistic and realistic about the work effort required to complete this work by 10/1/2013and build plans accordingly.A payers 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 needto be incorporated into your test plans as well. Your 5-year claim history will give you agood perspective on how big of a ICD9 to ICD10 mapping challenge you have in termsof 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, youshould be well situated.work done on ICD-10 remediation should be analyzed on HOW (via ICD codes) in abenefit, contract administered including any overlying Medical Policy rule. Somebenefits are complex and are restricted by multiple levels of criteria and run across linesof 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 andtumor conditions) for which the cost to deliver these services is high and for the plan toovercome higher costs, the claims are managed to the degree that Disease ManagementPlans can be developed to improve the patients condition. Hint - if a service requiresauthorization, it is also likely to be managed for a condition (diagnosis). Authorizationrules play a role in this too.As for QNXT specifically, the Medical Policy rules often conflict with benefit andcontract configuration, so documentation of what the intention of the managementrestrictions is key to the appropriate configuration options. Remember also that QNXTprocesses claims by hierarchy rules and they were originally designed to make paymentdecisions leaning toward what is best for the member. Take a look at the adjudicationsteps on a claim and you can see where the hierarchy is and when the claim processeswhat rules. The manual will be of value to you if you are new to QNXT,ICD-10 Testing ServicesAutomated field validation enabling quick testingPartner migration testing and QATesting new partner boardingTest management suite for tracking testing status, test cases, defect tracking, builds, andresolutionUser acceptance testingClinical Neutrality:Clinical neutrality will mean to convert all the ICD-9 to ICD-10 codes and ICD-10 to ICD-9codes in an absolute 1:1 relationship with respect to the code descriptions for both theform of code sets. This will help the systems to convert all the incoming ICD-10 claims toICD-9 claims and process in the legacy systems without the need to completelyremediate the mainframe systems.This can be achieved by a crosswalk which will contain both the ICD-9 codes andICD-10 codes in the form of a map and the map will be 10 to 9 for the same. The goal ofClinical Neutrality is based on having approximately the same number of candidates in awellness and care management programs as they are today (with ICD-9), so there shouldbe no impact of the code change.For example, ICD 733.82 (non-union of fracture) is only one code forfracture of any site, but in ICD-10, it has ~2000 codes describing differentlocations. So clinical integrity can be established by picking the right codeaccording to the location.The Clinical Integrity Rules placed in iCRM are already achieving somelevel of clinical neutrality which can be further fine-tuned by adding moreclinical variables where unspecified or other specified code is mapped.
For the other artifacts such as medical policy, benefits, and provider contracts; each ofthe artifact need to be reviewed and mapped to ICD-10 codes and further tested withrespect to the test case scenarios in the form of ICD-10 claims and process to achieveclinical neutrality in the ICD-10 environment.Benefit neutrality: This means that the use of ICD-9 or the equivalent ICD-10 codes results inthe 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 forICD-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 talksabout how these neutralities can be achieved. What are BCBSMs six dimensions ofneutrality and how the payors transition plan incorporates these aspects into ICD-10readiness, what is BCBSMs 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.htmlhttp://www.amazon.com/Roadmap-ICD-10-Readiness-Practices-BCBS-Michigan/dp/193722967XAs discussed, tried to find out how the codes are being mapped in the industry so as toachieve the best possible clinical neutrality.In the iCRM, we already have rules which are based on Clinical Integrity Rules whichhave been made by using physician’s inputs. In certain rules where codes are beingmapped to other specified or unspecified code those scenarios can be fine-tuned byadding more clinical variables from the data.Had a discussion with some of my friends who are working in this industry suggested mean approach which is listed in the document and also provided the inputs that they havesubscribed to certain services (mentioned down below) which help them achieve therequired 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.htmlhttp://www.amazon.com/Roadmap-ICD-10-Readiness-Practices-BCBS-Michigan/dp/193722967XAlso – as of now there are no LMRP/MCD available for ICD-10 which is released forICD-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=1Automated Claims Testing SoftwareXpress 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 virtuallyany moderndatabase technology available today. Below is a summary of supported software andtechnologies.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-0420fax: 480-820-2938Virginia Beach, VA Officeoffice: 757-216-9710fax: 757-216-9711medicaldataexpress.comScenario Based TestingTHE BUSINESS CHALLENGEThe 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-10vs. 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 today• It recreates that event virtually through some verbal or data representation• We 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 risk
• Identifying requirements• Virtually applying alternative assumptions and variables• Virtually testing remediation options• Establishing the test plan and test cases for post-development systems testingPICKING THE RIGHT SCENARIOS?It will be impossible to identify every process and potential area of risk, but we cangreatly minimize risk and improve the efficiency of assessment, remediation and testingby picking the scenarios that represent:• High Volume• High Cost/Revenue• High complexity, or likely points of failure• Anticipated 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 VOLUMEThe 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/REVENUESimilar 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 data3% 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 system13.8% = Diseases of the musculoskeletal system and connective tissue9.7% = Injury and poisoning8.9% = Diseases of the digestive system8.8% = NeoplasmsBased on MDC categories of DRGS, the top 5 MDCs included the following:
17.3% = Diseases& disorders of the musculoskeletal systems & connective tissue16.6% = Diseases and disorders of the circulatory systems8.7% = Diseases and disorders of the digestive system8.5% = Pregnancy, child birth & the puerperium7.1% = Newborns and other neonates with conditions originating in the perinatal periodHIGH COMPLEXITYThe 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 purposes7.6% of billed charges were related to claims where the primary procedure code (ICD-9)required more than one ICD-10 code for mapping purposes23% 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 OPPORTUNITIESThe 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-outsREFERENCE 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 mayhave 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 the
factors mentioned above.THE SCENARIO• A 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 thewound 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 reportingAccreditationQuality 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.SUMMARY• Testing 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 implementation• True 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 complexityEvaluating 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 hasreduced the number of internal test scenarios to just a couple of hundred.
Flo Buendia of WellPoint discussed external testing and noted that WellPoint usesseveral 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/termsWellPoint has targeted 8 hospital facilities for its first phase of external testing. Thepayer gives the providers claims that are high-risk (potential for significant variation inpayment) and asks them to recode them into ICD-10. WellPoint manually processes theclaims and then jointly reviews the results with providers. Future phases will include amore complete end-to-end processing of claims and will be expanded to the generalprovider organization.ICD-10 testing will soon become a major activity for payers and providers. Theexperience by Humana and WellPoint both reflect the importance of developing testscenarios based on analysis of historical claim data.Areas to Consider When Testing ICD-10 Impact to Payer BusinessProcessesRemediation of payer systems is not complete withoutperforming adequate testing of revised softwareapplications and business processes. The following aresome of the areas that should be considered whencreating and defining ICD-10 test plans.All Areas1. Internal and external systems may use an ICDversion code so downstream logic can discern code type.This code type must be recognized on an effective datedbasis: either date of service or discharge date, dependingon setting (inpatient vs. outpatient.)Logic needs to distinguish version code, date and setting todecide code path.2. Logic in many areas will be based on configured andcross-walked ICD-10 codes back to a corresponding ICD-9code(s), or to crosswalk ICD-9 codes forward to thecorresponding 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 claims 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 claims 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 testingTesting should include:• A means to perform validation of format and content• Provide visibility into and accountability for transaction flow through multiple process stepsincluding transformation and crosswalking and the linking of results/response transactions tothe 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 businessoutcomes)The differences with ICD-10 will require new test cases and more casesMigration to ICD-10 changes the foundation or “building blocks” of the business processMore complex due to ICD-10 (i.e., change in validation logic, redefinition of rules, redefinition ofpolicies, crosswalking, retention of original code, changes to technology, etc.)Standard testing will not sufficeTesting needs to support the magnitude of this initiativeTesting Progression from Level I to Level IIPurpose of the slide: To convey that overall, there are two types of testing; level I (internal) andlevel II (external). Convey that level I testing must satisfy goals before moving to external or levelII testingTalking Points:• There are two (2) recommended testing types for ICD-10; internal or level I and external orlevel II.• Internal testing is to be conducted first and consists of many different levels of testing thatvalidates internal operations. Includes end-to-end testingExternal testing is subsequent to internal testing and is just as critical as its predecessor andtests the sending and receiving of transactions that include ICD-10 with business associates;ensuring interoperability amongst trading partnersSuccessful completion of internal and external is essential. The next step is “move to productionor “go live”. However, SMAs should consider that there are other tasks/deliverables that mayrequire assessment/review before transitioning to “live”.In a post production environment, some re-testing may occur as issues/problems are identifiedand solutions reachedSuccessful testing will minimize problems in transaction processing and claims payment afterOctober 1, 2013.Major challenge for all of the participantsConsider 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 stepsincluding transformation and crosswalking and the linking of results/response transactions tothe 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 businessoutcomesInternal Testing – Level OnePurpose 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 fromthe completion of all design / build activities• Internal testing is done to determine if the programming or software changes for the ICD-10code set have been installed correctly and the systems are functioning properly• Completing internal testing will allow SMAs to identify and resolve any internal systems issuesthat 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 flowprocesses used to collect and report diagnosis codesSMAs 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 theSMA with internal testingExternal Testing (Level Two)Purpose of the slide To convey that the transition to ICD-10 is based on exhaustive testingamongst all the external organizations that do businesses with the SMA ICD-10 Testing 4 April26, 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 eachtransaction• To conduct business-to-business testing, all parties have to be ready to test the sametransaction at the same time• The success of ICD-10 depends on testing; simple testing to verify changed formats andcontents will not sufficeSMAs 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 transactionlevel?• 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 isdifferent about testing ICD-10?”Talking Points:Standard testing for compliance with format and content will not be enoughWhat is important is end-to-end testing with trading partners and the review of responsetransactions that ensure business intent and reimbursement requirements are metTesting: What’s Different about ICD-10?Purpose of the slide: To convey that the standard testing approach and methodology works forICD-10 but also convey how ICD-10 makes testing differentTalking Points:Standard testing approach categories (i.e., performing a needs assessment, developing a teststrategy, developing test plans, developing test data, and developing test scenarios) aresteps/activities that need to be performed for ICD-10 but,Standard testing approach needs to be modified to include the differences that ICD-10 offersPreparing for ICD-10 includes:Speak briefly to each of the items: Examples belowArchitectural ChangesTesting needs to occur to ensure that the system will accept the increased field length andalphanumeric character place holders as well as ensure recognition of the ICD-10 during theadjudication process to ensure accurate payment or non payment of claims.System performance testing will be key in determining the appropriate data base size toaccommodate the new code set.Significant testing will need to occur to ensure that during dual processing the MMIS recognizesthe ICD-9 codes versus the ICD-10 codes and accesses the appropriate benefit string based ondates of service.Testing needs to occur to ensure that the correct code type is riding with or is accompanied bythe correct I9 or I10 code.Linking the translated code back to the original code will require new processes to be developedand tested so that history accurately reflects the code originally submitted on the claim.Maintain original as well as new code
New FormatTesting to ensure that MMIS recognizes all codes submitted and that the new format isrecognized during adjudication and downstream processing. Testing to ensure that the datadictionary is updated appropriately .Business rules and EditsTesting needs to occur to ensure that the revisions made to business rules related to clinicalediting, claims adjudication, fraud detection , and care management are appropriate and alignwith SMA objectives. Testing to ensure that during equivalent aggregation, the intent of therules are met. Basically all existing logic requires testing to determine if the revisions satisfy SMAguidelines and operating procedures.SMAs will need to test to determine if the revisions made to re-coded edits are appropriate. Forexample, the edits to ensure proper payment or nonpayment for services will need to be testedto ensure accuracy.AlgorithmsSMAs will need to test to determine if the revisions made to risk stratification and predictivemodeling algorithms are appropriate/meet SMA guidelines. SMAs will need to test the changesto AP-DRG and MS-DRGs support accurate claims processing; consider impact to providercontracts.Code Conversion – Crosswalks, GEMS mappingGiven the dramatic increase in codes from ICD-9 to ICD-10 and the increased specificity ofICD-10 have created more many-to-many matches than exact matches. With so few exactmatches, SMAs will need to redefine their policies and procedures and ensure that their tradingpartners’ rules align. SMAs need to test to ensure accurate claim payments.Revisions made to clinical policies require testing to ensure appropriateness of care andaccurate adjudication.Scope:Test scenario approach document elaborates the preparation of the test details forclinical test scenario.Following are the steps which are pursued in preparation of Test details fora 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 RevisionsUser screens are updated to accommodate new format, structure and ensure the correctdefinition of the code displays.System Interfaceinternal interfaces and external interfaces require update to accept and send transactionscorrectlyHistorical DataTypically 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 forclaims submitted with ICD-10 history will start to be encoded in ICD-10. Testing will need toinclude accurate adjudication taking into consideration benefit limits/accumulators, etc.Consider converting historical data; crosswalkOperations ManagementPurpose of the slide: nTo explain the operations management business requirements, theICD-10 testing impact, and the level of testing requiredTalking Points (Applies to each business area following this slide)When business requirements are defined, the business unit has the information needed to begindefining how IT can be used to fulfill the business requirements identified.Speak to the impactsExplain how the level of testing will support the needNote: list includes high level impactsNew 5010New formatRedefined rules, policies, etc.Code type supportCode translationLink/retain original codeClaim pricing/DRGDual processingTesting Levels Impact- Remediation StrategiesPurpose of the slide: Discuss ICD-10 testing impact to the remediation strategiesTalking Points:Maximum Upgrade StrategyTesting is focused more on validating the newly developed /changed business processes,workflow, and interfaces, integrating the re-designed workflows/processes/interfaces with theexisting 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, casemgmt)• 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 DRGTest CasesPurpose 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 thesystem components function efficiently to support business requirements; the resultsdetail/report system readiness• The design of test cases includes both anticipated outcomes and scenarios that relate toexception processing and errorsStructured Test GovernanceObjectives: To convey that a strong, well structured governance / management is required fortesting.Talking Points:Governance establishes:Clear roles and responsibilities for each testing groupComprehensive communication between the relevant teams; bring all the teams to acommon ground of understandingClearly defined quality gates for each stage of testingMinimum testing overlap between testing teams / vendorsTest environments are available for each stage of testingBetter information on overall testing activities and quality of the applicationAllows top management to make informed decisionsScenario based TestingPayment NeutralityScenario: Validate that the Medical Claim is processed successfully (same asin the existing ICD-9 based systems) by a PCP in the new remediatedsystems for a subscriber suffering from Osteoporosis and treated with totalknee replacement given as ICD10 code and who is enrolled in HMO Planwhere referral is mandatory.
Test Data:Claim details are as follows:ICD-9 Dx : 71536ICD-9 Px : 8154DRG-9 : 470Charged Amount : $5000Allowed Amount : $4500Expected Output:ICD-10 Dx : M179ICD-10 Px : 0SRC07ZDraft-DRG 10 : 470Charged Amount : $5000Allowed Amount : $4500* Assumed Acceptable variance of +/- 3%Possible matches with DRG shiftsICD-9 ICD-10 Claim MDC-9Claim DRG-10 MDC-10 DRG-98154 470 08 0SRC07Z 470 08 0SRT07Z 469 08 0SRT0JZ 469 08Benefit Neutrality:Scenario:Validate that the Medical Claim is processed successfully (same as in theexisting ICD-9 based systems) by a PCP in the new remediated systems fora subscriber suffering from Other benign neoplasm of skin of lower limb,including hip and treated with Insertion of tissue expander given as ICD10code 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 : 578Charged Amount : $6000Allowed Amount : $5100Member Deductible : $300Member Copay : $100Member Liability : $400Payer Liability : $4700Expected Output:ICD-10 Dx : D2370ICD-10 Px : 0JH00NZDraft-DRG 10 : 578Charged Amount : $6000
Allowed Amount : $5000Member Deductible : $305Member Copay : $102Member Liability : $407Payer Liability : $4593* Assumed Acceptable variance of +/- 3%Possible Matches with DRG shiftsICD-9 ICD-10 Claim DRG-9 MDC-9 Claim DRG-10 MDC-108693 578 09 0JH00NZ 578 09 0JH03NZ 573 09 0JH10NZ 573 09ICD-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 dataICD-10 Test Management Test Scenario and Test Case Management Test Data Management Traceability Management Defect Management Metrics Management Test Environment MgmtICD-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 ReportsRisk 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 codesMedical Policy Configuration Test Scenario/caseScenario Description: Validate that the Medical Policy has been configuredsuccessfully in the ICD-10 environment when mapped from the equivalentICD-9 environment for the policies of CT scan and Para vertebral Facet JointNerve Block for the same code(s) 73382 i.e., nonunion of fracture.CT ScanParavertebral Facet Joint Nerve Block
RecommendationAs per the intent of the policy "Para vertebral Facet Joint/Nerve Block", thepolicy is specific to procedures performed on the cervical, thoracic andlumbar joints and their coverage is also specific to the same anatomicalregions. When the nonspecific code 73382 (as part of the coverage) ismapped to ICD-10 codes, it has several codes which are specific to thepolicy but other codes are not specific to the policy, hence the highlightedcodes 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 TestDetails Samples.xls
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 testCompleted 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 mayCCGs in Review 44 3 132 change based on review Total Hours 369Note: Total CCGs are 178.