feat!: update aac 2017 profiles to better reflect guidelines

[korikuzma]

close #293

For AAC 2017 community profiles:

• StudyStatement -> Statement
• Strength changed from Level A-D -> Strong, Potential, Definitive, Likely
• Classification.primary.coding.name includes modifiers
  • Tier I -> Tier I (Strong Clinical Significance)
  • Tier II -> Tier II (Potential Clinical Significance)
• Added VariantClinicalSignificanceProposition which the community profiles should use. Diagnostic, Prognostic, and Therapeutic Response Propositions will be used in EvidenceLine.targetProposition.

These changes were needed to support the work I'm doing to submit CIViC data to ClinVar as well as @larrybabb 's work.

@ahwagner Let me know if the description needs to be updated at all

[larrybabb]

+1 I like this fix. This will help me make the ClinVar data work with these statement types.
I'll defer to @ahwagner for the final call on approval.

[korikuzma]

I probably should add constraints for the following:

Tier I: Strong, Supports
Tier II: Potential, Supports
Tier III: -, Neutral
Tier IV: Definitive OR Likely, Refutes

[korikuzma]

TODO: code needs to be tier i-iv, name can have the parentheses

[larrybabb]

predicate fix on ClinSigProp.

[ahwagner]

Updated descriptions and left some clarifying remarks.

[korikuzma]

@ahwagner

Just want to chime in to second Larry’s comment about the predicate change. He’s absolutely right that it should reference a condition.

👍

Also, to clarify: Definitive and Likely are codes, reflecting the standard AMP/ASCO/CAP classifications we expect. That said, I’m a little puzzled about why we’re discussing that here, since this section is part of the base VariantClinicalSignificanceProposition, not the AAC profile.

Okay, I will leave them as we had before (codes and NOT names).

As for why we're discussing it on the proposition, I'm not sure, but I can confirm that the codes are defined in the aac profiles.

I think it’s important we keep those contexts separate. Larry’s ClinVar-GKS implementation will use name to capture non-standard concepts (like “Definitive/Likely”), while the AAC profile will rely on codes to stay consistent with community guidelines.

👍

[korikuzma]

@ahwagner @larrybabb this is ready for re-review

[larrybabb]

Tier IV: Definitive OR Likely, Refutes

Refutes should be disputes. disputes is the term we settled on. feel free to verify

[larrybabb]

Before I go any further I think we need @ahwagner to verify my assertion below...

Based on our recent discussion on how to represent these AMP/ASCO statements I understood that the top-level statement would be a VariantClinicalSignficianceProposition-based Statement, which would be profiled under the AMP/ASCO community profies. In addition, we would create three EvidenceLine profiles for each of the 3 AMP/ASCO propositions related to TherapeuticResponse, Diagnostic and Prognostic, called something like VariantTherapeuticResponseEvidenceLine, VariantDiagnosticEvidenceLine and VariantPrognosticEvidenceLine where each had a targetProposition for the corresponding base profile for TR, DIAG and PROG propositions. These EvidenceLine profiles would reflect the strengths outlined in the AMP/ASCO guidelines for Level A, B, C & D. The would be reverse engineered from ClinVar SCVs with the least amount of lossiness.
Finally, there would also be 3 Statement profiles for each of TR, DIAG and PROG that would also have propositions with the corresponding TR, DIAG and PROG propositions. However, these would be more loosely defined so that the CiVIC strengths could be reflected Levels A/B/C/D/E. These 3 statement profiles would be useful for creating EvidenceItems for the corresponding propoer AMP/ASCO EvidenceLines above.

@ahwagner please verify this as I think @korikuzma may have understood it differently, based on where this PR currently is.

[larrybabb]

I'm not sure we ever need to have the VarClinSigProp ever be a targetProposition on evidenceLine. I think we would only ever have TR, DIAG, PROG props associated at the evidenceLine Level.

[larrybabb]

Shouldn't this be the VariantDiagnosticProposition?

[larrybabb]

I think we should try to stick to a rule that all enumerations that are used as code values should be lowercase. We have already set the precedence with definitive and likely for strength in the ACMG 2015 profiles, so I think these should be strong, potential, definitive and likely. If someone wants a proper-cased label then they can use the name attribute of the MappableConcept.

[larrybabb]

These enumerations should be tier I, tier1, tier2, tier3 and tier4. IMO, roman numerals are for the label and name not the code. We may eventually want to create real dereferenceable codes and put them in a terminology system, but that's a bigger discussion. (and one that is definitely going to happen eventually)

[larrybabb]

Let's keep in mind that the code is not meant to play the dual role of the label or name so we should be careful not to conflate them.

[larrybabb]

IMO, this should render to Tier I - Strong which is a precedent that ClinVar set when working with the AMP/ASCO folks to display this data in ClinVar. Having the addition terms "Clinical Significance" is unnecessary and makes the label less compact and useful for displaying in various scenarios.

[larrybabb]

change to Tier II - Potential

[larrybabb]

change to Tier III - Unknown per clinvar and their work with the amp/asco folks to depict these type of classifications

[larrybabb]

I think this may be best left as just Tier III

[larrybabb]

change to Tier IV - Benign/Likely benign

[larrybabb]

I think this may be best left as Tier IV since CiVIC will have specific definitive vs likely strength assertions whereas ClinVar will not have this precise info.