October 29, 2012 APHA Conference 2012 San Francisco, CA

1. Lessons learned in developing a national registry for community-led Patient Centered Outcomes Research October 29, 2012 APHA Conference 2012 San Francisco, CA Reesa Laws, BS, Thu Quach, PhD, Rosy Chang Weir, PhD, Erin Kaleba, MPH, Chris Grasso, MPH, Stephan Van Rompaey, PhD, Jon Puro, MPH-HA, Joe Carroll, MD, Suzanne Gillespie, MS

2. Background • The Community Health Applied Research Network (CHARN) is a federally funded research network comprised of 18 community health centers (CHCs) organized into four research nodes (each including an academic partner), and a data coordinating center (DCC). • Goal of establishing a community-led network for patient-centered outcomes research (PCOR). • One key initiative is to develop a robust central CHARN Data Registry.

3. Community Health Centers • CHC’s were created to provide health and social services access points in poor and medically underserved communities and to promote community empowerment. • They are considered the “safety net” for many of the underserved population. • 7000 CHCs nationwide in all 50 U.S. states and territories, serving approximately 20 million.

5. The CHARN registry population • V1 of the registry was defined as all patients who had at least one primary care encounter that occurred on or after January 1, 2008 and prior to December 31, 2010. • Detailed data was shared for those patients that had at least one diagnosis, medication or laboratory test from one of the seven CHARN diseases of interest, which will be discussed in a later slide. • Number of patients across the CHARN nodes: • AAPCHO: 89,889 • Alliance: 280,171 • Fenway: 4,907 (only HIV patients were included) • OCHIN: 156,848

6. CHARN Data Registry UpdateV1 Patient Characteristics tables

7. CHARN Data Registry UpdateV1 Patient Characteristics tables Age Gender

8. CHARN Data Registry Update V1 Patient Characteristics tables Race

9. Objective • To establish a centralized data registry extracted from electronic health record (EHR) data systems at CHCs to: • Better describe our vulnerable, diverse safety-net populations traditionally underrepresented in research, and • Establish a multi-site, multidisciplinary collaborative infrastructure to advance PCOR. • Address scientific questions that can be easily answered by a large-scale combined community health center registry.

10. Methods • As a key initial step, we developed multi-level Data Use Agreements (DUA) between all participating CHCs and their representative node, and between the nodes and the data coordinating center (DCC). • Simultaneously, a multidisciplinary team of community clinicians, researchers, and data programmers defined data elements needed to support future PCOR.

11. Data Use Agreements • The multi-step DUA process added complexities and time to the development and approval process, however, this process was crucial for building trust in using individual CHC’s data at a national level. • Different strategies were reviewed for streamlining the DUA approval proces.s • Individual CHC’s with the DCC: It was too laborious and time intensive. • Creation of a node specific or CHARN specific IRB: Most CHC’s wanted to maintain their data sharing authority at their individual organizations. However, one node has a central IRB established and at least one other node is moving towards a central IRB process for their node.

12. Registry Design • The CHARN Steering Committee (SC), which is the leadership body of the Network, defined the high level goal for the CHARN Registry. The focus for version 1 (V1) of the registry was to compile data on seven specific disease cohorts: • Diabetes • HIV • Hepatitis B and Hepatitis C • Cardiovascular Disease • Hypertension • Dyslipidemia

13. Registry Design • The Data Sharing and Registry Subcommittee (DSRS) was tasked with the development of a data schema for the organization and extraction of the CHC level data for the construction of the CHARN registry. • A standardized data dictionary (DD) was created to define requested data elements. • A data submissions process was developed to specify procedures for compiling, querying and transmitting the data. • Microsoft SQL Server was chosen as the database to store data at the CHC, node and DCC as it’s a commonly used and robust tool.

14. Registry Design • Limited data sets were created with patient identifiers removed, as defined by the HIPAA privacy rules. Dates of service are included in the registry. • As a result, we are not able to de-duplicate patients across nodes; however, we rely on the nodes to de-duplicate the patients within their individual nodes. • Metadata will be captured on the procedures used at the node for this process.

16. Registry Implementation • The DCC created node-specific SQL script that the nodes used to create empty registry tables. • Data from the individual CHC’s could then be loaded into the node level registry. • Standardized data queries were then run at the node level before transferring the data to the DCC.

17. Registry Implementation • Two levels of data queries were run at the node level to ensure data integrity. Level one included: • Confirming that all data conformed to the defined SQL server field data types. • All records loaded into the tables conformed to the primary key constraints. • Level 1 checks had to be passed in order to load the data into the tables.

18. Registry Implementation • Level two checks consisted of the following: • Data format (field level data conformity) • Required fields (no missing data in required fields) • Foreign key (data values exist in other tables where an explicit relationship exists) • Valid code (values confirm to a list of pre-defined codes) • Valid range (values confirm to a pre-defined range) • Orphan records (every record in a “non-patient” table links to a record in the “patient” table) • After completion of any needed data cleaning at the nodes, the data were uploaded to a secure website at the DCC for aggregation across the nodes and additional data queries.

19. Data Complexities • Lack of a standardized data classification system for labs and medications. • Missing data. • Current workgroups were limited to the seven disease cohorts due to the decision to create a registry vs. pulling all data to create a warehouse (e.g., untreated hypertension was an area of interest that could not be ascertained with the current version). • Not all CHC’s had an EHR system in place. • Linking encounters (visits) to medication orders and lab orders. • Multiple data sources at the CHC level made it time intensive to compile all required data.

20. Results • Nodes have executed DUA’s with their CHC’s and with the DCC. • Each participating CHC has approved this project through its institutional review board (and local research committee when required). • Data for version 1 have been submitted by all nodes to the DCC, and subsequently aggregate reports are being returned to the nodes for QA and to inform research study proposals. • V2 of the registry is being developed to capture all patient data across more years (a data warehouse). • Study of diabetes using version 1 registry data is currently underway. Other version 1 studies are pending.

21. Conclusions • It is feasible to create a centralized data registry among multiple CHC partners, with different types of EHRs, and varying levels of experience and research topics. • For this type of unprecedented research endeavor, it is essential to allow for significant time for: • approval processes • discussions which ultimately foster collaboration and trust among new partners • addressing technical issues in an era of suboptimal data standardization