Pilot Implementation of Clinical Genomic Data into the Native Electronic Health Record: Challenges of Scalability

Abstract Background Recently, electronic health record (EHR) vendors have allowed for the storage of discrete genomic data within the EHR. With this new capability there remain many challenges related to adoption and implementation. Geisinger has genomic data available for approximately 145,000 patients. With the goal of integrating genetic data into the EHR for the entire sequenced population, we performed a pilot study on a subpopulation to assess the plausibility of large-scale deployment. Objectives Import genetic results into the EHR for seven pharmacogenes, Center for Disease Control tier one conditions, and hereditary hemochromatosis. Build decision support and information resources for each condition. Identify barriers to scaling the deployment. Identify short-term and long-term solutions to overcome identified barriers. Methods Discrete genomic variants were imported into the EHR. Maintenance guidelines and information resources were developed for each genetic condition and best practice alerts were built for pharmacogenomic variants. Weekly calls were held to address barriers to implementation. A list of challenges was maintained throughout the process. Solutions were proposed and categorized into short-term and long-term solutions. Results Challenges were identified and solutions proposed for five discrete areas: Transmitting data from the laboratory to the EHR. Maintenance of information and decision support. Disparate implementation needs of geneticists versus primary care. Differing perceptions/uses of discrete genomic data versus a PDF report. Classification and reclassification of variants. Conclusion Scaling the use of genomic data in the EHR requires the engagement of hospitals, open standards communities, laboratories, EHR vendors, and genomic information resources.


Background and Significance
The integration of genetic information into health care is considered a major priority with several national and international initiatives that have been launched to pursue this goal. 1 Despite this, only recently have electronic health record (EHR) vendors allowed for the storage and access of discrete genomic data within the EHR ecosystem. Even with this new capability, there remain many challenges related to adoption and implementation of such technologies. As part of the Electronic Medical Records and Genomics (eMERGE) network 2 and through our MyCode ® Community Health Initiative, 3 Geisinger has exome sequencing data available for more than 145,000 patients. With the goal of integrating genetic data into the EHR for our entire sequenced population, we first performed a pilot study on 1,317 patients from the eMERGE patient cohort to assess the plausibility of scaling the deployment to more genes and a larger sequenced population.

Import genetic results into the EHR for Center for Disease
Control (CDC) tier one conditions, hereditary hemochromatosis, and 7 pharmacogenes for 1,317 patients. 2. Build clinical decision support (CDS) and both patient and provider facing information for the imported genetic results. 3. Identify barriers to scaling the deployment to more genes and the larger sequenced population of 145,000 patients. 4. Identify short-term and long-term solutions to overcome identified barriers.

Methods
We presented a plan to Information Technology Governance (ITG) to import discrete pathogenic and likely pathogenic genomic variants for the CDC tier one conditions (hereditary breast and ovarian cancer syndrome (BRCA1, BRCA2), Lynch syndrome (MLH1, MSH2, MSH6, PMS2, EPCAM), and familial hypercholesterolemia (APOB, LDLR, PCSK9), and variants from seven pharmacogenes (CYP2C19, SLCO1B1, DYPD, TPMT, IFNL3, CYP2C9, and VKORC1). Variants for hereditary hemochromatosis (HFE) were included to assess for challenges related to the implementation of autosomal recessive conditions. We constructed context-sensitive maintenance guidelines in the EHR for each of the disease conditions and built best practice alerts for medications impacted by the pharmacogenomic variants. Patient and provider facing information were developed for all genetic conditions to be accessible through both the physician chart and the patient portal. Through the implementation process, weekly calls were held with pertinent stakeholders to address challenges and barriers to implementation as they arose. A list of these challenges was maintained throughout the process. After implementation, we analyzed the challenges and potential solutions to scaling our implementation to more genes and our entire sequenced population.
Solutions were categorized into short-term and long-term solutions.

Results
We were able to successfully implement all conditions for 1,317 patients with minimal compromises. Support from organizational leadership was critical to securing technical resources to achieve implementation and prioritization in the queue of many EHR implementation projects. The proposal was passed through ITG after a thorough review of the need and potential impact on patient care and was based on the contingency that there would be dedicated resources from the Genomics Institute to maintain and support CDS and information resources pertaining to genomics. Due to the inability of our laboratory information system (LIS) to store or transmit genomic data in a structured format, our research team wrote custom Python scripts to convert structured laboratory data into Health Level Seven (HL7) OBX segments for import into the EHR. The resulting messages were reviewed and passed through several methods of validation by the EHR technical team.
As there was no single external resource that provided adequate patient or provider facing information, this content was developed by internal domain experts and formatted in an Excel spreadsheet for use by the EHR technical team to deploy in the EHR. Provider facing information contained more detailed management information, whereas patient facing information was more succinct and provided contact information for providers and links to outside patient-centered resources. Health maintenance guidelines were developed by domain experts and deployed in the EHR by the technical team to alert providers to needed studies at appropriate intervals (i.e., breast magnetic resonance imaging, colonoscopy, etc.). A pharmacist worked directly with the EHR technical team to develop active CDS for the seven pharmacogenes. Where applicable, the pharmacogenomic CDS would present an option to order an alternate medication.
Our initial plan was to develop slight variations in interfaces and workflows for primary care providers (PCPs) compared with clinical geneticists (CG). After reviewing workflows and needs of both groups, we decided to abandon the CG interface and workflow for this deployment as the needs were very disparate and pursuit of both workflows would hamper our ability to complete the implementation in the given time frame and within the allotted budget.
The EHR vendor offered an automated process to classify variants through ClinVar that was determined to be insufficient. All variants were assessed and independently validated by both an external Clinical Laboratory Improvement Amendments laboratory and an internal variant scientist prior to import into the EHR.
Several challenges were encountered that are anticipated to affect our ability to scale the process. We encountered some vendor-specific informatics challenges, including the inability to store discrete variants for pharmacogenomics (the native functionality stores the star allele diplotypes) and having inadequate infrastructure for autosomal recessive ACI Open Vol. 4 No. 2/2020 conditions where the patient is a compound heterozygote. Although these were vendor-specific issues, the vendor's data implementation was based on the HL7 V2.5 Clinical Genomics Report standard, which had deficiencies that contributed to these problems. A list of global challenges and solutions is outlined in ►Table 1.

Discussion
We were able to capture discrete genomic data from our primary genetic testing laboratory; however, neither the current FHIR molecular sequence resource nor the HL7 V2.5 Genomic report standard was adequate for reporting as neither encapsulated all the information in the genetic test report. Because of this our primary genetic testing laboratory used its own proprietary JSON structured format. The passage of data into the EHR became a significant bottleneck in our process with the EHR interface team responding that this process could delay the implementation by several months. Having a research team that was well versed in both informatics and genetics, we were able to rapidly build a translator for an existing interface that converted structured laboratory data into HL7 messages. This effort required a significant amount of coordination and trust between our research team and the EHR technical team and underwent thorough validation prior to implementation. Even with the ability to pass discrete genetic data, our efforts in this area were hampered by lack of standardized genetic phenotypes. We developed the ability to pass the genetic phenotypes included in the pilot study for a single laboratory. To scale this to include any result returned on exome, we would have to specifically define and build out any additional phenotypes that might be discovered on exome sequencing. We would then have to map these phenotypes to each sequencing laboratory used. We opted in the short term to only allow the passage of secondary findings from exome where we had genetic phenotypes built out and limit our process to two laboratories. The initial role of our LIS was unclear, since laboratory data currently enters the EHR from the LIS, and our LIS did not have the ability to store discrete genomic variants. We opted to keep the existing pathway for ordering and reporting genomic testing through the LIS intact and build an additional messaging pathway that bypassed the LIS and delivered data directly to the EHR.
Long-term maintenance of gene/variant-specific information and CDS is a major challenge in a rapidly changing field. Changes to patient/provider facing information and CDS require support from vendor-specific technical personnel. Engaging this technical team can be challenging, given their responsibility to maintain all aspects of the EHR for the entire health care system. These personnel have little to no experience in genomics, requiring communication between the clinical and technical teams to make any changes to the system. EHR vendors adhering to more open standards for genomics and CDS, including SMART on FHIR and CDS Hooks, would allow for the development of interfaces to external applications where maintenance can be performed by staff with genetics training and less technical skill. This is particularly important while we are still largely in the discovery phase of genomics, where many of the applications of genomic data are still being developed and may be governed and deployed in substantially different ways among institutions. Without nontechnical interfaces, it was critical that we had strong support from leadership to be able to maintain priority in the technical team's queue of projects. Another important component to this is the need for maintained resources such as ClinGen and PharmGKB that are Infobutton accessible and can allow for rapid access to the most current information on a specific gene or variant. To our knowledge, no vendor has implemented Infobutton support for genomics, and outside of pharmacogenomics, no such Infobutton compliant resources exist.
Early in the process, the clinical genomics team was brought on board to review workflows. It was clear in the first stages of deployment that the needs of CGs compared with PCPs were markedly different. Due to the complexity of implementation of CG workflows and the relative impact on care versus population genomics, we opted to focus on population genomics workflows and delay implementation for CGs. It remained critical to continue to engage the clinical genetics team in the population genomics deployment.
Although discrete genetic data fields and PDF reports contain identical information, genetic data as it exists in a PDF seemed to have a perceived protective effect where the data remained more in the domain of specialists, whereas adding a variant discretely to the patient summary subjected it to more visibility and potential action by providers with less experience. This contributed to a fear of providing uncertain information or providing information without clear guidelines and decision support within the EHR to support the actions that should be taken on the variant. In addition, the structured information can trigger CDS, which should not be triggered in cases where the classification is not certain.
We opted to bypass automated processes to classify variants and manually reviewed each variant laboratory classification prior to allowing import to the EHR. This process does not scale well; however, we felt that challenges in variant classification warranted extra caution. Reclassification of variants based on clinician reinterpretation presented several challenges. Vendor-specific challenges included the inability to reclassify at the variant level, requiring the updating of each patient with the same variant separately. Although variant reclassification was allowed and tracked appropriately in the EHR, this presented the possibility of having structured genomic data that was discordant with the scanned PDF. This demonstrates the need for bidirectional communication between the clinician and the laboratory when variants are reclassified, particularly if both parties submit their classification to ClinVar. While the need was expressed to automatically reclassify all patients with a given variant once reclassification was warranted, there was no clear process to manage this at scale.

Clinical Relevance Statement
Integration of genomic data into the EHR allows for improved health through targeted clinical management using genetic sequences. Achievement of this has been a recent target of the scientific community.