Keywords
Research - clinical laboratories - information systems - living donation - apolipoprotein L1
Background and Significance
Background and Significance
Clinical operations and clinical research are increasingly intertwined, especially as the clinical informaticists who study and support the electronic health record's (EHR) optimization aim to make new interventions more accessible.[1] Despite shared interests in using the EHR as a resource for improving health, clinical and research stakeholders may have competing goals. Clinical informatics and information technology (IT) teams ensure optimization of the EHR for daily use at scale where thousands to millions of transactions pass through each day. Researchers have clearly defined hypotheses and study objectives, often with a limited timeline and funding to complete their work.
With growing use of genetic and genomic results in clinical practice, informaticians recognized the importance of having these results in a discrete (machine-interpretable) format to integrate genomic and other clinical data and to provide more advanced clinical decision support (CDS).[2]
[3] Studies integrating genetic and genomics in clinical practice describe both challenges and successes of placing genetic test results in the EHR. Challenges include the large size of certain results (e.g., whole genome sequencing) and the lack of (or adoption of) standards to represent the results for both transmission to and display in the EHR.[4]
[5]
[6]
[7] Successful studies have provided strategies for transmitting genomic data using the Fast Healthcare Interoperability Resources (FHIR) standard,[8] integrating genetic and genomic results in the EHR,[9] and their subsequent use to trigger CDS for genetics care delivery,[10] pharmacogenomics,[11]
[12] and clinical trial matching for molecular tumor boards.[13] Genetic test results must be integrated into the EHR in a way that enables providers and patients to access the results as they would with any other test result in their current workflows.[14]
[15] However, this integration process requires coordinated efforts from clinical, laboratory, operational, and research stakeholders.
Objectives
As part of a larger study to integrate apolipoprotein L1 (APOL1) genetic testing into clinical practice to enhance living kidney donor candidates' informed decision making about donation, we describe our experiences in designing, developing, and implementing an informatics solution for the return of APOL1 test results. Engaging a multidisciplinary team of nephrologists, genetic counselors, informaticians, clinical IT staff, and social scientists, we identified project goals to inform how test results should be integrated into the EHR and describe challenges along the way.
Methods
We convened key stakeholders[16] for the design and development of the EHR integration plan for APOL1 test results. The multidisciplinary team included three organizations: Northwestern University (NU), Northwestern Memorial HealthCare (NMHC), and Knight Diagnostic Laboratories (KDL) which is affiliated with Oregon Health & Science University. NMHC is an integrated health care system that houses the Organ Transplant Center, provides clinical care, and manages the Epic EHR (Epic Systems Corporation, Verona, WI) used across the health system. NU is the academic institution that developed the research project in collaboration with NMHC and comprised the research stakeholder for the project. Both NMHC and NU (Feinberg School of Medicine) are located in Chicago, IL. KDL partnered with NU to conduct APOL1 genetic testing for the study, as NMHC's in-house laboratory did not provide APOL1 testing.
Stakeholders included social scientist researchers, genetic counselors, nephrologists, informaticists, clinical IT, project management, and laboratory staff. The research team at NU engaged the NMHC Research & Development (R&D) team. The R&D team specialized in the intake and management of research-initiated projects that impact clinical care at NMHC, and helped researchers navigate the process of integrating research-driven projects into the EHR. The EHR integration work was coordinated by a project manager, within the R&D team, who identified the appropriate technical staff to facilitate the design and implementation, oversaw the requested EHR changes in accordance with NMHC IT policies, and ensured project timelines and deliverables were met.
All teams discussed the project objectives and high-level strategies for technical solutions during the preparation and submission of the grant application. Upon receiving notification of award for this grant-funded study, a kickoff meeting was convened a few weeks later in April 2021 to review the research aims and objectives. Subsequent ad hoc meetings were held to discuss and refine design decisions.
The study planned to receive a total of 316 APOL1 genetic results. Initial discussions concerned how the APOL1 test results would be transmitted to and stored in the NMHC EHR. One goal of the grant was to demonstrate how integrating discrete APOL1 test results into the EHR could facilitate CDS,[3] considering primarily passive CDS (such as via infobuttons[17]
[18]) to provide transplant nephrologists access to materials for use in counseling during the return of results. Although no institutional initiative was in place regarding the storage, integration, and management of genetic and genomic results, storing discrete results aligned with NMHC's goal to embed discrete laboratory results, where possible, in the EHR, instead of only uploading PDF reports. NMHC did not have Epic's Genomics Module in operation at the time of the study. Epic's Genomics Module has been used successfully by other institutions to store genetic and genomic results[19] and drive CDS.[20] NMHC has instead stored some structured genetic results (similar to the planned APOL1 test results) along with other laboratory results.[11]
Results
The teams evaluated four options for transmitting APOL1 results from KDL to NMHC. The first option entailed the transmission of a discrete laboratory result over a Health Level 7 (HL7) v2 interface, which is commonly used for the receipt of laboratory results. As KDL was also using Epic as their laboratory EHR, the second option involved the use of Epic's Care Everywhere, which would allow results to be imported into the NMHC version of Epic. Both options would have allowed for KDL (who had provided structured APOL1 results to other organizations) to transmit the number of APOL1 risk alleles as a structured result to be used for developing CDS at NMHC. The third option was for KDL to fax the APOL1 test result to NMHC. This would have required manual effort to scan and upload the fax into the EHR. The fourth option required a provider or member of the study team to access the results from KDL's secure results portal and download a PDF of the APOL1 test result. Similar to the option of faxing, this option would have required manual effort to then upload and file the result into Epic. Although uploading PDFs for genetic test results is not uncommon, it was not optimal considering one objective of the grant was to automate the process of integrating test results into the EHR.
As planning continued, a concern was raised within NMHC's compliance team about the use of Epic's Care Everywhere for research purposes. Although APOL1 testing is routinely performed for living donor candidates, the APOL1 testing was being done by a Clinical Laboratory Improvement Amendments (CLIA) laboratory, and our research study was funding all APOL1 genetic tests to better enable the transplant team to clinically evaluate candidates for living donation, NMHC's Compliance office ultimately did not consider the results as clinical results, based on input from Epic and their interpretation of Epic's policies. The key distinguishing factor was that we requested the APOL1 tests for both clinical purposes and research purposes, rather than for solely clinical purposes. Therefore, the APOL1 results from KDL had to be classified as research results instead of as clinical results. Epic's oversight group for Care Everywhere reviewed this situation and agreed with this determination. In November 2021, we received the final decision that we could not use Care Everywhere to receive test results.
Despite having identified multiple options for returning results to the EHR in a discrete format, all of the teams held focused meetings and had external evaluation time to pursue the Care Everywhere option. While we kept other options in mind throughout, due to the amount of effort each team member had allocated to this project along with the amount of time it generally takes to evaluate and architect each option, we were unable to pursue all of them in parallel. Given that substantial time had been invested in pursuing Care Everywhere, KDL had obligations with other projects (including an Epic upgrade) that precluded them from establishing an HL7 v2 interface directly with NMHC for this project. Therefore, we were only able to consider downloading results from the KDL portal or receiving a fax—meaning a PDF result only, and not a structured result. The NMHC team pursued options to automate downloading from the KDL portal; however, the portal did not support an application programming interface. We briefly considered the use of optical character recognition (OCR) software to automatically convert the PDF into discrete results, but this was cost prohibitive.
Ultimately, the teams agreed to integrate KDL faxes into an existing workflow within the Transplant division. KDL would fax results to the clinical donor team, the transplant assistant would scan and upload the result into the media tab in Epic as a PDF, and the result would be reviewed by the nurse coordinator and clinician.
Discussion
The most salient lesson learned from this project reflects the expression “Is the juice worth the squeeze?”[21] Despite having clearly articulated our objective early within the grant to integrate discrete APOL1 results into Epic, it became apparent that the volume of our research results (316 samples in total) did not justify time and effort necessary for significant custom development or expensive licenses (e.g., for automated OCR). By comparison, other studies that have built robust or custom infrastructure for integrating structured genetic or genomic results into the EHR have had thousands of results or were expressly focused on building this type of infrastructure.[10]
[11] The solution to upload scanned faxes into the media tab was disappointing for the research team, as it meant that the research stakeholders could not evaluate research questions related to CDS. However, it demonstrated a need to accept a pragmatic solution when all other options were exhausted.
The stakeholders recognized that they had invested significant time (both personnel effort and elapsed calendar months) with the hope that Care Everywhere would work as a solution. The clarification of what constitutes a “research result” is a concrete example of a barrier to integrating research results into a patient's medical record.[22] Despite this barrier having been identified over a decade ago, our experience shows that this barrier is still present, and it is important to continue sharing these findings with the broader scientific community so that researchers can avoid similar pitfalls. As noted, the determining factor in our situation was that the APOL1 test was being requested as part of both a research study and clinical care, and would not necessarily have been ordered if the research study was not covering the cost.
Our study's approach of evaluating options sequentially highlights a challenge with extramurally funded research projects. While the research and clinical stakeholders discussed options early on with the NMHC R&D team, fully specifying the architecture for integrating APOL1 test results until the grant was awarded was not feasible or practical as funds were not available to support time for investigation. Attempting to fully assess architectural options is further complicated as decisions often involve interrelated components and investigating one facet may not allow a comprehensive tradeoff analysis. In preparation for grant submission of this multisite study, we sought recommendations for the laboratory that the transplant division had been using to perform APOL1 testing and that provided the most economical price per genetic test; we established a partnership with KDL, which met both goals. The known cost was then balanced with anticipated clinical IT costs for integrating results into the EHR. In retrospect, a more in-depth engagement with the NMHC laboratory team in the planning phase (despite the fact they did not internally offer the APOL1 test) could have identified external laboratories with an existing electronic results interface to NMHC (reducing clinical IT costs on the grant), even if it were at a higher cost per APOL1 test. Without funding available, the research, clinical IT, and laboratory teams could not justify investing significant time to investigate all of the possible options. Therefore, the only time the teams could reasonably have pursued and evaluated the options was after the grant was funded, as occurred in this case.
Furthermore, with the significant amount of time spent focusing on Care Everywhere as a possible solution, “Don't put all your eggs in one basket” emerged as another lesson learned. However, the reality of our research project counteracts this. Given the constrained budget of research projects, and multiple competing demands on clinical operational teams, it was not feasible for us to pursue multiple options in parallel. Instead, we accepted the risk of our active approach failing, and maintained general ideas for alternative strategies in case we had to pivot. In the future, we need to consider the reality of a worst-case scenario occurring and ensure that the research project is able to ultimately succeed in that scenario.
Finally, we note that the challenges we encountered within this study were organizational and did not overlap with technical challenges reported in other reviews of integrating genetic results in the EHR.[4]
[5]
[6] Our project did not require significant storage or complex processing—we sought to integrate results for a single gene (APOL1) —and the number of risk alleles would have been easily represented in our EHR. Instead, our study showed how research projects intersecting with clinical care may encounter seemingly simple challenges and highlighted the importance of disseminating lessons learned in the informatics field.
Conclusion
Despite engaging all stakeholders during the development of the grant submission, dedicated project management, and multiple contingency plans, this case report highlights a research-initiated clinical integration project that did not meet its objectives. We believe by reflecting on successes and challenges, our experience grants insight for other projects bridging research and clinical practice.
Multiple-Choice Questions
Multiple-Choice Questions
-
What is the designation of a laboratory result that is ordered for a research study, even if the intent is for the laboratory result to be used for routine clinical care?
-
Investigational result
-
Research result
-
Clinical result
-
Multiclass result
Correct Answer: The correct answer is option b. As we learned in this study, even when planning to make a laboratory result available for clinical purposes, because it was ordered by a research study it is classified as a research result.
-
Which activity should projects such as ours employ in the future to avoid similar outcomes?
-
Budget review
-
Technical design
-
IRB audit
-
Risk analysis
Correct Answer: The correct answer is option d. The research project budget was already set, and technical design was done throughout the project. We noted that it was not feasible to exhaustively plan for every technical option, and so b could possibly have helped but was not feasible in a research project like ours. Although a compliance team raised the question of the use of Epic's Care Everywhere, that team was within our clinical partner, and would not have been caught by the IRB. Answer d is correct as a risk analysis would have let us better consider and actively plan for the worst-case scenarios.
Clinical Relevance Statement
Clinical Relevance Statement
Research projects increasingly intersect with clinical operations, especially when the intent is to study the impact of an intervention and its mode of delivery on clinical care. Given the limited scope of research projects, it is important to consider and plan for all failure scenarios, even in projects where active stakeholder engagement and project management are used.
