1. Apex/Epic and Research Academic Senate Clinical Affairs Committee October 26, 2011 Seth Bokser

2. Major Areas Where APeX Will Support Research  Ensure continued support for functions supported by existing departmental systems  Facilitate the use of clinical data in research (i.e. retrospective data in the IDR)  Support clinical research –Compliance –Billing –Enrollment –Clinical Data Capture 2

3. Departmental Systems 3

4. Support for Existing Systems 4  Survey conducted this summer and fall of 2010 –197 Systems were identified 11 duplicates removed, 13 added  198 systems remain. 53% systems,47% databases 45% patient care, 53% operations, 53% research (most have multiple uses)  Prioritized for review –Criteria were implementation date, system function and sensitivity

5. Classification of Systems for APeX Implementation 5  Our goal is to ensure continuity in the functionality  Five categories: –Replaced by Epic –Possible scope in optimization phase –Independent system –Data and interface conversions - Planned/Underway –Data and interface conversions - Required

6. Systems Review Results 6

7. Replace by Epic 7 Epic features can replace system’s functions at go-live. Description Implementation teams to be alerted to this work. Implement replacement of function as part of go-live. Plan OB/GYN Access Databases – Used by operations, to report births to state agencies, and for research. Can be replaced by worklists, Clarity reports and IDR. AccessANYware – Remote access for Coders. Function to be replaced with Epic Features. ED Filemaker system – Replaced by Epic ASAP. Examples

8. Possible Scope in Optimization Phase 8 Epic features can replace this system’s functions, but work is impractical at this time due to limited data, timing or scope of implementation. System should be reviewed after the initial implementation. Description Implement without changing system. Keep a list for review after implementation. Plan EEG Reader in Epilepsy/Clinical Neurophysiology - EEG Study data. System is currently independent; No IDX or UCare interfaces; Would like integration for viewing and demographics. Pediatric Nephrology Database – Screens patients for research recruitment. Consider migration when sufficient data is in Epic. Examples

9. Independent Systems 9 The system is not impacted by APeX implementation. Typically these systems are not linked to clinical data; serve a non-clinical function or where Epic features are not planned for implementation. Description No APeX action needed. Coordinate system with School of Medicine as appropriate. Plan QuesGen – collects and stores data about volunteers for pharmaco-genomic studies Airway tissue Bank – Tracks samples for research study. CAPSURE.NET Web-site with public information on Prostate Cancer Canfield Scientific – In Plastic Surgery used as an imaging tool. Examples

10. Data and Interface Conversions - Planned or Underway 10 An interface or download of Epic Data is needed to replace an existing download or interface. This work is underway or planned. Description Implementation of replacement interface is underway. Continue on plan. Plan Apollo-related systems in cardiology including Tumor Registry ADT feed OmniView Download IDXRAD – Radiologic Systems interfaces Examples

11. Data and Interface Conversions - Required 11 An interface or download of Epic Data is needed to replace an existing download or interface. This work is not underway or planned. Description Assess need for data, ensure a plan is in place to support data need. Plan Dynamic Clinical System – Used in Urology/Oncology as a pre-appointment screening tool. Currently gets download from IDX. Urology/Oncology Database (Prostate) – Master Research Database. Need to replace monthly download from STOR. Examples

12. Clinical Research Support 12

13. APeX features at Enterprise go-live (6-2012) 13  UCSF will use APeX (Epic) to: –Identify studies –Identify patients who are participating in the studies –Identify which encounters have content for the studies –Place orders for care related to studies –Appropriately bill responsible entities (i.e. Personal Family account or Research account) for the orders. –Support chart review by clinical monitors –Identify research patients and include or exclude them from medical center reports, metrics and statistics as appropriate  Research features go-live at Enterprise Roll-out –Interim workflow keeps research orders and billing on paper. (through June 2012)

14. Future directions for Clinical Study Support with APeX  Implement Epic function to indicate when a patient may qualify for a particular study (Welcome; MyChart; APeX)  Integration with : –Clinical Trials Management Systems (e.g. OnCore) We are working with Epic, Forte, U Wisconsin, Yale and U Virginia on HIE Standards- based approach to interfacing clinical trials activities. –Research Participant Management System (being scoped and planned in SOM) –Clinical trials development process (iMedris, Medicare Charge Analysis) 14

15. APeX/Epic Staff Activities 15  Appropriate Research Staff will: –Set up clinical studies with assistance of Apex Team including: Identify allowed procedures (including tests and treatments) for a study Determine how study-related orders are entered Identify billable entity at time of order –Enroll Patients –Identify or confirm that each order is research-related at time of order entry –Attend training and adhere to policies and procedures that support research workflows in Apex.

16. IDR Overview

17. Integrated Data Repository  School of Medicine based  Repository for researchers which integrates data from many source systems  De-identified data is readily available to appropriate personnel  Goal to create research environment that is: –Accurate, Accessible, Easy to use, Secure  Target inclusion of initial APeX data November 2011.

18. ReplicaSource Systems IDR & My Research – Big Picture Audit DB / IDR Data Warehouse End User Tools Cognos BI Data WarehousingBusiness Intelligence Cohort Selection Tool (i2b2), SAS, STATA, SPSS, Alias.ti, Enterprise Architect MyResearch Portal UCare PICIS Cancer Registry MisysIDXrad Apollo Worx CTMS STOR MAR Flowcast TSI CoPath Kaiser VA ED Epic Extract, Transfer Proxy process and Load Axium SiemensRadiology Transplant Terminal Servers SGD Web top Alfresco REDCap Epic LPPI EMR UCare Will be replaced by Epic Will have interfaces to bring data into Epic SFGH PICIS Cancer Registry CTMS? TSI Kaiser VA Axium Transplant? LPPI EMR SFGH Security Red = Currently Integrated

19. Shadow Server Clarity (Microsoft SQL Server) IDR (HIPAA Limited Data Set*) Epic Production Server (Chronicles Caché) MyResearch (Data Marts / Ontologies) Operational and financial reports Government-mandated reporting Research Patient care Staging Server (Microsoft SQL Server) Medical Center Network (Requires CHR Approval for Access) MyResearch Network (No CHR Approval Required) * “HIPAA Limited Data Set” = No PHI Except Dates of Service APeX-IDR Information Flow

20. Operational, financial and government mandated reporting out of Epic’s Operational Data Store ‘Clarity’ HIPAA Limited Data Set (LDS), i.e. no PHI except dates of service, brought over to IDR for Cohort Selection Any PHI data extract for research purposes: Requires CHR approval Comes from Med Center, not IDR Done via separate secure interfaces 20 IDR and Clarity Environments

21. 21  Use existing MOU with Medical Center for data use  APeX data available in i2b2 to trained and certified users  Use existing IDR data security and governance  Key data views or marts mapped –Demographics –Encounter –Disposition/Discharge –Diagnosis –Medications  Incremental improvements to existing documentation / training / support Phase 1 Revised Scope and Deliverables

22. Questions / Discussion 22