Monday, January 03, 2011

ICD-10 and Final Rule Information


·     Why now?
·     ICD 9 is running out of codes fast
·     Lack of comparability of data with global health reporting for disease tracking and research
·     ICD 9 lacks sufficient flexibility to describe new diseases, new technologies and new treatments
·     ICD 9 does not support development of new DRGs with adequate specificity for new technologies or treatments
·     What are the benefits?
·     Improvements in specificity
·     Expandability for new advances in medicine and medical technology
·     Expandable for future coding needs
·     Supports laterality
·     Supports improved coding for primary care, external causes of injury, mental disorders and other areas
·     Supports comparability of data with other countries
·     What is CMS’s compliance approach
·     Big Bang (same true for HIPAA EDI 5010)
·     BUT CMS will not immediately adopt ICD 10 for actual basis of DRG assignment and severity adjustment until a few years later
·     Why Big Bang is better?
·     To avoid issues with “dual use” that would result in overlapping use of ICD 9 and ICD 10 by payers and providers that would be out of synch
·     To reduce burden on coders to maintain two systems of coding
·     To eliminate costs of maintaining production systems support two coding systems
·     To reduce costs of maintaining multiple edit systems
·     To prevent confusion over which coding system to use in filing claims or report data externally
·     Why Not Immediately Using for DRG Payment?
·     To avoid rework of MS-DRGs so soon after initial adoption
·     To build experience with ICD 10 coding usage to assess DRG classifications and severity adjustment impact on reimbursement
  
ICD 10 IMPACT ASSESSMENT PROCESS

·     Is this not just another version change for ICD? Why is this different?
·     Order of magnitude – far more than managing the usual code expirations and additions – whole new medical nomenclature type
·     No historical frame of reference for use of the medical code set values built up unlike with a normal version change
·     Significance of impact on clinical content, clinical coding, decision support and business logic within HIT applications to maintain par level function
·     Comparability of data disrupted without some means of supporting mapping
·     What must be inventoried?
·     Only Revenue Cycle?
·     Or all the systems that use coding data for diagnosis and procedures?
·     Given that CMS proposes a “big bang”, what all needs to be updated?
·     Obvious Stuff
·     Coding Systems
·     Patient Accounting Systems
·     Scrubbers
·     Groupers/Encoders
·     Contract Management Systems
·     Somewhat Obvious Stuff
·     Eligibility Management Systems with Medical Necessity components
·     Compliance editing within coding, claims management, scrubber and charge master systems
·     Estimated reimbursement modeling
·     Revenue Cycle reporting systems
·     Less Obvious Stuff
·     Acuity modeling systems/database
·     External regulatory reporting specifications (e.g. state discharge/public health reporting)
·     Visit coding tools
·     Clinical decision support systems and content
·     Clinical documentation systems – forms and templates
·     Quality Management data collection, abstraction and reporting systems and specifications
·     Stuff You May Not Think Of
·     Surgical Pick Lists
·     Specialty Scheduling Systems (Resourcing driven by Condition or Procedure requirements)
·     Patient Education Materials
·     Discharge Planning tools
·     Nurse Staff Scheduling Systems
·     ICU Morbidity and Mortality Modeling
·     Order Sets, Care Plans, Care Protocols
·     Etc, etc and so forth

Key Areas of Assessment
 
·     Search functions and validation routines
·     “Hardwiring”
·     Policies for effective date
·     Data Capture/Data Entry Edits and Formats
·     Any embedded referential integrity edits on code set values
·     Field lengths as entered or stored
·     Display of code descriptions
·     Need or Use of Mapping Between ICD 9 and ICD 10
·     Conversion of databases
·     Conversion of code set maps
·     Continuity of information
·     Dual Use
·     Preserve logic functioning around compliance date
·     Retain ability to use ICD 9 for older activity that predates compliance date
·     Documentation Forms
·     Any form presentation or selection driven by application logic
·     Predefined Reference Content/START
·     May be more a consideration for Bedrock
·     Decision Support Rules
·     Any embedded Discern Expert or Advisor rules – again may be addressed by Innovations
·     Workflow/Business Processing Rules
·     Application logic flows or user conversational flows driven by ICD 9 CM or PCS
·     Compliance Edits
·     Applied during processing beyond point of data capture
·     Printed or Outputted Materials or Notices
·     Patient Education Materials/Discharge Instructions
·     Reference Links
·     Reporting or Analytics
·     Use of diagnosis or procedure codes for selection, filtering, presentation or sorting
·     Interfaces/Third Party Embedded Solutions
·     To third party products used for support of application logic or function
·     In the transaction layout – especially for external regulatory reporting or for application to application interfacing
·     Within third party products
·     Modeling
·     Acuity/Staffing
·     Risk modeling
·     Preferences
·     Catch all for any other application behaviors

Output from Assessment - Core Guiding Principles for the vendors

·     Enable common use of a default nomenclature type
·     Enable common support for effective date policy
·     Enable use of mappings where appropriate to use case especially to assist in search
·     Eliminate any hardwiring tied to ICD 9
·     Provide ICD 10 enabled content
·     Do not attempt to convert but either enable general equivalency or allow selection of a more appropriate and specific code
·     Do not convert any stored activity or analytic data
·     Enable use of mappings as appropriate on abstracted data especially for analytics
  
Core Project Checklist Used to Evaluate Each Application

·     First Phase for any given IP team – Address basic behaviors and uses 
·     Search component – support a default vocabulary type (no hardwiring for ICD 9)
·     Search component – support effective date policy
·     Validation routines – support a default vocabulary type
·     Validation routines – support effective date policy
·     Displays of code set values – assure field length of 7 supported
·     Analytics/reporting – support use of diagnosis or procedure code concept – not hardwired reference to ICD 9
·     Second Phase for any IP team and for specific domain issues– Address more complex issues 
·     Enable a search assistant that uses forward map
·     ICD 10 enabled reference lists, pick lists, order sentences, documentation fragments and other displays of reference lists
·     Use effective date policy
·     Address any business logic hardwiring
·     Update use of mapping  for SNOMED to ICD 9 to SNOMED to ICD 10 (limited use currently – mainly to support problem list to diagnosis code selection)
·     Discretionary
·     Move to a common nomenclature routine
·      Adopt SNOMED to ICD 10 mapping to facilitate end use
·     Use of ICD 9 to ICD 10 mappings for any extracts for analytics 

Resources
 
·     ICD-10-CM (Diagnoses)
·     ICD-10-PCS (Procedures)
·     GEMS
·     The CMS website has the GEMs and User’s Guides
·     ICD-10 General Information
·     ICD-10 Educational Resources
·     ICD-10 CMS Sponsored Calls
·     ICD-10 Final Rule
·     CDC
·     General ICD-10 information
·     ICD-10-CM files, information and general equivalence mappings between ICD-10-CM and ICD-9-CM
·     AHIMA
·     Readiness checklist

No comments:

Post a Comment