CC BY-NC-ND 4.0 · Methods Inf Med 2018; 57(S 02): e115-e123
DOI: 10.1055/s-0038-1676466
Original Article
Georg Thieme Verlag KG Stuttgart · New York

A Pharmacogenomics Clinical Decision Support Service Based on FHIR and CDS Hooks

R.H. Dolin
1  Elimu Informatics, Richmond, California, United States
,
A. Boxwala
1  Elimu Informatics, Richmond, California, United States
,
J. Shalaby
1  Elimu Informatics, Richmond, California, United States
› Author Affiliations
Further Information

Address for correspondence

Robert Dolin, MD
1160 Brickyard Cove Rd STE 200 Richmond
CA 94801-4173
United States   

Publication History

27 June 2018

27 October 2018

Publication Date:
03 January 2019 (eFirst)

 

Abstract

Objectives Pharmacogenomics (PGx) is often considered a low-hanging fruit for genomics–electronic health record (EHR) integrations, and many have expressed the notion that drug–gene interaction checking might one day become as much a commodity in EHRs as drug–drug and drug–allergy checking. In addition, the U.S. Office of the National Coordinator has recognized the trend toward storing complete sequencing data outside the EHR in a Genomic Archiving and Communication System (GACS) and has emphasized the need for “pilots that test Fast Healthcare Interoperability Resources (FHIR) Genomics for GACS integration with EHRs.” We sought to develop a PGx clinical decision support (CDS) service, leveraging the emerging FHIR and CDS Hooks standards, and based on an assumption that pharmacogene sequencing data would be stored alongside the EHR in a GACS.

Methods We developed a PGx CDS service as a functional prototype. The service is triggered by a medication order in the EHR. When evoked, the service looks for relevant genetic data in a GACS and returns corresponding recommendations back to the ordering clinician. Where the patient has no genetic data on file, the service can recommend pretreatment genetic testing where applicable.

Results Overall, we were able to meet our objectives and deploy a functional prototype, interfaced with a commercial EHR. We identified several areas where FHIR or CDS Hooks lacked necessary semantics or have implementation ambiguity. Primary FHIR challenges included multiple ways to say the same thing, which exacerbated the complexity of variant to allele conversion and lack of representation of deoxyribonucleic acid region(s) studied. Primary CDS Hooks challenges included the complexity of executing an authenticated query against one system (GACS) upon being triggered by a different system (the EHR), and limitations in the types of actionable recommendations that can be returned to the EHR.

Conclusions In conclusion, we have found that PGx CDS based on FHIR and CDS Hooks appears to represent a promising means of genomics–EHR integration. More real-world testing along with a set of use-case driven GACS interface requirements will push us closer to the U.S. National Human Genome Research Institute vision of a plug-in PGx app.


#

Introduction

Pharmacogenomics (PGx) is often considered a low-hanging fruit for genomics–electronic health record (EHR) integrations, and many have expressed the notion that drug–gene interaction checking might one day become as much a commodity in EHRs as drug–drug and drug–allergy checking.[1]

PGx use cases are of particular interest because over half of all primary care patients are exposed to PGx relevant drugs.[2] Studies have found that 7% of U.S. Food and Drug Administration (FDA)-approved medications and 18% of the 4 billion prescriptions written in the United States per year are affected by actionable PGx variants[3]; that nearly all individuals (98%) have at least one known, actionable variant by current Clinical Pharmacogenetics Implementation Consortium (CPIC) guidelines[4]; and that when 12 pharmacogenes with at least one known, actionable, inherited variant are considered, over 97% of the U.S. population has at least one high-risk diplotype[5] with an estimated impact on nearly 75 million prescriptions.[6]

Additional rationale for targeting PGx includes the public availability of well-characterized drug–gene interactions[7] [8]; standards for drug information representation and exchange are well established in EHRs[9]; and drug-related clinical decision support (CDS) systems are well established in EHRs.[10]

Projects such as DIGITizE,[11] eMerge,[12] IGNITE,[13] and others have made important advancements in PGx–EHR integration. PGx CDS implementation is generally triggered by medication initiation at order entry. In many cases, patients have been preemptively tested, using a genetic testing platform with known result formats.[14] Recent projects have leveraged emerging interoperability standards as a means of further easing PGx–EHR integration.[15] [16] Mandel[16] describes a project at Boston Children's Hospital, building an open-source PGx CDS service using the Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) specification[17] along with CDS Hooks[18] to provide medication dosing guidance at the point of care. The project integrates patient-level genotypes, expressed in FHIR, to compute and convey dosage advice that can be integrated into the EHR's electronic prescribing user interface. Several other groups have developed FHIR-based clinical genomics applications,[19] [20] [21] and in a structured comparison, Swaminathan et al[22] found that only FHIR supported all of their defined evaluation criteria for clinical genomics application interfaces. Further accelerating this work are efforts by Logical Observation Identifiers Names and Codes (LOINC),[23] Systematized Nomenclature of Medicine,[24] and others to standardize the terminology used in PGx reporting.

Scant literature exists describing the use of the emerging CDS Hooks specification in clinical applications. The specification describes a “hook”-based pattern for invoking decision support from within a clinician's EHR workflow. The CDS Hooks application programming interface (API) is in active development, working toward a 1.0 release, and will include a hook for “medication-prescribe,” invoked in an EHR by medication order entry; a hook for “patient-view,” invoked by opening a patient's record; and a hook for “order-review,” invoked by reviewing a set of orders prior to signing. A CDS Hooks-enabled EHR, when invoked, will send a notification to an external CDS service. The service can then perform its rules, external to the EHR. The CDS Hooks standard also specifies how the external CDS service communicates back to the EHR. Each CDS service can return any number of CDS Hooks “cards” back to the EHR. Cards can be informational, can include suggestions (such as recommendations for a medication dose change), or can include a link to an application (such as a SMART-on-FHIR application) where the EHR user can supply details, step through a flowchart, or do anything else required to reach an informed decision.

Many challenges to PGx–EHR integration have been described. Issues range from those common to any CDS implementation (e.g., alert fatigue, resource limitations, the need for manual rule curation)[25] [26] [27] to common integration issues due to lack of sufficient standards[28] [29] to genetic and PGx-specific issues that in general are reflective of the biological complexity of the human genome coupled with the technical limitations and platform variability involved in genetic testing.

Genetic variants (differences between a patient's deoxyribonucleic acid [DNA] and a reference DNA) are commonly represented in Human Genome Variation Society (HGVS) sequence variant nomenclature.[30] One challenge with HGVS is the potential for multiple representations for a given variant. An HGVS expression includes a reference sequence and an indication of how the observed sequence differs from the reference. An example is shown in [Fig. 1]. Reference sequences exist for each human chromosome, for each gene, for each gene transcript, etc. There can be many synonymous HGVS representations of a variant, each showing a variation from a different reference sequence or from a different version of a reference sequence.

Zoom Image
Fig. 1 Example Human Genome Variation Society (HGVS) expression. This expression represents a variant in the thiopurine methyltransferase (TPMT) gene that results in altered azathioprine metabolism. Reference sequence NM_000367.4 is a messenger ribonucleic acid (mRNA) transcript of the TPMT gene. At position 238 in this transcript, a Guanine (G) has been replaced by a Cytosine (C). This leads, in the corresponding protein product of the gene, to Alanine (Ala) being replaced by Proline (Pro) at amino acid position 80.

PGx “star alleles” have raised particular challenges. A “star allele” is an identified unique gene sequence. Each unique gene sequence for a given PGx gene is assigned an identifier—for instance, allele identifier “27” for gene CYP2C19 would be represented as the “CYP2C19*27” star allele. Many star alleles are comprised of more than one variant, each occurring at a different location in a gene. In [Fig. 2], for instance, star allele thiopurine methyltransferase (TPMT)*3A is comprised of two variants. U.S. FDA product labels generally define drug–gene interactions at the level of the gene allele, whereas genetic test results often provide variant-level data. Challenges with PGx star alleles include confusing nomenclature, the lack of a definitive source of truth for allele-variant mappings, and technical issues that arise in converting between alleles and variants.[31] [32] [33] [34] Furthermore, some alleles (e.g., CYP2D6*13) do not have a corresponding set of variants, and some alleles (e.g., HLA-B*57:01) are challenging to compute from a set of unphased variants. On top of this, sequencing data may show variants beyond those previously studied through single-nucleotide polymorphism (SNP)-based testing[35] [36] or may have no variant calls in poor quality regions,[37] confounding allele assignment.

Zoom Image
Fig. 2 Illustration of the thiopurine methyltransferase (TPMT) gene, showing the relationship between star alleles and variants. The blue line represents the TPMT gene, with thick bars corresponding to exons and the intervening thin horizontal lines corresponding to introns. Variants are indicated as red arrows. Note that TPMT*1 is the wild-type allele and therefore has no variants, and that TPMT*3A is comprised of two variants.

With the trend toward storing complete sequencing data outside the EHR in a Genomic Archiving and Communication System (GACS)[38] [39] [40] comes additional PGx–EHR implementation considerations. A GACS stores next-generation sequence data generated from a sequencing laboratory and is analogous in many ways to a Picture Archiving and Communication System, which stores image files that are not suitable to store directly in an EHR. Traditional laboratories have focused on communicating simple categorical results and interpretative information. Some of these laboratories now need to provide more provenance and underlying raw data for potential reanalysis and other scenarios, and are turning to a GACS type of solution. However, raw sequencing data formats and EHR data standards have evolved independently, posing interoperability and integration challenges. This has prompted the U.S. Office of the National Coordinator, through their Sync for Genes project, to emphasize the need for pilots that test GACS integration with EHRs.[38] GACS considerations are relevant to PGx because incidental findings from genome sequencing studies have been successfully used to create PGx decision support alerts[41] and because many believe that DNA sequencing is likely to become the standard method for PGx genotype determination.[42]


#

Objectives

A summary report from the U.S. National Human Genome Research Institute (NHGRI) Genomic Medicine PGx meeting in May 2017 notes that “to date, successes in implementing PGx have largely been through projects funded by the NIH but this is not scalable or sustainable. Furthermore, EHRs are constantly being updated which necessitates hospitals to spend more money on keeping their systems up to date. Plug-in applications are available for drug-drug interactions; potentially they could be developed for drug-gene interactions.”[1] We sought to develop a PGx CDS service, as a functional prototype, based on FHIR and CDS Hooks, and based on an assumption that pharmacogene sequencing data would be stored alongside the EHR in a GACS, in addition to discrete results stored in the EHR. Here, we describe the service, including a discussion of how our architectural design allowed us to address several known PGx–EHR integration issues and further the objectives of a plug-in app as expressed by the NHGRI.


#

Methods

Overview: Pharmacogenomic Clinical Decision Support Service

We developed a drug–gene decision support (PGx CDS) service as a functional prototype.[43] The service is triggered by a medication order in the EHR. When evoked, the service looks at patient genetic data for potential interactions, and returns corresponding recommendations back to the ordering clinician. Where the patient has no genetic data on file, the service can recommend pretreatment genetic testing where applicable.

The service is designed to use FHIR and CDS Hooks, and is based on an assumption that sequencing data are stored alongside the EHR in a GACS, in addition to discrete results stored in the EHR. The PGx CDS service interacts with the GACS via a FHIR API, using this interface to obtain a patient's genotype. Medication order entry in the EHR triggers a “medication-prescribe” CDS Hook, which invokes the service. Recommendations from the service are returned to the EHR via CDS Hooks cards.


#

PGx CDS Service Architecture

The PGx CDS service is built as a high-performance software-as-a-service platform for evaluating patient data. The core functionality of the platform is to integrate services including patient data access APIs (such as FHIR interfaces) into flows that can perform analysis or workflow services. It contains a rules service and a FHIR-compatible terminology service and has a modular architecture in which new flows are composed declaratively by linking various services. A component diagram of the PGx CDS service is shown in [Fig. 3]. Sample FHIR and CDS Hooks instances are in the [Supplementary data].

Zoom Image
Fig. 3 Pharmacogenomics (PGx) clinical decision support (CDS) service architecture. See text for details. The fire icon symbolizes the use of Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR). The blue/green/yellow square icon symbolizes the use of CDS Hooks.

Underlying the service is a rules engine containing CPIC Level A recommendations. At the January 2018 HL7 FHIR Connectathon,[44] we interfaced to a commercial EHR and demonstrated the execution of the CPIC TPMT-azathioprine rule.[45] Azathioprine is a prodrug that requires transformation to its active metabolite, thioguanine nucleotide (TGN). The TPMT gene product metabolizes azathioprine down an alternate path so that less azathioprine is available to be transformed to TGN. Where TPMT activity is diminished or absent, more azathioprine is available to be transformed into TGN, potentially resulting in severe myelosuppression. CPIC guidelines recommend azathioprine dose reduction if the patient is heterozygous for an inactive TPMT allele, and use of an alternate agent if the patient is homozygous for an inactive TPMT allele. Where the patient has no genotype data on file, CPIC guidelines recommend genetic testing prior to medication initiation.

The controller is the orchestrator of the service. It can house multiple interfaces (APIs) to the external world and store multiple protocols that dictate when other components perform their duties. The PGx CDS service leverages CDS Hooks controller capabilities.

Rules are implemented in Drools, and encompass CPIC Level A recommendations involving star alleles comprised of simple variants (SNPs and indels). Rules are designed to trigger on notification of medication order entry coming in from a CDS Hooks-enabled EHR, and return recommendations back to the ordering clinician before the order is signed. Rule construction is a mixed manual and semiautomated process. For each CPIC Level A recommendation, we manually review CPIC and PharmGKB recommendations and data tables. For each gene, we extract relevant variant, allele, and genotype structured information. For each medication, we extract the RxNorm drug ingredient code. For the drug–gene interaction, we extract categorical genetic risk impact, genetic metabolism impact, and/or genetic efficacy impact. Extracted data are put into a knowledge base that underlies and drives the PGx CDS service's rules engine.

As noted above, many alleles are comprised of more than one variant, each occurring at a different location in a gene. This requires that the PGx CDS service maintain allele-variant conversion rules that enable the system to translate between alleles and variants where necessary (such as in the case where patient data provides variants but rule logic is based on alleles). Conversion rules need to account for several biological and technical considerations. A variant can be heterozygous or homozygous. Where multiple variants are present, they may all be “in phase” (i.e., all on the same chromosome), or out of phase (i.e., some variants on the maternally derived chromosome and some on the paternally derived chromosome). Technologies differ in their ability to report phase. Where phase data are lacking, conversion rules can attempt to infer it using population frequencies. There exist situations, such as where key regions of a gene were not studied, where it may not be determinable exactly which alleles are present.

The PGx CDS service leverages a FHIR-compatible terminology service, where we house RxNorm value sets for each PGx actionable medication. Medication order entry in the EHR triggers a “medication-prescribe” CDS Hook, which not only invokes the PGx CDS service, but also supplies the service with a FHIR Medication resource that includes an RxNorm code for the ordered drug. The service tests this RxNorm code for inclusion in the PGx medication value sets (using the FHIR $validate-code operation). If not present, no further action is taken and the service terminates silently.

The service interacts with an EHR and GACS via a FHIR API. The EHR interface can be used to gather additional patient information, such as conditions and laboratory results. Rule execution requires knowledge of a person's genotype (i.e., both the gene allele on the maternally derived chromosome and the gene allele on the paternally derived chromosome), which is obtained via the GACS interface.

We were not aware of any standard published GACS interface specifications, FHIR-based or otherwise, at the time the service was designed. We developed a relatively simple interface, initially based on an assumption that next-generation sequencing data residing in the GACS would be queryable in one of two formats, both compatible with FHIR Observations. The first format is based on the HL7 FHIR Release 3, Standard for Trial Use (STU3) Observation-genetics profile (https://www.hl7.org/fhir/genomics.html#observation-genetics), and represents discrete variants in HGVS syntax,[30] along with allelic state (e.g., heterozygous, homozygous). The second format is based on the HL7 FHIR STU3 Observation-genetic PGx profile (such as https://hl7.org/fhir/observation-example-diplotype1.html), and can convey haplotype or full genotype information. Specific data sought from GACS included region(s) studied; variants; allelic state and allelic phase for identified variants; star-alleles; and genotype. Our design assumes that not all data will be available on all patients. Execution of the interface entails the PGx CDS service sending a query containing specific FHIR Observation search parameters to the GACS, and retrieving a set of FHIR Observations matching those parameters.


#

Rule Execution

Overall workflow for rules in the PGx CDS service is shown in [Fig. 4]. We describe the workflow by way of a fictitious clinical scenario.

Zoom Image
Fig. 4 Pharmacogenomics (PGx) (CDS) service rule execution. See text for details. The fire icon symbolizes the use of Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR). The blue/green/yellow square icon symbolizes the use of CDS Hooks.

Connie SMART is a 45-year-old woman with persistent and disabling joint pain and swelling despite nonsteroidal anti-inflammatory medications. Diagnostic studies, including whole genome sequencing done in search of an explanation for her arthritis, have been unrevealing, although genetic markers showing her to be at an increased risk of rheumatoid arthritis are positive (HLA-DRB1*03 positive; HLA-B*08 positive). Given her ongoing disabling symptoms, her physician, Doctor DoGood gives her a presumptive diagnosis of rheumatoid arthritis and decides to give her a treatment trial with Imuran.

Dr. DoGood enters an order for “Imuran 50 mg 1 tablet twice a day by mouth” into the EHR order entry system. This order triggers a “medication-prescribe” CDS Hook which invokes the PGx CDS service and provides it with a FHIR Medication resource that includes RxNorm code “197388” (azathioprine 50 mg oral tablet).

Having been triggered by the “medication-prescribe” CDS Hook, the PGx CDS service executes a decision support rule that determines if the ordered drug has a known gene interaction; determines, where there is a known drug–gene interaction, whether or not the patient has genetic test results on file; determines, where there are genetic test results on file, if the patient has an interacting genotype; and determines, where there are not genetic test results on file, if the patient needs pretesting.

For azathioprine, the PGx CDS service determines that there is a known drug–gene interaction between azathioprine and certain “inactivating” variants of the TPMT gene, that if present, greatly increase the potential for severe azathioprine-induced bone marrow suppression. Next, the service queries GACS, looking for genotype results for the TPMT gene. The service finds and retrieves observations on the TPMT gene that were generated as part of Connie SMART's previous whole genome sequencing. Connie SMART is found to have two TPMT alleles—one is the normal “wild-type” allele (TPMT*1) and one is a known inactivating allele (TPMT*2). Based on this finding, the PGx CDS service returns a CDS Hooks “information card” back to the EHR, surfaced as a dialog box prior to order entry completion, which states “Azathioprine Alert! Patient is heterozygous for an inactivating allele of the TPMT gene and is at risk for severe drug-induced bone marrow suppression. Reduce the typical starting dose by 50%.”

Dr. DoGood alters the order to “Imuran 50 mg 1 tablet once a day by mouth,” signs and completes the order.


#
#

Results

We sought to develop a PGx CDS service, as a functional prototype, based on FHIR and CDS Hooks, and based on an assumption that sequencing data would be stored alongside the EHR in a GACS, in addition to discrete results stored in the EHR. Our findings are derived from attempting to use FHIR and CDS Hooks to fulfill our design objectives, which included the construction of a FHIR-based PGx CDS service to GACS interface.

Overall, we were able to meet our objectives and deploy a functional prototype, interfaced with a commercial EHR.[43] In the paragraphs that follow, we summarize areas where FHIR or CDS Hooks were found to be lacking necessary semantics or to have implementation ambiguity.

FHIR and GACS Interface

We based our work on FHIR STU3. FHIR genomics resources are in an early stage of standardization, where real-world testing is not only required to advance the standard, but is also likely to identify areas for enhancement. In some cases, the challenges we encountered may have been partially due to our choice of FHIR resource to use (e.g., we based our work on the FHIR Observations-genetics profile, whereas our findings may have differed had we instead based our work on the FHIR Sequence resource or the FHIR DiagnosticReport-genetics profile).

At a high level, our requirements can be summarized by the need to identify variants, variant zygosity (e.g., heterozygous, homozygous), and phase (i.e., whether variants are in phase, meaning all on the same chromosome, or out of phase, meaning that some variants are on the maternally derived chromosome and some are on the paternally derived chromosome), and region(s) studied. Our focus was on the identification of simple variants. Future efforts will include querying GACS for more complex structural variants. Challenges in meeting these requirements included multiple ways to say the same thing, which exacerbated the complexity of variant to allele conversion, and lack of representation of DNA region(s) studied.

We found redundant ways of representing variants and alleles in FHIR STU3. The FHIR Observation-genetics profile can represent discrete variants represented in HGVS syntax, and provides fields for the representation of zygosity and phase sets; variants and alleles can also be communicated in different ways via the FHIR Sequence resource, the HL7 FHIR STU3 Observation-genetic PGx profile, and the HL7 FHIR STU3 Observation-genetic human leukocyte antigen (HLA) profile (https://www.hl7.org/fhir/genomics.html#hla). Although not strictly speaking a FHIR issue, we were also challenged by the multiple ways a given variant can be represented in HGVS. We addressed this latter issue by maintaining a database of variant synonyms, although we describe what appears to be a more robust solution in the “Discussion” section.

As described above in the “Introduction” section, one of the challenges of PGx “star alleles” can be the need to convert from variants to alleles. Conversion rules need to account for several biological and technical considerations. A variant can be heterozygous or homozygous. Where multiple variants are present, they may all be in phase or out of phase. Technologies differ in the ability to report phase, and in their overall coverage of PGx-relevant genomic regions. Conversion challenges have been well described,[34] and our findings corroborate prior reports. Redundant FHIR representations of alleles and variants exacerbated this issue, given the need to account for each possible representation. In addition, we found that the general notions of an allele being comprised of one or more in-phase variants, and a genotype being comprised of two alleles presented a conceptual hurdle to the development team.

One of the steps in the decision support rule shown in [Fig. 4] includes a determination “Is there a genotype on file?” This step cannot be answered by simply querying GACS for the presence or absence of variants in a particular region, because the absence of variants might mean the region was not studied (i.e., was not sequenced as part of the specific laboratory procedure) or that the region was studied and no variants were found. Such a differentiation requires knowledge of the region(s) studied. We identified candidate LOINC codes (e.g., 51959–5 “Ranges of DNA sequence examined”), and felt that FHIR implementation guidance on the use of these codes would have been valuable.


#

CDS Hooks

CDS Hooks is in active development, working toward a 1.0 release. As such, the specification is not yet in a deployed operational EHR, and testing is done against commercial EHR development platforms. Similar to FHIR, the CDS Hooks specification requires real-world testing to advance the standard and to identify areas for enhancement.

At a high level, our requirements can be summarized by the workflow in [Fig. 4]. In this scenario, a trigger in the EHR such as the creation of an order or a prescription for a medication creates a request to the PGx CDS service. The CDS Hooks request provides the service with the parameters for the service to securely obtain patient data from a FHIR server. However, the PGx CDS service also needs to execute an authenticated query against the GACS before returning recommendations back to the EHR. Challenges in meeting these requirements included the complexity of executing an authenticated query against one system (GACS) upon being triggered by a different system (the EHR), and limitations in the types of actionable recommendations that can be returned to the EHR.


#
#

Discussion

We are neither the first nor the only group to identify many of the findings noted above, and many active genomics informatics activities are directly or indirectly addressing the PGx CDS challenges we have identified. We list a small handful of the most relevant here.

HL7 has recently gone to ballot with the May 2018 version of the HL7 FHIR Clinical Genomics Reporting, Implementation Guide.[46] Considerable focus has gone in to resolving the multiple representations challenges and to presenting a unifying view of variants, alleles, sequences, haplotypes, and genotypes, and their interrelationships. The Guide includes targeted recommendations for communicating next-generation sequencing results, microarray and cytogenetic results, PGx and somatic findings and structured interpretations, HLA typing, and more. Representation of region(s) studied remains a recognized requirement and a work in progress at the time of this writing. Of note is that while this Guide will provide an unambiguous way of communicating phased variants, technological improvements that enable the determination of phase sets are also rapidly evolving.[47]

Bioinformatics is a computationally intensive field, and better, faster, and more clever data manipulation algorithms are constantly being developed. Two in particular include (1) U.S. National Center for Biotechnology Information (NCBI) Variation Services,[48] and (2) PharmGKB's Pharmacogenomics Clinical Annotation Tool (PharmCAT).[34] We describe challenges with HGVS synonyms above (i.e., how to determine whether two HGVS expressions represent the same variant). The NCBI Variation Services offers a solution, whereby a given HGVS expression can be normalized into a canonical expression known as a Sequence Position Deletion Insertion expression, and then compared with another normalized expression. We anticipate that the use of this normalization approach will obviate the need for us to track and maintain HGVS synonyms. The PharmCAT software computes star alleles from a set of variants and is optimized for inferring the star alleles that are in the CPIC PGx guidelines. Use of PharmCAT may obviate the need for us to maintain our own variant-allele conversion rules.

We encountered several situations where our development team needed some baseline genetics education to conceptualize the requirements. While there is no shortage of avenues for genetics education, we found that some programs were focused primarily on clinical genomics, many were focused on bioinformatics, and many were long or expensive. We ultimately developed our own educational series “Introduction to Human Genomics for Clinical Informaticists,”[49] comprised of twelve 2-hour webinars. The sessions were designed for clinical informaticists and developers with little or distant genetics education and with a lack of familiarity with evolving genomic standards. Course curriculum includes FHIR Genomics resources; cancer genetics; immunogenetics; genomics–EHR integration challenges; PGx; Next-Generation Sequencing/Variant Discovery; HL7 Genomics standards; CRISPR/Cas9; and more. All course material is available online for free.

An analogy between drug–gene, drug–drug, and drug–allergy checking is interesting in that for the latter two, we generally think of rules being automatically updated by a trusted knowledge source, whereas manual curation is the current norm for drug–gene CDS implementation. While not specifically studied as part of our implementation, we did find that both CPIC and PharmGKB provide structured data (PharmGKB offers a free API and additional structured content that requires a paid license to access). We found, for instance, that the publically available PharmGKB API[50] could be used as a trusted source of PGx allele functional categorization. For instance, “api.pharmgkb.org/v1/data/haplotype?gene.symbol = CYP2C19” returns CYP2C19 alleles, allele functions, HGVS variants, and more. Our current approach is that manual curation is needed to first construct a new drug–gene rule and to ensure its optimal performance during deployment. From there, we anticipate using APIs selectively to automatically update certain rule components. The ability to leverage public knowledge sources to dynamically update CDS rules is likely to expand considerably.

In parallel to the maturation of public knowledge sources is the evolution of efforts to share PGx CDS rules using standard formalisms. All of the CDS PGx rules developed under eMerge and IGNITE are available,[51] but vary in format. Efforts such as the multilayered framework for disseminating knowledge[52] and other standards-based approaches to shareable CDS[53] [54] appear promising.


#

Conclusions

In conclusion, we have found that PGx CDS based on FHIR and CDS Hooks appears to represent a promising means of genomics–EHR integration. More real-world testing along with a set of use-case driven GACS requirements will push us closer to the NHGRI's vision of a plug-in PGx app.


#
#

Conflict of Interest

All authors work at Elimu Informatics, a for-profit healthcare informatics software and consulting company.

Acknowledgments

We gratefully acknowledge the HL7 communities, particularly the FHIR, CDS Hooks, and Clinical Genomics communities, for their determinism and persistence in driving toward improved health care through technology, and for their open and collaborative spirits. None of this work would be possible without such roll-up-your-sleeves collaboration.

Supplementary Material


Address for correspondence

Robert Dolin, MD
1160 Brickyard Cove Rd STE 200 Richmond
CA 94801-4173
United States   


  
Zoom Image
Fig. 1 Example Human Genome Variation Society (HGVS) expression. This expression represents a variant in the thiopurine methyltransferase (TPMT) gene that results in altered azathioprine metabolism. Reference sequence NM_000367.4 is a messenger ribonucleic acid (mRNA) transcript of the TPMT gene. At position 238 in this transcript, a Guanine (G) has been replaced by a Cytosine (C). This leads, in the corresponding protein product of the gene, to Alanine (Ala) being replaced by Proline (Pro) at amino acid position 80.
Zoom Image
Fig. 2 Illustration of the thiopurine methyltransferase (TPMT) gene, showing the relationship between star alleles and variants. The blue line represents the TPMT gene, with thick bars corresponding to exons and the intervening thin horizontal lines corresponding to introns. Variants are indicated as red arrows. Note that TPMT*1 is the wild-type allele and therefore has no variants, and that TPMT*3A is comprised of two variants.
Zoom Image
Fig. 3 Pharmacogenomics (PGx) clinical decision support (CDS) service architecture. See text for details. The fire icon symbolizes the use of Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR). The blue/green/yellow square icon symbolizes the use of CDS Hooks.
Zoom Image
Fig. 4 Pharmacogenomics (PGx) (CDS) service rule execution. See text for details. The fire icon symbolizes the use of Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR). The blue/green/yellow square icon symbolizes the use of CDS Hooks.