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.
