Segment Two: Business Requirements Drive the Technical Updates January 26-27, 2012 Idaho ICD-10 Site Visit Training segments to assist the State of Idaho with ICD-10 Implementation

Agenda Introduction – What’s Really Involved Business Requirements Technology Updates to Support Business Requirements Vendor Support Non Functional Requirements 1

More Than an Update to a Code Set 2 Source: Cognizant Health Care 2009

Determining the Requirements 3 Functional Requirements Non- Functional Requirements Historically known as System Requirements User Requirements Business Requirements/ Business Rules Business Process Models Business Purpose Errors made during the requirements stage account for 40 to 60 percent of all defects found in the software program CMS Requirements Writer’s Guide (Version 4.11). Centers for Medicare and Medicaid Services. Accessed at:

SMA High Level ICD-10 Implementation Timeline 4 Sep 2010 – Mar 2014 Awareness Awareness, Communication, and Education/Training Awareness Awareness, Communication, and Education/Training Oct 1, 2013Jun 2012 Jun 2011 – Jun 2012 Remediation Develop Change Requests and Requirements Develop Policy Updates, Process Updates, and System Updates Execute Systems Testing Remediation Develop Change Requests and Requirements Develop Policy Updates, Process Updates, and System Updates Execute Systems Testing Sep 2010 Sep 2010 – Jun 2011 Assessment Plan for ICD-10 Activities Perform an Impact Assessment Develop a Remediation Strategy Finalize APDs Assessment Plan for ICD-10 Activities Perform an Impact Assessment Develop a Remediation Strategy Finalize APDs Jul 2013 – Oct 2013 Transition Implement Policy, Process, and System Changes Transition Implement Policy, Process, and System Changes Jul 2013 Window for developing policy, process, and system updates Jun 2011 Start Program Remediation ICD-10 Changes Completed ICD-10 End-to- End Testing Completed ICD-10 Implemented and Live May 2012 – Jul 2013 End-to-End Testing Conduct Internal End-to-End Testing (Level I) Conduct External End-to-End Testing (Level II) End-to-End Testing Conduct Internal End-to-End Testing (Level I) Conduct External End-to-End Testing (Level II) Core ICD-10 Strategies Developed Impact Assessment Completed

5 Technology updates must be coordinated… Preparation & Planning Business Rules Architectural Changes Data Definition & Validation System Engineering Vendor Dependency System Interfaces User Interfaces Data Warehouses / Data Marts Auditing and Logging Code Translation Non- Functional Requirements

Business Rules Update the business rules to reflect revised internal business policies: – Re-point all rules that use tabled codes to appropriate reference tables – Re-code rules that are hard-coded to reflect the intent of the rules in ICD-10 – Update algorithms – Update claim edits 6 MMIS Way Aggregate Pl

Data Definition and Validation 7 Perform updates across systems Data Dictionaries Validation processes based on date of service and code type Inbound and outbound transactions File format specifications

Architectural Changes: Structural Changes Influence Systems 8 Systems Field Length Alphanumeric Characters (place holders) Database Size (increased codes per claim) Dual Code Sets Code type support (qualifier) Retaining/linking translated code to original code

User Interfaces 9 Updates will be needed to the following:  Captions  Data Type Support  Field Length  Data Sources  Code Descriptions Displays  Number of Supported Codes Per Clai m

System Interfaces 10 Internal Interface  Exchange of information within an organization External Interface  Exchange of information within an internal organization and from an external organization

Data Warehouses / Data Marts 11 Impact to Reporting:  Ability to store data  Retrieve and extract data  Transform and load data  Manage the data dictionary  Update defined aggregation schemes  Evaluate Grouper Logic – DRG, DX CG, ETG Data Warehouse/ Data Mart Report

System Engineering 12  Hardware and processing capacity  Dual processing supported in operations and testing  Test Servers to support varying vendor go-live dates  Inventory equipment and evaluate the transmission capability and physical storage of hardware  Data Server’s ability to support increased claims, records, and other data  Adequate processing and storage capacity for live operations and testing  Transmission capacity  Ability to handle increased call volume and system interaction Evaluation of the hardware or systems engineering environment is critical.

Auditing and Logging Code Translation The SMA will need a log to identify each ICD translation created for each system transaction: Data translated; Translation direction; Purpose of translation; Date of data translation; and What was the original code and can you retrieve it? Who or what performed the translation? 13

Vendor Support 14  Application Support  Interoperability  Programming and Testing  Appropriate mapping and crosswalk programming  Maintenance and Support

Non Functional Requirements 15 Requirements Governance Non-Functional Requirements Types Maintainability Operational Usability Internal Data States and Modes Performance Security Privacy Section 508 Legal Human Factor Engineering (Ergonomics) Design Constraints and Qualification System Quality Characteristics Internal Data SMAs should maintain strong Requirements Governance to assure there are proper controls related to: The standard CRUD (Create, Read, Update and Delete) Change Control Process Approval processes

16 Closing Points Communicate to your teams the importance of evaluating business processes for ICD-10 impacts to further define supporting requirements for applications, databases and enterprise infrastructure. Identify gaps in business requirements to meet ICD-10 compliance. Inventory of Business Requirements Work with SMEs from business and IT to identify remediation strategy advantages and disadvantages. Access hardware. Communicate timelines with vendors and define common ground to evaluate ICD-10 vendor readiness.