This implementation guide is not fully complete. Portions of the implementation guide are provided for "framework purposes only" - giving a sense of what additional topics are intended to be covered and where that content will fit. The work group has prioritized standardizing those portions of the specification with general applicability and related to sequencing. The work group will continue to flesh out additional sections for future ballot publications.

1.1 Scope

Genomics is a rapidly evolving area of healthcare that involves complex data structures. There is significant value in sharing this information in a way that is consistent, computable and that can accommodate ongoing evolution of medical science and practice. The value comes from the ability to easily sort, filter and perform decision support on such information and the resulting improvements in care and reduction in costs such as the elimination of redundant testing. The implementation guide is also paradigm-independent - the data structures presented here could be used in RESTful, messaging, document or other paradigms.

This guide covers all aspects of genetic reporting, including:

• Human and veterinary as well as bacterial and viral specimens
• Representation of simple discrete variants, structural variants including copy number variants, complex variants as well as gross variations such as extra or missing chromosomes
• Representation of both known/catalogued variants as well as fully describing non-catalogued variations
• Germline and somatic variations
• Relevance of identified variations from the perspective of disease pathology, pharmacogenomics, transplant suitability (e.g. HLA typing), etc.
• Full and partial DNA sequencing, including whole genome and exome studies
• Mosaicism (differing genetic characteristics for different specimens from the same subject)
• Mitochondrial DNA variations

At present, this implementation guide focuses solely on data structures - what data should be/might be present and how it should be organized. It does not address workflows around how reports are requested, created, approved, routed, delivered, amended, etc. The implementation guide is also paradigm-independent - the data structures presented here could be used in RESTful, messaging, documents or other mechanisms.

1.2 Guiding principles

This guide adheres to a set of design approaches:

• It is intended to be international in scope and only leverages terminologies which are freely available to all countries.
• It avoids pre-coordinating the type of variant, medication or other information into the Observation.code as this makes it easier to leverage industry standard terminologies for genetic information (e.g. HGVS) and avoids needing to duplicate this information into observation coding systems such as LOINC.
• It maximizes the use of resources that are in common use by laboratory reporting systems for other clinical areas - specifically Observation and DiagnosticReport. This eases implementation and also reduces the chance of data being lost by systems that might not have been designed to specifically accommodate genetic-related information.
• It minimizes the use of FHIR extensions, also with an objective of reducing the risk of data loss when information is passed to systems that might not explicitly support this implementation guide
• It uses separate observations for each independently useful assertion. This maximizes the discoverability and queriability of the data.
• It tries to ensure that data is captured in a manner that's consistent regardless of the type of testing that was done to ensure data can be consistently queried even if captured differently (e.g. variations identified in assay tests are reported in the same manner as those identified through direct sequencing)
• The guide allows for variability in the amount of discrete information captured. Systems are encouraged to populate what discrete elements they can and allows for the possibility of systems populating additional elements as their technical capability and/or time and other resources allow.
• Where possible the guide aligns with HL7's v2 Genetic Variation Model Implementation Guide and v2 Cytogenetic Model Implementation Guide to maximize consistency for those FHIR systems converting from or otherwise interoperating with v2 systems. (Note that there are some variations driven by the the differeing approach between FHIR and HL7 v2 as well as additional requirements analysis going into the FHIR implementation guide.)

Together, these principles should make adoption easier and allow systems to more easily adapt in a compatible way as genetic reporting continues to evolve.

1.3 Previous Specifications

FHIR STU3 included a set of profiles that provided guidance on how to convey genetic orders, results and observations. Those profiles are superceded by this implementation guide. Guidance for converting from these older profiles is found here.

1.4 Understanding FHIR

This implementation guide is based on the HL7 FHIR standard. It uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it's important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.

• FHIR overview
• Developer's introduction
• (or Clinical introduction)
• FHIR data types
• Using codes
• References between resources
• How to read resource & profile definitions
• Base resource

It's a good idea to also look at the Diagnostics Module and review the resources that are used as part of this implementation guide, especially Observation, DiagnosticReport and Sequence.

1.5 Content and organization

This implementation guide is organized into a set of sections. The first two sections are applicable to all types of genetic reporting. All implementers intending to do clinical genomic reporting should read 'Background' and 'General Genomic Reporting.'

The remaining sections provide support for more specialized types of reporting. They are optional. If your system is involved with genetic reports in a particular area, then read through that section of the implementation guide. However, there's no reason to read through sections that deal with reporting your system does not use.

The following table provides a list of the main sections in this guide and a summary of the content found in each:

Background	Background on genomic concepts represented within this guide. It's essential reading for those who may not have a deep knowledge of genetics, but it's recommended for all implementers as it provides definitions for terms as they are used in this implementation guide. In some cases, agreement on term defitions is not unanimous within the gentics community, so this IG's use of a term may differ from the meaning you may be used to.
General Genomic Reporting	Guidance and examples for the general structure of genomic reports, how to report overall interpretations and how to report genotypes, haplotypes and different types of variants. This content will be leveraged by all genomic reporting implementations.
Sequenced variants	Guidance on expressing information about variants gleaned from various sequencing approaches including direct sequencing, shotgun sequencing, array-based testing, etc.
Cytogenomic Reporting	Guidance on expressing information gathered by [[cytogenomic - link TBD]] testing techniques including FISH tests, chromosomal analysis, etc.
Pharmacogenomic Reporting	Additional guidance and examples related to genetic testing done for the purpose of assessing genetic variations' impact on the use of medications - both for oncology and for general patient treatment
Somatic Genomic Reporting	Additional guidance related to genetic testing done on somatic (non-germline) tissues, including assessments of tumors
Genomic Profiling for Transplantation	Additional guidance related to genetic testing done for transplant match assessments, including HLA typing
HL7 Domain Analysis Use Cases	Some use cases on FHIR design: Specimen Identification, Clinical Sequencing and so on
Appendix A: Relation to v2 reporting	Guidance on how the guidance in this implementation guide aligns with reports expressed using HL7 v2 and advice on how to convert between the v2 and FHIR representations
Appendix B: Clinical Genomics Apps	Introduction of the Clinical Genomics Applications(Genomics Advisor, etc) apply for this implementation guide
Appendix C: Domain Analysis Model	A domain analysis model for various use cases in clinical genomics with an emphasis on clinical sequencing

Are there other reporting areas we should also cover?

1.6 Credits

[Work group to decide what they'd like here]