Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardization (or at least guidance) for MappableConcepts #262

Open
Mrinal-Thomas-Epic opened this issue Jan 27, 2025 · 3 comments
Open

Comments

@Mrinal-Thomas-Epic
Copy link

Mrinal-Thomas-Epic commented Jan 27, 2025

Some uses of mappable concept describe a concept from a small list of values that are generally well-known, but aren't officially maintained by any standards body. Some examples I've noticed:

  • Within Statement
    • classification - this would need to be standardized based on the more specific proposition types
    • strength
  • Within ClinicalVariantProposition
    • alleleOriginQualifier
  • Within VariantPathogenicityProposition
    • modeOfInheritanceQualifier
    • penetranceQualifier
  • Within EvidenceLine
    • strengthOfEvidenceProvided
    • evidenceOutcome

The vast majority of implementations will be able to agree upon these value sets, so we should have a way to standardize this within GKS. We should avoid situations where one implementation uses a classification value of LP, while another uses LikelyPathogenic.

Other mappable concepts refer to entries in large databases (e.g., ClinicalVariantProposition.geneContextQualifier and VariantPathogenicityProposition.objectCondition). While it would be harder to standardize these, we could still include basic guidance/recommendations, if the initial set of implementors are able to agree on databases. E.g., use HGNC ID for gene and MONDO for disease codes.

@Mrinal-Thomas-Epic
Copy link
Author

Mrinal-Thomas-Epic commented Jan 27, 2025

@larrybabb and I started discussing this a couple weeks ago. We could petition another org (e.g. LOINC) to maintain these value sets or maintain them ourselves in another repo. The latter seemed easier at the time. LOINC does have concepts for some things, but they are pretty outdated (ex. classification)

FHIR has a way of defining its own value sets. We could make this part of FHIR, or we could emulate their approach.

@rrfreimuth
Copy link

IMO, if terms are likely to have broad use, especially if they are used in clinical contexts, I think we should explore building them in a way that will be implementable by clinical systems. The FHIR terminology group has requirements related to the structure and governance of external terminologies. I support Mrinal's comment about using LOINC or FHIR for the pathogenicity terms could be a good solution.

@Mrinal-Thomas-Epic Mrinal-Thomas-Epic changed the title Standardizing (or at least guidance) for MappableConcepts Standardization (or at least guidance) for MappableConcepts Jan 27, 2025
@mbrush
Copy link
Contributor

mbrush commented Feb 3, 2025

Outcome of 1-30-25 Call:

  • General agreement with the benefit of a push toward standardizing values for most of these MappableConcept entries in the future. However, we will not pursue this for the pending 1.0 release.
  • For now, we will add examples/considerations of terminology systems to use to populate MappableConcepts in attributes such as alleleOriginQualifier (GENO), modeOfInheritanceQualifier (HPO), and penetranceQualifier (HPO).
  • We will not call these ‘recommendations’ however, as we felt it would be overstepping our authority at this point to presume that a particular system is better/preferred over others, based on our own preferences/biases.
  • 'Recommendations' (and possibly formal constraints) can come in future work when we have time to do outreach and landscape/requirements analysis with the community, and settle on a consensus preferred standard.

@mbrush mbrush added this to VA-Spec Feb 10, 2025
@mbrush mbrush moved this to Review in VA-Spec Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Review
Development

No branches or pull requests

3 participants