This guide introduces Observation profiles to report results of tests that involve sequencing the DNA, RNA or amino acid chains of specimens. This includes direct sequencing, shotgun sequencing, array-based variant testing, and other mechanisms. See the scope and overview sections for more details.

Currently, there is one profile used to model most variant information: Variant. In future versions of this implementation guide, HL7 may subdivide Variant into multiple sub-profiles with more specific purpose.

Variant Profile Scope

The purpose of the Variant Observation profile is to capture genomic data elements fulfilling the following three purposes:

1. To define a variant of interest, which could be a simple, well understood change from a reference sequence, or one of several types of structural variations with uncertain endpoints.
2. To contextualize the observation of the defined variant (e.g., presence or absence in the sample and determinations of state or inheritance).
3. To terminologically annotate the variant according to the type or location of the change (generally optional, but needed to define certain types of structural variations).

It is NOT intended to support other Observations that are clinically relevant on their own and have separate profiles defined in this guide, including:

1. Statements of pathogenicity or of correlations with conditions or therapeutic interactions (see pharmacogenomics, somatic reporting, Therapeutic Implication, Diagnostic Implication, Molecular Consequence). Note that these statement observations will often use `Observation.derivedFrom` to point to one or more variants. This approach allows those statements to be reevaluated and updated or created downstream as the underlying knowledge bases and guidelines are updated.
2. Presence statements of whole haplotypes, genotypes, or phasing data (see Haplotype, Genotype, and Sequence Phase Relationship);

Defining Variants

This Implementation Guide supports two reporting patterns for defining variants:

1. By describing the change using HGVS or ISCN nomenclature. Example HGVS-styled variant.
2. By providing multiple component details similar to VCF columns. Example VCF-styled variant.

For each variant reporting pattern, different components MUST be used to properly define the variant where possible. Other components MAY be used to provide additional information for cross referencing external sources or increasing human readability of the instance.

Additional resources that implementers may want to leverage when reporting variant information include NCBI’s ClinVar, a freely accessible public archive of reports of the relationships among human variations and phenotypes, and NCBI’s Variation Services that relies on a common data model described as Sequence Position Deletion Insertion (SPDI).

Variants Defined by a Nomenclature Statement

This pattern describes the observed nucleotide sequence or configuration using HGVS or ISCN statement strings. Care should be taken to follow nomenclature guidelines and properly distinguish variants with the degree of precision needed for clinical use. Note that synonyms may arise within these nomenclatures so downstream validation and normalization may be required.

{
"system" : "http://varnomen.hgvs.org", 
"code" : "NM_022787.3:c.769G>A"
}          

{
"system" : "https://iscn.karger.com", 
"code" : "46,XX,t(9;22)(q34;q4)"
}          

Variants defined by multiple components (VCF-like)

This representation leverages multiple component slices to communicate an allele within the context of a specific location on a reference sequence. It is the most accurate definitional representation in FHIR, but is limited to variations with known breakpoints, and alleles should be normalized per VCF specifications. Note that VCF representations often specify genome build and chromosome identifiers rather than explicit reference sequences. Build and chromosome identifier may optionally be included for cross reference.

{
"system" : "http://www.ncbi.nlm.nih.gov/refseq",
"code" : "NC_000010.10"
}          

{
"system" : "http://www.ncbi.nlm.nih.gov/refseq",
"code" : "NM_000044.3"
}          

{
"system" : "http://loinc.org",
"code" : "LA30102-0",
"display" : "1-based character counting"
}          

{
  "valueRange" : {
    "low" : {
      "value" : 96527334
    }
  }
}          

Defining Repeat Expansion Variants

When reporting a repeat expansion variant (also known as trinucleotide repeat or tandem repeat), additional details are required to fully define the variant. Implementers should use as many of the elements in the section above (VCF-like) to describe the location of the repeat expansion, then use both the components from this section to state the observed repeat expansion. If the change is described as multiple contiguous repeat expansions, the extension in this section can be used to link the component pairs as in this example.

{
"valueString" : "GGC"
}          

{
  "valueQuantity" : {
    "value" : 11
  }
}          

{
  "extension" : [{
    "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/repeat-motif-order",
    "valuePositiveInt" : 1
  }]
}          

Variant Assessment

Data producers SHALL include an assessment for each variant that is shared. This assessment indicates if the defined variant is present in the sample or not, or if there was an issue in calling the variant. It is structured in Observation.valueCodeableConcept, and is bound to the answer list LL1917-2 Variant Assess.

See below for additional guidance on each answer from this value set.

These variant assessments are supplemented by other indicators of the analysis like quality and coverage. These other indicators include:

        {
        "system": "http://hl7.org/fhir/uv/genomics-reporting/CodeSystem/variant-confidence-status-cs",
        "code" : "high",
        "display" : "High"
        }
        

Contextualizing Variants

Clinical context for observing the variant are often important in understanding the variant. Often, multiple tests are done to determine the values for these elements.

Note that many other properties associated with contextualizing the observed variant are stored in other FHIR resources. For example, ethnicity/race/biological sex are on the Patient resource (referenced by Observation.subject) and the tissue/tumor type are on Observation.specimen.

{ 
"system" : "http://loinc.org",
"code" : "LA9633-4",
"display" : "Present"
}
          

{ 
"system" : "http://loinc.org",
"code" : "LA26398-0",
"display" : "Sequencing"
}
          

{ 
"valueQuantity" : {
   "value" : 120,
   "unit" : "reads per base pair",
   "system" : "http://unitsofmeasure.org",
   "code" : "[1]"
 }
}
          

{ 
"system" : "http://loinc.org",
"code" : "LA6705-3",
"display" : "homozygous"
}
          

{ 
"system" : "http://loinc.org",
"code" : "LA6684-0",
"display" : "Somatic"
}
          

Annotating Variants

This implementation guide defines several components on Variant that can be used to provide helpful cross references and low-level annotations - annotations completely determined by the molecular change and calculable for example by NCBI.

{ 
"system": "http://www.ncbi.nlm.nih.gov/clinvar", 
"code":"619728", 
"display" : "NC_000019.8:g.1171707G>A"
}
          

{ 
"system": "http://www.genenames.org",
"code" : "HGNC:644",
"display" : "AR"
}
          

{
"system" : "http://www.sequenceontology.org",
"code" : "SO:1000002",
"display" : "substitution"
}          

{
"system": "http://varnomen.hgvs.org",
"code" : "NP_006209.2:p.(His1047Arg)",
"display" : "p.H1047R"
}          

Representing Structural Variants

The Variant profile is capable of representing a subset of structural variants (e.g. copy number variants), whereas more complex structural variants such as translocations will require additional model development. We provide guidance here on how the Variant profile can be used to communicate common structural variants. (The cytogenomic-nomenclature component can also be used to communicate more complex structural variants, in ISCN notation).

While sources vary in how they differentiate simple vs. structural variants, here we differentiate based on end point precision and by variant length. All variants with imprecise end points are treated as structural variants. Variant length is more arbitrary - consider for example, a precisely located deletion of one base pair, of one thousand base pairs, of one hundred thousand base pairs. As variant length increases, it can become onerous to include REF and ALT alleles. Therefore, where end points of a variant are precisely known, users can decide whether to represent the variant as a simple or a structural variant, although a variant length of 50 bases is often used as a cutoff.

Suggested minimal representations of common structural variants are shown in the table. Data originating from NGS or DNA Chip testing will (and data originating from FISH testing will not) generally be amenable to these recommendations. HGVS representations, and any other components in the Variant profile not mentioned, can also be communicated where appropriate.

Notes

• While a DEL is conceptually the same as a CNV with decreased copy number, and a DUP is conceptually the same as a CNV with increased copy number, in practice, different variant callers will call different structural variant types. For instance, DEL and DUP claims are generally made by breakpoint-based callers (e.g. Delly) whereas CNV claims are generally made by abundance-based callers (e.g. CNVnator). Furthermore, breakpoint-based callers generally report allelic state and/or allelic frequency whereas abundance-based callers generally report copy number.
• All structural variant positions are represented with outer-start-end and inner-start-end components, and not exact-start-end.

Examples

• Germline CNV
• Germline DEL
• Germline INV
• Somatic CNV
• Somatic DEL
• Somatic INV

Representing compound heterozygotes

Compound heterozygosity is the presence of two different heterozygous mutations in a gene, one on each chromosome of a pair.

While a single HGVS expression within a single Variant observation can be used to represent a compound heterozygous state (e.g. ‘LRG_199t1:c.[2376G>C];[3103del]’), we recommend that compound heterozygotes be represented using two Variant observations, each showing one of the heterozygous variants.

The special case where the two different variants are at the same base pair location can also be represented by two Variant observations. For example:

• Variant Observation 1
• allelic-state: heterozygous
• ref-allele: G
• alt-allele: A
• exact-start-end: 1234567
• Variant Observation 2
• allelic-state: heterozygous
• ref-allele: G
• alt-allele: C
• exact-start-end: 1234567

It is important to note in this example that the Variant observation indicates the presence or absence of a variant with the given ALT allele, and does not indicate presence of the REF allele on the other chromosome of the pair. Even though it is almost always the case for heterozygous variants that one chromosome has the variant and the other chromosome has the reference allele, one should not assume this is the case from a single heterozygous Variant without separate knowledge that no other variants were detected at that position.

If there is a need to be explicit about both alleles at a given location, one can use the Genotype observation profile. Here is a bundle showing a compound heterozygous example with two Variant instances grouped together by one Genotype instance.

Additional variant attributes

If implementers have additional variant annotations, the Variant profile is defined to allow flexibility. See the section on flexibility for additional guidance, especially the guidance for the Open Slicing allowed on Observation.component.

Higher-Level Variant Categorization

It can be beneficial to provide a higher-level categorization of a variant. For instance, the LOINC Variant category offers 'simple' or 'structural' codes. While the component coding-change-type (LOINC 48019-4) provides a coarse description of the change, an implementer could also include a higher-level code as an additional coding. Other codes may be included as long as they adhere to the rules for additional coding described here.

This is an example of the coding-change-type component showing threee entries:

• Code from the ValueSet in the binding (from SequenceOntology)
• Code from the Variant Category ValueSet (from LOINC)
• Code from a lab defined ValueSet

  "valueCodeableConcept": {
    "coding": [
      {
        "system" : "http://www.sequenceontology.org",
        "code" : "SO:0000694",
        "display" : "SNP"
      },
      {
        "system" : "http://loinc.org",
        "code" : "LA26801-3",
        "display" : "Simple variant"
      },
      {
        "system" : "http://example.org/labX-variant-category",
        "code" : "substitution",
        "display" : "Substitution"
      }
    ]
  }

Moreover, the Molecular Consequence profile includes a component feature-consequence, which categorizes the structural implications of a variant. The codes in the ValueSet could be used, and a higher-level concept could be included as well.