CROWNWeb Overview & Update

1. CROWNWeb Overview& Update Samantha Richardson & Matthew Leipold Centers for Medicare & Medicaid Services Kelly M. Mayo, MS & Matthew McDonough FMQAI: The Florida ESRD Network Debbie Cooley CSC

2. Objectives • Describe the goals, milestones and related activities of CROWNWeb • Identify functionality of the CROWNWeb tool  • Describe other resources and processes under development to support the CROWNWeb product

3. CROWNWeb Goals • Provide more timely data • Improve data accessibility • Eliminate collection redundancy • Strengthen community collaboration • Provide value to the dialysis community • Promote quality improvement • Improve the lives of individuals with ESRD

4. Release 1.0 Functionality • Administrative elements • Clinical elements • Patient attributes and related treatment (PART) • Reporting output

5. Administrative Elements • User roles • Facility • Network • CMS • Permissions (CRUD) • Facility information • Personnel and practitioner information • Patient demographic information

6. Clinical Elements • Laboratory • CPMs • 2728 • Non-lab values (ie: weight) • History and treatment • Admit / discharge • Vascular access information

7. PART -- Administrative • Patient identifying & demographic information • Patient Last Name, Patient First Name, Patient Date of Birth (age), Patient Unique Identifier • Facility identifying information • Facility DBA Name, Facility Unique Identifier, CCN • Patient treatment information • Admit Date, Discharge Date, Discharge Reason, Attending Practitioner Last Name, Attending Practitioner First Name, Primary Dialysis Setting, and Primary Type of Treatment

8. PART -- Clinical • Hemodialysis • Anemia Management • Adequacy • Mineral Metabolism • Vascular Access – General, Exam & Site • Peritoneal Dialysis • Anemia Management • Adequacy • Mineral Metabolism

9. Reporting Output -- Data • CPM Summary • January – March 2009 • Hemodialysis and peritoneal dialysis • Facility-specific data with Network & US comparison data • Vascular Access Summary • Monthly • Incident and prevalent hemodialysis patients • Facility-specific data with Network & US comparison data

10. Reporting Output -- Other • Patient roster • Facility personnel • Audit reports • Forms • Updates • Additions • Deletions

11. Supporting Activities • Contacts & grievances • Testing scenarios • Training & guides • Marketing

12. Contacts & Grievances • Held Focus Group Meeting in Dallas on January 7-8, 2008 • Thursday, 2/21 at -- Breakout Session #2: CROWN Environment Contacts • Overview of current status of contacts, complaints & grievances BRs and KDD. • Opportunity for question and answer session. • Review of the options for an interim solution. • Presentation of proposed options developed by Focus Group under the QIS contract.

13. Testing Scenarios • 31 Testing Scenarios for Alpha 0.3 • Scenario ID • Scenario Name • Actors • Pre-Conditions • Scenarios • Outline of Actions • Questions to consider while performing scenarios • Business Requirement related to Quick Start Guide reference

14. Testing Scenarios (continued) • High level scenarios • Spectrum of events • Natural disaster cases • Transient patient cases • Gap patient cases • Admit/transfer/discharge patient cases • New/expired ESRD patient cases • Create/view/print report cases • Create/view/update/ facilities and facility’s personnel cases • Involve cross-communication between Networks and Facilities

15. Testing Scenarios (continued) • Benefits • Provide spectrum of scenarios for NWs and facilities to perform • Includes multiple tasks for both NWs and facilities as way to participate more thus giving output for feedback • Alpha 0.3 testing feedback – 101 comments in the first 2 weeks (2/7/08 to 2/13/08) • 76 comments from Networks • 18 comments from Facilities • 7 comments from CMS

16. Training Approach • Specialized training based on system roles • Providers • LDOs • Networks • CMS • Multiple off-site training sessions • Network Specific Features • Network Train-the-trainer • Collaborative LDO training • Provider Specific Features • Quick Start Guides • Web-based Learning Management System

17. Quick Start Guide • A “subset” of the CROWNWeb User Guide, containing the most frequently accessed information. • Features information “chunking”: • Modular design • Adult Learning • Document design ideal for locating information quickly. • Task-based material designed for on-the-fly use.

18. Learning Management System (LMS) • Web-based tool • Flash-based interactive training • Custom dynamic LMS • SCORM: Standardized scoring and record keeping for courses • Uses pass-through authorization from portal login • Maintains user-level and facility-level transcripts and records

19. MarketingCommunication Approach • Web communication portal • Convention exhibition and presentations • Attending ESRD community events • Presence in publications • Standard ESRD community messaging

20. ESRD Community Events • FRAA (7/12/2007) • NRAA (9/25/2007) • ASN (11/1/2007) • Network 7 Annual Forum (11/14/2007) • CMS/Network Forum (2/18/2008) • 28th Annual Dialysis Conference (3/2/2008) • RPA (3/14/2008) • NKF (4/2/2008) • ANNA (4/25/2008) • Annual Network Meetings

21. Marketing Handout Material

22. Publications • Mass Mailing • Inclusion in Network Mailings (???) • Articles Targeted for: • Nephrology News • NephrOnline • Nephrology Nursing Journal • RenaLink • Network Newsletters • Renal Watch

23. Standard ESRDCommunity Messaging “Improving ESRD Patient Care Quality... Through Data Reporting.” • Focuses on patient care • Highlights improvement • Explicit effort to improve quality • Ellipsis mechanism lends dynamic capacity • “Data Reporting” emphasizes goal of initiative

24. CROWNWeb Data

25. Facility Data Collected in CROWNWeb • New Elements: • DBA Name (in addition to Legal Name) • Organizational Affiliation • Backup Facilities • Changed Elements: • CCN, NPI values have more structured validations • Number of Certified Stations, Number of Isolation Stations, Total Count of Stations • Breakout of Services into “Certified” and “Additional” • Open Time, Close Time, and Number of Shifts for each day of the week

26. Patient Data Collected in CROWNWeb • New Elements: • Current Employment Status • Work and Cell Phones • Email Address • Current School Status • Current Voc Rehab Status • PART Verification Date • Changed Elements: • Physical, Mailing, and Transient Addresses

27. 2728/2746 Data Collected in CROWNWeb • A majority of 2728/2746 fields are pre-populated from patient attributes, admit/discharge, and modality information for a patient (one-way arrow). • Users will be required to update missing fields in the source record where the form requires a value.

28. Admit/Discharge & Modality Data Collected in CROWNWeb • New Elements: • Transient indicator with collection of contact information • Attending Physician • Transplant Prep Hospital and Transplant Status in Transplant admissions • Changed Elements: • Transfer Discharge Reasons • New treatment records replace Modality Shift events • Time per Session (in minutes rather than hours)

29. Functionality Differences in CROWNWeb • Every admission executes searching algorithms to prevent duplicate patients • Stringent Admit/Discharge Date and Reason validations. • One-way arrow information is pre-populated and disabled in 2728/2746 records • Physician selection in an admission, 2728 & 2746 are based on physicians with positions in the selected facility • Personnel cannot be added without a position • Online NPAR – PART Verification Tool • Gap Patients Tool

30. Alpha Testing

32. Alpha Testing – Participants To Date

33. Alpha 3 Testers • 79 Network Testers (all 18 Networks) • 71 Facility Testers • 13 CMS Central Office Testers • 4 CMS Regional Office Testers • 18 BCSSI Testers • 185 Total

34. Alpha 3 Testing – In Progress • Alpha 3 testing began on February 7th • Batch testing with LDOs will begin on 3/27/08 • During alpha testing, two capabilities will be added: • Patient Monthly Verification Page • Add personnel link for facility editors • The first week of alpha testing - 101 comments received • 28 were where the user issue was resolved by clarification • 14 where a system defect was found (e.g., patient and clinic sorting on patient roster report) • 11 potential design enhancement • 18 requiring a new business requirement • 30 under research

35. Data Conversion

36. Data Conversion • The following data was converted for Alpha 3 testing. • Facility. • Dialysis and transplant only. • Current record only. • Personnel. • Personnel with at least one valid job code. • Patient demographics and basic medical information. • Current record only. • Events. • Form 2728s. • Form 2746s.

37. Data ConversionData Cleanup • Data Managers have been very responsive to cleanup spreadsheets. • Problems with data (other than events) have been significantly reduced. • Event problems identified in spreadsheets supplied in November 2007.

38. Data Conversion StatisticsAlpha 0.3 Test Load • 6,841 Facilities loaded. • 35,401 Personnel loaded. • 1,711,167 Patients loaded. • 1,500,567 Form 2728s loaded. • 907,105 Form 2746s loaded. • 3,002,085 Patient Admit Discharge records created. • 3,303,165 Patient Treatment records created

39. Data Conversion’s Impact to CROWNWeb • Due to the more stringent validity checking performed in CROWNWeb, the data converted from SIMS will require the user to enter/correct this data when editing records • Some data missing in SIMS will require the user to enter this data when editing records • For example, dialysis treatment records require a patient's physician, but we do not have that information in SIMS to convert

40. What happens to SIMS after February 9, 2009? • Data will be replicated from CROWNWeb back to the SIMS Central Repository to support REMIS • Replication to local databases will be turned off • Users will be unable to add data to SIMS Central Repository

41. Electronic Data Submission (Batch)

42. Batch Overview • Batch user will be able to submit patient and clinical data via XML files • Files will be processed within 24 hours of receipt by CROWNWeb • The following will not be supported via batch in Release 1: • transplant patient admissions • 2728 and 2746 record submissions • facility information • attending physician information is supported, but other personnel records are not

43. Batch Overview • Two XML Schemas: • One for patient information (patient attributes, admit/discharge, and treatment (modality) elements) • One for Clinical and Vascular Access data • Although still under discussion it is anticipated that • Clinical data will be submitted monthly • Patient data will be submitted on a more frequent basis (weekly) • A final patient update file will be submitted together with the clinical file so that they are synchronized.

44. Batch Participants • Three LDOs will submit via batch for Release 1.0 • Davita (DVA) • Dialysis Clinics, Inc. (DCI) • Fresenius Medical Care (FMC) • As resources permit, CMS will approve additional third party submitters after 2/2009 based on • Technical ability to comply • Responsibility and reliability • All potential additional submitters after 2/2009 have to agree to the same definitions for purposes of batch submissions • CMS has no control over LDOs to standardize their systems so reporting is uniform

45. Batch Activities • Held a meeting in Nashville on 12/5/07 with CMS and electronic submitter representatives • Received several complete patient files from DaVita, FMC and DCI. • Each LDO has submitted full facility files with NPI’s for each facility. • Continuing development and testing batch processing of patient data, identifying issues and feeding back to LDOs. • LDOs are correcting data in their systems. • Last in-person technical meeting held 1/23/08

46. Batch Results to Date

47. Batch Processing • The first time a patient is received, it is matched to the existing CROWNWeb data. There are 3 possible results: • No match – patient will be added to CROWNWeb • Exact match – patient in CROWNWeb will be updated or transferred as appropriate • Near match – LDO and Network work together to ensure correct result above which may require some manual intervention.

48. Batch Processing (2) • Once matched, CROWNWeb stores: • The submitter facility ID matched to the CROWNWeb facility ID • The submitter patient ID matched to the CROWNWeb patient ID • The submitter admit/discharge and treatment ID’s stored alongside the CROWNWeb admit/discharge records

49. Batch Processing (3) • The second time a patient record is submitted from an LDO, no matching is needed, since the patient is already uniquely matched. • It is hoped that pre-matching of patients from submitters can occur in the months before the production release – so that the first production uploads will minimize near matches.

50. CROWNWeb Batch Flow Alpha 0.3