Harris, Paul A.

Abstract Objective To describe the development and implementation of an automated platform for genomic risk prediction that integrates multiple data types. Materials and methods Using the REDCap infrastructure, we constructed the R4 (Recruitment, Results, and Risk Reduction) platform to intake data from clinical sites, partner laboratories, participant surveys, and electronic health record (EHR) data across 13 institutions. Results The R4 Portal successfully integrated data to generate genome-informed risk assessments (GIRAs) across 11 conditions for a 23 840 person cohort. Testing phases and quality control led to network-wide protocols ensuring consistency and accuracy. Discussion As the science of estimating disease risk evolves, standardized and high-throughput methods of collecting and manipulating complex data are required. Platforms should be open-source, modular, and reusable, ensuring flexibility, security, and integration across healthcare environments. Conclusion The electronic MEdical Records and GEnomics (eMERGE) network successfully generated and returned comprehensive risk profiles using logic and data specific to 11 conditions in a secure and semi-automated fashion employing a customized REDCap database.

Background: Institutions that participate in PCORnet ® transform their local electronic health record (EHR) data into the PCORnet ® Common Data Model (CDM), which is then used to generate data extracts for PCORnet ® Studies. PCORnet ® Studies can also include institutions that do not participate in PCORnet, and for these organizations, the cost of instantiating a PCORnet ® CDM can be prohibitive. Fast Health care Interoperability Resources (FHIR) provides an alternative method of obtaining EHR data. Objective: To determine whether data obtained through FHIR might be a viable study solution for those sites that do not participate in PCORnet. ® This mixed-methods project had 2 objectives: (1) survey sites participating in PCORnet on the availability of FHIR (FHIR survey); (2) compare the coverage of a FHIR-based data extract using REDCap with one from the PCORnet ® CDM across 3 sites (FHIR extract). Methods: (1) FHIR survey: A series of questions were asked about the use of FHIR in a production capacity. (2) FHIR extract: REDCap FHIR and PCORnet ® CDM extracts were created based on study variables from 2 prior PCORnet ® Studies. Data were extracted for 40 patients and concordance measures were computed between the 2 sources. Results: (1) FHIR survey: Of responding organizations, 73% (n=49) reported that FHIR was deployed in a production capacity. (2) FHIR extract: Results were highly variable. Cohen kappa ranged from 0.01 to 0.76 for certain diagnoses, 0.24 to 0.84 for laboratory results, and 0.1 to 0.87 for medications. Conclusions: Despite differences in data, certain studies may be well-suited for FHIR-based extracts.

Abstract Objective Health care generated data have become an important source for clinical and genomic research. Often, investigators create and iteratively refine phenotype algorithms to achieve high positive predictive values (PPVs) or sensitivity, thereby identifying valid cases and controls. These algorithms achieve the greatest utility when validated and shared by multiple health care systems. Materials and Methods We report the current status and impact of the Phenotype KnowledgeBase (PheKB, http://phekb.org ), an online environment supporting the workflow of building, sharing, and validating electronic phenotype algorithms. We analyze the most frequent components used in algorithms and their performance at authoring institutions and secondary implementation sites. Results As of June 2015, PheKB contained 30 finalized phenotype algorithms and 62 algorithms in development spanning a range of traits and diseases. Phenotypes have had over 3500 unique views in a 6-month period and have been reused by other institutions. International Classification of Disease codes were the most frequently used component, followed by medications and natural language processing. Among algorithms with published performance data, the median PPV was nearly identical when evaluated at the authoring institutions (n = 44; case 96.0%, control 100%) compared to implementation sites (n = 40; case 97.5%, control 100%). Discussion These results demonstrate that a broad range of algorithms to mine electronic health record data from different health systems can be developed with high PPV, and algorithms developed at one site are generally transportable to others. Conclusion By providing a central repository, PheKB enables improved development, transportability, and validity of algorithms for research-grade phenotypes using health care generated data.

AbstractBackground Electronic health records (EHRs) are increasingly used for clinical and translational research through the creation of phenotype algorithms. Currently, phenotype algorithms are most commonly represented as noncomputable descriptive documents and knowledge artifacts that detail the protocols for querying diagnoses, symptoms, procedures, medications, and/or text-driven medical concepts, and are primarily meant for human comprehension. We present desiderata for developing a computable phenotype representation model (PheRM).Methods A team of clinicians and informaticians reviewed common features for multisite phenotype algorithms published in PheKB.org and existing phenotype representation platforms. We also evaluated well-known diagnostic criteria and clinical decision-making guidelines to encompass a broader category of algorithms.Results We propose 10 desired characteristics for a flexible, computable PheRM: (1) structure clinical data into queryable forms; (2) recommend use of a common data model, but also support customization for the variability and availability of EHR data among sites; (3) support both human-readable and computable representations of phenotype algorithms; (4) implement set operations and relational algebra for modeling phenotype algorithms; (5) represent phenotype criteria with structured rules; (6) support defining temporal relations between events; (7) use standardized terminologies and ontologies, and facilitate reuse of value sets; (8) define representations for text searching and natural language processing; (9) provide interfaces for external software algorithms; and (10) maintain backward compatibility.Conclusion A computable PheRM is needed for true phenotype portability and reliability across different EHR products and healthcare systems. These desiderata are a guide to inform the establishment and evolution of EHR phenotype algorithm authoring platforms and languages.