Starren, Justin

Abstract Background Computational phenotyping from electronic health records (EHRs) is essential for clinical research, decision support, and quality/population health assessment, but the proliferation of algorithms for the same conditions makes it difficult to identify which algorithm is most appropriate for reuse. Objective To develop a framework for assessing phenotyping algorithm fitness for purpose and reuse. Fitness for Purpose Phenotyping algorithms are fit for purpose when they identify the intended population with performance characteristics appropriate for the intended application. Fitness for Reuse Phenotyping algorithms are fit for reuse when the algorithm is implementable and generalizable—that is, it identifies the same intended population with similar performance characteristics when applied to a new setting. Conclusions The PhenoFit framework provides a structured approach to evaluate and adapt phenotyping algorithms for new contexts increasing efficiency and consistency of identifying patient populations from EHRs.

AbstractObjectiveThe aim of this study was to analyze a publicly available sample of rule-based phenotype definitions to characterize and evaluate the variability of logical constructs used.Materials and MethodsA sample of 33 preexisting phenotype definitions used in research that are represented using Fast Healthcare Interoperability Resources and Clinical Quality Language (CQL) was analyzed using automated analysis of the computable representation of the CQL libraries.ResultsMost of the phenotype definitions include narrative descriptions and flowcharts, while few provide pseudocode or executable artifacts. Most use 4 or fewer medical terminologies. The number of codes used ranges from 5 to 6865, and value sets from 1 to 19. We found that the most common expressions used were literal, data, and logical expressions. Aggregate and arithmetic expressions are the least common. Expression depth ranges from 4 to 27.DiscussionDespite the range of conditions, we found that all of the phenotype definitions consisted of logical criteria, representing both clinical and operational logic, and tabular data, consisting of codes from standard terminologies and keywords for natural language processing. The total number and variety of expressions are low, which may be to simplify implementation, or authors may limit complexity due to data availability constraints.ConclusionsThe phenotype definitions analyzed show significant variation in specific logical, arithmetic, and other operators but are all composed of the same high-level components, namely tabular data and logical expressions. A standard representation for phenotype definitions should support these formats and be modular to support localization and shared logic.

Abstract Objectives The study aimed to understand potential barriers to the adoption of health information technology projects that are released as free and open source software (FOSS). Methods We conducted a survey of research consortia participants engaged in genomic medicine implementation to assess perceived institutional barriers to the adoption of three systems: ClinGen electronic health record (EHR) Toolkit, DocUBuild, and MyResults.org. The survey included eight barriers from the Consolidated Framework for Implementation Research (CFIR), with additional barriers identified from a qualitative analysis of open-ended responses. Results We analyzed responses from 24 research consortia participants from 18 institutions. In total, 14 categories of perceived barriers were evaluated, which were consistent with other observed barriers to FOSS adoption. The most frequent perceived barriers included lack of adaptability of the system, lack of institutional priority to implement, lack of trialability, lack of advantage of alternative systems, and complexity. Conclusion In addition to understanding potential barriers, we recommend some strategies to address them (where possible), including considerations for genomic medicine. Overall, FOSS developers need to ensure systems are easy to trial and implement and need to clearly articulate benefits of their systems, especially when alternatives exist. Institutional champions will remain a critical component to prioritizing genomic medicine projects.

Abstract To better understand the real-world effects of pharmacogenomic (PGx) alerts, this study aimed to characterize alert design within the eMERGE Network, and to establish a method for sharing PGx alert response data for aggregate analysis. Seven eMERGE sites submitted design details and established an alert logging data dictionary. Six sites participated in a pilot study, sharing alert response data from their electronic health record systems. PGx alert design varied, with some consensus around the use of active, post-test alerts to convey Clinical Pharmacogenetics Implementation Consortium recommendations. Sites successfully shared response data, with wide variation in acceptance and follow rates. Results reflect the lack of standardization in PGx alert design. Standards and/or larger studies will be necessary to fully understand PGx impact. This study demonstrated a method for sharing PGx alert response data and established that variation in system design is a significant barrier for multi-site analyses.

Abstract Objective Clinicians’ ability to use and interpret genetic information depends upon how those data are displayed in electronic health records (EHRs). There is a critical need to develop systems to effectively display genetic information in EHRs and augment clinical decision support (CDS). Materials and Methods The National Institutes of Health (NIH)-sponsored Clinical Sequencing Exploratory Research and Electronic Medical Records & Genomics EHR Working Groups conducted a multiphase, iterative process involving working group discussions and 2 surveys in order to determine how genetic and genomic information are currently displayed in EHRs, envision optimal uses for different types of genetic or genomic information, and prioritize areas for EHR improvement. Results There is substantial heterogeneity in how genetic information enters and is documented in EHR systems. Most institutions indicated that genetic information was displayed in multiple locations in their EHRs. Among surveyed institutions, genetic information enters the EHR through multiple laboratory sources and through clinician notes. For laboratory-based data, the source laboratory was the main determinant of the location of genetic information in the EHR. The highest priority recommendation was to address the need to implement CDS mechanisms and content for decision support for medically actionable genetic information. Conclusion Heterogeneity of genetic information flow and importance of source laboratory, rather than clinical content, as a determinant of information representation are major barriers to using genetic information optimally in patient care. Greater effort to develop interoperable systems to receive and consistently display genetic and/or genomic information and alert clinicians to genomic-dependent improvements to clinical care is recommended.