UC-Rex: A model for cross-campus collaboration and data sharing

1. UC-Rex:A model for cross-campus collaboration and data sharing UC-CSC Meeting San Francisco August 4, 2014 Doug Berman UCSF and Ayan Patel UCLA

2. Today’s discussion: • What is UC-ReX? • Who is involved and what did we do? • What technology was involved? • How we worked together: • Project structure • Sponsorship, leadership, governance, workgroups and coordination • Results and outcomes • Results • What we learned about working together

3. UC- Research Exchange (UC-ReX)Background • During the past few years UC Medical Campuses have made significant investment in Electronic Health Records • Research is a key mission at each campus • We recognize the power in working together in research • Medical campuses may share data in order to achieve a large population for our work

4. UC-ReX Goals • Five-Year Goal: Enable researchers and quality improvement specialists to query and analyze clinical data collected at the point of care at all UC medical campuses for research or quality improvement purposes under a common cross-institutional IRB approval process (Trust/Rely) and in a manner that preserves privacy.

5. UC-ReXSponsors • UC Office of the President Funding for Cross-UC Data Sharing $5 million/5 years (July 2011- 2016) • UC - BRAID Biomedical Research Acceleration, Integration & Development • Local CTSA’s (Clinical Translational Science Awards) • Campus CIO’s

6. Demonstration :UCReXData Explorer (SHRINE) https://ucrexi2b2.ucsf.edu/

7. Governance Structure Working Groups • PI from each UC CTSA • Budgetary oversight • Review quarterly status reports • 1 voting + 1 non-voting member from each UC • Simple majority • Rotating Chair http://www.ucbraid.org/informaticsmdashuc-rex.html

8. Working Groups

9. Technology Strategy • Identify use cases • Review and select technologies and partners • Sets technical direction

10. UC-ReX Use Cases Support Clinical Trials and Recruitment • Clinical studies are challenging • It is difficult to identify and recruit appropriate research subjects. • Clinical studies may take years to recruit sufficient populations to support conclusions; many fail for lack of patients Performing studies in larger populations may make many studies possible. Quality comparisons among sites to identify best practices Research Questions on Retrospective data

11. Technical Implementation • Open source software developed at Harvard • i2b2 – Informatics for Integrating Biology and the Bedside • Scalable informatics framework that enables clinical researchers to use existing clinical data for discovery research • https://www.i2b2.org/ • SHRINE - Shared Health Research Information Network • System for enabling clinical researchers to query across distributed hospital electronic medical record systems • https://open.med.harvard.edu/wiki/display/SHRINE/SHRINE++Basics • 1 Proxy Server, 2 Application Servers, 1 Database Server • Proxy Server – Apache • i2b2 Application Server – jBoss • SHRINE Application Server – Tomcat • Database Server – Oracle/SQL Server • UCSF, UCLA, UCD – Oracle • UCI, UCSD – SQL Server

12. What’s at each site • Unique ETL - Moves data to harmonized dataset • i2b2 database • Web-site for queries • Management agent • Local provisioning for access • Local support for users

13. Central Node (located at UC Davis-MC) Data remain at each UC UCReX Network Topology • The Central Management Node (CMN) is a webapp deployed to complement SHRINE – as agent or manager • Provides a central point for monitoring nodes and gathering information

14. UC-Rex Architecture

15. Data Harmonization • Develop/determine ontology to reference source data from each site • In order to query all sites, we all must speak the same language • 5 different EMR implementations (4 sites with Epic EMR – Not much help) • Clinical workflows implemented differently • Different modules at different stages of deployment • What about legacy data? • Types of Medical Data • Demographics – Local source data mapped to various standards from CDC, WHO, ISO, HL7 • Diagnoses and Procedures – ICD9 Standard Terminology used consistently across all sites for billing/finance • Lab Results • Different laboratories with different equipment • Different reference ranges and units for the same lab • Medications • Maintaining Consistent Ontology • GitHub repository set up to ensure each site has the same ontology

16. User Support • Communicate with local users • Develop websites, documentation • Provide training and support • Develop support protocols and communication among site-based support groups • Implement processes for sharing identified data (IRB approvals, data sharing agreements, request process and secure delivery of results) • Receive feedback from use community

17. Data Quality • Discovery data anomalies by querying the i2b2 databases • Look at trends of counts of data types by year from each site • View distribution of demographics • One site had a unreasonably high percentage of a certain race, upon investigation it was discovered that that race was used as a default value • Lab Results • Look at medians and means for each lab type • Discovered some lab units were not converted to the appropriate unit agreed upon in Data Harmonization • Continue to slice and dice data and look at it from different perspectives • Investigate potential issues - feedback discoveries to Technical Implementation and Data Harmonization

18. Lessons learned • Balance Project Goals • Research project versus IT project to support research • Focus on delivery • Expect institutional differences • Infrastructure, organization, approval and change processes will differ at each institution • Time lines needed to adapt to diversity among institutions

19. Lessons learned (continued) • Project management was key • Program management - central coordination and decision making • Site level – planning resources and deliverables • Virtual work – Conference calls and screen shares are effective • Team members from each site work together directly • ‘Perfect is the enemy of good’

20. UCReX –Team

21. Questions