Preparing for ICD-‐10: A Case Study for how Children`s

Preparing for ICD-­‐10: A Case Study for how Children's Medical of Dallas EffecBvely TransiBoned their BI Environment to ICD-­‐10 John Cheyney RN, MS – Children’s Medical Center Dallas Eric Vallo, President / Chief Architect – EV Technologies Your Speakers Eric Vallo • 
• 
• 
• 
• 
President of EV Technologies SAP Mentor SAP CerAfied Professional 14 Years of experience with BI Co-­‐author of SAP BusinessObjects BI System AdministraAon Your Speakers John Cheyney RN, MS • 
• 
• 
• 
Business Intelligence Architect 10 year Pediatric CriAcal Care Nursing 10 years InformaAon Services 7 years in AnalyAcal ReporAng/Business Intelligence •  Crystal Reports •  Web Intelligence •  MulAple Epic CerAficaAons Agenda § 
§ 
§ 
§ 
§ 
§ 
Children’s Medical Center of Dallas EV Technologies ExplanaAon of how Children’s uses SAP BusinessObjects Challenges of TransiAon from ICD-­‐9 to ICD-­‐10 Children’s Required SoluAon Overview of Sherlock from EV Technologies Children’s Medical Center of Dallas §  Children’s Medical Center of Dallas (CMCD) is one of the naAon’s premiere healthcare systems for children. • 
• 
• 
• 
• 
• 
• 
• 
• 
Pediatric teaching facility for UT-­‐Southwestern Medical School Pediatric Level I Trauma Center 408 Beds 136,000 ED visits 19,000 inpaAent admissions 27,000 surgical procedures 452,000 outpaAent visits HIMSS Level 7 US News and World Report ranked in mulAple specialAes EV Technologies §  EV Technologies is an SAP Socware SoluAons Partner and a Sybase Partner in the SAP Ecosystem. •  2 SAP Mentors, 3 SAP CerAfied Associates, 4 SAP Press Authors •  Small businesses to Fortune 50 enterprise organizaAons •  1 server to 50 disAnct deployments •  SAP Gold Partner •  Services organizaAon focused on designing BI strategy, implemenAng BI deployments, and creaAng effecAve data visualizaAons using SAP BusinessObjects •  Socware developer and creator of the Sherlock Inspector Suite Electronic Healthcare AnalyBc ReporBng §  Electronic Health Record: Epic (Verona, WI) §  IniAally live October 2008 Admissions and RegistraAon/Billing Clinical DocumentaAon (Including CPOE) Surgical Procedures/Anesthesia Radiology Clinical applicaAon is built on Cache database Data extracted nightly into an Oracle 11gR2 database (Clarity) •  Crystal Reports/Web Intelligence used to create analyAcal reports and file extracts from Clarity •  Business Objects Enterprise XI 3.1 in a clustered environment • 
• 
• 
• 
• 
• 
InternaBonal ClassificaBon of Diseases §  InternaAonal ClassificaAon of Diseases §  Published by the World Health OrganizaAon (WHO) • 
• 
• 
• 
• 
DiagnosAc codes used for classifying diseases and procedures Major categories include a set of similar diseases Code is alphanumeric and can be up to 6 characters long Used for: •  Morbidity and Mortality AnalyAcs •  Healthcare Decision Support •  REIMBURSEMENT (Errors in diagnoses can cause loss of reimbursement or potenAally charges for fraud) NaAonal Center for Health StaAsAcs is the US Federal agency responsible for adapAng ICD informaAon. Works in collaboraAon with Canadian resources. hjp://www.cdc.gov/nchs/icd/
nacc.htm ICD-­‐9-­‐CM §  ICD-­‐9-­‐CM (1979-­‐1998) §  Current system used in the US to assign diagnoses and procedures §  Codes can be added by the provider seeing the paAent or by professional coders/automated coding socware §  Available online from the NCHS •  hjp://www.cdc.gov/nchs/icd/icd9cm.htm •  $29.00 ICD-­‐9-­‐CM §  Can be very simple • 
• 
• 
382 (SuppuraAve and unspecified oAAs media) 382.0 ( OAAs Media, acute) 382.01 (OAAs Media, acute, w/ rupture of ear drum §  Or Not • 
• 
COUNT
21843
549
482
369
340
4
3
We actually have 240 diagnoses that roll up to 382 But luckily we only use a few of those (Jan-­‐Dec 2012) ICD9_CODE
382.9
382.3
382.00
382.4
382.01
382.1
382.2
DX_NAME
Unspecified otitis media
Unspecified chronic suppurative otitis media
Acute suppurative otitis media without spontaneous rupture of eardrum
Unspecified suppurative otitis media
Acute suppurative otitis media with spontaneous rupture of eardrum
Chronic tubotympanic suppurative otitis media
Chronic atticoantral suppurative otitis media
ICD-­‐10 §  Work on the 10th version was completed in 1992 •  144000 codes •  Adds new diagnoses •  Breaks old diagnoses into new categories •  Already adopted in many countries •  Current deadline for US adopAon is 1 October 2014 •  Has been postponed mulAple Ames due to the enormity of the work effort •  Not only a new list of codes but an enArely new structure ICD-­‐10 The Issues §  Conversion to ICD10 is a huge challenge • 
• 
• 
• 
• 
• 
• 
• 
• 
EnArely new code set ApplicaAon changes and new applicaAons New workflows Not opAonal. Changes driven by the US government PotenAal loss of revenue due to coding errors PotenAal for accusaAon of fraud Other organizaAonal prioriAes Huge impact on analyAcs and staAsAcal reporAng already in place. Need to maintain conAnuity in reporAng across the changes Changes to deadlines cause organizaAonal stress The Timeline §  April 2013 • 
• 
• 
• 
• 
ImplementaAon of hidden dual coding Providers will conAnue to use ICD9 Background processes will add/convert ICD9 codes to ICD10 codes Training and troubleshooAng Reports have to be modified by the day of go live or they quit working §  August 2013 • 
• 
• 
Visible dual coding More training and troubleshooAng Second round of report modificaAon has to be done §  1 October 2014 • 
ICD10 coding in full use Impact on AnalyBcs §  Data extracted from Cache to an Oracle database (Clarity) •  Primary source of analyAcal reporAng •  Also used as a source for various file extracts •  Crystal Reports is the primary tool for reporAng out of Clarity (increasing use of Web Intelligence) •  Database had been in place for approximately four years. •  Somewhere around 1000 individual report files loaded on the Enterprise server THE MAJOR ISSUE Epic made fundamental changes to their data model for ICD10. All reports had to be modified by the day the applicaAon changes went live or the reports would stop working. The Response §  Massive OrganizaAonal Freakout • 
What needs to be done? • 
• 
Who is going to do it? • 
• 
Distributed report writers. Approximately 25 people who could be wriAng reports. How many reports need to be touched? • 
• 
• 
Modify Crystal Reports currently in producAon so that they conAnue to work acer the first stage goes live How many don’t need to be touched because they are not in actual usage? EsAmates were all over the board. IniAal guess was 400. Where are they? • 
Distributed report writers may be using local copies of reports not loaded to the server. IniBal Plan §  Epic had a process to analyze the reports •  Required taking the report files and sending them to Epic for analysis •  Did not go through reports that used a SQL command •  Best guess was that approximately 1000 files would need to be rounded up and sent •  OrganizaAon decided this was a capital project. Project lead allowed us to hire contractors for the iniAal work Started looking for other opAons… The New Plan § 
§ 
§ 
§ 
Locate tables storing ICD-­‐9 data Implement Sherlock from EV Technologies Magic (a.k.a., locate affected reports) Modify affected reports How does Sherlock work this
magic?
Sherlock SoluBon Overview 3
Sherlock stores the
data in it's repository
4
1
Sherlock engines
inspect your SAP
BOBJ Deployment
2
The data is returned and
the engine performs
calculations to create
more interesting and
actionable data
You report on
it using native
SAP BOBJ
tools
The Sherlock Engines Sherlock CMS Inspector Sherlock Report Inspector Sherlock Universe Inspector Sherlock KPI Sherlock ERF Sherlock System Metrics Sherlock Quick Sizer Sherlock Recent Usage Scenarios 2 days to diagnose a CMS that had been failing for 4 months 85% decrease in schedule batch window 42% of producAon licenses recovered 15% redundancy in producAon Universes 72% reducAon in used storage by eliminaAng 600,000+ unused reports 25% reducAon in number of discovered issues acer an upgrade New Plan Part I: LocaBng the Tables §  CommunicaAon to the distributed report writers about the project and that if they needed our help they had to let us know. Found out that all reports that needed analysis were loaded onto the Enterprise servers. §  Epic provided us with documentaAon showing which tables were affected. Key was to find the reports that used those tables. New Plan Part II: LocaBng the Reports §  Put the list of tables into Sherlock •  Aliased tables also found •  Excluded folders that held archived/one-­‐off/unused reports •  Final number was 184. New Plan Part III: Modifying the Reports §  List of reports and the file path to get to them was given to contractors. §  All reports were modified/tested/rescheduled by the contractors §  Effort used to actually modify the reports was approximately 240 hours over approximately 3 weeks (2 contract resources). §  As of right now the effort hasn’t gone live so I don’t know the outcome. By the Ame we actually do the presentaAon we should know how it went. Lessons Learned §  Lessons Learned • 
• 
• 
Knowledge is the enemy of chaos and fear. By finding out the correct number of reports that needed to be modified we were able to make solid plan to make our deadlines Dedicate the resources necessary. Without the ability to purchase the applicaAons and contractors we needed this would have made a major impact on our operaAons. Plan but be flexible. Since very few other faciliAes have gone live with this there is not a roadmap. The underlying assumpAons of the project changed a number of Ames. THANK YOU FOR PARTICIPATING Please provide feedback on this session by compleAng a short survey via the event mobile applicaAon. SESSION CODE: 3507 For ongoing educaBon on this area of focus, visit www.ASUG.com