Stream: genomics
Topic: Secondary Findings - New Extension proposal
Kevin Power (Jul 24 2018 at 18:31):
All feedback welcome: (attn @Eric Haas )
Eric Haas (Jul 24 2018 at 19:52):
- The bindings makes it specific to only CG so would not be a general Observation extension - but that is OK.
Eric Haas (Jul 24 2018 at 19:53):
- The cardinality should be 0..1 right?
Kevin Power (Jul 24 2018 at 19:56):
We didn't feel qualified to decide if it should apply to a general Observation, so decided to scope it down to our use case.
RE: Cardinality - It is possible labs might want to reference their own definitions of what makes a 'secondary findings', or we might have other bodies (like European Society of Human Genetics https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3660957/) who publish their own guidelines. In either case, it is possible a variant might be shared due to more than one policy / guideline.
Patrick Werner (Jul 25 2018 at 10:37):
As the DataType is CodeableConcept 0..1 should be fine. The different CodeSystems then will fit into CodeableConcept.Coding, which is 0..*
Kevin Power (Jul 25 2018 at 19:04):
My only concern is that is that a single CodeableConcept/multiple coding setup implies the codings are really the same concept, just from different termonolgies. That may not be the case here - as the different policies/guidelines referenced might be defined differently? Not sure when (or if) that will become an issue.
Lloyd McKenzie (Jul 25 2018 at 19:09):
It doesn't imply that they're the same concept, it implies that they're all encodings of the same concept. The granularity/expressiveness could be different, but they're all describing the "whole" concept at some level of granularity. So "dog", "miniature poodle", "mammal" would all be valid codings for my dog and could all be codings within the same codeable concept. However, "black", "furry" and "high-strung" would not be appropriate codings within a single CodeableConcept because they aren't all trying to represent the same concept - they're describing different aspects.
Kevin Power (Aug 02 2018 at 19:42):
It seems that Lloyd's original tracker (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=15823) was approved today by O&O. Can someone confirm if the plan is to add the extension to base Observation or instead to one of the profiles in the CG IG? @Lloyd McKenzie @Rob Hausam
Lloyd McKenzie (Aug 02 2018 at 19:57):
Base observation - it won't just be for us.
Lloyd McKenzie (Aug 02 2018 at 19:57):
I.e. it'll be a 'core' extension.
Kevin Power (Aug 02 2018 at 22:43):
OK - The 'secondary-finding' as proposed is VERY genomics specific, which is why in the google doc I suggested tying it to one of the CG profiles in our IG. I don't really have a problem with it being on a core extension, but I don't feel it will be very broadly applicable as proposed today.
Lloyd McKenzie (Aug 02 2018 at 23:19):
Ah. The name and the definition/binding don't seem to jive in terms of specificity...
Kevin Power (Aug 03 2018 at 13:24):
ACMG refers to "secondary findings", hence why I chose the name. And I really like the classification called out in page 3 of this document and the it's distinction of "incidental" versus "secondary": https://bioethicsarchive.georgetown.edu/pcsbi/sites/default/files/Clinician%20Primer%20Incidental%20Findings%2010.30.16.pdf
So if there is a mismtach now, how do we best resolve it? Move the extension to one of our profiles (my preference)? Broaden the definition and leave it where it is? Other?
Lloyd McKenzie (Aug 03 2018 at 14:37):
If it's specific to genetics, then call it genetic-secondary-finding or something like that.
Lloyd McKenzie (Aug 03 2018 at 14:37):
(If we feel that this concept is truly limited to genetics)
John Moehrke (Aug 03 2018 at 14:39):
please... NO... secondary findings are very common with many tests.
Lloyd McKenzie (Aug 03 2018 at 14:41):
I thought so, but I got pushback from OO for even proposing the notion. They seemed to feel that all other secondary findings were handled as reflex tests, which are flagged by other means.
John Moehrke (Aug 03 2018 at 14:43):
has that been reviewed by the Radiology domain? They have secondary findings all the time. @Elliot Silver @Brad Genereaux ?
Kevin Power (Aug 03 2018 at 14:47):
The extension as currently defined is focused on genetics - so if we want to broaden the definiiton, we will certainly have to re-work the current proposal. For genetics, it is important to have the ability to indicate the "why" behind this result being delivered - as in, this variant is related to the ACMG guidelines.
John Moehrke (Aug 03 2018 at 14:51):
Im trying to ask that we not do this in a genomics specific way... the result would then be special extensions for all other modalities (blood work secondary findings, x-ray secondary findings, ecg secondary findings, etc...), and that would not be helpful overall. I know that genomics is special... but not really
Kevin Power (Aug 03 2018 at 14:54):
The idea of using the same extension regardless of modality is fine with me, but I suppose it might depend on the requirements of the other modalities. I would be happy to work with anyone on the topic to define a more widely applicable solution.
Rob Hausam (Aug 03 2018 at 15:14):
I think it's not clear if we're all thinking of the same thing when we talk about "secondary findings" (even when it's specific to the laboratory reporting context). It seems that there wasn't sufficient clarity and agreement to be able to move forward with this as a core Observation element, so my suggestion was to agree to add the genetics-specific extension as proposed in the Google doc. We can then get experience with this and if it seems that the need is actually more general then we can consider broadening it and adding it to core in a future release. I don't quite agree with Lloyd's characterization that OO "seemed to feel that all other secondary findings were handled as reflex tests". That's definitely not the case, but the issue was rather around what is and isn't a "secondary finding", as I mentioned before, and what the implications would be of a lab labeling a "result" as a "secondary finding" (i.e. what are the expectations around how and how much the clinician needs to consider the finding in the care of the patient). The extension for genomics is a way to move this forward and gain experience.
John Moehrke (Aug 03 2018 at 15:38):
okay, then please put a note into the extension expressing this and asking for broad review. That is a fine position in my view for right now.
Elliot Silver (Aug 03 2018 at 17:16):
Are there even secondary findings on an observation? Or are these separate observations? I certainly understand a DiagnosticReport containing primary and secondary findings/observations, but I'm not sure I agree that an observation itself can have a secondary finding.
Kevin Power (Aug 03 2018 at 17:26):
This proposal was to make an extension that indicates when a particular observation is a secondary finding. It would be referenced from a DiagnosticReport.results along with all primary findings.
Elliot Silver (Aug 03 2018 at 17:32):
Ah, a "flag" on the observation, not additional findings in the observation. Got it. That makes more sense.
Elliot Silver (Aug 03 2018 at 18:03):
@Rob Hausam Between a genomics-specific extension, and making it a core element, we have the option of a core extension.
As John says, secondary/incidental findings are common in Radiology. (Yup, patient cracked a vertebrae, and oh, by the way, there's a nodule on the lung you might want to follow up on.) My initial thoughts are yes, this would be useful to be able to record. I'm not sure if recording it in the observation or on the report is correct, i.e. a particular observation is/isn't incidental vs. these are the primary findings and these are the secondary. Is there value in knowing an observation is incidental when referenced on its own, or in the absence of having a report; or does it only become meaningful in the context of a report? I expect there is value knowing it independent of a report, but don't immediately have a use case.
I would suggest we make this a core extension on observation, and see how the community reacts. I'm not sure about unsolicited vs. incidental vs. secondary terminology. And we should be clear about interpretation when absent.
Rob Hausam (Aug 03 2018 at 18:20):
What I was thinking (but probably didn't actually say) was a standard (core) extension that addresses the genomics use case. If it's straightforward enough for it to include other use cases as well, then I'm fine with that. But getting back to Kevin's comment that "if we want to broaden the definition, we will certainly have to re-work the current proposal", we would have to decide how much re-work is needed and is reasonable (my thought was to keep it fairly minimal). I think the standard (core) extension is the right place to do it. @Lloyd McKenzie Are you creating the extension (we didn't discuss that in OO)?
Lloyd McKenzie (Aug 03 2018 at 20:22):
The answer to that is: If I have to... ;) (I.e. No offense if you're willing to take it on :))
Kevin Power (Aug 03 2018 at 20:38):
I would welcome comments on the proposal to make it broadly applicable as a standard extension. Make comments here:
https://docs.google.com/document/d/10BdwflZG2AXEj0WcMVIXQ-aIK-R4H7JaTLPQlQn98is/edit
Patrick Werner (Aug 06 2018 at 14:14):
Hi Kevin & all,
maybe i miss-understood the google document but here are my thoughts:
A secondary finding is a general abstract concept independent of CG.
In the Google Doc, there are ValueSet Bindings to ACMG SF; these itself are using MIM disorder numbers.
My, maybe to trivial approach would be to have a core extension which contains a fixed code or a bound valueSet to express the fact that this observation is a secondary finding. What kind of secondary finding (e.g. BREAST-OVARIAN CANCER, FAMILIAL, SUSCEPTIBILITY TO, 1; BROVCA1 ) should be part of the observation itself.
Patrick Werner (Aug 06 2018 at 14:14):
Therefore i currently can't see the benefit of binding to ACMG-SF-V1
Patrick Werner (Aug 06 2018 at 14:16):
ACMG refers to "secondary findings", hence why I chose the name. And I really like the classification called out in page 3 of this document and the it's distinction of "incidental" versus "secondary": https://bioethicsarchive.georgetown.edu/pcsbi/sites/default/files/Clinician%20Primer%20Incidental%20Findings%2010.30.16.pdf
These codes on page3 would be the correct binding for the extension (in the CG domain)
Kevin Power (Aug 06 2018 at 14:41):
You are suggesting the codes be:
Incidental Finding: Anticipatable
Incidental Finding: Unanticipatable
Secondary Finding
?
Patrick Werner (Aug 06 2018 at 14:43):
yes, for completeness we could add Primary Finding as well. Maybe other domains also have their "special codes" for SF and would add them.
In the end we would have a ValueSet with all needed code to express different kinds of "secondary findings"
Elliot Silver (Aug 07 2018 at 16:47):
I like those definitions, but not the examples -- I'd much rather have four examples on the same test.
Do we really want to the ability for sites to extend this list? A fixed list would simplify processing. An implementation could always put an extension on this extension if they want to categorize "secondary" further. Or we add an optional element for a more specific code, but have one element that only has (primary, secondary, incidental: anticipatable, incidental: unanticipatable).
Although, having just argued for a fixed list, I'd suggest we make the values heirarchical, and add one more:
- primary
- secondary
- incidental
- incidental: anticipatable
- incidental: unanticipatable
Kevin Power (Aug 07 2018 at 18:39):
That list seems reasonable to me. I don't have a preference in flat versus heirarchical. I think as long as we (CG) can add an extension to the extension to further categorize Secondary, we should be covered.
Lloyd McKenzie (Aug 07 2018 at 18:43):
Hierarchy allows you to sy "incidental" without commenting on whether it's anticipatable or not
Last updated: Apr 12 2022 at 19:14 UTC
