Driver Project (or other organization)

Respondent

Use cases/user stories for interoperability of pedigree data

Are there systems that you currently need to exchange pedigree data between, and being able to point to a GA4GH standard would help? From where, to where, for what?

Use cases/user stories for computation on pedigree data

Are there computations that you need to make from the pedigree model, or operations you need to perform on the pedigree representation? For example, we could implement these functions in a GA4GH software library.

Requirements beyond PED

What data elements, relationship representations, or  do your use cases require that are not already supported by PED

Any other notes/context

For example, any information which helps us understand the technical environment e.g. EMR connections, data collection tools, etc

AGHA

Respondent

Zornitza Stark

zornitza.stark@vcgs.org.au

User Story/Use Case

Diagnostic genomic testing across a range of rare disease groups, with de-identified data from unsolved patients progressing into discovery research (data from solved cases also stored in research environment). Majority of testing undertaken as singletons, <5% as trios, other family configurations extremely rare (parent/child duo, sib pair, half-sib pair, quad). Pedigree information required to inform clinical and research genomic data analysis.

Required Data Elements

1. Biological relationships between individuals tested (if more than one family member tested). These would almost exclusively be first-degree relatives.

2. Information on whether any relatives are similarly affected. Again, this would be first-degree relatives most of the time, except for rare cases of XLR inheritance, where the family member may be more distant, eg maternal uncle.

3. Information on parental consanguinity, although of course parental relatedness is usually obvious from the genomic data.

4. Alive/deceased status, and distinguishing fetuses from liveborn individuals. Can assist with conveying severity/penetrance information (clinician to lab) and providing appropriate advice regarding segregation testing (lab to clinician).

What would happen if the GA4GH did not develop anything in this area?

Technical Environment Information

Any technical information which helps us understand the technical environment e.g. EMR connections, data collection tools, etc

Data collection tools: pen/paper; PhenoTips; Cyrillic and possibly other tools used by individual services; however AGHA data management platform (REDCap) only supports scanned pdf at present. We are developing a plug-in for an electronic pedigree drawing tool.

Universal FHH in clinical/research processes - using family health history (FHH) as an indication for genetic testing, or for genetic analysis post-sequencing

Respondent

Grant Wood

Grant.Wood@imail.org

User Story/Use Case

1. FHH risk assessment can be used as an indication for genetic testing or analysis across many diseases or differential diagnoses. The use case here is breast/ovarian cancer.
2. As part of standard patient intake information, visit to mammography center, patient concern about an affected or at risk relative, patient participation in research study or clinical trial, a comprehensive FHH is collected.
3. The computerized FHH application supports the creation of a pedigree, with disease, and disease age of onset and death, in a coded format. Optimally, the application is a shared record by all members of the pedigree.
4. Validated and published algorithms for breast/ovarian cancer risk are performed. If a high risk is determined, a consult with a genetic counselor is held, with genetic testing or sequence analysis performed.
5. The combination of pathogenic variants and FHH guide the clinician on decisions for patient management supported by clinical decision support systems.
6. Both FHH and variant analysis results are stored in a coded format in the patient electronic health record, and available to all clinical providers of the patient.

Required Data Elements

The Core Family Health History Data Set published here. The HL7 FHIR FamilyMemberHistory resource and profile for FamilyMemberHistory-Genetics.

What would happen if the GA4GH did not develop anything in this area?

GA4GH should support pilots were participants share FHH data using HL7 FHIR Pedigree standard. Without data interoperability, FHH will have to be collected multiple times for each use, which is not efficient.

Technical Environment Information

The infrastructure to support advanced FHH functionality should include a data repository outside of any single EHR, and a FHH system that is a shared record for all family members. Both the clinical and patient-facing applications must follow published standards for minimum data elements collected, and standards for the sharing of complete FHH’s between systems, including the patient’s EHR. Guided by patient consent, the data should be combined with clinical and genetic data for clinical decision support, and research discovery.

Universal FHH in clinical/research processes - using FHH, genotype, and phenotype results of a patient or relative, to determine if the patient needs further testing or sequence analysis, and/or if a relative needs the same, which is called cascade testing.

Respondent

Grant Wood

Grant.Wood@imail.org

User Story/Use Case

1. Using cancer as a use case, cascade testing begins when a person is diagnosed with a familial cancer predisposition syndrome or a cancer that is likely to have been caused by an inherited mutation.
2. A FHH is collected and analyzed in combination with a hereditary cancer gene panel.
3. The results of the analysis may indicate further testing with parents and children.
4. The analysis may further indicate testing relatives such as aunts, uncles and cousins in a stepwise, cascade fashion, until all at-risk relatives have been screened to determine if they do or do not carry an inherited cancer-risk mutation.
5. Family members who have not been diagnosed with cancer, but who are found to carry an inherited cancer risk mutation, can be offered close monitoring, including screening tests at an earlier age than would be recommended for someone at average risk.
6. This process could help researchers gather more familial data, and discover new biomarkers and understand new gene regulatory networks.

Required Data Elements

As listed in the previous use case, the Core Family Health History Data Set, the FHIR FamilyMemberHistory for Genetics profile, FHIR Genomics profiles for results of hereditary testing, and phenotypic (clinical) data.

What would happen if the GA4GH did not develop anything in this area?

Using FHH to guide cascade testing will help driver projects gather and analyze critical data that previously was not part of the study plan.

Technical Environment Information

The infrastructure to support advanced FHH functionality should include a data repository outside of any single EHR, and a FHH system that is a shared record for all family members. Both the clinical and patient-facing applications must follow published standards for minimum data elements collected, and standards for the sharing of complete FHH’s between systems, including the patient’s EHR. Guided by patient consent, the data should be combined with clinical and genetic data for clinical decision support, and research discovery.

Universal FHH in clinical/research processes - tracking in pedigrees inherited genetic disorders, such as both autosomal recessive and dominant, codominant, x-linked, and mitochondrial

Respondent

Grant Wood

Grant.Wood@imail.org

User Story/Use Case

1. This use case will review the autosomal codominant disorder called Alpha-1 antitrypsin deficiency (AAD).
2. A FHH is collected using a future computer application that offers the following functionality.
3. Within the FHH application, the user starts with a full pedigree view, then selects an overlay option to track and analyze risk for Alpha-1 on the pedigree. The app will track the normal and two pathogenic alleles in the SERPINA1 gene that lead to reduced levels of alpha-1 antitrypsin.
4. If the proband or a relative has been tested for AAD, and the allele is known, the allele is recorded on the pedigree for the affected person.
5. The application can then calculate, both up and down the pedigree, the percentage risk that an untested relative might be a carrier, or might have the disease causative alleles.
6. The future FHH application has functionality to share the pedigree with all relatives, and allows the user to alert pedigree members who may want to be tested because of a high percentage of affection.
7. As more relatives are tested, the pedigree is updated, and more accurate percentages are calculated.
8. Either a pre-test percentage or actual test result is stored in the patient EHR. General practice, pulmonologist, and hepatologist clinicians are notified based on result levels.

Required Data Elements

AAD alleles, the Core Family Health History Data Set, the FHIR FamilyMemberHistory for Genetics profile, FHIR Genomics profiles for results of carrier testing.

What would happen if the GA4GH did not develop anything in this area?

This use case does not currently have fully functioning tools to support it. However, if implemented, undiagnosed high-risk individuals can be identified, get tested, and get early treatment if affected.

Technical Environment Information

The infrastructure to support advanced FHH functionality should include a data repository outside of any single EHR, and a FHH system that is a shared record for all family members. Both the clinical and patient-facing applications must follow published standards for minimum data elements collected, and standards for the sharing of complete FHH’s between systems, including the patient’s EHR. Guided by patient consent, the data should be combined with clinical and genetic data for clinical decision support, and research discovery.

Genomics England: Diagnostic

Respondent

Richard Scott

User Story/Use Case

Pedigree data from where, to where, for what?

From where?

• Our clinical data input systems (called our ‘Test Order Management System’ - TOMS).
• Currently, this has a web-based user interface that collects clinical data on sequenced individuals and how they’re related to each other, generates a pedigree from that and has a Phenotips-based tool that allows you to add further pedigree data
• In time, requesters will link to this using local systems via APIs/messaging.

NOTE: we collect a unique pedigree for each test order as different amounts of data may be relevant/considered proportionate to share in different clinical settings

To where?

• Our bioinformatics systems. And from there on to

• our diagnostic lab users
• our research users

• Our research environment - see separate submission. Note: this is in addition to the availability in the research environment of pedigree data in

For what?

• To unambiguously document relationships between sequenced individuals to drive our rare disease bioinformatics systems

• joint calling of variants, and
• filtering of variants based on segregation

• To describe wider family history (re: non-sequenced individuals). This is not currently used by our bioinformatics systems but is used to support laboratory interpretation of genomic variants and support research

We are using the same / a very similar approach in our new diagnostic systems as we used in the 100,000 Genomes Project. Our families are most commonly singletons or trios but we a requirement is to be able to analyse other family structures, sometimes quite extended.

A key feature of our design is that we have a pedigree for each test request so that the same person can be included in multiple test requests e.g. once as the mother of a child with intellectual disability and again as a singleton with cystic kidney disease

Required Data Elements

• Unambiguous representation of relationships
• Consanguinity
• Twin zygosity
• Adopted status
• Separated
• Alive/Deceased/Miscarried etc
• Disease status (for that request)
• Other clinical data is captured using the same formats as we use elsewhere in our clinical data systems
• Compliance with expectations on recording gender (as opposed to sex) according to patients wishes in their notes - exact implications of legistation in the UK still being worked through

We do not currently accommodate mitochondrial donation or other ‘exotic’ family structures. While this would be beneficial, it’s currently considered acceptable that our systems don’t accommodate them because our stream are mainly for ‘mainstream’ diagnostics

What would happen if the GA4GH did not develop anything in this area?

Technical Environment Information

Any technical information which helps us understand the technical environment e.g. EMR connections, data collection tools, etc

See first box

Genomics England: Research Environment

Respondent

James Holman

User Story/Use Case

Pedigree data from where, to where, for what?

From where?

• Our clinical data input systems (called our ‘Test Order Management System’ - TOMS).
• Currently, this has a web-based user interface that collects clinical data on sequenced individuals and how they’re related to each other, generates a pedigree from that and has a Phenotips-based tool that allows you to add further pedigree data
• In time, requesters will link to this using local systems via APIs/messaging.

To where?

• Our Research Environment where the pedigree data will be stored within our clinical data platform and represented in both OMOP and FHIR resources.

For what?

• To unambiguously document relationships between sequenced individuals to drive our rare disease bioinformatics systems^[a][b]

• joint calling of variants, and
• filtering of variants based on segregation

• To describe wider family history (re: non-sequenced individuals). This is not currently used by our bioinformatics systems but is used to support laboratory interpretation of genomic variants and support research
• To support the following types of research analyses.

1. I want to identify the number of subjects with a specified condition with a set of phenotypic characteristics so I can analyse their sequences.  This is about broadening a cohort's definition to capture all the affected people.
2. I want to identify the number of subjects in a family with an affected proband that are unaffected so I can analyse their sequences.  Identified unaffected subjects +/- within the families of the affected subjects. Identify all subjects with sequences.
3. I want to identify families and relationships between family members for a given disease.  Genomic Analysis amongst family members. unambiguous relationships encoded in the pedigree data sets is not lost. It’s vital to genomic interpretation. This is carried in the pedigree id; pedigree member id; mother id; father id fields. The ‘relationship to proband’ data very quickly becomes ambiguous e.g. if a proband has two uncles and a cousin on the same side of the family, which one of the uncles is that cousin the child of etc. The pedigree id; pedigree member id; mother id; father id fields can always hold the data unambiguously and are the standard expected in genomic analysis.
4. I want to identify newborns with disease A, mutation in Gene X, their family history and phenotypes.   Newborns with XXX have a very rare mutation in the gene GENE-A. I am curious if GEL might have seen any such mutations. We would like a disease report for XXX to include: Participants recruited as DIS-A patients, Participants with phenotypic annotation of DIS-A at enrolment, and descendants. Participants with HES record of DIS-A. We would like the overlap between recruited disease, phenotype and HES.
5. This is again a combination of clinical and genomic variation data, together with some family data.

Required Data Elements

• Registered disease type and disease subtype
• ICD10 HES APC, OP, ED primary diagnosis
• HPO terms
• Family relationships, history
• Genomic sequence data-Whole Genome Sequencing (WGS

What would happen if the GA4GH did not develop anything in this area?

Federated analysis would be hindered.

Technical Environment Information

Any technical information which helps us understand the technical environment e.g. EMR connections, data collection tools, etc

• Will be stored within our clinical data platform and represented in both OMOP and FHIR resources.
• Used in the genomics analytics platform (eg https://hail.is/docs/0.2/genetics/index.html)

Kids First Data Resource Center (DRC)

Respondent

Allison Heath

heathap@email.chop.edu

User Story/Use Case

Each year, the Gabriella Miller Kids First Program selects pediatric cohorts representing a wide variety of pediatric cancer and structure birth defects via a X01 mechanism for whole genome sequencing. The DRC is responsible for collecting and making available both the genomic and associated clinical data. Many of these studies are trio or family based design and the pedigree and associated family history are important for the mandate of the program to understand the underlying genetic etiology of these diseases.

Pedigree data from where?

The DRC currently receives this information in a wide variety of formats, from collection in systems like REDCap, PhenoDB, Phenotips and Progeny to ad-hoc spreadsheets or even scanned images. While most of the studies are trio design, the multi-generational family ones with complex structures can often be critical to research and discovery.

To where?

Currently the DRC has a lightweight data service that stores this information in a database, but to support richer clinical data we are currently working towards modeling and persisting data aligned with FHIR. So having the pedigree data available in a similar manner would be optimal.

• Store biologically related members in a grouping which we call family
• Store every relationship between two participants in another table

For what?

Genomic Processing

• The Bioinformatics team uses a script to generate a PED file from the /families, /family-relationships endpoints in the Kids First Data Service.
• This is used in genotype refinement, which requires this information for phasing and de novo annotation.
• Also used in joint variant calling for families

DRC Portal

For the DRC portal, we currently aggregate the family information into a search field containing the values like “trio”, “trio+”, “duo”, “duo+”, “proband-only” and “other”, having a human understandable vocabulary like this would be useful for users looking across multiple data resources. In the portal we are also planning to display family pedigrees and we need a representation that makes it easy to programmatically such visualizations.

Lastly, but perhaps most importantly, we can’t predict all of the secondary uses of this information and so having it in a programmatic standard that people can consume across a number of resources in both a format for analysis as well as for building algorithms and tools over would be of high utility.

Current Issues

Data Errors

• Lot of human errors in the PED files

• Wrong sex - someone listed in paternal ID column but in other clinical data their sex is female
• Wrong relationship - someone listed as child of parents in PED file but actually not related to the parents
• Wrong family - relationships contradict the family IDs assigned to each related person

• Bioinformatics team uses individual VCFs and pedigree data in Data Service to identify errors in sex and pedigree

Data Service → Poorman’s Pedigree Service

• Family relationship table should only record parent/child/sibling/relative. It should automatically determine other human friendly relationship labels (mother, father, daughter, son, etc) OR don’t use these labels at all
• Biological groups (families) should be automatically generated from the family relationships → recursively search all linked people and form a group.
• Recursive searching is hard right now because data is stored in a relational database → should probably be stored separately in a graph DB.
• Due to the simplistic nature of the Data Service, a participant is only part of 1 family
• Doesn’t capture sibling relationships like twins, triplets, etc.

Required Data Elements

The representation should be able to support unambiguous genetic relationships. Each individual in the pedigree can have a number of attributes attached to them (which may be open or controlled access). When exact relationship status isn’t known “summary” pedigree features like consanguinity and general disease/outcome/risk history are useful to have.

We currently see phenotype and disease status most heavily used, but really any clinical feature should be able to be linked/used in the context of a pedigree. A nice to have would be, when known, ability to distinguish between clinical features observed/reported directly of/by the patient versus them describing a family history.

What would happen if the GA4GH did not develop anything in this area?

Likely what always happens when there’s a vacuum. We need practical but programmatic representations for the reasons above, so we’d come up with a reasonable representation focused our use cases (and would probably see others doing something similar). Hopefully, we could align and communicate with others with similar needs and keep our eye out for opportunities to reuse other solutions, but it’s unlikely to end up being the best state for meeting the mandate of accelerated research for these diseases.

Technical Environment Information

Any technical information which helps us understand the technical environment e.g. EMR connections, data collection tools, etc

Collection tools are really driven by the study investigators, as described above. Further down our roadmap includes looking at more automated ways to extract from EMRs and patient reported outcomes, thus part of the interest in FHIR. We are making the data available via web APIs (REST and GraphQL) and are interested in making it more readily available in cloud based workspaces hosting Jupyter Notebooks and RStudio as well as for other application developers.

BRCA Challenge

Respondent

Amanda Spurdle

User Story/Use Case

Rationale

Primarily - using Bayes analysis for assessing variant (or haplotype) causality against expected disease penetrance for that gene-disease relationship, and considering background population risk of relevant cancers. Note most “mendelian” cancer syndromes involve multiple cancer types, each with a different “expected” penetrance

Secondarily (more as a research exercise, but also used for variant interpretation) - conducting modified segregation analysis to assess disease penetrance for a given variant (or haplotype) as a proportion of expected penetrance for that gene-disease relationship.

From where - information may be provided by

Clinicians

Commercial and non-commercial Diagnostic test providers

Research organizations, generally with database facilities for storing pedigrees in structured format

For what - see rationale above

Presently this analysis is done in a research environment (ENIGMA) since that permits sharing of more sensitive information, and only the final Bayes Scores are shared for the purpose of variant interpretation. Some clinical sites will allow sharing of pedigree information for the purpose of analysis, but will not permit long-term storage of pedigree information in an off-site database (Netherlands, Spain have cited local ethical requirements as a barrier to such long-term storage).

Approach

• Identify variant/haplotype for which clinical significance is to be assessed. The variant

may be considered uncertain significance, conflicting significance (across multiple submitters), or questions may have been raised in relation to “non-typical” penetrance profile eg reduced penetrance overall, penetrance differs for one cancer type over another.

• Review all information available pertinent to classification, including pedigree information
• Call for all additional clinical/functional information, including pedigree information
• Review pedigrees and check for potential overlap using “shared” features. Within a research environment this could be date of birth, gender and cancer type/s. More generally (in a clinical environment) due to ethical concerns only Year of Birth is shared.
• Re-contact submitters with potentially overlapping pedigrees to confer (in a clinical environment, where names etc may be shared) and provide information necessary to merge pedigrees. Pedigrees may overlap between different states in a country, or across countries (neighbouring, emigration etc)

• Also check pedigrees for potential overlap with published information (generally via email to corresponding author)
• Where necessary also confirm additional details/updates for published pedigrees, irrespective of potential overlap.
• Conduct statistical analysis of independent pedigrees, assess potential heterogeneity across pedigrees, and combine scores.
• Return combined results, and also individual pedigree scores to data providers. If relevant, highlight potential errors underlying heterogeneity. At this point can also highlight individuals for which additional genotype information would be particularly informative for variant interpretation (triggering reanalysis).
• Reassess variant interpretation using combined pedigree AND other information. Generally only the combined pedigree Bayes score, with individual pedigree Bayes components, is made public. (Pedigree structure is sometimes made public via publication, and this depends on the requirements of Journal and data submitters combined).

• Other considerations. Tumour pathology (subtype, hormone receptor status) is another feature used in variant interpretation, and is requested alongside pedigree information as an additional data type to facilitate variant interpretation. Also see required data elements below.

Required Data Elements

See link to sheet (would be much easier if i could just paste it in here!)

https://docs.google.com/spreadsheets/d/1deqKeyqMPdCvD1ARJTjBut580v2Y68rVVFDBB2J5wBA/edit?usp=sharing

What would happen if the GA4GH did not develop anything in this area?

The main thing would be to try to promote standardised collection in a way that permitted container analysis offsite. Would get past some of the issues of pedigree storage etc etc

Technical Environment Information

Any technical information which helps us understand the technical environment e.g. EMR connections, data collection tools, etc

We use a variety of pedigree collection programs - we take what we can get from emails, hand-drawn pedigrees, to output from progeny or other pedigree drawing programs. Ability to collect information or encourage collection using freeware would be good/ Options include Boadicea or a tool that Bing Feng has developed that falls under his overarching tool VICTOR.

TrakGene Pty Ltd

Respondent

Kathryn Van Diemen

Use cases/user story

We are coming at this from a slightly different angle, as TrakGene provide a software tool and we are not directly custodians or collectors or analysers of the data itself.  However, we do have 15 years of direct experience with 500+ users from clinical genetics services around the world!  

Ubiquitous requests/requirements from these Clinical Geneticists and Genetic Counsellors are to;

1. Utilise pedigree and individual data from the TrakGene database to query unlimited risk assessment tools
2. Quickly and easily contribute pedigree and individual data to research databases and projects for eligible patients
3. Exchange pedigree data with other services when shared families are known

While these tasks can be achieved at the present time, it is often a manual process which is painstakingly time consuming.  The richness and quality of data in any one system is often hindered as users will opt to only enter data where it is perceived to be most useful.  Or alternatively, clinicians spend their precious time “doctoring” their existing data into a form that may be accepted by other system/project.

A pedigree standard (adopted by all!) would obviously go a long way towards allowing the automation, or at the least streamlining of many of these processes.

Required Data Elements

In our experience the majority of genetics services will;  

• Document the pedigree exactly as reported by patient
• Wish to openly view and use the pedigree in their session with the patient and family
• Record social relationships as essential elements of the pedigree; adoptions, multiple spouses, consanguinity, twin zyogosity, same-sex relationships, represent transgender individuals etc.
• Produce pedigrees of 3-4 generations, with 50-100 family members not uncommon, and many examples with 300-400 family members.

Tricky pedigree scenarios not previously mentioned in other use cases;

• Loops (not necessarily consanguineous) or cross-references, eg

1. Multiple sibling – sibling partnerships (3 brothers marry 3 sisters)  
2. Donor gametes come from related person (Woman donates egg for her sister’s IVF pregnancy)

What would happen if the GA4GH did not develop anything in this area?

Geneticists and Genetic Counsellors and their support staff continue to spend valuable time “doctoring” their clinically relevant pedigree in the pursuit of further information and better outcomes for their patients.  

Worst case scenario is that the effort required to prepare their data becomes a barrier or blocker to the pursuit of further info or contribution to research.

Technical Environment Information

TrakGene implements a native pedigree drawing tool.  The principles of standardised pedigree nomenclature from Bennett et al 2008 are applied in the representation of the pedigree. At this time no external standard (such as PED) is used for the storage or export of the pedigree data.