A Recommendation for The Common Data Set for Family Health History
GA4GH Clin/Pheno Pedigree Subgroup - DRAFT
The collection and use of family health histories span modalities from genetic research to heritable risk assessment in patient care. For every participant in this process, the goal should be collecting and storing accurate and coded data that is qualified for analysis and easily transferable between systems. To achieve this, a globally accepted and universally implemented common data set for family health history should be established.
The purpose of this document is to create the initial version of a common data set that can be used in both research and clinical settings, with the intent to eliminate the gap between the two disciplines. This recommendation should also guide the development of research, clinical, and patient-facing family history data and information collection tools, applications, and data repositories. This document should only be used as informative, as companion implementation guides will be published subsequently.
The GA4GH conceptual model for family health history (FHH) introduced here includes our best attempt at alignment with existing standards PED and FHIR Family member history for genetics analysis. The idea is to provide a path forward from current limitations in FHH collection and use to a common data set with more robust possibilities.
Background
This work was inspired by the efforts of the Personalized Health Care Workgroup of the American Health Information Community, which first released its recommendation on a core FHH minimum data set on October 25, 2007. A peer-reviewed paper was published in December 2008.
One of our design goals was that the common data set support the GA4GH use cases submitted here - with the ability of future support as new use cases emerged. Many GA4GH driver projects and other interested parties in GA4GH expressed interest in a pedigree standard that supported these wide-ranging applications. These stakeholders, and many others in the healthcare industry, wanted to see more streamlined and easily implemented approaches to improved data collection, analysis, and data sharing. They need better tools, like the ability to change the pedigree focus and proband within the same data set. The problem is that data collection processes today produce limited and insufficient data that is locked in data silos. By building more comprehensive FHH data sets, stakeholders will advance their capabilities in new knowledge generation.
The recommendation in this document does not suggest specifications for a technical standard. The companion work on a data model will be done separately (see the Pedigree Conceptual Model paragraph after the data element tables), and appear in the previously mentioned implementation guides. Comments and feedback on all aspects of this work will be accepted from any source, while further standards balloting may be completed with the HL7 Clinical Genomics work group.
Goals for the Common Data Set
The operative purpose of a common data set is to standardize methods for FHH data collection, but also allow for other specialized data elements to be collected based on the use case. With the construction of a pedigree being the first step, we recommend that pedigrees support 1st-degree relatives (i.e., parents, siblings, children) and 2nd-degree (i.e., grandparents, aunts/uncles, nieces/nephews, half-siblings), with 3rd-degree (i.e., cousins) a stretch goal. Besides the first goal of this recommendation to support building a substantive pedigree, we also hope to promote the collection of both biological and non-biological family members, and the ability for proband change and re-analysis.
Most of the common data set elements describe the health and clinical histories of each pedigree member. This is to support the many purposes of a FHH - to determine heritable risk, for clinical diagnosis, for clinical genetic/genomic test guidance and interpretation, and for research and public health applications. We view this as highly valuable data, and may be required to apply algorithms for risk assessment. It should be noted that the historical FHH data may change over time, with both corrections and with new health episodes.
Coming with the adoption of the common data set, we see the emergence of a FHH ecosystem. With real data interoperability, easy data sharing, and with privacy maintained, benefits will come to all participants. Such an ecosystem will support the wide range of FHH apps - from clinic-based, to research, to patient and family created, and for lab results and direct-to-consumer services. A diagram to illustrate below how data may be collected, stored, and accessed in a FHH ecosystem is found at the Global Genomic Medicine Collaborative website.
Using this Recommendation document, we encourage all interested stakeholders to build tools based on the common data set. Whether using the tools internally, or wanting to exchange FHH data with another system, consider piloting the new tools with GA4GH as a partner. Contact Lindsay Smith at Lindsay.Smith@ga4gh.org.
Long-term goals
As we build a common framework of standards and harmonized approaches for FHH data sharing, we hope to see the community of GA4GH - including healthcare, research, patient advocacy, life science, and information technology - expand their collection, study, use, and especially sharing, of FHH information. At the same time we also hope that all organizations, projects, and products that are interested in advancing FHH, implement, test, and promote the Common Data Set for Family Health History.
Further versions of this effort may include the addition of genetic variant data and risk analysis information as part of the data set. This will lead to the development of more advanced FHH risk algorithms and clinical decision support. A shareable repository of these algorithms should be established. We see these components leading to when machine learning and AI tools are applied to FHH and genomics.
The International Standards Organization (ISO) has recently created the ISO/TS 82304-2 standard that specifies requirements for health apps, and defines a health app quality label in order to quickly determine the quality of each app. We see another goal of all FHH apps using the common data set to achieve the higher quality label scores.
And finally, we see this document as ‘living’, and plan to maintain and update it as we receive use cases, implementation experience, and other evidence to do so.
Data element tables
The data element tables on the following pages are divided into 1) the data elements that describe the pedigree record as a whole, 2) the data elements that define the relationships between members of the pedigree, and 3) the data elements that add health history detail to each individual in the pedigree. As a reference to existing formats, the data elements are mapped to both the PED file format and the HL7 FHIR Family member history for genetic analysis profile. The Notes column includes more information about the use of the data element. The text in red is to highlight where gaps or remaining questions still exist.
Where there is “NA” in the table, it means that there is no property in the model to represent that field. In the case of FHIR Genetic Pedigree, it may be possible to represent those fields via extensions.
The required (R) elements are sorted at the top of each table. These data elements are necessary to build the structure of the pedigree or family tree. This could be as small as a trio. The optional (O) elements then continue the recommended common data set for those applications, databases, and implementations which seek to be a more complete risk assessment tool. Where appropriate and available, we list important terminologies and answer lists for data elements that require them.
Appendix sections
Additional information supporting the common data set appears in the Appendix sections. In these sections we cover the methods used in developing this document, the differing systems used to collect FHH data, and a longer discussion on Race, Ethnicity, and Ancestry (REA) issues (see Appendix A).
We also list other data elements to consider that are outside of a common data set, such as data sharing status and consent status, along with looking forward to capturing genetic observations and pedigree analysis results are included (see Appendix B). We then highlight how the GA4GH Phenopacket Schema also includes family health history data (see Appendix C). And finally, we show the three FHIR model diagrams to highlight their differences (see Appendix D).
Data Elements: Pedigree
Element Name | Required / Optional | Card. | PED | GA4GH Phenopackets | FHIR (Genetic Pedigree) | FHIR (GA4GH) | Notes |
Family ID (Pedigree ID) | R | 1 | Col. 1 Family ID | Family.id Also org.ga4gh.pedigree.v1.Pedigree.id | NA | NA | In PED this is used when distinct family records are defined then shared. Also can be thought of as the Pedigree ID. There is no field to represent a family in any of the FHIR representations. In the GA4GH IG, the composition that represents the pedigree can have an identifier. However, if sending a pedigree per family the representation becomes convoluted (i.e., a bundle of bundles). The families can be derived from the graph so this attribute is redundant. The IG does not specify how to represent multiple families in a pedigree. |
Patient ID (proband) | O | 0..* | Family.proband.subject.id Also org.ga4gh.pedigree.v1.Pedigree.indexPatients | FamilyMemberHistory.patient.identifier No way to represent. | Composition.subject (consultand) Composition.section:proband.entry (proband) No way to represent First Tested Positive. | This is a repeating field. Only required when the pedigree is used to focus on heritable risk for a specific person in the pedigree. For other use cases such as research, a Proband type may be needed. Types may include Proband, Consultant and First Tested Positive. It would be preferable to have a proper Pedigree resource in FHIR that could include a list of proband references and types. | |
Pedigree Source metadata | O | Family.meta_data | FamilyMemberHistory. Meta Or FamilyMemberHistory. reasonCode | NA | Possible uses are, but not limited to, where did the pedigree come from, tool or method used, clinical or patient entered, research identifier. | ||
Status | O | Available through org.ga4gh.pedigree.v1.Pedigree.status | FamilyMemberHistory. status | NA | From FamilyHistoryStatus choices are: partial, completed, entered-in-error, and health-unknown. | ||
Language | O | NA | FamilyMemberHistory. language | NA | The codes SHOULD be taken from Common Languages. | ||
Narrative | O | Available through org.ga4gh.pedigree.v1.Pedigree.narrative | FamilyMemberHistory. text | NA | A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. Resource definitions may define what content should be represented in the narrative to ensure clinical safety. | ||
Date of FHH data collection | O | 0..1 | Family.meta_data.created Also org.ga4gh.pedigree.v1.Pedigree.date | FamilyMemberHistory. date | Composition.date | Date should be the latest date of when any data is updated. In the FHIR Genetic Pedigree profile, the date does not exist at the pedigree level because there is no pedigree resource. Therefore, there will be a date per FamilyMemberHistory resource. |
Data Elements: Relationship
Element Name | Required / Optional | Card. | PED | GA4GH Phenopackets | FHIR (Genetic Pedigree) | FHIR (GA4GH) | Notes |
Individual | R | 1 | NA | org.ga4gh.pedigree.v1.Relationship.individual ID | FamilyMemberHistory.patient | FamilyMemberHistory.patient | The pedigree model in FHIR is not a graph and therefore no resource is used to represent a relationship. The Genetic Pedigree allows linking FamilyMemberHistory resources but it doesn’t use a resource to represent relationships either. The GA4GH IG uses the FamilyMemberHistory resource to represent relationships between individuals. |
Relationship | R | 1 | NA | org.ga4gh.pedigree.v1.Relationship.relation | FamilyMemberHistory.relationship or FamilyMemberHistory.family-member-history-genetics-parent or FamilyMemberHistory.family-member-history-genetics-sibling | FamilyMemberHistory.relationship | For the Pedigree conceptual model, GA4GH has created KIN, a new family relations ontology. KIN includes consanguineous relationship types. Also see HL7 v3 Value Set FamilyMember and CodeSystem: RoleCode. |
Relative | R | 1 | NA | org.ga4gh.pedigree.v1.Relationship.relative ID | FamilyMemberHistory | FamilyMemberHistory.familymemberhistory-patient-record | In both FHIR and the Genetic Pedigree, the FamilyMemberHistory resource represents both the relationship and the information about the individual (i.e., there will only be a single Patient resource to represent the proband). In the GA4GH IG individuals are represented using Patient resources and the relationships between them using FamilyMemberHistory resources. |
Data Elements: Individual
Element Name | Required / Optional | Card. | PED | GA4GH Phenopackets | FHIR (Genetic Pedigree) | FHIR (GA4GH) | Notes |
Individual ID | R | 1 | Col. 2 Individual ID | Person.individual_id | Patient.id FamilyMemberHistory .id | Patient.id | An ‘Individual type’ (not type of ID) may be needed. This could include the individual’s electronic medical record identifier, genealogical record identifier, could be the person is only represented via their lab sample identifier, or person information is missing or unknown (just have a relationship), or person information is private/hidden based on a consent choice, or the same individual and/or Individual ID is found in other pedigrees. |
Father ID | R | Col. 3 Paternal ID | Person.paternal_id | FamilyMemberHistory. extension:Parent | Must be an Individual ID | ||
Mother ID | R | Col. 4 Maternal ID | Person.maternal_id | FamilyMemberHistory. extension:Parent | Must be an Individual ID | ||
Administrative Gender | AdministrativeGender or FamilyMemberHistory. sex | See AdministrativeGender and Patient Gender and Sex. The gender that the patient is considered to have for administration and record keeping purposes. Systems should not infer any specific clinical meaning without pre-coordination with exchange partners | |||||
Biological Phenotypic or Karyotypic Sex | R | Col. 5 Sex | Phenopacket.subject.sex Person.sex | Supported through Observations | Clinical Observations about sex characteristics (from HL7 FHIR) - a testable observation about a biological property of the patient. This could include karyotypic/ genetic/chromosomal sex, gonadal sex, ductal sex, hormone levels, or various other phenotypic attributes, etc. Clinical observations about sex characteristics should be represented using Observation, qualified with the appropriate clinical codes from LOINC and/or SNOMED. These observations may serve as supporting information for the Sex for Clinical Use categorization | ||
Gender | O | Phenopacket.subject.gender | Patient.gender Only available for the proband. | Patient.gender | The gender might not match the biological sex as determined by genetics, but the individual's preferred identification. | ||
Name | O | Phenopacket is not identifiable | FamilyMemberHistory. name | Patient.name | Datatype in Patient is HumanName and includes Given name, and subsequent Given names for middle names. In FamilyMemberHistory this is just a string. | ||
Date of Birth | O | Phenopacket.subject.date_of_birth | FamilyMemberHistory. Born[x] Patient.birthDate | Patient.birthDate | In most cases the DOB can be just the birth year. If not known, age or age range is recommended. | ||
Age | O | Phenopacket.subject.time_at_last_encounter.age | FamilyMemberHistory. age[x] | NA | System should alert about age when the pedigree is over a year old. | ||
Estimated age | O | Not supported | FamilyMemberHistory. estimatedAge | NA | If true, indicates that the age value specified above is an estimated value. Clinicians often prefer to specify an estimated age rather than an age range. boolean | ||
Age range | O | Phenopacket.subject.time_at_last_encounter.age_range | FamilyMemberHistory. age[x] | NA | Represented as two elements of lower age range and upper age range. | ||
Deceased | O | Phenopacket.subject.vital_status.status | FamilyMemberHistory. deceased[x] | Patient.deceased[x] Patient.patient-unborn | Deceased flag or the actual or approximate age of the relative at the time of death. | ||
Disease or Condition | O | Phenopacket.phenotypic_features.type.label | FamilyMemberHistory. condition | Condition (not in the scope of the IG) | PED only supports a single disease. | ||
Disease or Condition Affected | O | Col. 6 Affected status | Phenopacket.phenotypic_features.excluded | NA | Observation (Affected Status) | When using PED, a single disease is the focus for all in the pedigree. PED tags people as affected or unaffected for that single disease. | |
Disease or Condition Code | O | Phenopacket.phenotypic_features.type.id Phenopacket.diseases.term.id | FamilyMemberHistory. condition.code | Condition.code (not in the scope of the IG) | |||
Disease or Condition Age of Onset | O | Phenopacket.phenotypic_features.onset Phenopacket.diseases.onset | FamilyMemberHistory. condition.onset[x] | Condition.onset[x] (not in the scope of the IG) | |||
Disease or Condition Contributed to Death | O | Phenopacket.subject.vital_status.cause_of_death | FamilyMemberHistory. condition.contributedToDeath | “Contributed to Death” could be represented in the Condition resource with the condition-outcome extension. (not in the scope of the IG) | |||
Race, Ethnicity, or Ancestry (REA) | O | NA | NA | NA | Several REA ontologies exist, each designed with a specific need and philosophy. Data collection tools should allow for multiple values. Many sites will be bound by local requirements. (See more on this topic in A.3 below.) The Human Ancestry Ontology (HANCESTRO) provides a systematic description of the ancestry concepts used in the NHGRI-EBI Catalog of published genome-wide association studies. The ClinGen Ancestry & Diversity Working Group is developing standards and guidelines for clinical genetics about the interpretation, collection, and use of REA. In the GA4GH IG, an extension on Patient would be required. | ||
Multiple birth status | O | NA (KIN includes relationships that indicate a multiple birth, when using the Phenopacket GA4GH Pedigree implementation) | NA | Patient.multipleBirth[x] | The KIN ontology also includes relationships that indicate a multiple birth. | ||
Adoptive status | O | NA (KIN includes relationships that indicate adoptive status, when using the Phenopacket GA4GH Pedigree implementation.) | NA | KIN includes relationships that indicate adoptive status. | |||
Observation including genetic markers | O | Phenopacket.medical_actions Phenopacket.measurements Phenopacket.interpretations | (not in the scope of the IG) | Allows capturing risk-relevant observations about the relative that aren't themselves a specific health condition; e.g. Certain ethnic ancestries that are disease-relevant, presence of particular genetic markers, etc See “Adding genetic observations” in B.4 below. |
The Pedigree Conceptual Model
To support the interoperability of this family health history data set, we developed the GA4GH pedigree conceptual model. This model defines core classes for Pedigree, Individual, and Relationship data that are interoperable with other standards, including HL7 FHIR (implementation guide) and GA4GH Phenopackets (currently defined on a branch). Relationships between individuals are standardized using concepts from the newly developed Kinship Ontology. To allow existing workflows and tools to gracefully add interoperability with this standard, we developed an open-source pedigree data interoperability library, pedigree-tools.
APPENDIX A: Additional Information on Minimum Dataset Data Elements
A.1. Methods used creating this document
To get started, representatives from several of the GA4GH Driver Projects submitted FHH use cases that describe how FHH data is collected and used within their activity. For data interoperability, they shared what systems need to exchange pedigree data, and how a GA4GH standard would help. They described what computations they need to make from the pedigree model, or operations they need to perform on the pedigree representation. We also captured from them what data elements, relationship representations, or other requirements they need that are not supported by PED. And finally, we asked about any information which helps us understand their technical environment e.g. EMR connections, data collection tools, etc.
A table of data elements for a recommended FHH common core data set was created and based initially on the original data set published in 2007 (as mentioned previously). The GA4GH Pedigree subgroup then updated the data set to match what is currently used in PED, note what is supported by HL7 FHIR FamilyMemberHistory profiles, and highlight gaps and other issues. A data modeling process based on the common data set was completed to confirm how the data should be represented in an interoperable data message.
A.2. Capturing the data elements
Multiple formats and methods exist for the capturing of these data elements. Each has their strengths and specific design purposes. If a form, survey, or questionnaire is used, the HL7 FHIR Structured Data Capture (SDC) project offers an implementation guide around the use of questionnaires and data elements to standardize the capture of information via user-facing forms. Chatbot technology has been applied to the questionnaire format to guide people in gathering a complete history. Other data capture methods may include the graphical creation of a pedigree. These tools follow the genealogical method of building a family tree, but then add medical histories for each family member on that tree. The Pedigree Standardization Work Group (PSWG) of the National Society of Genetic Counselors (NSGC) developed a system for a clinical pedigree nomenclature. The pedigree drawing symbols they use are incorporated into their professional training.
The different formats and methods available are to support the creator of the family health history record. These creators include patients and family members with self-reported information, to genetic counselors, to clinical health providers putting data into an electronic medical record, to self-reported data that is validated by the EMR, and to the genomics researcher and clinical trial. All of these creators and their use cases must be supported, so that family health history data can be technically interoperable between all compliant systems.
A.3. Issues on collecting Race, Ethnicity, or Ancestry
We cannot make a recommendation on how to use Race, Ethnicity, or Ancestry at this time. After speaking with several organizations and experts on this question, we learned there exists differing needs and use cases that have resulted in multiple REA ontologies. At least one ontology uses an ethnicity-language combination in identifying ethnolinguistic tribal affiliation. Identification codes for the various ontologies should be created. Another helpful FHIR resource could be Extension.extension:Source, which could capture in what way the ancestry was reported (e.g. Patient reported, Genetic test/markers, Other, Unknown).
A recent paper published in The American Journal of Human Genetics titled Clinical genetics lacks standard definitions and protocols for the collection and use of diversity measures states ”... there was no consensus on the relevance of REA, including how each of these measures should be used in different scenarios and what information they can convey in the context of human genetics. A lack of common definitions and applications of REA across the precision medicine pipeline may contribute to inconsistencies in data collection, missing or inaccurate classifications, and misleading or inconclusive results.”
Many in the research world use gnomAD and ancestry informative markers (AIM) to infer ancestry. The Genome Aggregation Database (gnomAD) Consortium sponsored by the publication Nature, and the Broad Institute gnomAD browser includes exomes and genomes from European, Latino African and African American, South Asian, East Asian, Ashkenazi Jewish and other populations. They assigned ancestry to all samples for which the probability of that ancestry is > 90% according to the random forest model. All other samples were assigned the other ancestry (oth).
Concerning the use of AIM, according to the National Human Genome Research Institute “Ancestry informative markers refers to locations in the genome that have varied sequences at that location and the relative abundance of those markers differs based on the continent from which individuals can trace their ancestry. So by using a series of these ancestry informative markers, sometimes 20 or 30 or more, and genotyping an individual you can determine from the frequency of those markers where their great, great, great, great ancestors may have come from. These are generally resolved to the three major continents: Africa, Asia, and Europe.”
Also see -
- US Federal Drug Administration (FDA, contains nonbinding recommendations) Collection of Race and Ethnicity Data in Clinical Trials
- US Centers For Disease Control and Prevention (CDC) Race Category Value Set
- US Core Implementation Guide (v3.1.1: STU 3) based on FHIR Release 4 Detailed Race Value Set and Race & Ethnicity - CDC (mostly a list of countries and hundreds of US native indian tribes)
A.4. Biological (Phenotypic) Sex and Person Gender
For more information on this topic, see the Context Definitions in HL7’s Gender Harmony Project. The site explains that “It is expected that these context of use will be an attempt to represent single or combinations of things such as chromosomal allosomes, genotype, hormone levels, secondary sex characteristics, desired perception, surgical status or planned outcome, organ function, etc.” This is a work in progress.
APPENDIX B: Other Data Elements to Consider
These data elements are not part of the common data set recommendation, but could be very helpful in specific use cases.
B.1. Interoperability capability of the captured pedigree
- Data sharing status (needs a FHIR extension) - interoperability characteristics with other systems.
- Consent.status (FHIR) - may be required in some use cases, especially if names and DOB’s are shared.
- Resource Permission (FHIR) - Permission.status and Permission.purpose
- As an example of value sets, the following is from FamilyHistoryAbsentReason (FHIR) -
Code | Display | Definition |
Subject Unknown | Patient does not know the subject, e.g. the biological parent of an adopted patient. | |
Information Withheld | The patient withheld or refused to share the information. | |
Unable To Obtain | Information cannot be obtained; e.g. unconscious patient. | |
Deferred | Patient does not have the information now, but can provide the information at a later date. |
B.2. Post-coordination of data elements
- Representation of marital or partner status and other relationship qualities (e.g., estranged, close, household member)
- Extension.extension:Source (FHIR) - In what way the disease, condition, race, ethnicity, ancestry is reported (e.g. Patient reported, Genetic test, EMR record, Public records like death certificate or disease registries, Clinical trial or research, Other, Unknown)
- A ‘Severity’ option for diseases and conditions
- FamilyMemberHistory.condition.outcome (FHIR) - Indicates what happened following the condition. If the condition resulted in death, the deceased date is captured on the family member
- An ‘Unknown’ and level of ‘Certainty’ option for data elements that are not certain
- A ‘Sensitivity’ field and management options of the sensitive issue
B.3. Use case specific data elements
- Fetus as an Individual type
- Donor conceived person (egg, sperm, embryo)
- Gestational carrier
- Age of last follow-up - important to track disease progression in a research use case
- Non-diagnosed health status
- Non-genetic laboratory results
- Relevant environmental/social data
- Prophylactic surgery date/type - important for censoring age for pedigree analysis in the cancer space where prophylactic surgery is recommended management for people at risk e.g. mastectomy, oophorectomy, hysterectomy
- Presymptomatic screening initiation date/type, important also for establishing a censoring age for colon cancer in particular, and suspicious polyps are removed during colonoscopy
B.4. Adding genetic observations
One may choose from a long list of coded information, from variants to findings, in the HL7 Genomics Reporting Implementation Guide (STU1). The guide is officially labeled as “not fully complete” and only for trial use, but it is very robust and ready for piloting.
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. | |
Guidance on expressing information about variants gleaned from various sequencing approaches including direct sequencing, shotgun sequencing, array-based testing, etc. | |
Additional guidance and examples related to genomic testing done for the purpose of assessing genomic variations' implication on the use of medications - both for oncology and for general patient treatment | |
Additional guidance related to genomic testing done on somatic (non-germline) tissues, including assessments of tumors |
B.5. Adding analysis results
PedigreeAnalysisResults is a class that represents the results of analysis done to the data captured in the family history pedigree. Originally from the HL7 V3 Family History/Pedigree Implementation Guide, these data elements could be retrofitted to be included in pedigree data sharing which contains advanced risk assessment. A FHIR profile for PedigreeAnalysisResults would need to be developed.
PedigreeAnalysisResults contains several options to represent the actual results:
- AnalysisResult - This class is a catcher for any analysis that cannot be represented through the other classes in this choice box.
- Probability - The value holds a probability of having what is represented in the PedigreeAnalysisResults.code attribute (e.g., disease, variation). The code attribute holds a value that indicates that this is a probability observation.
- PercentageRisk - The value holds a percentage risk of having what is represented in the PedigreeAnalysisResults.code attribute (e.g., disease, variation). The code attribute holds a value that indicates that this is a percentage risk observation.
- Relative Risk - The value holds a relative risk of having what is represented in the PedigreeAnalysisResults.code attribute (e.g., disease, variation). The code attribute holds a value that indicates that this is a relative risk observation.
- Polygenic Risk Score - The value is calculated from genetic observations in B.4 (Variant Reporting - single nucleotide polymorphisms) and can be integrated into disease risk as part of a cosegregation analysis, penetrance estimation, and risk assessment.
- code: identifies the disease or variation for which the probabilities/risks/etc. are calculated. Note that this class can be populated as many times as needed, for each clinical condition which is the is the focus of the risk calculations
- negationInd: can be used to represent the fact that there is no risk found for this family history and the clinical condition in the code attribute
- methodCode: holds the type of the algorithm used to analyze the pedigree (e.g., BRCAPRO)
Lifestyle and environmental risk scores could also be considered.
APPENDIX C: Supplemental Information
C.1. Family History in GA4GH Phenopackets
The Phenopacket Schema represents an open standard for sharing disease and phenotype information to improve our ability to understand, diagnose, and treat both rare and common diseases. The Phenopackets Pedigree element represents a PED file, which describes the family relationships of each specimen along with their gender and phenotype. PED files are typically used by software for genetic linkage analysis. A pedigree node extends the FamilyMemberHistory-Genetic profile.
https://phenopacket-schema.readthedocs.io/en/2.0.0/family.htmlhttps://phenopacket-schema.readthedocs.io/en/2.0.0/pedigree.html#rstpedigree
The Phenopacket schema repository also includes a GA4GH Pedigree implementation based on the Pedigree model, however it replaces the Individual class with a full Phenopacket. Currently, it is in beta form here: https://github.com/phenopackets/phenopacket-schema/blob/pedigree/src/main/proto/ga4gh/pedigree/v1/pedigree.proto but will be published once the Pedigree model is finalized.
C.2. External Family Health History Efforts
Global Genomic Medicine Collaborative (G2MC) website on Family Health History - By better understanding the needs in each individual country, the FHH project aims to promote the benefits of family health history for patient self-knowledge, family sharing, public screening, pre-screening for genetic testing in a clinical setting, and research.
The Office of the National Coordinator for Health Information Technology (ONC) - Representing Family Health History for Clinical Genomics
GA4GH Family History Tool Inventory is a catalog of family history tools currently available for documenting family health history information.
APPENDIX D: FHIR Models
This appendix highlights the differences in the FHIR models available to represent pedigrees using a simple example.
D.1. Plain FHIR
The plain FHIR model is patient centric and is not a graph model. The FamilyMemberHistory resource is used to capture information about the patient’s family members. The relationship attribute represents the relationship between the patient and the family member. Typically, only the patient is represented using a Patient resource, which is connected to all the FamilyMemberHistory resources. There is an official extension that allows connecting a FamilyMemberHistory resource to a Patient resource, but none of the examples in the FHIR specification make use of it.
D.2. FHIR Genetic Pedigree
The FHIR Genetic Pedigree extensions introduce additional relationships between FamilyMemberHistory resources. This means that an additional FamilyMemberHistory resource needs to be introduced to represent the proband, with a relationship type of ONESELF. The relationships between FamilyMemberHistory resources also contain a type. Despite these additions, this model is still patient centric. All the FamilyMemberHistory resources still need to point at the proband.
D.3. GA4GH Pedigree Implementation Guide
The implementation guide developed as part of this project makes use of the official extension that allows connecting a FamilyMemberHistory resource to a Patient resource, so the FamilyMemberHistory resource can be used as a relationship in a graph. The model requires nodes to be Patient resources and also disallows storing any patient information in the FamilyMemberHistory resource to avoid duplication. Also, a Composition resource is used to represent the entire pedigree.
