Stream: genomics
Topic: Representation of secondary findings
Mullai Murugan (Nov 01 2019 at 18:52):
Hi all - the only element related to secondary findings is the observation-secondaryFinding extension element in the InheritedDiseasePathogenicity resource. Though the definition for this element states "This extension should be used to denote when a genetic finding is being shared as a secondary finding, and ideally refer to a corresponding guideline or policy statement.", the related valueset seems to be more about the policy statement as the two options available are acmg-version1 and acmg-version2. Indicating if a finding is secondary is considered somewhat of a first class element for us and establishing a granular distinction between related secondary finding elements will be useful. Can this expanded further to include something similar to the following -
- isSecondaryFinding (boolean)
- SecondaryFindingSummaryText ( e.g. A heterozygous pathogenic variant in the PMS2 gene was detected . This finding is considered unrelated to the patient's primary phenotypic indications and is considered an actionable incidental finding)
- categorycode (acmg v1, v2)
Kevin Power (Nov 01 2019 at 20:22):
That extension is actually on the base Observation resource as of R4:
https://hl7.org/fhir/extension-observation-secondaryfinding.html
Regarding the ValueSet, it is extensible, so you can indicate other values as well. So if you include the extension, then you are indicating this is a secondary finding.
Regarding your text statement, I think most of that data will be included discretely, but you could include it in an InheritedDiseasePathogenity as a RelatedArtifact extension value?
Mullai Murugan (Nov 01 2019 at 22:37):
@Kevin Power thanks. Instead of the relatedartifact, I added the secondaryfinding text to the "text" value of the observation-secondaryFinding and included a boolean value to CodeableConcept to indicate if the finding is secondary.
Kevin Power (Nov 01 2019 at 22:48):
My only caution to you is that the CodedableConcept.text field is intended to represent a "Plain text representation of the concept" and not necessarily additional information like this. And I am not sure where you put the boolean value?
Larry Babb (Nov 05 2019 at 14:40):
@Kevin Power To be clear, the way this extension attribute (observation-secondary-finding) is designed to work is to provide a coded value that represents the secondary finding policy or guideline used to find secondary findings with clinical significance to phenotypes not directly indicated by the ordering physician. So, the producer and consumer must understand that if this extended attribute is absent or has no value then the finding is related to the primary indication (or a primary finding) and if there is any value in this field then it is a secondary finding. And if the consumer wants to know the secondary finding policy that the lab used as a part of the assay methodology then they must inspect this value on each secondary finding to figure that out.
It seems to me that this is a bit of an indirect way to indicate secondary findings. It would be much cleaner IMO if we simply had an indicator on each genomicsbase subprofile to state explicitly whether it is a secondary finding or not (if left out then the default is that it is NOT a secondary finding- very similar to how present and absent works). But the producer can explicitly indicate "Yes" this is a secondary finding or "No" this is not a secondary finding. This could be done in a codeableconcept if desired, but I wouldn't mix it with the method or policy for how secondary findings where determined. The secondary finding policy or method should be part of the assay plan definition or methodology.
If we open the door to putting "methods" into specific observations which would otherwise be defined at the overall test definition then things could get pretty confusing for the implementers and users. I would reserve adding method-like information to observations only in exceptionally situations where it deviates from overall assay plans.
If this is not going to be changed then I would clearly state in the extensibility notes for this observation-secondary-finding that implementers should never add a value that represents a "negative" value (e.g. observation-secondary-finding = "Not a secondary finding"). I know that seems silly but folk may add the notion of positive and negative values to this extension in cases where they want to clearly indicate which genomicsbase sub-profiles are secondary findings vs primary findings.
Kevin Power (Nov 05 2019 at 19:11):
I made the original request to O&O to get it defined. Based on feedback I had received, the indication of the 'policy' was an important thing to understand, in addition to the base fact that an Observation is a secondary finding.
If we want to change the data type of the current extension, that would be a request to O&O since they own Observation. That extension is still in draft so would be changeable if approved. We could then consider how the 'policy' portion is best modeled in our IG, perhaps as its own extension or, as you hint, perhaps it should be aligned with a broader definition of methodology.
Thoughts from others?
Jamie Jones (Nov 05 2019 at 19:39):
I think ideally what is in the "SecondaryFindingSummaryText" in the proposal should be generated from the coded components/extensions and included in the Observation's narrative. :smiley:
Jamie Jones (Nov 05 2019 at 19:46):
If a system is attempting to query for a bundle of Observations based on secondary-finding status, the current setup would require primary findings to not populate this extension or have some coherent way to distinguish themselves.
Kevin Power (Nov 05 2019 at 19:55):
Current setup absolutely assumes that only Observations that are 'secondary' would get a value for this extension. I don't know why a 'primary' finding would ever populate something used to indicate 'secondary' anyway, regardless of its data type.
Jamie Jones (Nov 05 2019 at 19:59):
It does get us dangerously close to one of our favorite spaces however, the "assumed negative by omission" issue. Certainly something implementers should be aware of.
Larry Babb (Nov 06 2019 at 13:04):
@Kevin Power or @James Jones can you clarify if the notion of "secondary findings" is an O&O issue or is it a CG issue? Is O&O taking on the analysis and generalization of how secondary findings would be communicated in any kind of observation for all domains?
Maybe we could try to separate the kinds of observations that are happening to determine how to best use the Observation resource to communicate each individual piece of information...
The tuple of Observation code, value pairs as we know is the foundation of the observation. The code is typically a LOINC code which describes the question in a precise enough manner to provide significant context to the value that can and should be provided. The LOINC system has taken on an significant amount of complexity to describe the question and value in a context that makes this code-value pairing useful in computational healthcare systems.
So what are the questions, context and answers that we really need for clinical genetic testing (just spitballing here)
-
Code: What region of the specimens germline genome did I interrogate?
Value: A structure that represents a reference-based sequence location. -
Code: What genotype of the specimens germline genome did I interrogate?
Value: A structure that represents a small SNP InDel genotype. -
Code: What genotype (small SNP or InDel) was PRESENT in the germline genome of the specimen?
Value: a construct / data type that represents the precise sequence variants and its zygosity or allelic state? -
Code: What sequence variant genotype (small SNP or InDel) was ABSENT in the germline genome of the specimen?
Value: a construct / data type that represents the precise sequence variants and its zygosity or allelic state? -
Code: What is the primary clinical significance assessment of the genotype found in the germline specimen?
Value: Maybe some type of structure that holds both the level of pathogenicity coupled with the disease/phenoteyp associated. (NOTE: this particular observation would be required to have a "DerivedFrom" observation of the type of #3 above.) -
Code: What is the secondary clinical significance assessment of the genotype found in the germline specimen?
Value: same as #5 above but clearly indicating that this is a secondary finding type of assessment.
... I could go on and on...
This is a brand new idea that hit me this morning. I've been working for a long time to try to find ways to organize and simplify the way genetic observations are reported. This approach may be something worth exploring at the least. LOINC can be extended to support the class of codes we would need to annotate things like "germline vs somatic" genomes, types of variation (sequence variant genotypes, alleles, complex hets, structurcal variants, copy number variants, etc...).
While I was never too keen on LOINC due to the fact that it externalized the context of the question, I think I understand the value in it now in that it removes the need to include that complexity directly in the HL7 message itself. Let's let LOINC help us shape the world of questions (observation codes) in a thoughtful way that works for genetic testing results. Then we can focus on providing the new data structures to put in the values that align with those newly crafted LOINC observation codes for genetics.
If anyone is up for discussing this let me know. It's a pretty raw idea, but I think it opens the door to a systematic approach to sharing these results.
Kevin Power (Nov 06 2019 at 15:05):
@Larry Babb - The current secondary findings extension is owned by O&O, so they would have to approve changes. It was introduced at CG's request.
Regarding your other points - I think you just described how we approached this problem. Just a couple of other points/clarifications on our approach:
- The questions we are asking are different. Your proposals above are much more specific than the ones we have.
- The 'structure that represents X' is not a structure specific to each question, but instead is mapped to the value[x] + the components we have defined for each profile.
I would map your questions to our profiles roughly like this:
- RegionStudied
- RegionStudied
- Variant (with a .value = Present and components to define the 'genotype'
- Variant (with a .value = Absent and components to define the 'genotype'
- InheritedDiseasePathogenicity
- Use the profiles above, but add a value to 'secondaryFindings' extension on the appropriate observations.
Does that make sense, or did I completely miss something?
Larry Babb (Nov 06 2019 at 16:07):
@Kevin Power i do completely get what the CG group did to define more generalized questions with more complex component-based results. I think there's a better balance to avoid the structure by component model as is being done currently. This would also offer the opportunity to define the more computable, reliable and standardized structures to use in the "value" of the observation.
Kevin Power (Nov 06 2019 at 18:27):
I hope that the IM work will inform what our model should ideally look like, but once that is complete we will still be faced with aligning that with FHIR - and that is where introducing new structures requires someone to build firm proposals and clearly describe why what is in place today does not meet our requirements.
Kevin Power (Nov 06 2019 at 18:28):
If you are willing to build on your ideas, I for one would be happy to help work through it.
Last updated: Apr 12 2022 at 19:14 UTC
