ARCHIVED

GA4GH Variation Annotation:
Minutes and Actions 2021-2023

These are the minutes for the GA4GH Genomic Knowledge Standards - Variant Annotation Work Stream. For further information, please visit the GA4GH Work Stream page (will link to the page on the website when it is ready) at ga4gh.org.

2017-2018 Minutes

2019-2020 Minutes

Table of Contents:

2017-2018 Minutes

2019-2020 Minutes

Meeting Protocols

Sub-Group Minutes and Actions Documents

List of Meetings

2023-01-10

2022-12-14

2022-10-05

2022-02-16

2022-05-18

2022-02-02

2022-01-19

1. ClinGen/ClinVar and VICC implementation  [see ‘Structuring Semantics of ‘Certainty’ in SEPIO Statements’ section of document here]

2021-10-06

I. Upcoming Phases of Work / Timeline

II. Organizational and Operational Redesign

2021-06-02

Topics/Minutes:

2021-04-30

Minutes:

2021-04-28

Minutes:

2021-03-10

2021-02-24

2021-02-17

2021-02-10

2021-02-03

2021-01-13:

2021-01-06:

2021-##-##: TEMPLATE

Meeting Protocols

• Please note that by participating in meetings, attendees agree to adhere to the GA4GH Standards of Professional Conduct.
• Meetings may be recorded for note-taking purposes. Recordings will be deleted within three months of the meeting taking place.

Sub-Group Minutes and Actions Documents

List of Meetings

2023-01-10

Goal: reconnect after holiday break, and set stage for work to come

Proposed Topics:

1. GKS repo organization follow up

1. recap outcomes from last call
2. close the loop on open issues regarding maturity models, repo organization, etc.
3. set next steps to push ahead here . . .

2. VA Framework level-setting

1. a short high-level presentation of latest thinking about VA Framework and development approach . . .to get us all back on the same page

3. Triage model alignment issues 

1. list existing misalignments between the Core IM and metakc-cvc (see below)

4. prioritize those rising to the level of "full disagreement"m
5. VA development processes:

1. Consider formal processes through which the Core IM, Starter Profiles, and Implementation models might be developed in the short term, and how they will be coordinated and documented, and how a final ‘standard’ will emerge from these efforts

6. Misc Issues/tickets (that can help me progress on spec docs):

1. Naming conventions for multivalued attributes https://github.com/ga4gh/va-spec/issues/97 

2022-12-14

Attendees:

Topics:

See also notes here: https://docs.google.com/document/d/1kTDIdutsKXt6AfJYiyVZaUt4TKQlGkEmjMAPxM6XFHI/edit#heading=h.3dxj50gz87fd 

1. Close the loop on any open technical/organizational issues re: maturity models, repo organization, etc from the Connect meeting - and next steps to push ahead here . . .

2. List existing misalignments between the Core IM and metakc-cvc, prioritize those rising to the level of "full disagreement", and make a plan for when/how we will address these efficiently in early 2023.

1. Align high level class structure across specifications / repos.

1. https://github.com/ga4gh/gks-metaschema/issues/11
2. related issues/dependencies:

1. metaschema repo #6, #7, #8, #9 . . . resolve all at once

3. priority: high
4. difficulty/effort: moderate

2. Review / vet the VA-SEPIO Statement hierarchy and its application in Profiles

1. https://github.com/ga4gh/va-spec/issues/96 
2. priority: high
3. difficulty/effort: moderate

3. Use of Evidence Lines to represent EID records in CIViC Data

1. https://github.com/ga4gh/va-spec/issues/94
2. priority: high
3. difficulty/effort: moderate

4. Use of confidence/evidence level and direction attributes in metakb-cvc profiles and data

1. https://github.com/ga4gh/va-spec/issues/93, https://github.com/ga4gh/va-spec/pull/88
2. priority: high
3. difficulty/effort: high

5. Revisit naming of the 'id' attribute of the 'Coding' class (and change back to 'code')

1. https://github.com/ga4gh/gks-metaschema/issues/12
2. priority: high
3. difficulty/effort: moderate

4-3-24 UPDATE:  Looks like the current version of the Coding class in GKS commons has a ‘code’ property, which I assume is where the concept code would go.

6. Various minor suggestions to improve/align CIViC data example:

1. https://github.com/ga4gh/va-spec/issues/95
2. priority: high
3. difficulty/effort: low

7. Align Value Object Descriptor representations across VRSATILE and VA models (then cede to VRSATILE)

1. https://github.com/ga4gh/vrsatile/issues/37
2. priority: medium
3. difficulty/effort: low

8. Align 'Expression' representation across VA and VRSATILE (then cede to VRSATILE)

1. https://github.com/ga4gh/vrsatile/issues/38
2. priority: medium
3. difficulty/effort: low

9. Inheritance from Information entity class in the metakb-cvc model

1. https://github.com/ga4gh/va-spec/issues/84
2. priority: medium
3. difficulty/effort: moderate

10. Update RecordMetadata attribute names to align with VA model

1. https://github.com/ga4gh/gks-metaschema/issues/5
2. priority:  low/long term
3. difficulty/effort: moderate

11. Refactor / improve representation of GKS Core Domain Entities (Disease, Phenotype, Condition (to align with VA GeneticCondition modeling)

1. https://github.com/ga4gh/gks-metaschema/issues/13
2. priority: low/long term
3. difficulty/effort: high

12. Include VA attributes to handle 'extension' content in annotation-source.yaml

1. https://github.com/ga4gh/va-spec/issues/89
2. priority:  low/long term
3. difficulty/effort: moderate

13. Codeable Concepts vs Mappings:

1. see Prep Notes for Sept 2023 Connect VA Session
2. see  gk-pilot_example_conditions_mappings_20230915.yml

3. Consider what type of documentation of the Core IM will give you something you can point people to that will show the relationship between ClinGen/VICC implementation profiles and the core model . . . so I can get working on these artifacts.

1. Review/vet  new Framework components per latest iteration: https://docs.google.com/presentation/d/1IT1zROXTLDTYiNojGoS9neZ1OCiKDQ6vlG7OlhQNJpY/edit?pli=1#slide=id.g19f39648df4_0_19 

4. Discuss general development processes through which the Core IM, Starter Profiles, and Implementation models might be developed in the short term, and how they will be coordinated and documented.

2022-10-05

I. Alignment and Modeling Tasks on Path to v0/v1 Release

1. Get VA model connected up to the modeling in the GKS metaschema repo (so VA can swap out the duplicative content that is currently found across these specifications)

1. Align high level class structure between core-source vs va-spec (see metaschema repo tickets #6 - #11)
2. Align representation of specific Utility Classes defined in both specifications

1. ValueObjectDescriptor, Expression, RecordMetadata
2. These are things that VA defined for its own needs before VRSATILE / gks-metaschema came along and defined them again

3. Coordinate / Refine representation of key DomainEntities as Value Objects - address key differences between va-spec and core-source

1. e.g. representation of Condition vs Disease vs Phenotype
2. e.g. Therapeutic Intervention classes in particular was an issue

4. Implement gks maturity model in the va spec

2. Internal VA modeling issues

1. Settle representation of evidence and confidence direction/level

1. we kind of punted on this for the plenary - using a generic direction and level fields without committing to direction and level of what . . . but said we would come back to this
2. what do we want in the core IM, and what should be in the metakb-cvc schema, and what should be used in ClinGen and CIViC data.

3. Use of VA model in ClinGen and VICC data/schema

1. Advocate for use of the Evidence Line class in representing CIViC/VICC data

1. I know this is an implementation decision - but not leveraging the EvidenceLine class here would be IMO a huge missed opportunity to demonstrate the utility of this key VA-SEPIO class, and demonstrate concretely how the VA-SEPIO DAM model is reflected in real data.
2. I am willing to make some changes/concessions to the EL model to help here, but will be very unhappy if we cannot make EvidenceLines work for this use case

2. Use of RecordMetadata class in ClinVar data - https://github.com/ga4gh/gks-metaschema/issues/5 
3. Consider putting content in Extensions into existing va structures - https://github.com/ga4gh/va-spec/issues/89 

II.  Plan for Connect

1. what do we want to try and get done ahead of meeting?
2. what to try to accomplish at the meeting?

2022-02-16

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation): Larry, Alex, Dmitriy, Bob, Andy, Tristan …

Modeling Exercises and examples:: https://docs.google.com/document/d/17o_xXLcfsRjE_Hc58dNQsgWERjIAvRFmSHXi84qMRi8/edit#heading=h.y0j43uhwwjco 

Data Examples: https://github.com/ga4gh/va-spec/blob/master/docs/Modeling/VariantPathogenicity/ClinGen_ERepo_VPI_Statement_Examples_20220215.yml 

Domain Statement vs Evidence Level Statement comparison: https://docs.google.com/presentation/d/1kKxbnh7xnBYz2hVr3kZFwwpgWeQg4RKwoYuGMJ_XZhA/edit#slide=id.p 

Matrix of data examples comparing modeling approaches: https://docs.google.com/spreadsheets/d/1bJEFWP8BBYYCLg_k2l6kekyQbhatHQEQ--Jr2y6EPBo/edit#gid=1045853565 :

Outcomes:

After a two hour conversation, I think we reached a really promising conclusion that sets the stage nicely for moving forward.  This was Larry, Dmitriy, and myself for the last half hour or so (and then just Dmitriy and myself for the final 10 minutes). Some highlights:

We achieved a shared understanding that Larry and Alex are using the (flexible) SEPIO-VA framework to define models that work for their systems/use cases.  Their implementation models are not intended to be 'the standard' GA4GH puts out for exchange of Variation knowledge.  Rather, they are meant to inform such a standard, and demonstrate general value/utility of the modeling framework - by showing that it can support the needs of a real working implementation. Other systems (e.g. CellBase) are free to apply the VA-SEPIO framework to develop SEPIO-VA based models for VPI statements to fit their use case.  We will learn from all of these, and apply what we learn toward the official GA4GH-recommended model for exchange of VPI knowledge.

That said, in an ideal world the ClinGen/VICC model to be as close as possible to the standard we end up with at the end of the day. This is why  Larry and Alex are including us in the implementation modeling work - to ensure they are applying the SEPIO-VA framework correctly, and to understand if any design decisions they make may be problematic for other perspectives and use cases.  They are willing to make some compromises in their implementation model to make it more generally useful - as long as they don’t block them from doing what they need to do.

Toward this end, by two hours in Larry, Dmitriy and I converged on a three-predicate model for making Domain Level Statements. From their earlier comments, Tristan and Alex may still prefer a 1-predicate model for making 'Evidence Level Statements' - but they indicated they would be amenable to a 3-predicate model if it moves us forward.  For my part, I’d like to explore how this approach will handle the types of 'Evidence Level' statements I know many systems will want to be able to express, and decide if we can have separate approaches for representing this type of data, or need to stuff it into the Domain Statement approach.

To facilitate these discussions, I will work up some concrete examples and share with you soon. I hope we can use these to achieve broader consensus on the next call - as all seem keen on moving past this roadblock, and letting Alex and Larry generate real data in a working system!

This 3-predicate model seems a reasonable as a first iteration of a VA standard for VPI - as it is not far off from the models we have been discussing for the past couple years.   ClinGen and VICC are free to adopt this model in their systems, or do their own thing - b/c at the end of the day they need to meet the needs of their community. As long as they can produce messages that *do comply* with the eventual GA4GH-standard for VPI Statements, all is well.

I am working to update the data examples file I shared today to illustrate how the proposal handles different path classifications (P, LP, B, LB, VUS, VUS-TLP, VUS-TLB), and will share this shortly.  

—--------------------------

Proposed Topics:

1. Review outcomes/insights from last call

2. Discuss higher level strategic goals for the VA Spec, and Framework -  get on same page about what use cases we want initial releases of the VA spec to support as an exchange standard, and how.

1. e.g. if/how we need the ClinGen/VICC implementation model to align with what VA ends up putting out as an initial release for a GA4GH standard for Var Path representation.

3. Explore ClinGen and VICC use cases and requirements in more depth (Larry, Alex to present, all to discuss)

1. What specifically are the aggregation tasks you want to enable?
2. What specifically will be done with the aggregated data once aggregated  - i.e. what specific processes and reasoning tasks do you want to be able to enable/automate?
3. How important a factor/consideration is alignment with a single linear quantitative scale of evidence strength?

4. Gain a more complete and concrete understanding of the 1-predicate Var Path model,  by looking at data examples for all possible classification scenarios

1. I fleshed out the tabular representation we started last call here
2. Larry/Alex feel free to provide more concrete examples, or add to/comment on this s/s

5. Extrapolate the 1-predicate approach/paradigm over the broader landscape of clinical significance statement types, and more foundational statement types. What are implications of applying this approach to these other statement types.

1. VP, TR, Diagnostic, Prognostic, statement types from other ClinGen efforts
2. What about more foundational (non clin sig statement types like MC, PopFreq, Fxnl Impact . . .  

2022-05-18

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation): Larry Babb, Alex Wagner, Dmitriy Sonkin, Bimal Chaudhari, Jamie Allen, Kevin Riehle, Tristan Nelson, Wes Goar

Notes:

• GKS Metaschema
• VRS PR - number of discrepancies identified between VRS and JSON schema.

• Metaschema tooling [insert presentation link]

2022-02-02

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation): Larry Babb, Alex Wagner, Dmitriy Sonkin, Bimal Chaudhari, Andy Yates, Reggan Thomas, Tristan Nelson, Ana

Notes: https://docs.google.com/document/d/17o_xXLcfsRjE_Hc58dNQsgWERjIAvRFmSHXi84qMRi8/edit#heading=h.y0j43uhwwjco 

Presentation from Alex: TO DO - add link

Proposals form Larry:  https://docs.google.com/spreadsheets/d/1bJEFWP8BBYYCLg_k2l6kekyQbhatHQEQ--Jr2y6EPBo/edit#gid=0 

2022-01-19

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation): Larry Babb, Alex Wagner, Dmitriy Sonkin, Bob Freimuth, Bimal Chaudhari, Kevin Riehle, Andy Yates, Justina Chung, Reggan Thomas, Melissa Cline, Tristan Nelson, Dmitriy Sonkin

1. ClinGen/ClinVar and VICC implementation  [see ‘Structuring Semantics of ‘Certainty’ in SEPIO Statements’ section of document here]

1. Use cases and models

Meeting recording:  https://docs.google.com/document/d/17o_xXLcfsRjE_Hc58dNQsgWERjIAvRFmSHXi84qMRi8/edit?usp=sharing

2021-10-06

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  

I. Upcoming Phases of Work / Timeline

1. VA-Spec v0 'release' Phase - October / November

1. Get v0 out the door

2. Operational Planning / Regrouping Phase - November

1. Refine approach to model development and meetings

3. Laying Groundwork Phase - December / January

1. Set up tooling / administrative support and create onboarding/training materials to enable broader, meaningful participation

4. Ongoing Development Phase - 2022

1. Do the work . . .

II. Organizational and Operational Redesign 

Two plans - one for how we develop the spec, an one for how we communicate

1. Development Plan - Defines five areas of effort to be carried out in a parallel and coordinated manner. Organizationally, these areas may align with separate teams performing the work.

1. VA Profiling: separate, small work groups (task forces?) of VA members to draft Profiles for new Statement types
2. Implementation / Testing: DP-specific teams to perform DP-driven testing and development
3. Technical Development:  define and formalize the technical framework that will support model specification and framework-based development
4. Core Spec Development / Maintenance:  core model maintenance, framework definition, outreach / coordination
5.  Outreach: Manages coordination with external partners and stakeholders

2. Communication Plan - defines communication channels and conventions used to get our work done

Meeting recording:

https://us02web.zoom.us/rec/share/KqFwtg2usdnaC50udwxNi35T96D_MFTbEU0p_Jphwp2EFq0wuAaCuRIlIw_QUCem.y6ypoKkRXLNl4vrH

2021-06-02

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  

Topics/Minutes:

LinkML Discussion

1. Recap of LinkML Webinar - summary / questions

2. Application of LinkML to the CCDH Project

1. CCDH Project Background (link)
2. LinkML yaml generation from spreadsheets (tabular model, code, yaml model)
3. Publishing documentation to GitHub pages (link)
4. Generating formal specifications (e.g. JSON schema)
5. Data generation/validation using Python classes (python, example data)

3. Application of LinkML to VA work?

1. Model Specification
2. Model Documentation
3. Data Generation / Reference Implementation
4. Terminology / Value Set Services

2021-04-30

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  

Minutes:

I Proposed VA-Spec Content - link 

II Currently planned release timeline - link

III Timeline for a v0 and v1 release by plenary v1

1. v0 Base Profiles / documentation out by May 21

1. MC done, VPI, TR, EFI still to do

2. Other / supporting v0 documentation out by May 28

1. Will be minimal, and aimed at DPs working with us.
2. More general documentation for public will wait until v1 release.

3. Testing, feedback collection, iteration done by June 25 (5 weeks)

1. core VA team can be working on plans / formats / tooling  formal specification and documentation while DPs test

4. Prepare v1 documents for release/submission (should just be formalizing spec and documentation at this point - would have 4-5 weeks for this)

1. Deliverables:

1. Formalized documentation of core and Profile IMs (RTD)
2. Formal message specifications (LinkML? JSON-schema?)
3. Documents for submission
4. Exemplar implementations?

2. Timeline:

1. 3 weeks to prepare initial drafts of content
2. 1 week for folks to review (but can review docs as we go as well)
3. 1 week to incorporate edits

2021-04-28

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  

Minutes:

2021-03-10

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  Larry Babb, Alex Wagner, Dimitriy Sonkin, Irina A, Jamal Nasir, Justina Chung

Minutes:

• When you put strength and direction, what's the distinction with assertion.

• Matt: started putting together notes; will be a long conversation maybe we can dive deeper on the next call. There’s a lot to unpack.

• Larry: Why can’t we collapse assertions into evidence lines; they are inherently related and for convenience it would make sense to mungle them.
• Javi: Any type of reasonable guidelines will say if something is pathogenic or benign, there is scoring mechanism, assertions sits on top and under that you have different variants.
• Larry: Assertion sits at top, I agree. But based on evidence lines that are lower level.

CIVIC MetaKB use case:

• Curates evidence lines; they assign direction and strength as evidence.
• When enough evidence lines accumulate, the curators creates assertion record when there is enough evidence.
• Proposal is well aligned with SEPIO already. Red outline are changes/suggestions.
• Evidence line is focal point, and has a direction and strength that points to an evidence item in the context of a proposition and then we represent what the proposition is saying.
• Subject line that goes from proposition to variation. Variation descriptor line is optional but subject is required. Planning to extend principle to therapy and disease. Therapy, disease, variation will have underlying core concepts.
• This pattern is generalizable, and the subject of propositions or assertions should be a descriptor. Optional qualifier that provides descriptor for additional information.

• We recognize when sharing data we will want to decorate entities that ultimately define what we are asserting. There is great value doing that. Should it be required to have descriptor for all domain entity. Should we say In the instance when you don’t need to decorate, the descriptor is variation itself. If you do need to transfer additional concept, descriptor is in place. So there is consistency in messaging strategy without sacrificing importance of value object part. For those who don’t want to use VRS they can still pass descriptor through HGVS and use VA. Gives them a bridge.

• Javi +1
• Alex: don’t agree. What we need to do is provide a way so that propositions are central, value object representations themselves. Necessary lift and why we built VRS. Way things are now is not sustainable and we are trying to overcome that. It's the value add of the whole model.

• Need to sort out subject and descriptor
• Added: We might want to describe contributions to the study result and evidence line itself. We can describe study to capture metadata.
• We want to describe publication and indicate methods used. Additional fields are taking what Alex and Larry said is needed and adding additional features that may be useful for other use cases.
• Evidence lines can be in opposite directions, you can have propositions but under that have evidence lines that don’t point to the same direction. It’s built in.
• Assertion modelling is similar, tweaked to align with SEPIO model, no major changes. Moved assertion in line with core access objects to highlight that the assertion is the focal point and radiates out from it.

2021-02-24

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  Melissa Cline, Bob Freimuth, Alex Wagner, Larry Babb, Kevin Riehle, Dmitriy Sonkin, Yiqing Zhao

Minutes:

• Leverage 6 hour gap between Connect meetings to move work along. We will meet statement working groups to have 2 hour working session.
• Today, send out a when to meet poll to find session next week to dig into this. Focus will be on the modeling.
• Matt will reach out individually to others to go through requirements before this working session.
• Create Slack channel to facilitate discussion. Create email list or thread for this?

• Dmitriy: Slack not something I would constantly keep open to check.

• With activity around Connect and VR, bandwidth is an issue. May be hard for some people to provide meaningful input in the time frame.
• If people think it’s a bad week, I would rather leave it for a different week. 1 hour a week is not enough. We can target and try to find 1 hour next week as needed so Matt can get an understanding of what is needed for v0. Longer working meeting after Connect to flush out and finalize model.
• Next week we will get remaining requirements.

Meeting recording available here. Passcode: ^=M32ETE

2021-02-17

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  Alex Wagner, Dimitriy Sonkin, Irina Armean, Kyle Ferriter, Larry Babb, Tristan Nelson, Andy Yates, Deepti, Brian Walsh

Minutes:

• Compare models to see if Genetic Condition model fits the DPs
• Disease or genetic object required?
• Revisiting the decision to collapse pathogenicity into one statement type? Maybe split?
• Larry: trying to determine whether or not it’s worthwhile to structure assertions such that proposition can be pulled out and modeled that way instead of inherently embedded in assertion concept. If we want all our data to line up, the notion of creating propositions at assertion level and evidence that is yet to be asserted is significantly useful.

• Enough use cases? Utility for use cases?

• Bottom up approach, what data implementation has and what we want to represent.  
• Variant Pathogenicity Statement

• 5 steps for SEPIO profiling workflow.
• So many diverse implementations, we want to collect requirements per DP basis and aggregate and synthesize. Set up an appendix, for each DP set up a template where they enter different requirements they have for their use case.

• Try to tackle one (ClinGen) on the call today.
• Brian: Will these be separate classes or objects within SEPIO?

• Each requirement should map to a class in a field or through a path in the SEPIO model.

• Alex would like to have discussion about oncogenicity statements in order for VICC to fill out requirements.

• Dmitriy: oncogenicity is pathogenicity with some somatic contexts?
• Alex: disagrees, CIVIC makes distinction between somatic context predisposition variants and idea behind somatic contexts oncogenicity statements. I think they are separate stigma types.
• Dmitriy and Alex to discuss offline, have discussion points, and bring to the group at the next call.

• ClinVar:

• 6-7 requirements

• Take 15-20 min over next week to start populating documents so that we can discuss next week.

2021-02-10

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation): Malachi Griffith, Alex Wagner, Bob Freimuth, Brian Walsh, Dimitriy Sonkin, Helen S, Irina Armean, Kevin Riehle, Larry Babb, Tristan Nelson, Yiqing Zhao, Kathy Reinold, Justina Chung

Minutes:

Status/Plans for Wrapping v0 Statement Models: Molecular Consequence, Experimental Functional Impact, Variant Pathogenicity, Therapeutic Response

1. Molecular Consequence

1. Status: complete (95%)

2. Artifacts:

1. Profiling Doc: https://docs.google.com/document/d/1V8UbwubFbUCUHIy4lYMyHkkqN5YhjYSMlDsC3AE8iLY/edit#heading=h.vysdh1w8mzt2
2. Core Semantics in s/s:  https://docs.google.com/spreadsheets/d/1zQU-Yv7gB7IHKIOVsTh-74BwdtgB9KQpKcWkSHZOa-Q/edit#gid=1646330759&range=1:1
3. Modeling artifacts: https://app.lucidchart.com/lucidchart/fdc0ba92-e43a-4163-9bfb-5ee40524c45f/edit?page=-fSa56Sr3HfH#?folder_id=home&browser=icon

3. Next Steps:

1. Modeling loose ends to tie up?
2. finalize/formalize specification and documentation . . . for v0:

1. UML diagram of the model
2. data dictionary with details
3. some implementation notes/guidance
4. data example

2. Experimental Functional Impact

1. Status: in progress (75%)

2. Artifacts:

1. Profiling Doc: https://docs.google.com/document/d/1knWCFtKnuLUt3lXS0D7YJlcGpNDcizbl54cQPzUKVH0/edit#
2. DP-specific requirements: https://docs.google.com/document/d/1knWCFtKnuLUt3lXS0D7YJlcGpNDcizbl54cQPzUKVH0/edit#heading=h.o2pnwxa0juxy
3. Aggregated requirements:  https://docs.google.com/spreadsheets/d/1HeSUH0mViEHtJasMeywLF08INUdQM_2v5l7vD5du2bI/edit#gid=0

3. DPs with data and/or planned Implementations

1. ClinGen Evidence Repositories 

1. e.g. the Functional Data Repo - a catalog of functional impact knowledge curated from the literature, for use as evidence supporting clinical variant interpretations (mainly pathogenicity)
2. Bradford, Sai, Kevin, Debbie

2. Atlas of Variant Effects (AVE) - Functional Impact data generated through HTP assay pipelines that systematically analyze the effect of (almost) all possible mutations in a given gene - used as evidence to make Functional Impact Statements. Also fed into clinical variant interpretation systems as evidence for things like pathogenicity classifications.

1. Alan

3. BRCA Exchange - integration and recalibration/re-analysis of Functional Impact data from MAVE and other HTP studies. Results fed into clinical variant interpretation systems as evidence (e.g. ClinGen FDR / VCI)  for things like pathogenicity classifications.

1. Melissa C.

4. CIViC / VICC - functional impact statements curated from the literature (to support clinical interpretations). Used to support different types of (mostly) somatic variant interpretations

4. E/P Requirements collection was major focus of initial work here  - given diversity of use cases and richness of experimental metadata that DPs want to be able to collect.

1. E/P modeling currently underdevelopment - starting with understanding at a higher level the analysis and interpretation workflows implemented across the DPs
2. Higher level structures will then be fleshed out with specific fields and data elements needed to support the specific requirements we identified.

5. Statement Semantics - The other big challenge for EFI is representation of the Statement semantics - we never defined this model b/c EFI wasn’t one of the original prioritize Statements, but implementation use cases for this far surpass those for CFI since work began

6. Next Steps/To Do:

1. finish core SEPIO modeling to support experimental metadata an analysis workflows
2. derive a SEPIO EFI profile E/P representation
3. define model for Statement semantics (S-P-O-Q)
4. Contributors:

1. . . .

2. Variant Pathogenicity

1. Status: in progress (50% of work has been done?)

1. Model of Statement structure/semantics is complete.
2. Model for Domain Entities is complete (e.g. Genetic Condition)
3. Required value sets are complete  (clinical significance, allele origin)  
4. Model / SEPIO Profile for E/P and other metadata still TO DO

2. Artifacts:

1. Profiling Doc: https://docs.google.com/document/d/1ewpN34ZTJD6Bpoi0cO7-4DB7tIOo68V_B17MUx7xrVM/edit#
2. Data Examples: https://github.com/ga4gh/va-spec/tree/master/docs/Modeling/VariantPathogenicity
3. Prior SEPIO-based ClinGen VCI models: https://app.lucidchart.com/lucidchart/8312f38a-8db9-4a33-99fb-fd7b360716cb/edit?page=0_0#?folder_id=home&browser=icon
4. General ClinVar Modeling Notes - https://docs.google.com/document/d/1fe8inroQZ6nn0mT1zOgqnuCdLcMDRSxQQKlmAE15Nv4/edit#heading=h.m3qwig781ze4
5. ClinGen modeling for CrC Project work - lots of docs/examples and artifacts (Larry)

3. Notes:

1. This is perhaps the most important Statement type to provide - most widely used, broadly relevant, and dependent on many other types of variant knowledge as evidence
2. Modeling so far has been led by Larry and ClinGen team
3. Have focused on adapting SEPIO-VA model to support a single concrete implementation use case (CrC project), as opposed to a more generic re-usable VA Statement model
4. We need to broaden this profiling effort to consider other use cases / data sources from other DPs, and define a generic VP Statement model that will cover minimal info needed for the v0 release

1. ClinGen-ClinVar, ClnGen-VCI, BRCAExchange, VICC, GeL/CellBase?, AGHA

5. AFAIK E/P has not been a focus of ClinGen’s work - largely b/c E/P metadata is minimal / unstructured in CV . . . there are fields to capture some minimal E/P info, but most are rarely populated with data. This will be an important focus of rounding our the v) modeling effort.

4.  Next Steps:

1. Perform a E/P requirements collection effort, driven by DP data and use cases  - to help us hone in on key data to cover in v0 (similar to what we did for EFI modeling)

1. keep simple - knowing that v0 E/P model will be minimal and focus on core elements.  Future iterations will define a richer E/P model.

2. Then use our synthesized requirements to inform  a v0 VPI model/profile
3. Tasks

1. collect data examples, use cases
2. hold a series of 2-3 calls with reps for each relevant DP to review/document their data and requirements
3. follow template used for EFI to extract, aggregate, and map requirements to SEPIO
4. Matt to take pass at initial E/P Profile

4. Contributors:

1. . . .

4. Therapeutic Response

1. Status: in progress (50%)

1. Statement types and semantics  - almost done. E/P model - more work needed here. But have earlier work to build on.

2. Artifacts:

1. Modeling Notes:

1. https://docs.google.com/document/d/17J08ozgnPeubBO_Hs12GvDjC0djcJLCD-77nqW1wM7o/edit#heading=h.jyilcuwipqd2
2. https://docs.google.com/document/d/1PljqVkVOKBzY4zTi4Ag9fLa-538Em2hN4s5-sF5dBsQ/edit#heading=h.9yjsecrxboc

2. PharmGKB Analysis:

1. https://docs.google.com/spreadsheets/d/1Z-i3xJYCOlNQ7H4cmcXB5PPHHeteTeiO/edit#gid=1598665287
2. https://docs.google.com/document/d/1ZY2uUAEMW5CscJ9zI1L8V1vPwDxObxoCYFhrNIA5EKg/edit#heading=h.a7ct1pdpbxt8

3. ClinVar Analysis: https://docs.google.com/document/d/1fe8inroQZ6nn0mT1zOgqnuCdLcMDRSxQQKlmAE15Nv4/edit#heading=h.2f4lq4fym9zc
4. Prior CIVIC SEPIO Profiling work: https://app.lucidchart.com/lucidchart/ef4f86fb-ddc1-492b-94bd-3d4749725d4b/edit?page=0_0#?folder_id=home&browser=icon
5.  

3. Notes:

1. Bob, YQ and I have been working on modeling of TR Statements - based largely on PharmGKB, ClinVar, and CIViC TR sources.
2. Goal is to define a general approach that will accommodate this full diversity of TR knowledge.
3. We will use these and other resources to understand the landscape. But we will prioritize one or two areas to model initially, and work through other areas in time.

4. Next Steps:

1. assemble team of contributors spanning implementation use cases (CIViC/VICC, ClinGen-PhamrGKB work?, ClinGen - CrC work?)
2. bring team up to speed on details of work to date
3. define scope for v0 release (w.r.t. types of TR statements, and extend of E/P metadata)
4. make final decisions on modeling of Statement semantics
5. develop E/P model following DP-driven requirements analysis approach described above

2021-02-03

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation): Larry Babb, Justina Chung, Alex Wagner, Melissa Cline, Dmitriy Sonkin, Irina Armean, Yiqing Zhao

Minutes:

Implementation Survey results:

2021-01-13:

Chair: Matthew Brush

Attendees (Affiliation):

Minutes:

2021-01-06:

Chair: Matthew Brush

Attendees (Affiliation):

Minutes:

2021-##-##: TEMPLATE

Chair: Matt Brush, Javier Lopez

Attendees (Affiliation):  

Minutes: