eMERGE Results FHIR® Specification¶
Introduction¶
The Electronic Medical Records and Genomics (eMERGE) Network, funded by the National Human Genome Research Institute (NHGRI), is a consortium of of U.S. medical research institutions that “develops, disseminates, and applies approaches to research that combine biorepositories with electronic medical record systems for genomic discovery and genomic medicine implementation research”. Phase III of this program, as part of the Network’s overarching goal to integrate genomic test results to the EHR for clinical care, sought to create a proof of concept, standards-based representation of clinical genomic test results using the rapidly evolving Health Level Seven (HL7®) Fast Healthcare Interoperability Resource (FHIR®) standard. The effort to implement a FHIR based specification for the eMERGE genetic test results using the HL7 FHIR Genomics Reporting Implementation Guide was managed by the two Centralized Sequencing and Genotyping Facilities (CSGs): the Broad Institute (BI) and Partners Laboratory for Molecular Medicine (LMM) and Baylor College of Medicine Human Genome Sequencing Center (BCM-HGSC).
Below you can find background information on eMERGE Phase III Results, eMERGE Pilot Implementation, and Specification Aim.
How to read this Guide¶
This Guide is divided into several pages which are listed at the top of each page in the menu bar.
Home: The home page provides the introduction and background for the eMERGE Results FHIR Specification.
Design: These pages provide insights into the process used to generate the specification.
- Example Reports: This section provides examples of the 2 different versions of lab reports used during eMERGE III.
- Report Layout & Structure: This section describes how the 2 different report versions were generalized and mapped into common components.
- FHIR Report Resources: This section introduces the FHIR Diagnostic Report and associated sub component resources relevant to the eMERGE report model.
Artifacts: … (catalogue of artifacts & detailed pages)
- Catalogue (classified as core, ig, custom) (table of resources)
- Custom Extensions (3)
Issues & Resolutions: This section contains a comprehensive listing of issues in mapping and structuring the eMERGE data to the Genomics Reporting IG (STU1) and their resolutions.
Discussion: This section contains discussions on strategic concerns with adoption, concerns related to representing variation and potential future use cases.
FHIR Genomics Reporting IG¶
This specification in built on top of the FHIR Genomics Reporting Implementation Guide (STU1) which is under active development by the HL7 Clinical Genomics WG. During the development of this specification the FHIR Genomics Reporting Implementation Guide (STU1) progressed from Draft to Standard for Trial Use version 1.
eMERGE Phase III Results¶
The eMERGE Results HL7 FHIR Specification is a product of the eMERGE network and was initiated by the EHR Integration Workgroup during phase III of the study. It focuses on providing an HL7 FHIR electronic message standard for returning the lab results for the eMERGEseq Platform panel assays performed by the two eMERGE Sequencing Centers (SC) for the individual eMERGE sites. During the fulfillment of the eMERGESeq Platform of phase III an XML schema was specified and all results were generated, delivered and stored using this format. This specification is an evolution of the phase III eMERGE XML structure Schema.
eMERGE Pilot Implementation¶
eMERGE is piloting and implementation of this specification in conjunction with its development and release which includes a subset of the eMERGEseq Platform’s panel results returned from the SCs.
Specification Aim¶
The aim of the eMERGE test results return specification and implementation is to inform the efforts of the HL7 Clinical Genomics WG so as to accelerate the process towards a normative standard for general practice in clinical genetic test reporting.
Design¶
The design of a HL7 FHIR Genomics Reporting Implementation Guide (GR IG) based specification for eMERGE Phase III electronic return of structured results was motivated by the following guiding principles:
- Structured content - All content from the narrative PDF eMERGE reports and all eMERGE standard reporting use cases should be captured in structured format and as meaningful data elements without losing content and context.
- Alignment with HL7 FHIR Core and GR IG - All eMERGE concepts and associated elements shall be aligned with GR IG and FHIR Core Standards and extended as required.
- Computationally reliable representation of results - An optimal computational form for each data element shall be determined, prioritizing eMERGE pilot objectives for EHR integration and CDS. All specimen types and genetic data elements related to the resulting observations must be based on reference sequences, coordinates and structures that consistently and accurately reflect the lab methods used to align the raw data, determine coverage and call the variants.
- Codify concepts when reasonable - Concepts should be codified using FHIR Core and GR IG guidance. eMERGE concepts that extend beyond the FHIR and CG guidance should be codified if possible and within reason.
The design and development of the eMERGE FHIR Specification consisted of the following steps:
Example Reports¶
The first step towards the creation of the eMERGE FHIR Specification was an “As Is” analysis of the existing genetic reports to inventory all eMERGE reporting concepts and elements. To this end, we compiled a set of all-inclusive representative reports from both the CSGs (see Figure 1 for a de-identified example report from each CSG) to ensure use cases requiring unique report concepts and elements were included.
Figure 1: HGSC & LMM eMERGE Report Examples (click to enlarge)
Report Layout & Structure¶
Using selected reports for these use cases, the structure and composition of the reports was analyzed and a set of data elements was assembled (Figures 2 & 3), resulting in 18 core concepts and around 100 fundamental data elements. This analysis and documentation of the existing eMERGE report content served as the foundation for the design of the eMERGE FHIR Specification.
Figure 2: HGSC general report layout and detailed mapping (click to enlarge)
Figure 3: LMM general report layout and detailed mapping (click to enlarge)
FHIR Report Resources¶
The next step in the development of the eMERGE FHIR Specification was the mapping of eMERGE report concepts and elements to the GR IG. Adopting the GR IG’s guidance, all major eMERGE report concepts were aligned to the GR IG resources and profiles, followed by a granular mapping of every eMERGE report element to a corresponding FHIR resource element.
The GR IG provided the guidance for driving the mapping of the eMERGE report concepts to its resources, profiles and extensions. Our first attempt at mapping resulted in several key structural and organizational questions, documented at Issues & Resolutions.
Addressing and resolving these issues resulted in the mapping and structural design of the specification, illustrated in Figure 4. As illustrated, the root profile of the specification is the GenomicsReport; this is the key resource that encapsulates the ServiceRequest for the test, the Observations that constitute the results (i.e. findings or implications of the test), the Tasks that include clinical care recommendations, and the Grouper Profile to organize and manage composite resulting (i.e. GenePanel and PGx results). Other major resources attached to the GenomicsReport include the Patient for whom the test is being ordered, the associated Specimen, the Practitioner ordering the test, the Organization (i.e. Diagnostic Laboratory performing the test) and the Practitioner interpreting the results of the test.
Figure 4: FHIR Diagnostic Report Schema Alignment An illustration of the associations between the major report components and FHIR Diagnostic Report Schema.
We then mapped every eMERGE report attribute to an equivalent field in the FHIR resources identified in the previous step. This was a laborious process which in addition to requiring precise and careful mapping of the fields themselves, also required determining naming systems and assignment of coding systems, codes and values. The artifacts section includes the complete set of eMERGE FHIR resources and its associated elements, with a summary listed in the table below. Furthermore, gap analysis at this step revealed the need for additional fields such as summary interpretation text, test disclaimer etc. that were not available in the GR IG. Though we documented these as feature requests in HL7’s Tracking System Jira, to satisfy the immediate needs of the project, we created these fields as FHIR Extensions.
| No. | Element | FHIR Resource | IG Profile/Ext | Related Properties |
|---|---|---|---|---|
| 1 | Report | DiagnosticReport | Genomics Report | Test Disclaimer,
Gene Coverage
|
| 2 | Patient | Patient | none | |
| 3 | Sample / Specimen | Specimen | Specimen Profile | |
| 4 | Request / Orderer | ServiceRequest | Service Request Profile | |
| 5 | Test Performed … | PlanDefinition | none | …Name,
…Background,
…Methodology,
…References
|
| 6 | Ordering Provider,
Results Interpreter
|
PractitionerRole | none | |
| 7 | Performing Lab | Organization | none | |
| 8 | Recommendations (Proposed) | Task | Recommended Followup | |
| 9 | Comments (Additional Notes) | Observation | none | |
| 10 | Overall Interpretation | Observation | Overall Interpretation | Summary Text |
| 11 | Diagnostic Gene Panel Results Group | Observation | Grouper | Summary Text |
| 12 | Clinical Interpretation | Observation | Inherited Disease Pathogenicity | |
| 13 | PGx Gene Panel Results Group | Observation | Grouper | |
| 14 | Medication Implication | Observation | ||
| 15 | Identified Variant Genotype | Observation | Variant | |
| 16 | Identified Variant Diplotype | Observation | Genotype | |
| X5 | Summary Text | none | custom | |
| X6 | Test Disclaimer | none | custom | |
| X7 | Gene Coverage | none | Related Artifact Extension |
Artifacts¶
Figure 5 below illustrates a complete map of the resource, profile and extension FHIR artifacts used to support the eMERGE report defined by this specification. It starts at the center with #1 the GenomicsReport profile in purple from the FHIR CG Genomics Reporting IG. At the top are the red artifacts representing the patient and specimen concepts. The light green artifacts in the upper right hand side represent the order (Service-Request) and the ordered assay (PlanDefinition) along with the ordering and performing practitioners and their facility. The yellow artifacts on the left-hand side represent the top-level interpretation, comments and recommended actions, if applicable. The bottom half of the mapping diagram divides the diagnostic disease gene panel findings and results in pink on the left from the pharmacogenomic gene panel findings and results in green on the right. Both results and findings share common artifacts in orange at the bottom of the diagram to represent the variants and genotypes associated with the findings and results.
Figure 5: Artifact Catalog Map A map of the associations between the major schema artifacts (resources, profiles and extensions).
The additional sub-diagrams at the bottom of Figure 5 contain the complete set of extensions utilized in this specification. These extensions were used from other sources when available as indicated or created as custom extensions if no reasonable alternative was available. These extensions primarily are used to extend the Patient (X1 thru X4) and GenomicsReport (X6 thru X8) concepts, but one extension was needed for capturing summary interpretation text (X5) on both the GenomicsReport and/or any Observation.
The following catalog provides a tabular view corresponding to the numbers in Figure 5 as well as the figures shown elsewhere in this specification. The links will open the specific artifact’s page in this specification.
| No. | Artifact | FHIR Resource | Description |
|---|---|---|---|
| 1 | Genomics-Report | DiagnosticReport | The top level resource representing the genetic test results report with the final findings and interpretations for the eMERGE Test Panel. |
| 2 | Patient | Patient | The patient for which the eMERGE Test Panel was ordered and fulfilled. |
| 3 | Specimen | Specimen | The sample or specimen collected from the patient being tested. |
| 4 | Service-Request | ServiceRequest | The fulfilled order for a patient along with the ordering practitioner, the specimen and the assay methodology and description performed. |
| 5 | (Assay) PlanDefinition | PlanDefinition | The plan definition resources is used to represent the eMERGE lab developed test (LDT) performed. |
| 6 | PractitionerRole | PractitionerRole | The practitioner role is used to represent the health care personnel in the context of their role and organization (e.g. geneticists, clinicians, etc..). |
| 6a | Practitioner | Practitioner | The practitioner is either the individual health care provider playing the role of an ordering physician or result interpreter when paired with the organization and practioner role. |
| 7 | Organization | Organization | The organization for the ordering provider, results interpreter and performing lab. |
| 8 | Recommended-Followup | Task | The recommended followup profile is a proposed task resource for structuring the return of recommendations for the report. |
| 9 | Report Comment | Observation | A generalized observation used by the performing lab to convey unstructured and uncoded comments about the report. |
| 10 | Overall-Interpretation | Observation | The overall interpretation for the diagnostic gene panel portion of the assay relative the primary indication for testing. |
| 11 | Dx Grouper | Observation | The grouping of diagnostic gene panel results to separate them from the PGx results and/or other logical groupings of results. |
| 12 | Inherited-Disease-Pathogenicity | Observation | The inherited disease pathogenicity interpretations for specific variant findings assessed in relation to the primary indication for testing which have the potential to also be secondary findings. |
| 13 | PGx Grouper | Observation | The grouping of PGx gene panel results to separate them from the diagnostic gene panel results. |
| 14 | Medication-Implication | Observation | The 3 types of medication implications: Metabolism, Efficacy, Transporter function interpretations used to assess PGx gene panel variant findings. |
| 15 | Variant | Observation | The variant profile supports the return of structured short sequence variants along with their zygosity for observed findings typically to support interpretations related to their clinical significance or in the context of the assay. |
| 16 | Genotype | Observation | The genotype profile supports the return of structured genotypes derived from individual variant alleles. This is used primarily to structure PGx diplotypes. |
| X# | Extensions | Extension | The list of all extensions used throughout this specification with special emphasis on the few custom extensions developed by eMERGE to support the project’s requirements. |
Genomics Report¶
The final findings and interpretation of the eMERGEseq Platform genetic test performed on blood specimens derived from patients.
Scope¶
The eMERGE project includes sequencing, interpretation, generation and delivery of clinical genetic reports from diagnostic labs (eMERGE Clinical Sequencing and Genotyping Facilities) to the ordering providers (eMERGE Study Sites). The GenomicsReport profile derived from the DiagnosticReport resource was adopted to represent the eMERGE report specification and includes textual and coded interpretations, variant findings and their diagnostic pathogenicity assessment, and pharmacogenomic implications, requesting and provider information, assay description and methodology as referenced resources and resulting observations attached to the GenomicsReport profile.
Content¶
eMERGE uses the Genomics Report profile which is derived from the DiagnosticReport resource.
Patient¶
The patient resource contains demographic information for the individual on which the genetic test is run.
Scope¶
The data in the Resource covers the “who” information about the patient: its attributes are focused on the demographic information necessary to support the result interpretation, logistic, administrative, compliance and regulatory procedures. A Patient record is generally created and maintained by each organization providing care for a patient. A patient or animal receiving care at multiple organizations may therefore have its information present in multiple Patient Resources.
This resource is referenced in Genomics Report, Service Request, Specimen, and all observations in the eMERGE report.
Notes¶
Not all concepts required for eMERGE were included within the base resource, such as race, ethnicity, birthsex and age. Race, ethnicity and birthsex were included from the US Core Profile as extensions. Age, an optional element to be included in lieu of birthsex for de-identifying purposes was created as a custom extension for eMERGE. See #19 in Discussion -> Issues & Resolutions for further detail. An eMERGE specific business identifier assigned to this resource.
Specimen¶
The characteristics defining the patient’s extracted sample to be used for testing and analysis.
Scope¶
A material sample taken from a biological entity, living or dead. The specimen covers substance used for diagnostic testing. The focus of the specimen resource is the process of gathering the specimen as well as where the specimen originated. An eMERGE specific business identifier assigned to this resource.
This resource is referenced in Genomics Report, Service Request, and all observations in the eMERGE report.
Content¶
eMERGE uses the Specimen Profile here which is derived from the Specimen resource.
Notes¶
Though the Genomics Reporting IG’s specimen profile was used for eMERGE considering that there is a 1:1 overlap between specimen profile and the specimen resource, preference should be given to the core specimen resource.
Service Request¶
The service request is the order information describing the specific assay requested and/or fulfilled, the patient and specimen and the ordering provider that authorized the request.
Scope¶
The eMERGE project had prescribed assays from the two sequencing centers that fulfilled the genetic testing services. As such, the service request was used to represent the fulfilled assay. In a generic clinical genetic testing system, order management would require additional uses of the service request not included here.
The ordering provider or requester is typically a practitioner and their provider organization, but a provider organization alone may be used if appropriate.
This resource is referenced in Genomics Report and all observations in the eMERGE report.
Content¶
eMERGE uses the Service Request Profile here which is derived from the ServiceRequest resource.
Notes¶
The ordered and performed test (or assay) is also provided in the service request via the instiantiatesCanonical association to the PlanDefinition Please refer to the PlanDefinition page for the rationale and approach to scope and structure of the Assay.
(Assay) PlanDefinition¶
The PlanDefinition resource is used to support the exchange of the assay protocol and methodology information.
Scope¶
A common genetic testing panel and plan was coordinated across both emerge sequencing centers. However, as is often the case with genetic testing, the individual sequencing centers often use different procedures and technologies to achieve similar aims. These differences in methodologies for both sequencing and resulting are essential in reporting results.
This resource is referenced in Service Request.
Content¶
eMERGE uses the PlanDefinition resource with the following constraints.
Notes¶
For cases where a global or shared test registry can be defined with sufficient and accurate test information, the computational reporting of test information could possibly be simplified to passing an identifier to such a resource. In the case of emerge the sequencing assays performed for various providers and across sequencing centers deviates to a large enough degree that it is critical to include these details about the testing methodology, description and references in the structured electronic results. Since this information is not case specific it is not considered to be an observable result but instead a definition of the test itself. It will be consistent across all cases that share the same testing methodology for a given SC.
PractitionerRole¶
A specific set of Roles/Locations/specialties/services that a practitioner may perform at an organization for a period of time.
Scope¶
PractitionerRole covers the recording of the location and types of services that Practitioners are able to provide for an organization.
The role, specialty, location and healthcare service aspects of the PractitionerRole resource have been used in eMERGE to distinguish between the role of the ordering provider placing the test order (requester) and the geneticist responsible for the report’s interpretations and conclusions (resultsInterpreter) by creating a PractitionerRole resource for each role respectively. Additionally highlighted in this resource are the institutions i.e. Organization resource under which Practitioners assigned to this role perform their respective responsibilities.
See Practitioner and Organization artifacts for additional detail.
The resultsInterpreter and performer are referenced in Genomics Report while the requester is referenced in Service Request.
Content¶
eMERGE uses the PractitionerRole resource with the following constraints.
Notes¶
Performer & Results Interpreter The performer and results interpreter typically correspond to the testing laboratory and lab resource that finalizes the report, respectively. These two components are closely related and exist at the DiagnosticReport level. In eMERGE there will always be one laboratory as the performer and there is typically one results interpreter. It is possible to have more than one of either, but that was not in scope for the eMERGE specification.
Their is no profile or extension for the Performer or the Results Interpreter and these components use the standard FHIR Resources of Organization and PractitionerRole, respectively.
Note
Performer For details see multi-use artifact: Organization
Practitioner¶
A person who is directly or indirectly involved in the provisioning of healthcare.
Scope¶
Practitioner covers all individuals who are engaged in the healthcare process and healthcare-related services as part of their formal responsibilities and this Resource is used for attribution of activities and responsibilities to these individuals. The two Practitioners for eMERGE are the ordering provider in the role of requester ordering the test and geneticist in the role of resultsInterpreter responsible for the interpretations and conclusions of the test. See PractitionerRole and Organization artifacts for additional detail.
The two Practitioner resources are referenced in PractitionerRole.
Content¶
eMERGE uses the Practitioner resource with the following constraints.
Notes¶
Performer & Results Interpreter The performer and results interpreter typically correspond to the testing laboratory and lab resource that finalizes the report, respectively. These two components are closely related and exist at the DiagnosticReport level. In eMERGE there will always be one laboratory as the performer and there is typically one results interpreter. It is possible to have more than one of either, but that was not in scope for the eMERGE specification.
Their is no profile or extension for the Performer or the Results Interpreter and these components use the standard FHIR Resources of Organization and PractitionerRole, respectively.
Note
Performer For details see multi-use artifact: Organization
Note
Results Interpreter For details see multi-use artifact: PractitionerRole
Organization¶
The institution(s) requesting a genetic test and the diagnostic laboratory responsible for performing and/or interpreting the results.
Scope¶
This resource is used in eMERGE to identify the Organization that the PractitionerRoles i.e. the requester of the test and resultsInterpreter for the test belong to. This resource is also used to identify the performer of the test i.e. the diagnostic lab providing the service.
The performer (performing organization) is referenced in Genomics Report and Service Request while the requester and result interpreter organization is referenced via the PractitionerRole.
Content¶
eMERGE uses the Organization resource with the following constraints.
Notes¶
Performer & Results Interpreter The performer and results interpreter typically correspond to the testing laboratory and lab resource that finalizes the report, respectively. These two components are closely related and exist at the DiagnosticReport level. In eMERGE there will always be one laboratory as the performer and there is typically one results interpreter. It is possible to have more than one of either, but that was not in scope for the eMERGE specification.
There are no profiles or extensions for the Performer or the Results Interpreter and these components use the standard FHIR Resources of Organization and PractitionerRole, respectively.
Note
Results Interpreter & Requester For details see multi-use artifact: PractitionerRole
Recommended Followup¶
Task describing the followup that is recommended.
Scope¶
eMERGE reports only use proposed recommendations. Please reference discussions for reason and follow up code constraint arguments.
This resource is referenced in Genomics Report RecommendedAction extension.
Content¶
eMERGE uses the Recommended Followup profile which is derived from the Task resource.
Report Comment¶
Observation resource that includes assertions made about the patient.
Scope¶
eMERGE reports typically include have a comments or additional notes section with case specific information. These comments are not really recommendations, conclusions or observations. This is additional information that the reporting lab wants to provide the ordering provider and patient related to the overall outcomes. The Observation resource is used to include this information by limiting the scope of this resource to a standard LOINC Report Comment code (86467-8) and an associated value that houses the comment or additional notes text. See #3 in Discussion -> Issues & Resolutions for further detail.
This resource is referenced in GenomicsReport as a result.
Content¶
eMERGE uses the Observation resource here.
Overall Interpretation¶
Provides a coarse overall interpretation of the genetic results reported.
Scope¶
eMERGE reports generally include an overall interpretation for the report, primarily based on the testing results of the gene panel.
This Overall interpretation result is typically displayed as a positive, negative and inconclusive value with summary interpretative text providing additional information and context. The OverallInterpretation profile included the concepts necessary to represent the result value and the Observations it was based on and is referenced in the GenomicsReport profile as a front-page result for the patient and in the Grouper profile as part of the aggregation of resulting Observations for the patient. However, an option to include summary interpretation text, a key component of the overall interpretation was not available as part of profile and a custom extension for eMERGE was created to include summary text.
This resource is referenced in Genomics Report and Diagnostic Gene Panel Grouper.
Content¶
eMERGE uses the Overall Interpretation profile here which is derived from the Observation resource.
Grouper Profile(s)¶
Organizes information within a genetic report.
Scope¶
Results for both the eMERGE gene panel and PGx sites are assembled together as a single report. Though bundled together, these results are discrete components requiring composite representation. Utilizing the Grouper profile, Observation results for both gene panel and PGx were added as members of the Diagnostic Gene Panel Grouper and PGx Grouper respectively, with these two Grouper resources referenced as results of the GenomicsReport Profile thereby resulting in the aggregation of a composite report.
See below for additional scope and content details on both the Diagnostic Gene Panel Grouper and PGx Gene Panel Grouper artifacts.
Diagnostic Gene Panel Grouper¶
The primary design of the eMERGE Seq assay is to perform a diagnostic assessment of the variation in a pre-defined panel of genes. The Diagnostic Gene Panel Grouper is an organizing Observation profile that aggregates the primary and secondary findings of any clinically significant variants identified, their assessments, as well as a reference to the overall interpretation for the final report of which the diagnostic panel is the basis.
Content¶
eMERGE uses the Grouper profile here which is derived from the Observation resource.
Notes¶
Primary and Secondary findings may optionally be segregated into separate “groupers” if it useful to the lab or clinic process. For eMERGE both primary and secondary findings were reported together in a single Diagnostic Gene Panel Grouper.
See #7 Secondary Findings for more details on the issues related to representing secondary findings and their derived interpretations.
PGx Gene Panel Grouper¶
In addition to the Diagnostic Gene Panel findings and interpretations, the eMERGE Seq Panel was designed to include the medication implications of several pharmacogenomic genes. The Pharmacogenomic Gene Panel Grouper an organizing Observation profile that aggregates all of the observed states of the pharmacogenomic genes and their medication implications. The pharmacogenomic gene results have no bearing on the overall interpretation for the report, unlike the diagnostic gene panel results.
Content¶
eMERGE uses the Grouper profile here which is derived from the Observation resource.
Notes¶
In practice the PGx results could be reported independently (as was the case in the BI/LMM reporting workflow). However, with genetic tests that are based on larger panels, exomes or genomes, there may be several categories of assessment that have useful clinical value based on the original wet lab finding (sequencing and/or genotyping). Genetic test reports for these larger assays often combine these distinct but grouped assessments in a single physical report. The Grouper profile provided an acceptable solution for eMERGE that did not otherwise exist.
Inherited Disease Pathogenicity¶
The inherited disease pathogenicity observation is the interpretation that the results interpreter associates with a genotype finding within the diagnostic gene panel.
Scope¶
The eMERGE assay is designed to sequence, identify, confirm and report the clinically significant variants in relation to the indication for testing. The inherited disease pathogenicity interpretation is the result that specifies which disease or condition the associated variant finding is pathogenic or likely pathogenic and thus considered clinically significant.
The inherited disease pathogenicity interpretation may also be used to identify secondary findings if it is not associated with the primary indication for testing but still within the secondary finding list of conditions. Secondary finding interpretations are indicated by using the observation-secondaryFinding attribute of the inherited disease pathogenicity association.
This resource is referenced in Overall Interpretation and Diagnostic Gene Panel Grouper observations of the eMERGE report.
Content¶
eMERGE uses the Inherited Disease Pathogenicity profile which is derived from the GenomicsBase profile and the Observation in turn.
Medication Implication¶
The result interpreter’s assessed implication of medication(s) associated with specific variant and/or genotype/diplotype findings for pharmacogenomic genes.
Scope¶
There are three subtypes of the medication implication profile: metabolism, efficacy, and transporter.
eMERGE uses the following three profiles that all derive from the medication implication profile:
These three profiles support the specific medication implications related to metabolism, efficacy and transport function, respectively. They all ultimately derive from the Observation resource.
This resource is referenced in PGx Gene Panel Grouper observations of the eMERGE report.
Content¶
The descriptions & constraints column in the attribute table below will indicate the specific numbered subtypes impact on the attribute, if applicable.
Variant¶
The variant profile is used to represent variants tested and/or identified. It specifies whether the variant is present, absent, indeterminate or a no call for the assay performed.
Scope¶
The variant is a complex profile that can be used to represent numerous forms of variation. The eMERGE report uses the Variant profile primarily for the diagnostic gene panel variant findings with their zygosity. These variant findings are the basis for the Inherited Disease Pathogenicity interpretations that are the aim of the diagnostic gene panel assay.
Please refer to the discussion topics for more information on this profile.
This resource is referenced in Inherited Disease Pathogenicity, Genotype, Diagnostic Gene Panel Grouper and PGx Gene Panel Grouper observations.
Content¶
eMERGE uses the Variant profile which is derived from the GenomicsBase profile and the Observation in turn.
Notes¶
The complexity and options available for applying this profile cause it to be confusing to use. There is no other alternative method for defining variants in a universally consistent and computationally reliable way at the current time.
Variant contains a zygosity attribute which enables the implementer to represent short variation (e.g. SNPs, indels, etc.) as genotypes, which can seem confusing with the naming and purpose of the Genotype.
Genotype¶
The genotype profile is used to represent a diplotypes tested and/or identified. It is a profile that can identify and link the underlying Variant findings that define the genotype or diplotype concept tested or found.
Scope¶
The genotype profile is a higher order profile that can use other variant profile records to define the variant components of the genotype. The eMERGE report uses the Genotype profile primarily for the pharmacogenomic gene panel diplotype findings. These diplotype findings are the basis for the Medication Implication interpretations that are the aim of the PGx gene panel assay.
eMERGE specified the need to include variants found for the specific PGx genes tested. The PGx genes were derived from both sequence and genotype testing. The eMERGE PGx methodology used one or more predefined locations with the various PGx genes to assert the haplotypes and diplotypes for those PGx genes. The CPIC star allele nomenclature was the display format for the final PGx diplotype calls.
This resource is referenced in Medication Implication and PGx Gene Panel Grouper observations.
Content¶
eMERGE uses the Genotype profile which is derived from the GenomicsBase profile and the Observation in turn.
Extensions¶
The eMERGE Results FHIR Reports use several FHIR extensions to supplement the resources and profiles specified by the the Genomics Reporting IG (STU1). When an extension was warranted the process was to find an available extension amongst those defined as part of the Genomics Reporting IG (STU1), then to look at other registered extensions available in the FHIR specification and finally to define our own custom extensions. All custom extensions were discussed with the HL7 Clinical Genomics WG as proposed additions to the Genomics Reporting IG (STU1).
The list of extensions below are used throughout this specification are marked with their source or “eMERGE custom” if they were custom defined for this specification only. Additionally, each extension references the artifact that it is used by to provide context.
X1. Birth Sex¶
| Name | : | us-core-birthsex |
| Source | : | US Core IG (STU3) |
| Used In | : | Patient |
| Description | : | The birth sex extension is used to provide a specific biological sex for
the patient being tested.
|
X2. Ethnicity¶
| Name | : | us-core-ethnicity |
| Source | : | US Core IG (STU3) |
| Used In | : | Patient |
| Description | : | The ethnicity extension is used to provide a specific set of ethnicities
for the patient being tested.
|
X3. Race¶
| Name | : | us-core-race |
| Source | : | US Core IG (STU3) |
| Used In | : | Patient |
| Description | : | The race extension is used to provide a specific set of races for the
patient being tested.
|
X4. Age¶
| Name | : | Patient Age |
| Source | : | eMERGE custom |
| Used In | : | Patient |
| Description | : | The age extension is used to provide a specific age in years of the
patient at the time of testing.
|
X5. Summary Interpretation Text¶
| Name | : | SummaryInterpretationText |
| Source | : | eMERGE custom |
| Used In | : | DiagnosticReport, Observation |
| Description | : | The summary interpretation text extension is used to provide short
narrative summary interpretations at the report level and any
observation level as needed.
See discussion Interpretation Summary Text for related information.
|
X6. Test Disclaimer¶
| Name | : | TestDisclaimer |
| Source | : | eMERGE custom |
| Used In | : | Genomics Report |
| Description | : | The test disclaimer extension is used to return the performing lab’s
test disclaimer at the report level.
|
X8. Recommended Action¶
| Name | : | RecommendedAction |
| Source | : | HL7 Clinical Genomics WG |
| Used In | : | Genomics Report |
| Description | : | The recommended action extension is used to return a top-level proposed
recommendation from the lab to the ordering provider.
|
Issues & Resolutions¶
This section summarizes several key structural and organizational questions and issues that were identified and discussed with the HL7 Clinical Genomics WG during the creation of the eMERGE FHIR Specification in 2019. During that time, the HL7 Clinical Genomics WG was working on the STU1 release of the Genomics Reporting IG (STU1). While some issues such as Composite Reporting were addressed quickly as part of STU1, the HL7 Clinical Genomics WG is continuing to address and improve changes, which this work has informed.
Difficulty A rating of Major or Minor is assigned to each issue to represent the level of difficulty to design a solution and gain consensus for its adoption by the developers of the HL7 GR IG or FHIR specification if needed.
Resolution Status The HL7 CG WG members helped address eMERGE issues by clarifying existing options, adopting changes in GR IG STU1 or submitting issue to the HL7 Jira board for consideration of changes to future GR IG or FHIR specification releases. Most of the issues required immediate resolutions to complete the eMERGE FHIR specification and pilot projects. Several issues were complex and not resolved. These were deferred by eMERGE but were documented and raised as they were determined to be important for inclusion in a GR IG and FHIR specification to provide more accurate utility of genetic test results.
The following resolution statuses are used to help summarize the impact of this project had on the Genomics Reporting IG (STU1) development.
- Clarification - a solution in the current Genomics Reporting IG (STU1) existed and needed clarification.
- GR IG Change - changes were applied to address the issue in STU1’s final release.
- Workaround - a general or custom extension was added for eMERGE only.
- Deferred - the issue was deferred and not resolved, CG IG was informed of the issue.
HL7 Jira Tickets Twenty one (21) HL7 Jira tickets of varying scopes and sizes were submitted based on this work. Some of the issues reference those Jira tickets below, but some may not be listed. There statuses at the time this was published are: 10 Triaged, 5 Published, 3 Applied, 2 Resolved/NoChange, 1 Resolved/Changed.
#1 Composite Reporting¶
Difficulty: Major | Resolution Status: GR IG Change
Description: Group multiple sections and associated results in one composite report.
Diagnostic labs frequently include several types of results in genetic test reports which then appear in separate sections within an overarching report. eMERGE genetic reports are examples of this model and include both gene panel interpretation as well as PGx results. This style of reporting is analogous to the notion of composite reporting whereby while individual sections of the report can be treated independently they are still combined together as they rely on shared findings from an upstream wet lab assay such as Whole Exome Sequencing or Gene Panels. We evaluated two options to represent composite reporting: 1. Nested Diagnostic Report Resources or 2. The Observation Grouper Profile. Based on analysis and collaborative discussions with the Genomics Reporting IG (STU1), we decided on the Grouper Profile.
Resolution: Use the Grouper Profile added to STU1 to group all related gene panel & PGx result resources, respectively.
HL7 CG WG & FHIR Suggestions: The resolution to use the Observation based Grouper Profile allows consuming EHR systems to utilize the Gene Panel & PGx results as separate components. Furthermore, while the usage of Grouper Profile is well-defined by the GR IG, the concept of nested Diagnostic Reports was still under investigation and not ready for adoption. The benefit of this approach also lends itself to including additional sections such as Polygenic Risk Scores to genetic reports and potentially other related report results that future composite reporting use cases may require. The Jira issue referenced below suggests that the HL7 FHIR designers consider how these more robust composite reporting use cases be handled.
Reference(s): Jira #19828 | Zulip CG: FHIR representation of a genetics test with multiple test…
#2 Nested Results¶
Difficulty: Major | Resolution Status: Clarification
Description: The eMERGE Diagnostic Report utilizes the Grouper resource to aggregate primary Observations (results) which in turn references other Observation results using either hasMember or derivedFrom. Without the reference to all Observations (results) directly in the Diagnostic Report, two related concerns are:
- Will consuming systems be impacted without a direct linkage of all results in the Diagnostic Report?
- Can the derivedFrom be used to reference a related value that is not directly a result for this Diagnostic Report?
Resolution: With the usage of the Grouper, hasMember and derivedFrom clearly documented, it was agreed that using nested Observation references streamlines the Diagnostic Report bundle. It was also agreed that derivedFrom could reference a related reference that is not a direct result for this Diagnostic Report.
Reference(s): Zulip CG: Indirect Results
#3 Test Information¶
Difficulty: Major | Resolution Status: Clarification
Description: Inclusion of Test Information, Methodology and References
Lab developed tests (LDTs) are standard practice in clinical genetic testing. As such it is useful and needed (for eMERGE) to share the assay title, code, description, methodology and references (citations) that appear in the report.
Resolution: The recommendation to use the PlanDefinition resource to represent the eMERGE test info and associated elements was satisfactory for the eMERGE use case.
HL7 O&O WG & FHIR Suggestion: More investigation for broader application across the domain could be useful. The assay definition, covered regions, methodology, etc… should be structured such that the elements can be reliably exchanged, accessed and used in relaying documentation, order guidance and computational queries for reporting and decision support.
Reference(s): Jira #19827 | Zulip CG: Report sections
#4 Interpretation Summary¶
Difficulty: Major | Resolution Status: Workaround
Description: Textual findings/interpretations are currently included in the eMERGE genetic report both at the report level and at the individual result (Observation) level.
Resolution: Without a option to include this kind of interpretative or summary text in the GenomicsReport or an Observation currently, an Interpretation Summary Text custom extension was created to house this information.
HL7 CG WG & FHIR Suggestions: Jira ticket request submitted and for consideration by both Clinical Genomics and Orders and Observations WGs. This is of fairly significant importance to the genetic testing community.
Reference(s): Jira #20978 | Zulip CG ?
#5 Gene/Region Coverage¶
Difficulty: Major | Resolution Status: Workaround
Description: For every test subject, information about coverage information on the regions studied as part of the eMERGE test panel is attached as part of the results. Generally information provided includes chromosome, gene, transcript, CDS, start position, end position and coverage. Though the Region Studied resource does seem like a possible candidate to represent this information, if we have to create a separate region studied resource for each of the regions that are in this test, that might run into 100s or 1000s of region studied resources and might not be a scalable solution. Ideally, it might be helpful to have a resource which we can use to include all the regions covered as part of the test.
Resolution: In the interim, for the current version of the eMERGE specification, we are attaching the coverage file (BED format) to the GenomicsReport as a RelatedArtifact.
HL7 CG WG & FHIR Suggestions: The current published solution associated with the Jira ticket #16258 does not seem to be a reasonable solution for large gene panels and a better solution should be considered.
Reference(s): Jira (Bob Dolin) #16258 | Zulip CG: Guidance re region studied
#6 Recommendations¶
Difficulty: Major | Resolution Status: Clarification
Description: eMERGE reports include a proposed recommendation section (see Example). We need to represent this accurately not only to enable actionability for the consuming EHR system but also to ensure that this is a requested proposed recommendation and not a resulting order.
Example: It is recommended that correlation of these findings with the clinical phenotype be performed. Genetic counseling for the patient and at-risk family members is recommended.
Resolution: Use the RecommendedTask extension in DiagnosticReport to reference a Task. The Task resource itself, with a status of requested and intent of proposal, fulfills eMERGE requirements for including proposed recommendations.
#7 Secondary Findings¶
*Difficulty: Major | Resolution Status: Clarification
Description: The Genomics Reporting IG (STU1) defines an abstract observation profile, GenomicsBase, that is the basis for all of their observations. GenomicsBase contains a SecondaryFinding extension which is used to indicate when a given observation is a secondary finding (SF). The eMERGE use case considered the need for easily identifying and segregating observations that are primary from secondary. Additionally, there are a number of different types of observations that are used in the eMERGE defined assay. Only Inherited Disease Pathogenicity observations may potentially be SFs since they represent the specific variant-disease findings that meet a given SF policy and is different than the primary indication for testing. The IG directs that the extension should only be used when the observation is a SF and the specific SF policy should be specified within the extension on each observation. eMERGE initially considered creating a simple custom boolean extension on the Inherited Disease Pathogenicity to indicate whether the interpretation was a SF or not and associating the SF policy with the assay methodology in the PlanDefinition.
Resolution: Use the CG IGs SecondaryFinding extension on the Inherited Disease Pathogenicity profile. The choice was made to use the CodeableConcept’s text field to indicate whether the inherited disease pathogenicity observation was a secondary finding or not.
Reference(s): Zulip CG: Representation of secondary findings
#8 Variant Data Types¶
Difficulty: Major | Resolution Status: Deferred
Description: The current flexibility in exchanging variant level information may be helpful in allowing adoption. However, implementers should be cautioned about the perils of using these forms of representation for clinical decision support (CDS). Clinical grade precision will require more rigor and guidance. Definitional variant data types and/or resources would help isolate the concern and advance progress towards that aim.
Resolution: For more information on Variant Representation see Variant Representation Discussion.
Reference(s): Zulip CG: Variant Data Type Proposal
#9 Report Comments¶
Difficulty: Minor | Resolution Status Clarification
Description: eMERGE and other clinical genetic test results have a comments or additional notes section with case specific information (see Example). These comments are not really recommendations, conclusions or observations. They are additional information that the reporting lab wants to provide the ordering physician and patient related to the overall outcomes or to a grouped set of results.
Example: Analysis of exonic deletions and duplications is pending and were not assessed at this time. The report will be updated if pathogenic or likely pathogenic deletions or duplications are detected in this patient’s sample.
Resolution: These comments are about the report itself or a section of the report and not a particular Observation. The O&O WG recommended using a dedicated Observation result associated to the DiagnosticReport to include the comments. This Observation is assigned the LOINC “Report Comment” 86467-8 code and with the comments being mapped to the value field.
HL7 O&O WG & FHIR Suggestions: Though sufficing for the short term, a more robust long term approach might be to evaluate the addition of a comments element to the Diagnostic Report Resource.
Reference(s): Jira #22830 | Zulip CG: Report Comments | Zulip OO: Notes on Observations
#10 Confirmation Testing¶
Difficulty: Major | Resolution Status: Workaround
Description: The eMERGE report includes information about confirmatory testing for both SNVs and CNVs.
Resolution: Though this request was deliberated and discussed by the Clinical Genomics WG, a resolution was not reached at the time of the creation of the eMERGE FHIR Specification. As a temporary solution, confirmation information has been added to the note element of the Inherited Disease Pathogenicity profile for the eMERGE FHIR Specification.
HL7 CG WG & FHIR Suggestions: The Jira ticket below is triaged and considered for future use. The idea of adding a confirmationMethod attribute to the Variant Profile to indicate when specific findings have been confirmed by an orthogonal method may be sufficient. This may also be something that could be added to the testing methodology or possibly as a separate report level observation that covers all findings in the report.
Reference(s): Jira #19829 | Zulip CG: Sanger confirmation testing
#11 Pathogenicity Phenotypes¶
Difficulty: Minor | Resolution Status: GR IG Change
Description: Inherited disease pathogenicity interpretations can sometimes require a condition componenent that is defined by multiple phenotypes.
Resolution: The cardinality of the associated-phenotype element in the Inherited Disease Pathogenicity profile was updated from 0..1 to 0..* per eMERGE request to accommodate the inclusion of possibly multiple phenotypes associated with a pathogenic/Likely Pathogenic variant.
Reference(s): Jira #20552
#12 Pathogenicity Values¶
Difficulty: Minor | Resolution Status: GR IG Change
Description: Terms such as risk factor or risk allele are being considered by the ACMG. Constraining the valueset binding for pathogenicity to not be extensible is not reasonable.
Resolution: Updated ValueSet bindings to extensible for the valueCodeableConcept element in the InheritedDiseasePathogenicity profile to accommodate additional entries from the Clinvar Clinical Significance list. Terms such as risk factor or risk allele are being considered by the ACMG
Note: the Clinical Genomics WG also updated other ValueSet bindings to be extensible.
Reference(s): Jira #20549
#13 Report Category¶
Difficulty: Minor | Resolution Status: GR IG Change
Description: Multiple report categories are needed to specify when a lab produces genetic test results report.
Resolution: The cardinality of the category element in the Genotype was updated from 0..1 to 0..* per eMERGE request to accommodate the inclusion of multiple test categories (LAB, GE) if required.
Reference(s): Jira #20538
#14 Assessed Med Citations¶
Difficulty: Major | Resolution Status: Workaround
Description: In the eMERGE PGx results the individual interpretations for each PGx diplotype found in the panel had one or more associated medications or assessed medications from the GR IG profile. Each assessed medication may also have one or more citations from the CPIC guidelines.
Resolution: The CG WG members suggested the use of the relatedArtifact at the top-level observation, however, some implications had different guidelines for each medication within the same observed medication implication. The eMERGE team determined the association of the CPIC guidelines was most appropriately associated within the assessed medication component. So a custom extension was added to the medication implication’s assessed medication component to add a 0..* related artifact whereby the guidelines associated to a given medication could be linked.
Reference(s): Zulip CG: relatedArtifact extension request
#15 Sign-Out v Sent Date¶
Difficulty: Minor | Resolution Status: Workaround
Description: eMERGE tracks both the report sign-out date and report sent date, which can differ. However, as the Diagnostic Report only records the report issued date, per Orders & Observations WG recommendations.
Resolution: eMERGE decided to use the report issued date in the Genomics Report Profile to include the sign-out date and to defer sending the report sent date, which represented the date the report was sent out to the ordering provider.
Reference(s): Zulip OO: date reported vs sign-off date
#16 Recommended Followup Reasons¶
Difficulty: Minor | Resolution Status: Workaround
Description: The cardinality for reasonReference element in the Task resource is 0..1 and should be modified to support multiple reasons if needed. This request will accommodate use cases where implementers might need to indicate that multiple Observations resulted in a particular Task Recommendation.
Resolution: Unresolved. Did not impact eMERGE’s use case.
HL7 CG WG & FHIR Suggestions: Only 1 code was needed for the eMERGE study. The Recommended followup profile has yet to be corrected to support multiple reason references post STU1.
Reference(s): Jira #25255 | Zulip CG: task recommendations
#17 Recommended Followup Codes¶
Difficulty: Minor | Resolution Status: GR IG Change
Description: The change request is to make the “code” binding extensible versus the current state of required. Currently, there are 3 codes available for recommended followup codes and it seems highly unlikely these will be robust enough to serve the implementations yet to occur. This is an enhancement requirement for the future and does not impact the current eMERGE FHIR Specification implementation.
Resolution: Only 1 code was needed for the eMERGE study. The Recommended followup profile appears to be corrected to support multiple codes post STU1.
Reference(s): Jira #25187 | Zulip CG: task recommendation follow up
#18 Disclaimers¶
Difficulty: Major | Resolution Status: Workaround
Description: Test disclaimers are a standard inclusion in every eMERGE report. The disclaimer is not case specific. There is no option to associate a Test Disclaimer on a Diagnostic Report or Genomic Report profile.
Resolution: Without an option to include the disclaimer in the GenomicsReport or an Observation currently, a TestDisclaimer custom extension was created to house the disclaimer and the disclaimer was added to the GenomicsReport Profile.
Reference(s): Zulip CG: performing lab disclaimers
#19 Patient Internal ID¶
Difficulty: Minor | Resolution Status: Clarification
Description/Resolution: eMERGE uses an internal patient identifier to identify a patient. An internal patient identifier is not a defined available identifier type for the Patient resource. However Patient internal identifier (code: PI) is available in the HL7 Version 2 Table 0203 but usage of the code PI from Table 0203 resulted in a validation warning during implementation.
Resolution: Based on the response (posted below) to the Jira ticket posted for this issue, it was decided to use Table 0203 and the code PI for the Patient internal identifier.
Jira ticket response: “The binding for this attribute is extensible so you are allowed to specify alternate codes if the value set does not cover your required concept. The warning that you are receiving is correct and can be ignored if you have specified a proper code for your purposes.”
Reference(s): Jira #24637
#20 Patient Age¶
Difficulty: Major | Resolution Status: Workaround
Description: The Patient resource currently only includes Date of Birth but not Age. As DOB is considered PHI, for de-identifying purposes we collect Age instead of (or in addition to) DOB as part of a test order to comply with CLIA regulations.
Resolution: eMERGE created a Patient.Age custom extension to handle this requirement.
HL7 PA WG & FHIR Suggestions: The Patient Administration Workgroup does not believe that a standard extension for Age for the Patient resource should be created.
Reference(s): Jira #24652
#21 Research Flag¶
Difficulty: Minor | Resolution Status: Deferred
Description: The BCM HGSC Clinical Lab produces both clinical and research genetic reports and we generally tag and label the reports as research or clinical. Typically, research reports are do not go through Sanger or similar confirmation process. It would be helpful to have a flag in the DiagnosticReport indicating if a report is clinical or research.
Resolution: Pending. This is an optional feature request and does not impact the current design of the eMERGE FHIR Specification. It is believed to be a useful addition to the FHIR DiagnosticReport to distinguish clinical from research study results.
Reference(s): Jira #22782
Discussion¶
The questions and issues raised and discussed during the development and implementation of this specification varied in scale in both importance as well as complexity. We have highlighted a few in this section; all our discussion has been captured on the Zulip emerge/genomics pilot stream.
Adoption and Direction¶
The principal goal of the eMERGE network for this project was to explore the feasibility of using FHIR in general and the Genomics Reporting IG in particular for representing clinical genomic results and for EHR Integration with Clinical Decision Support. Part of this feasibility analysis was also to explore the potential of using FHIR as the interoperability standard for the upcoming eMERGE Phase IV. To this end, the Baylor College of Medicine and Broad Institute team were tasked with putting together direction and adoptions recommendations for the eMERGE Network to evaluate going forward. As the roadmap and plans of the|hl7-cg-wg| regarding the Genomics Reporting IG would have somewhat of a direct bearing both on the goals of this project as well as a projected plan for future eMEREGE phases, the Baylor College of Medicine and Broad Institute team wanted to ensure that appropriate discussion with the HL7 Clinical Genomics WG was used to inform their decisions and recommendations.
With this in mind, the team highlighted the topic of Adoption Readiness and Direction during a presentation of eMERGE FHIR work to the HL7 Clinical Genomics WG in December 2019 with questions ranging across two categories. The first category, about the Genomics Reporting IG itself, included the following questions:
- What is the adoption readiness of the IG itself?
- Are there any plans to create targeted IGs to simplify adoption?
The second category, about the interest and keenness of the EHR vendors and Diagnostic Labs in this space, included the following questions:
- How are the major EHR vendors and Diagnostic Labs positioned with respect to considering the use of FHIR and in particular the Genomics Reporting IG as an interoperable standard for clinical genomic reporting?
- Are there any EHR vendors, Diagnostic Labs or Institutions working on or planning on adopt the Genomics Reporting IG (STU1) for a pilot or for full scale production?
Subsequent related discussions with the HL7 Clinical Genomics WG helped the team identify a few production pilots, in addition to the eMERGE pilot, that capitalized on the Genomics Reporting IG (STU1) -
- Creation of a HLA Reporting IG based on the Genomics Reporting IG (STU1) led by Bob Milius at the NMDP;
- A pilot project that utilizes the Genomics Reporting IG (STU1) led by Kevin Power at Cerner, in collaboration with a Diagnostic Laboratory;
- Representation of a VCF using FHIR led by Bob Dolin at Elimu Informatics;
- An oncology FHIR implementation led by Patrick Werner at MOLIT Institur gGMbH.
On the subject of adoption readiness, the HL7 Clinical Genomics WG recognizing the somewhat steep learning curve associated with using the Genomics Reporting IG (STU1), is currently eliciting input from Subject Matter Experts for STU2 themes, documented and discussed at Zulip Themes for STU2
The team, in light of the collaborations and discussions with the HL7 Clinical Genomics WG, experiences with the creation of eMERGE FHIR specification and the subsequent pilot, study of the ecosystem and landscape around this space, Additionally, the BCM/Broad team based on its work on creating the specification, implementing the pilot and collaborations/discussions with the Genomics Reporting IG (STU1), puts forth the following recommendations:
- The Genomics Reporting IG (STU1) specification can be utilized successfully, as proven by the eMERGE specification and the pilot, but cannot be readily and easily used by non-SMEs;
- The STU1 of the IG needs more maturity for full scale production implementations particularly in areas such definitional vs observations resources, management of secondary findings, interpretation summary text representation, knowledge bases of clearly findings/recommendations etc.;
- The current IG is broad and tries to cover multiple use cases and edge cases, targeting minimal viable products or headlining real-world usage scenarios might be helpful for widespread adoption;
- Considering the diversity and heterogeneity of the eMERGE Network, participation in STU2 themes and collaboration with HL7 Clinical Genomics WG during the upcoming eMERGE Phase iV will help inform the roadmap of the specification going forward.
Variant Representation¶
Community standards are required to define variants in a manner that will allow science and medicine to adopt and develop tools and procedures to track and attach information to variants at the scale demanded by genetic testing. Efforts to describe and identify variants to date include but are not limited to; Human Genome Variation Society (HGVS) nomenclature, International System for Human Cytogenetic Nomenclature (ISCN), and Variant Call File (VCF) formats. Public repositories and registries established by various authorities have evolved over the past decade or more to provide identifiers for variants in these systems (e.g. dbSNP, ClinVar, ClinGen Allele Registry, COSMIC, …). Without a common baseline set of data types and standards to support exchanging the breadth of sequence and structural variants in the genome and its derivative molecular products, genetic test results and generalized knowledge about variants will lack interoperability and continue to present barriers in complexity, cost and risk for use in clinical care and and scaling research and discovery.
The notion of a definitional or reference variant does not exist in FHIR or the Genomics Reporting IG. The Observation resource in FHIR is defined to exchange “Measurements and simple assertions made about a patient, device or other subject”[cite]. Without the existence of a single community standard model of data types for representing the breadth of variants required by genetic testing, FHIR and the Genomics Reporting IG (STU1) are unlikely to include the data types and resources needed to build these reference-able variants. The Genomics Reporting IG (STU1)’s proposed resolution to this complex challenge is to develop FHIR profiles based on the Observation resource. This approach begins to address the concern of separating the variant observation using the Variant or Genotype Profiles from the other assertion profiles, like disease causality or therapeutic implications of metabolism or efficacy, related to one or more of the observed variants. However, it does not provide a pragmatic computational standard for representing the variants referenced within those observed variants and associated assertions. The Genomics Reporting IG (STU1) Variant profile provides a large list of components that enable the flexibility of exchanging most of the popular nomenclatures, formats and variant identifier systems used in practice today along with a number of other annotations about the observed variant. While this seems to be a reasonable approach to enable innovators to structure data used in practice today, it may not convince early adopters to invest the engineering dollars if there is uncertainty in the clinical reliability, extensibility, complexity and basic capability of the use of this data for the rapidly growing requests for CDS and other downstream use of genetic test results.
If the data types and resources for defining a variant based on computationally reliable standards existed in FHIR and the Genomics Reporting IG, then reference variants could be built and used not only to help interpret genetic testing results but also be used in exchanging FHIR messages to and from knowledge bases to associate assertions about variants as well as allow registries and tools to interoperate with each other to support comparison and mappings to variants in alternative and emerging reference systems.
The eMERGE XML format that was used in phase III and preceded the creation of the eMERGE FHIR specification separated out the data structures needed for reference variants. The eMERGE XML used those reference variant structures to create the variant finding observations and to create the assertion (or lack thereof) of the variant in the interpretation context for testing (e.g. germline disease, somatic, pharmacogenomic) as a separate observation. Both case-specific findings and knowledge about variants are treated as statements. These two kinds of variant statements also contain additional qualifiers and context that allow the knowledge to be appropriately applied to the case findings and to allow the case findings to be appropriately used as evidence to further enrich and generate knowledge. These subject variants, whether simple SNPs or complex structural variants, should define the variant to the precision appropriate to the testing methodology (cytogenetic bands for a karyotype versus genomic coordinates for WGS) or essential to the knowledge produced by the domain experts. The data types or building blocks used to represent and exchange these variants should be interoperable to fulfill the growing demand and requirements for use in CDS and downstream use of genetic test results. The improved consistency, quality and simplicity should dramatically reduce the risk for adoption and remove key barriers for innovation.
While developing a standard model for variants and genomic features is a considerable challenge, it is paramount to successfully scaling the clinical use of genetic results. The Genomic Knowledge Standards (GKS) Workstream of the Global Alliance for Genomic Health (GA4GH) is committed to developing and expanding the Variation Representation Specification (VRS) to address the need for standards for computationally sharing variation. Instituting such a model in FHIR will significantly reduce the adoption risks caused by the complexity and unguided extensibility of the current Genomics Reporting IG (STU1) and FHIR specifications. As such, the growing collaboration between the Genomics Reporting IG (STU1) and the GA4GH GKS Workstream represents a promising step forward at introducing the concepts, resources and data types needed in the FHIR specification to improve the viability of implementing use cases related to variation in FHIR systems.
Gene / Region Coverage¶
Clinical genetic testing methodologies can vary greatly. As such, one important aspect that should be computationally shared with the results of the test is the gene and region coverage or simply region coverage. This Provides a quantitative representation of the precise molecular sequenced regions covered and the quality of coverage for each region. Perhaps more importantly, this clearly identifies what was not covered.
Clinical genetic tests are often designed to target specific regions of the genome. Even when whole genome or exome sequencing is performed there may be a predisposition for the assay to only analyze certain regions or genes related to the indication for testing. There’s also the chance that the outcome of running an assay on an individual sample may produce different actual coverage results than is expected or designed by the test. All of these factors play a role in raising the importance of being able to computationally represent the coverage regions with the results of a given assay. With both the clinically significant findings and the coverage region, receiving systems would be equipped to accurately determine whether a patient may need retesting or not, even though it may appear that they have been tested in the past for a given region of interest. Additionally, this information will be essential for clinical research and discovery at understanding patterns that are comparable across cohorts and studies.
Interpretation Summary Text¶
While structured and coded results are of great importance to the computational utility of results, text will always play a significant role in conveying information between humans. There are a number of text attributes available throughout the Genomics Reporting IG (STU1) profiled observation resources and their associated substructures. The genetics community and eMERGE require the ability to associate an interpretation summary with each reported clinically significant variant assessment. Additionally, there is a need to be able to provide interpretation text that summarizes the grouped observations. Using the grouper profile to organize subsections of results creates the need for an interpretation summary text attribute for these grouped results. It is our recommendation that the HL7 Clinical Genomics WG consider all of the important kinds of text fields needed to support clinical genetic test results and assure that there is a mechanism to do so, starting with an interpretation summary text field.
PGx Results Representation¶
The eMERGE PGx results make calls on the diplotypes, called star alleles, found in each relevant PGx gene that is covered by the PGx gene panel. These diplotypes are then used as a basis for relating PGx gene-drug knowledge implications. For eMERGE these PGx implications or PGx phenotype interpretations fell into three classes; metabolism, transporter, and efficacy. The eMERGE assay tested 7 PGx genes that contributed to 6 gene-drug phenotype implications.
The two key challenges to sharing PGx results are to provide a complete and accurate representation of the identified variants used to make the PGx gene diplotype calls. Efforts like PharmCat are defining named allele matching approaches that may help standardize this area. Regardless, the Genomics Reporting IG (STU1) or FHIR should provide a straightforward mechanism for defining the precise variants used to call the haplotypes and diplotypes and then provide the use of one or more of these diplotype assertions as subjects of the gene-drug phenotype result that is the intended output of the PGx gene panel service. This separation of concerns and design approach is further evidence supporting the need for variant data types as discussed in Variant Representation.