Segment Two: Business Requirements Drive the Technical Updates

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

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

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

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

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

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

7. 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 MMIS Way Aggregate Pl

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

9. Architectural Changes: Structural Changes Influence Systems

10. User Interfaces Updates will be needed to the following: • Captions • Data Type Support • Field Length • Data Sources • Code Descriptions Displays • Number of Supported Codes Per Claim

11. System Interfaces Internal Interface • Exchange of information within an organization External Interface • Exchange of information within an internal organization and from an external organization

12. Data Warehouses / Data Marts 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, DXCG, ETG Report Data Warehouse/ Data Mart

13. System Engineering Evaluation of the hardware or systems engineering environment is critical. • 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

14. 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?

15. Vendor Support • Application Support • Interoperability • Programming and Testing • Appropriate mapping and crosswalk programming • Maintenance and Support

16. Non Functional Requirements Requirements Governance • 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 Non-Functional Requirements Types Design Constraints and Qualification Legal Internal Data Performance System Quality Characteristics Internal Data Privacy Usability Human Factor Engineering (Ergonomics) Security Operational Section 508 States and Modes Maintainability

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