Pharmacogenomic Clinical Decision Support: A Review, How-to Guide, and Future Vision.

Clinical decision support (CDS) is an essential part of any pharmacogenomics (PGx) implementation. Increasingly, institutions have implemented CDS tools in the clinical setting to bring PGx data into patient care, and several have published their experiences with these implementations. However, barriers remain that limit the ability of some programs to create CDS tools to fit their PGx needs. Therefore, the purpose of this review is to summarize the types, functions, and limitations of PGx CDS currently in practice. Then, we provide an approachable step-by-step how-to guide with a case example to help implementers bring PGx to the front lines of care regardless of their setting. Particular focus is paid to the five "rights" of CDS as a core around designing PGx CDS tools. Finally, we conclude with a discussion of opportunities and areas of growth for PGx CDS.

Over the last 10 years, the number of institutions implementing pharmacogenomics (PGx) has dramatically increased. The change has been driven by an increase in the number of clinical guidelines for the use of genetic information to guide medication management, a reduction in testing costs, and a shift toward precision medicine. , However, it is challenging to use genomic data in clinical practice. These barriers and challenges have previously been well‐described. , , One of the most commonly cited barriers is gaps in knowledge related to PGx. A survey of more than 10,000 physicians indicated that while nearly 98% agreed that genetic variations might influence drug response, only 10% felt adequately informed about PGx testing. Even though 10 years have passed since that survey, a study in a community health system found that ~ 75% of participants were not confident in their ability to use PGx results in prescribing decisions. , Concerns with understanding PGx test reports and a desire for content clarification contribute to this lack of confidence. Clinicians often report the translation of PGx results to a prescribing decision in clinical practice to be a significant challenge.

Of note, there have been several terms utilized to describe the study and application of genetic information to medication guidance. Examples include drug gene pair, drug gene interaction, pharmacogenomic / pharmacogenetic association, and pharmacogenomic biomarkers. The connotative differences between these terms are beyond the scope of this article and they will be used interchangeably throughout.

Clinical decision support (CDS) tools are well‐suited to address these knowledge gaps across the care continuum. CDS tools refer to healthcare information presented through technology tools to relevant stakeholders (e.g., pharmacists, physicians, nurses, and patients) during the clinical workflow. A significant challenge affecting CDS is user engagement. For example, it has been reported that drug‐drug interaction alerts can be overridden or ignored at a rate exceeding 90%. Additionally, CDS tools and systems can be costly to build and maintain. Therefore, it is crucial to evaluate the fit between CDS tools and the clinical environment in which they are used, remove unnecessary tools, and minimize barriers that prevent the use of necessary CDS tools. It is important to note that these challenges are not limited to PGx CDS but apply to all CDS.

Clinical PGx programs use various CDS tools and frequently cite CDS tools as necessary for successful implementation. , , , , , , , , , , Multiple articles have been published describing key features, principles, and resources for PGx CDS. In this article, we review different types of CDS, the five rights of CDS, publicly available PGx CDS resources, and the steps needed for PGx CDS implementation. Additionally, we provide case examples to highlight important features and considerations in the design and deployment of CDS. Finally, we discuss a future vision of PGx CDS.

TYPES OF CDS TOOLS

Growth in electronic healthcare integration and data availability has led to an expanding pool of CDS solutions. The fundamental objective of CDS tools is to present and confer clinically relevant information to prevent errors and improve health. CDS tools come in various formats, use a variety of methods, and have a wide range of content. These tools can be described as passive or active. An active tool is typically rules‐based and requires the system to be the active agent. In contrast, passive CDS tools provide information or further interpretation, but only for users who choose to access them. In other words, the user is the active agent, and the system is passive. When combined, multiple CDS tools can successfully support the clinician‐patient relationship ( Figure  ). Understanding the differences between these products is vital in ensuring that the tools implemented provide the necessary aid for therapeutic decisions.

Figure 1

Types of CDS tools supporting the clinician‐patient relationship. CDS, clinical decision support; EHR, electronic health record; PGx, pharmacogenomics.

Interruptive alerts are the most common type of CDS used in health care and a standard example of active CDS. The pop‐up or interruptive alert typically involves an alert appearing when specific parameters are met, such as a medication order in the presence of certain test results. , The benefits of such measures are that they can act as safety nets by highlighting potential problems for the user. However, active alerts that are not integrated within user workflows force clinicians to deviate from their typical therapeutic decision process. This interruption may lead to skipping critical steps and potentially increase the risk for errors. Poorly designed active alerts contribute to alert fatigue. Alert‐based CDS tools are widely utilized to guard against serious safety events, such as potential allergic interactions, electrolyte imbalances, or severe drug‐drug interactions. , In the context of PGx, interruptive alerts are often used to communicate recommendations based on a PGx result. Less common active tools involved in the medication ordering process are dynamic order sets, which adjust the viewable orders based on patient‐specific features.

Other active CDS tools are designed to streamline documentation processes. Examples include automatically populating clinical notes with relevant information (e.g., the patient’s genetic results) or constructing auto text shortcuts for result interpretation or therapeutic recommendations, common genetic considerations, and appropriate therapeutic options. These tools reduce documentation time, may improve consistency of care, and potentially limit transcribing errors when transferring laboratory results to a clinical note.

Somewhat removed from typical workflows, we can find CDS tools, such as chatbots or technological conversation agents. , These are automated systems that patients or clinicians may engage with through a “conversation.” Through these conversations, the tool can gather data and be utilized as a screening system or provide educational content to the user.

Common examples of passive CDS include tools containing summative genetic reports or portals where patients or clinicians review available genetic results. Portals or other web‐based systems may have varying degrees of integration into the electronic health record (EHR) and can even be completely separate. Other passive CDS examples include banners or information within the EHR depicting that a patient has received genetic testing (e.g., listed in the problem list or allergy list). Additionally, automated PGx consults have been created to be available for prescribers to view at their discretion. Manual pharmacist consultations are increasingly used to facilitate the use of PGx in prescribing decisions but do not meet the aforementioned definition of CDS used here. , , Passive CDS can also include linked references or explanatory text attached to genetic results. More sophisticated examples of passive CDS include tools that provide therapeutic suggestions or visualize genetic results in line with the provider’s typical workflow, such as in the medication order composer.

One classification of CDS for genetic testing relates to the timing of the tool’s activation in relation to the genetic testing process. Pre‐test CDS occurs before the relevant genetic test and often serves to identify patients in whom a genetic test should be considered. Post‐test CDS tools are those that occur after and often act upon results of genetic testing. Reports and portals summarizing the test results are obvious examples of CDS that happens after the results are available. Post‐test CDS also includes note writing or documentation assistance and post‐test interruptive alerts.

It is important to note that one type of tool may be implemented in either of these styles. For example, interruptive alerts are often utilized as post‐test alerts. These are set to trigger and provide guidance when a specific medication is ordered if a patient has a particular genetic result. However, interruptive alerts are also utilized to provide pre‐test guidance. In this case, the alert would trigger and provide guidance when the medication is ordered, but no genetic results are available. Similarly, documentation tools could provide automatically generated verbiage to consider such a test if no results are found or to provide verbiage on a recommendation if a result is available. Multiple types of CDS tools need to be utilized by a given health system to create a productive ecosystem of support for the integration of PGx data into clinical care.

FIVE “RIGHTS” OF CDS

Given the numerous types of CDS used in PGx implementation, picking the right tools for the job is paramount. The five “rights” of CDS can help ensure the correct mixes of tools are used. The five rights ensure the right information is presented to the right person through the right intervention format and right channel at the right time in the workflow. In addition, these pieces ensure that therapeutic decisions are made in a timely manner and based upon the most appropriate reading of current data. If any one piece is out of alignment, then wastage and inefficiencies can occur as greater time is spent searching for data or contacting the correct personnel. At worst, failure to correctly target these tenets can lead to patient harm, as potential interactions are missed or therapeutic recommendations are not delivered.

Although important for all CDS, for PGx in particular, it is vital to determine to present. At the most reductive, what clinicians want to know from CDS is what to do with PGx results. , Thus, CDS tools should include an actionable recommendation for clinicians, where possible. In instances where a PGx interaction would recommend discontinuation or alteration of therapy, it is prudent to include therapeutic alternatives to prevent time wastage and reduce errors. When considering the information provided, it is also essential to determine what type of PGx data is needed and the level of detail (e.g., rsID, haplotype, diplotype, activity score, and phenotype). The phenotype is most commonly the level of detail used in interruptive alert CDS, as therapeutic recommendations for most PGx guidelines uses phenotypes (e.g., Clinical Pharmacogenomics Implementation Consortium (CPIC) and Royal Dutch Association for the Advancement of Pharmacy ‐ Pharmacogenetics Working Group (DPWG)). , Some clinical guidelines, such as those from the Canadian Pharmacogenomics Network for Drug Safety (CPNDS), may focus on specific rsID targets. However, some drug‐gene pairs (e.g., CYP2C9‐warfarin and CYP2D6‐atomoxetine) may have multiple recommendations within a single phenotype group. , In these instances, the tools would need to account for the patient’s diplotype or activity score. Multiple levels of PGx data will likely be required to meet all the CDS needs of a PGx program.

It is similarly essential to ensure that CDS tools target . Targeting the right person can include: limiting the triggering of alerts to specific provider groups or providing note writing assistance tools for certain disciplines. This prevents unnecessary alert fatigue by only interrupting those who can apply the information. The patient must also be considered when targeting the right person. Despite the potential for reduced genetic literacy, patients are frequently engaged and desire to be stewards of their healthcare journey. It is important for patient‐focused tools to ensure that the material is provided in patient‐friendly language and appropriate resources are available for patients who desire further information. However, patient‐focused CDS should address the risk of patients making changes to their medication based upon the results without contacting their provider.

The third right of CDS is ensuring the use of . When creating a CDS tool, the strengths and weaknesses of each type must be considered. One facet to consider is how users interact with the tool. An active CDS tool may be the right format for implementing a tool that detects a rare but severe genetic interaction. The clinician may not be familiar with checking for a rare interaction, or it may be overly time‐consuming for a busy clinician. Thus, an active tool, such as a pop‐up alert, may be the preferred format for a severe or rare interaction. Conversely, a passive interventional format, such as a genetic result summary report or portal, may be desirable in situations of milder intervention consequence or more prevalent genetic scenarios.

Another essential item to address during the design process is utilizing . This incorporates the method or access point the CDS object will inhabit. This can include the EHR but could also incorporate channels, such as a specific clinical information system or as general as an internet page. Choosing the EHR as your channel will open access to a plethora of laboratory results and health history but may reduce the ability to present information directly to patients. Stand‐alone clinical systems may represent a good channel for creating a controlled and easily curated environment for a vendor to distribute PGx CDS measures. Its utility may be limited by existing outside of the provider’s typical workflow. Additional consideration should be made for ancillary genomic systems. , These are systems designed to sit between the genetic laboratory and the EHR. The results can be processed in these systems and then imported into the EHR for consumption by patients, clinicians, and any other CDS elements. These systems can translate several distinct formats of results into a consistent output into the EHR, simplifying the design and maintenance of CDS tools within the actual EHR.

Finally, when designing CDS for PGx, it is imperative that clinicians are targeted at in their workflow to ensure that the patient is treated appropriately. Ideally, a CDS tool would target a prescriber when a decision is being made rather than too late (e.g., the patient already received the medication) or too soon (e.g., PGx data not yet available). The right time is inherently related to the type of CDS tool and the information it is communicating. Figure  shows examples of potential intervention spots for CDS tools.

Figure 2

Example opportunities for CDS along the patient care journey (orange = patient facing CDS; blue = provider facing CDS). CDS, clinical decision support; EHR, electronic health record; PGx, pharmacogenomics.

LIMITATIONS OF CDS

Regardless of how the CDS tool is classified, they all share certain common limitations. First, the tool can only be as good as the data that it has access to. At its most basic, this means that the tool needs access to data of some kind before it can be of use. Thus, it must either be able to pull discrete data elements directly from their source, or the user must manually enter them. The data should also be standardized regardless of the source. This will prevent two patients from receiving different levels of care because their results came from different laboratories. Access to standardized, structured, and discrete data is the biggest challenge for PGx CDS. Many groups cannot use PGx CDS because their data are inaccessible in this current format, likely PDFs. Multiple groups have highlighted this limitation, and some have developed solutions to help, such as CPIC’s term standardization project. , , , , ,

A second limitation is the maintenance CDS tools require. Particular attention should be drawn to the maintenance of the knowledgebase. These need updating as the literature evolves, and this updating likely requires expertise in PGx. Additionally, updates may be necessary as EHR updates occur and experience with tools is gained. Interruptive PGx alerts are very similar to interruptive drug‐drug interaction alerts, which are the most common inappropriately overridden alert. Thus, it is likely that interruptive PGx alerts will suffer similar limitations (e.g., alert fatigue presented after the initial decision made), limiting their effectiveness. , , , , Therefore, they should be evaluated at regular intervals. If used, interfaces to external resources, such as a portal or knowledgebase, will require maintenance to ensure the connection stays active. Maintenance requirements can require significant resourcing and may limit the scalability of a given CDS tool. Bringing to mind the phrase “Just because you can doesn’t mean you should,” which should be a consideration for all CDS builds.

Perhaps the most critical limitation to draw attention to is that, regardless of the sophistication of the build or availability of data, no one tool can solve every problem or is appropriate for all use cases. In the same way that personalized medicine focuses on incorporating the totality of unique patient factors into identifying treatment solutions, so too must the tools created for personalized medicine be crafted for their purpose. In addition, variations in EHR systems, health conditions, and cultures within patients and clinicians necessitate the use of individualized CDS solutions. In this way, it becomes clear that a multimethod approach is likely necessary to ensure comprehensive support for PGx testing.

CDS RESOURCES

Due to the current and growing complexity of PGx CDS, it is difficult for typical health systems to possess all of the expertise to implement a robust PGx program. As a result, several technical standards have been created, and multiple online resources are available to help solve this expertise gap and speed up implementation. In this section, we will provide a high‐level overview of a selection of these standards and resources.

As discussed earlier, the delivery of data in a contextually aware manner is an important feature in optimizing CDS. To perform this task, technical standards and services can be used. An application programming interface (API) allows two or more software applications to interact with each other and is a key tool for interoperability. To facilitate communication via APIs, standard formats are used. Fast healthcare interoperability resources (FHIRs) is one of these standards and is growing in importance for CDS implementations. CDS Hooks is one tool that uses FHIR services and can be used to deliver some of the content for the PGx CDS tools described earlier. The tool works by communicating through APIs to pull information for an external source and provide it back to the user who performed the action that triggered the CDS Hook. The “infobutton” tool is an additional tool used to bring context‐sensitive information into the EHR. In practice, this might be an icon next to a PGx result that when clicked brings up a web browser with a PGx guideline, thus powering PGx CDS.

The CPIC focuses on creating therapeutic guidelines for acting upon potential drug‐gene interactions. The CPIC has an informatics working group that creates EHR agnostic resources to support the translation of CPIC guidelines into CDS. Included in these guidelines are tables of recommendations and supplemental material containing suggested CDS elements. The CPIC recommendations are currently available in a structured database format via an API, allowing easy retrieval of the recommendations and content updates in a machine‐readable format. The CDS resources typically focus on interruptive alerts, including trigger conditions (medication and phenotype), alert context (pre vs. post‐test), and suggested text for the alert. Although structured around an interruptive alert, the suggested text and other elements could easily be transported into another CDS system, such as the text in a documentation assistance tool. Additionally, to help with the scalability and interoperability of PGx results, the CPIC has standardized terms to describe allele function and phenotype. Standardized terms reduce technical barriers to the exchange of information between electronic systems.

Two additional National Institutes of Health (NIH)‐funded projects helping bring PGx into clinical practices are the Implementing Genomics in Practice (IGNITE) consortium and Electronic MEdical Records and GEnomics (eMERGE). IGNITE is composed of 5 principal sites and 17 affiliates and was created to support the use of genomic medicine in clinical care. To accomplish this, they investigate and provide guidance on incorporating genetic results into the EHR and implementing CDS to support these results. The eMERGE has a mandate of improving the integration of genetic data into EHRs. These two groups have collaborated to create the Clinical Decision Support KnowledgeBase (CDSKB). This repository contains a library of diagrams of CDS systems and workflows and presentations on CDS systems at contributing sites. The library allows filtering by their sources, category, and entered search terms, such as medications or genes, and is an excellent way to learn from the experience of early adopters.

The Institute of Medicine formed an action collaborative called DIGITizE: Displaying and Integrating Genetic Information Through the EHR. This multi‐stakeholder group created several work products related to PGx, including a PGx standards model, a thiopurine and abacavir CDS implementation guide, and sample use cases for CDS. Even though the group has transitioned from its origins, these resources are still valuable starting points for implementing PGx CDS.

Each of the above resources provides helpful information when implementing PGx CDS. The following section will walk through the mechanics of creating PGx CDS with examples of how you might use the information in these resources.

CDS HOW‐TO GUIDE

The real challenge is translating the information discussed above into clinical practice. Here, we present a CDS build guide that incorporates the resources and concepts discussed above. It is important to note that each health system has different needs, clinical demands, technical expertise, EHRs, capabilities, and other factors that may influence how and what CDS may be built. In other words, it is unlikely that any two CDS implementations will be the same. Several health systems and organizations have published their experiences implementing CDS initiatives, including describing the planning and design process in detail. , , , , , This seven‐step build guide is a generalized foundation upon which health systems can ground their approach to building and maintaining CDS in support of PGx‐guided care. CYP2C19/Clopidogrel is used as a case study to highlight key aspects of the CDS development process.

Although this guide is presented numerically and linearly, this is more for ease of discussion rather than a necessity for practice. In actual settings, these steps may occur in parallel or loops where some steps are repeated rather than in a strictly linear fashion, and changes in one step may necessitate a revision or a return to a previously competed section. For instance, while forming a stakeholder group is presented as the third, it behooves the builder to solicit early feedback on the initial plan to minimize waste. An ideal situation may be the stakeholder group being the driving force behind the review and identification of the intervention opportunity.

Step 1 – Identify the targets

Identifying the targets may be the most important part of the entire process. When deciding on the PGx interaction to support, there are several key factors to consider: the level of evidence supporting this interaction, frequency of medication use, frequency of actionable PGx results, and the clinical effect. Identifying the targets is more than picking a specific interaction. It includes finding the potential patient population and at least one clinical champion. The clinical champion(s) will serve as a key resource in the early‐stage development of CDS and assist with receiving buy‐in among their colleagues and departments. Throughout each stage of the process, it is important you and clinical leads reach out to their respective groups to promote engagement and ensure the project’s target is valuable. Having these three components identified early will help ensure you have a successful implementation that can be measured and improved upon over time.

It is also essential to consider the level of evidence upon which the intervention will be based. The continuously expanding field of PGx has created an environment where there may be conflicting or heterogeneous descriptions of the supporting evidence for a PGx association. Various guideline organizations have been formed to process this literature and create clinical guidelines upon which clinicians can base their therapeutic decisions. However, there exist heterogeneity even among these guidelines. Therefore, each PGx program must decide what level of evidence they are willing to include and what sources they wish to use as their foundation.

An intervention will protect more patients if the relevant medications are commonly prescribed. It may be prudent to perform an initial review of prescribing or ordering practices to determine these volumes. National or even local averages may not be accurate for your institution if there are differences in the formulary and the availability of certain medications. Even within an institution, the values may differ between departments and specialties. Similarly, the intervention would be more impactful if the associated genetic variants were themselves common. The number needed to treat grows significantly if the high‐risk variants are only seen in a small percentage of the population. If no patients in your system receive the medication of interest or have the variant of concern, is it worthwhile building CDS to support the potential genetic interaction? The last key element is the clinical actionability of the PGx interaction. This encompasses the severity of a fulminant drug‐gene interaction, such as whether the expected interaction would be mild like reduced pain relief or severe, such as respiratory depression. It must also encompass the availability of clear therapeutic plans once the interaction has been identified. The value of the intervention is limited if there exist no suitable therapeutic alternatives. To this end, the institution’s drug formulary should also be consulted in order to determine if the interacting medication or its alternatives are currently included in the health system’s formulary and whether any restrictions are applied to their use.

Ideally, a project would target a PGx interaction with high values for all three of these metrics; a sizable percentage of the population is at risk for the variant, the medication is commonly prescribed, and the consequences of an interaction puts the patient at significant risk of morbidity and mortality. However, to be valuable, a project does not necessarily have to have all of these elements. It may be best to think of these as pieces contributing toward a value threshold rather than a set of switches that must all be “on.” For example, the drug‐gene pair of abacavir and HLA‐B*57:01. Abacavir is a less commonly used medication for the treatment of HIV. The genetic variant associated with this interaction is relatively rare, with a prevalence of just over 5% in European patients and much lower in African or Asian ancestry. However, the potential interaction is associated with Steven‐Johnson syndrome and toxic epidural necrolysis, which are significant severe cutaneous adverse reactions with high degrees of morbidity and mortality. Thus, even though the expected volume of patients impacted is low, the overall value of supporting this drug‐gene pair is high.

Although each institution may wish to determine its own thresholds for value, the DPWG has created an algorithm, the clinical implication score, to assist in assessing the impact of supporting a PGx association. Included in this score is the clinical effect graded by Common Terminology Criteria for Adverse Events, the number of studies with a sufficient level of evidence, the number needed to genotype to prevent one clinical event, and the presence of product labeling for the PGx interaction. The totaled score is then categorized as essential, beneficial, or potentially beneficial, allowing programs to devote resources to the highest value prospects (Table  ).

Table 1

How‐to guide step 1 checklist and case study narrative

Case study narrative

Step 1 – Identifying the targets Drug‐gene interactions Patient population Clinical Champion

Drug‐gene interactions Your program has decided to begin implementing PGx guidance into CDS. One potential drug‐gene pair that is of interest to you, due to a recent news article, is clopidogrel and CYP2C19. You investigate the supporting literature for this DGI and see that it is included in the FDA labeling and clinical guidelines (CPIC), which passes your programs or institution’s level of evidence requirements. To determine that this is a good use of your resources, there are a few metrics to review. The first of which is clinical significance. This interaction has the potential for significant patient morbidity and mortality from restenosis. You then check your formulary to confirm that a clear therapeutic alternative, ticagrelor, is already an approved option. Patient population. Next, you review the estimated frequency of the DGI. Through a demographic report, you determine that based upon your patient’s ancestry mix, ~ 30% are predicted to be intermediate or poor metabolizers of CYP2C19. You then request a report of the prescribing patterns for your interventional cardiologists, following PCI, clopidogrel is initiated 75% of the time. From these figures, you determine that this represents a sizable volume of your patients who this intervention may impact. Clinical Champion You recognize one of the cardiologists on your prescribing report and engage in a conversation with her to determine if she is interested in being a clinician champion for this project. Unfortunately, she is not sold on the value of PGx and declines but recommends another cardiologist.

CDS, clinical decision support; CPIC, Clinical Pharmacogenomics Implementation Consortium; DGI, drug‐gene interaction; FDA, US Food and Drug Administration; PGx, pharmacogenomics; PCI, percutaneous coronary intervention.

Step 2 – Designing the CDS

After defining the interventional opportunity, the next step is to determine the intervention method. At this point, the five “rights” of CDS serve as an excellent outline for planning the prospective intervention. All possible options for CDS tools should be evaluated. The clinical setting and impact can drastically change the type and design of CDS which will work best. This step will be most effective if the Health Information Technology (HIT) team, clinical champion, and project lead (you) work together (Table  ).

Table 2

How‐to guide step 2 checklist and case study narrative

Case study narrative

Step 2 – Designing the CDS Right Information Right Person Right Format Right Channel Right Time

Right Information For the wording of the tool, you decide to start with the text of the CPIC therapeutic recommendation “Alternative antiplatelet therapy (if no contraindication; e.g., prasugrel, ticagrelor)” and then rephrase it and focus on the formulary alternative “Recommend use of alternative antiplatelet therapy, such as ticagrelor.” Other options include the use of FDA labeling or longer descriptions based on provider preference. Next, define the information that will trigger the CDS element. For the medication, you discuss it with your HIT team and are informed that RxNorm codes are the most consistent medication identifier. Therefore, you decide to utilize the RxNorm code for clopidogrel. Next, you must determine whether the tool evaluates specific haplotypes, diplotypes, or phenotypes for the genetic results. At your institution, genetic results are stored as diplotypes, so you choose to utilize this level and provide your HIT team with a list of all diplotypes for CYP2C19 associated with reduced activity. Right Person You engage your clinical champion. She recommends targeting the ordering provider for this intervention, which in the setting of PCI may be a nurse practitioner, physician assistant, or interventional cardiologist. You could limit the tool to only trigger when the medication is entered by only those providers or during encounters in the cardiac catheterization unit. After discussing with the champion, you decide, because of the clinical significance of the DGI and variability in the ordering workflow, to avoid these limitations. Right Format For this tool, you want something that ensures that the provider is aware of the problem and considers the information presented. The DGI is also relatively small in scope, is ordered prior to administration, and has a clear therapeutic alternative. For these reasons, you decide that an interruptive or pop‐up alert is best. Right Channel In reviewing the clinical workflow, you determine the entire workflow flow is completed in the EHR, and thus it is the best channel for this alert. Right Time Finally, you review when you would like the alert to be triggered potentially. You and the champion decide that you only want to trigger the alert after clopidogrel has been chosen. The two options HIT presents to you are (1) for it to fire upon order entry or (2) further in the order process when the order is signed. You ask them to proceed with order entry as this will likely be closer to the time the decision is being made and prevent additional wasted provider time. To summarize, this intervention will be built as an interruptive alert within the EHR that will trigger when any provider selects to order clopidogrel (defined by RxNorm) for a patient with reduced CYP2C19 activity (defined by diplotype list).

CDS, clinical decision support; CPIC, Clinical Pharmacogenomics Implementation Consortium; DGI, drug‐gene interaction; EHR, electronic health record; FDA, US Food and Drug Administration; HIT, Health Information Technology; PCI, percutaneous coronary intervention.

Step 3 – Stakeholder feedback

Having defined the opportunity to address and the intended method that the intervention will take, it is time to gather and discuss the proposal with a larger group of stakeholders (Table  ). It is impossible to describe a team that will meet these needs at every organization, but some elements are consistent between sites. , , , , , The membership of the stakeholder group will be impacted by the structure of the PGx program and any institutional policies and procedures related to CDS oversight. Overall, the goal of this team is to ensure that personnel affected by the project have the opportunity to influence the CDS design. PGx interventions can impact multiple parts of the healthcare system and need to be seamlessly integrated into existing clinical workflows. Therefore, a multimember team is likely required to capture a complete picture of the clinical ecosystem.

Table 3

How‐to guide step 3 checklist and case study narrative

Case study narrative

Step 3 – Stakeholder Feedback Assemble the team Create an on‐going feedback forum Develop metrics

Assemble the team You create a synopsis of the project, with supporting literature, to present to the members of your stakeholder group. At your institution, the stakeholder group is required to include a department head, at least three clinicians, an HIT analyst, and a pharmacist. Your HIT analyst who has been assisting joins, and you serve as the pharmacist. The clinical champion reaches out to the department head, who is amenable, and provides five additional clinicians to reach out to for inclusion. Create an on‐going feedback forum After meeting with your stakeholder group, they recommend an expansion to the alert wording to “Due to reduced CYP2C19 activity, this patient is at increased risk of poor therapeutic response. Recommend use of alternative antiplatelet therapy such as ticagrelor.” One of the clinicians asks about integrating the PGx results into the PCI order set currently under development. As a next step, the team will develop a dynamic order set. Another clinician is concerned about non‐cardiovascular implications of PGx results. Luckily, your system already has an automatic consult request trigger every time a PGx panel has resulted. Develop metrics Finally, together you decide that you will track the number of times the alert fires, the number of overrides, and any comments or reasons submitted with the overrides. The plan is to re‐assess the alert functionality in 1 month initially and then again at 6 months.

HIT, Health Information Technology; PCI, percutaneous coronary intervention; PGx, pharmacogenomics.

Additionally, early involvement of the stakeholders will help with education, uptake, and optimization later on in the process. Finally, the project team should also work to create metrics by which the implementation may be assessed. Each member will be familiar with the types of objective measures valuable to patient care and the clinician workflows. Metrics for CDS that have been used include the number of alerts triggered, clinical response (i.e., changing therapy in accordance with the anticipated PGx interaction), and alert response (i.e., accepting or rejecting the triggered alert). , , , , , , , , , , Specifics will vary based on institutional policy but the culmination of the design and feedback phases generally consists of a presentation of submission for approval of the project to an overseeing committee. Often this will be the institution’s Pharmacy and Therapeutics (P&T) Committee or similar equivalent. Thorough understanding of the committee’s processes and requirements can prevent unnecessary delays in project timelines.

Step 4 – Build and test the CDS

The specifics of the build will vary significantly based on the structure and resources of the institution and the CDS tools. After selecting the tool that will be used and the concept that will be delivered, the next step of the CDS build is to define any necessary logic structure for the tool. This could include how specific medications are identified, how genetic results will be retrieved, and what knowledge bases will be accessed. CDSKB and DIGITizE websites contain artifacts with the logic structure for some drug‐gene pairs.

Identifying target medication orderables may seem like an easy task, but it is a bit more complicated in practice. Selecting medication via a standardized codified nomenclature system, such as RxNorm, may reduce maintenance complexities but not every orderable may be built with this level of detail. Therefore, it is crucial to test the mechanism used for identification to ensure that all medications that the project seeks to target are actually targeted.

The genetic components may likewise be available in many different formats, as discussed in the Five Rights section. When building, it is important to determine what level of fidelity is necessary and sufficient for the project. Choosing a suboptimal level here can result in logic inefficacies and unnecessary complexity. Additionally, genetic information continues to evolve; therefore, some consideration for future‐proofing is needed. In PGx CDS, this often means that whereas therapeutic decisions are often based upon the patient’s phenotype, specific rsIDs and haplotypes should remain available if a change in activity or recommendation necessitates the use of the more granular information.

After the initial build is completed, robust testing is needed for a successful go live. This means testing scenarios where active CDS is expected to trigger as well as not trigger. For passive CDS, the focus may be whether the content is mapped correctly or if the tools are accessible in the right places in the workflow (Table  ).

Table 4

How‐to guide steps 4 and 5 checklists and case study narrative

	Case study narrative
Step 4 – Build and test the CDS Leverage existing resources Develop robust testing strategy	Leverage existing resources The HIT analyst builds the alert using new verbiage from the stakeholders and uses RxNorm codes to identify the medication and diplotypes to identify the genetic results Develop robust testing strategy Unfortunately, the alert fails to trigger during testing when the orderable for clopidogrel 300 mg is selected. Upon troubleshooting, it is determined this one orderable is missing the RxNorm details in its build. A request to add this detail to the record is submitted, and the issue is resolved. Testing is finished successfully.
Step 5 – Develop and disseminate education Identify optimal education mechanisms Create educational materials Deliver education to all affected users	Identify optimal education mechanisms Through personal experience you know that there is a weekly pharmacy department newsletter and your cardiologist champion informs you of an upcoming monthly business meeting. Create educational materials You design a one‐page information sheet addressing what causes the alert to fire and what clinicians should do when it does. You utilize this material to also create a few slides for your champion to present at their meeting. Deliver education to all affected users Your summary sheet is included in the newsletter and distributed to pharmacists throughout the organization. You attend the cardiologist’s meeting where they inform their colleagues of the upcoming alert.

CDS, clinical decision support; HIT, Health Information Technology.

Step 5 – Develop and disseminate education to affected users

Delivering education to the ultimate end‐user is a critical component for success. The first time a clinician encounters the CDS, it may also be their first time encountering PGx in clinical practice. To avoid delays and confusion, clinicians should be educated about the upcoming changes and the expected actions they are to take. The breadth and audience of this education should be the minimum needed for the implementation. For instance, if a new PGx association between CYP2D6 and opioids is implemented, it may not be necessary to cover all other medications that could be affected by CYP2D6 or to include clinicians who do not manage pain. The education method depends on various factors, including institution standard practices, size, and the team’s capabilities. Some examples include Situation‐Background‐Assessment‐Recommendation (SBAR) memos, job aids, online modules, and didactic training (e.g., grand rounds). It is important to remember well‐designed CDS can serve as an additional educational tool for itself.

Step 6 – Go live

Once the affected clinicians have been thoroughly educated and the intervention has been sufficiently tested, it may be moved into production or go “live.” However, this is not the end of the implementation process (Table  ).

Table 5

How‐to guide steps 6 and 7 checklists and case study narrative

	Case study narrative
Step 6 – Go live Small celebration	Go live is seamless.
Step 7 – Maintenance and quality improvement cycles Establish metric review cadence Secure maintenance resources Return to prior steps as needed	Data from the initial go live is as expected. No changes are needed. Six months after go live, a new PGx is integrated into the system, and new diplotypes are possible. The CDS build must be updated. After 18 months, the number of alerts has dropped by 95%. Initially, the PGx team believes this signals that clinicians are reviewing the PGx results before making a medication. However, while sharing this at a feedback session, the cardiologists inform you their standard of care changed to no longer include clopidogrel. Based on this information you reallocate some of your development resources and focus on other opportunities for intervention, beginning the process again.

CDS, clinical decision support; HIT, Health Information Technology.

Step 7 – Maintenance and quality improvement cycles

The final step of the implementation is the transition to the assessment of the tool and continued maintenance and will be active as long as the CDS tool is implemented. This step will involve an initial review process wherein metrics determined by the stakeholders, such as the volume of patients impacted and clinical outcomes, are reviewed to ensure the project is meeting its intended goal. These metrics may also need to be presented to departmental committees or to the P&T committee for both quality assurance of the recent implementation and to support projects of a similar nature in the future. Planning is imperative for the maintenance phase as problems may not be apparent until several years have passed and other implementations have been enacted.

Needs for maintenance and revision may arise due to internal and external factors. To capture internal factors, feedback from the end‐users is vital as workflows and clinical needs for the CDS may change. External factors, such as new literature, beget a change in the therapeutic recommendation for a drug‐gene pair or when the interpretation of the genetic results themselves change. Two key examples of the latter case have occurred within the last few years when the phenotype assignment systems for CYP2C9 and CYP2D6 in CPIC guidelines were updated. , For CYP2D6, th e change may have created a need to revise CDS tools as the activity score for the *10 allele was changed, and the breakpoints for assigning phenotypes were changed. In particular, the reassignment of those with an activity score of one to intermediate metabolizer status could have impacted up to a third of the patients. If the system were utilizing diplotype lists in the logic for CDS, then those lists would need to be updated, but if a phenotype entry was used, then this might have required the change of historical results.

VISION AND IDEAS FOR THE FUTURE

Imagine 10 years from now moving to a new city across the globe. During the move, you drop a box on your left foot. On your way to the immediate care clinic, you use your mobile device to notify them what happened, that you are on your way, and setup up your patient account. Upon linking your new patient account to your previous systems account, your complete EHR, including whole‐genome data, is transferred and integrated into the new healthcare system records.

Your previous health system had a program offering whole‐genome sequencing from the comfort of your own home. Your pre‐test consulting was conducted using a virtual assistant. When you asked more specific questions about PGx, you were connected to a decentralized national expert via a video chat. You had an at‐home phlebotomy visit to collect your blood sample along with some other routine tests. When your genetic results were ready, because of your initial interest in PGx, you receive a customized video explaining how your PGx results impact your current and future medication needs. Periodically, you receive text‐based educational updates regarding new PGx findings related to your results.

You have arrived at the clinic, where you are immediately taken to have x‐rays performed and then to an examination room. While waiting for the x‐rays to be reviewed, you open your patient portal, and a virtual assistant greets you and asks if you are interested in how your healthcare data will be used during your visit. The virtual assistant highlights that if you need pain medication, the clinician will use 45 discrete datapoints, including PGx, to optimize your prescription. Next, the clinician knocks on the door and enters the room. They begin a physical examination and ask you several questions, including having you rate your pain. After finishing the examination, they input some data and make several selections on their tablet. With this information, risk algorithms and artificial intelligence recommend a treatment plan to your clinician. After a short discussion and review of your treatment, you are on your way home with a walking boot on your left foot. When you arrive home, there is a package from the pharmacy waiting for you, and you receive a text message asking if you are ready to meet with a pharmacist to discuss your pain medication. After 4 weeks, your foot is healed.

This future vision contains multiple advances in CDS from virtual assistants to integrated multifactorial CDS tools. These tools advance CDS into more predictive environments and expand the scope of CDS outside of physician visits. The future of PGx CDS is not as a stand‐alone silo of CDS utilizing only PGx data. Instead, the entire field of CDS must make progress, and PGx implementation can be a use case that drives that process. The most shocking to a current implementer might be the seamless movement of genomic data across systems. This future is within our reach. In a recent commentary, Denny and Collins stated that by 2030, we will have genomic data that moves effortlessly between EHRs and other applications. The EHR will be genome‐aware, making PGx easy, including automatically updating CDS logic from central guidelines. Multiple areas of opportunity and growth exist to realize this vision and drive PGx CDS into the future, including human factors engineering, expansion of patient‐facing CDS, and the development of standardized value‐based metrics.

What is human factors engineering?

The science of human factors engineering (HFE) can enhance the translation of genomic medicine into provider‐ and patient‐friendly, usable, and robust solutions for mental health. HFE uses knowledge about human capabilities and limitations to design safe, effective, and efficient work systems, such as technology, processes, and policies. HFE uses multiple methods to analyze user needs in the context of the task (e.g., reviewing scores of depression screening tools and reviewing PGx guidelines to inform prescribing decisions) and the system within which the task is intended to be performed (e.g., primary care clinics with high throughput). , , Analyzing the user’s interaction with the system to perform the intended task enables identifying points of mistakes, critical failures, and dangerous workarounds. This information can define the functional requirements of designing tools and technologies to minimize or eliminate these errors.

HFE applied to PGx

There is a growing body of literature eliciting user perceptions to shape the design of PGx CDS. Researchers have used varied methods, including interviews, surveys, observations, think‐aloud protocols, and heuristic evaluation to uncover user needs related to locating, integrating, and understanding information necessary to make PGx decisions. A user‐centered design approach was used to develop and evaluate PGx CDS for thiopurines. The ensuing CDS was designed using human factors principles to improve the salience of important information (e.g., color coding mutation risks and actionable items), and minimize memory load on the user (e.g., grouping information into categories and integrating numerical information, such as laboratory values), which lead to high physician satisfaction.

Researchers have also highlighted the continued need to improve training in knowledge about genetics and PGx and translating PGx results into easy, actionable items. Heale et al. observed clinicians working through case scenarios containing PGx information. They found clinicians desired clear, trustworthy, and reliable guidance about genetic testing, including when to order testing, how frequently testing should be conducted, the importance of testing, and how to interpret genetic effects. Similarly, others have also recommended giving clinicians an interpretation of test results and clinical recommendations. Human factors methods can be used to understand which pieces of information are essential in understanding PGx test results, how to integrate this information optimally, and how to display the tests to guide clinical actions within the visit meaningfully.

PGx information delivered without consideration of the overall workflow of the clinician is likely to be overridden. , Several excellent guidelines can be used to design PGx CDS systems to maximize the five rights of CDS. , , Khelifi et al. created and tested PGx prototypes through heuristic evaluation and provided step‐wise recommendations to support PGx‐based prescribing. The step of searching for relevant medications and treatment options should incorporate the medication and genetic risk as well as interactions. The step of selecting medications should present the provider with PGx test results, their clinical utility and validity, and relevant information about medications and interactions. Finally, the step of personalizing the treatment plan should contain an overview of the PGx results and interpretation, clinical validity, and a link to more detailed information.

HFE can identify and integrate patient and medication information that is critical when making PGx decisions. It can be used to identify appropriate clinical workflow points to maximize the accurate interpretation of PGx information. HFE can also be used to format and present PGx information to match the provider’s knowledge about PGx. Additionally, HFE can be used to structure PGx recommendations, so they are better integrated into prescribing decisions. An outcome of HFE may result in PGx CDS that is integrated into existing non‐PGx CDS tools. Removing the silo of PGx specific CDS tools would be a big win for integrating PGx into standard routine clinical care.

Patient‐facing CDS

As illustrated in Figure  , most current PGx CDS deployment is focused on clinicians, not patients. The most common way for patients to interact with PGx CDS is through a portal to view an interpretative report. There are novel ways of accessing these portals, such as the safety‐code card containing a QR code used by the Ubiquitous Pharmacogenomics project. Similar to clinicians, CDS tools beyond interpretative reports will be needed to maximize the utility for patients. National Human Genome Research Institute (NHGRI)’s strategic plan includes as a guiding principle “maximize the usability of genomics for all members of the public, including the ability to access genomics in healthcare.” This aligns with the purpose of patient‐facing CDS, at the same time highlighting the importance of creating CDS from a perspective of diversity and inclusion. Previous work has explored how different groups react to PGx interpretative reports, but CDS beyond that seems to be an underexplored area. The rapid development of patient‐facing CDS should be possible by learning from clinician‐facing CDS advancements. The 21st Century Cures Act and its information blocking provisions should accelerate the need for improvement in patient‐facing CDS. Because the ultimate stakeholders in clinical PGx are patients, there must be improvements and expansion of patient‐facing CDS tools.

Value‐based metrics

Developing meaningful metrics for any CDS, including PGx CDS, is difficult. However, meaningful metrics are essential to the quality improvement cycles in the how‐to guide. The NHGRI strategic plan highlights the importance of a genomic learning healthcare system, especially to identify the most effective methods and strategies for facilitating PGx. Robust CDS design with meaningful metrics can help lay the data foundation for the learning healthcare system approach. Metrics are meaningful when they are seated in the value of the process they are measuring. Therefore, we need to understand the total value of PGx data to the healthcare ecosystem. Unfortunately, today we do not know the full value of PGx, and further research is needed. In addition to the standard clinical outcomes in PGx studies, it will be essential to include all sources of value reported by patients, such as increased compliance and adherence to treatment plans and increased trust in the healthcare system. , , If we can link PGx CDS to these data, informative value‐based metrics can be created and used to optimize CDS implementations.

Initial steps to the future vision

The future vision laid out early will require significant changes to healthcare delivery in addition to CDS tools. These changes will take time. For an early win, it is important to devote resources toward improving the integration of PGx information within workflows and tools already being utilized by clinicians rather than adding additional CDS tools. PGx implementations may exist as “silos” that stand apart from other tools with which the clinicians may be more familiar. This has the potential for information to be missed as the clinician was not aware of it or for the clinician to receive duplicate or potentially contradictory guidance. For example, a health system may have alerts created to trigger when an International Normalized Ratio (INR) is sufficiently out of range and separate alerts to trigger when a patient’s PGx results indicate an increased sensitivity to warfarin therapy. Were these alerts linked, it may provide additional context for the clinician when determining their next action. Separated, the clinician may only receive a piece of the puzzle rather than the whole picture.

A potential strategy for improving the integration of available information within existing systems includes predictive text algorithms. , These programs are already utilized for predicting user responses in text or emails in the home setting. They may represent a prime opportunity to influence medication selection during an earlier stage of the workflow than most CDS tools. Rather than waiting for the medication, dose, frequency, etc., to be selected, such a system could instead determine that “simvastatin” is being typed, check for potentially impactful results, such as SLCO1B1, and suggest “lovastatin” or “rosuvastatin” to the provider instead.

It is also essential to expand the scope of CDS outside of physician visits. For many patients, their pharmacy represents their most common point of contact with their health care team. These visits may consist of a simple transaction to acquire medication refills but can serve as an initial point of triage for new issues in the patient’s health or issues with their medication regimen. Vast resources have been used to create tools for retail pharmacists to review prescriptions and check for allergies of potential drug‐drug interactions. In contrast, systematic access and support for other laboratory results, including PGx results, are much more limited. In an ideal system, these CDS measures at the pharmacy level would be redundant, as this information would have been taken into account at the time of prescribing and the issue already resolved. However, these pharmacy systems serve as a vital safety net for issues that make it through prior layers, particularly when a patient receives care from multiple health systems. This is a safety net that is currently lacking for PGx. The pharmacy is also a setting for pre‐test CDS to identify patients who might benefit from PGx testing.

CONCLUSION

CDS implementations are complex and those for PGx are even more so. Limitations, such as lack of access to structured data, and challenges of maintaining underlying knowledge bases highlight the complexity of PGx CDS. Many resources exist to describe existing PGx implementations but no one structure is optimal for all programs and even within a single institution, many different CDS tools must be utilized to support the use of genetic information in patient care properly. The five rights of CDS serve as a fundamental tool for designing impactful CDS and, in turn, serve as the foundation for the generalized how‐to guide presented here. The future vision illuminates several exciting opportunities in the field. It is hoped that this guide will empower new programs to begin their PGx journey and inspire further discussions and perspectives as there is a need for novel CDS measures and new ways of approaching integrating genetic information into healthcare.

FUNDING

No funding was received for this work.

CONFLICTS OF INTEREST

D.M.S. reports grants (to institution) from Kailos Genetics, Inc. S.K. reports grants to the Agency for Healthcare Research and Quality and Government of the District of Columbia Department of Behavioral Health. All other authors declared no competing interests for this work.

DISCLAIMER

As an Editor‐in‐Training of Clinical Pharmacology and Therapeutics, D. Max Smith was not involved in the review or decision process for this paper.