Stream: genomics
Topic: Representing tumor-normal sequencing tests?
May Terry (Feb 24 2020 at 18:07):
Have we considered how to represent tumor-normal testing with the Genomics Reporting IG? I'm currently investigating how we would represent this with our mCODE FHIR IG and I was wondering if there was any insight to share while I do this.
Jamie Jones (Feb 24 2020 at 18:12):
We touched on this briefly at a connectathon last year. For variant, I believe we identified the lab would likely need to link to additional specimens through an extension (that we haven't defined anywhere yet). The 0..1 cardinality is fixed on Observation.
Jamie Jones (Feb 24 2020 at 18:16):
Genomic source class seems to report the result but we haven't modeled the methodology anywhere yet to my knowledge.
May Terry (Feb 24 2020 at 18:20):
Thanks Jamie. So for the most part, it's pretty greenfield in our WG.
Happy to explore this further for both mCODE and the overall CG Reporting IG and present/solicit feedback and guidance from the team when I complete a first pass.
Kevin Power (Feb 24 2020 at 18:38):
Very much greenfield / not considered much :slight_smile:
DiagnosticReport can reference multiple specimens, so we are good there.
Would a particular Observation need to be about both specimens? Simple example - if the same variant being found in both tumor and normal, can that be two Observations? I think two makes sense to me. Just trying to see if the 0..1 -> Specimen on Observation is problem or not.
I do think exploring this is a fine idea :slight_smile:
Bob Dolin (Feb 24 2020 at 19:03):
Just to toss in another consideration - some of the somatic variant callers compute calls based on the comparison to normal, and therefore only report what are felt to be tumor variants. In this case, it might be that we could use the Variant profile, note that these are somatic variants, and just have something in the methodology
Jamie Jones (Feb 24 2020 at 19:14):
Thanks for articulating the point I attempted to make, Bob--we haven't modeled the "testing" or explicitly given guidance on reporting the methodology required, but marking a variant as "somatic" from https://loinc.org/LL378-1/ as opposed to "likely somatic" or "unknown ..." implies the lab confirmed it
Kevin Power (Feb 24 2020 at 19:22):
This is a good example of how 'methodology' is a very layered concept - lots of different levels at which we might need to express these things. Lots to figure out if someone is willing to dig in and start documenting ideas? :construction_zone:
However, I don't know that 'representing tumor-normal' makes clearly defining our approach to methodology a "must have" requirement? Sounds like another consideration that needs to be accounted for when someone figures out methodology. Does anyone disagree?
Jamie Jones (Feb 24 2020 at 19:25):
An extreme approach that has been gaining popularity: allow a relatedArtifact extension to be used on each Observation.component to provide references in context. :grinning:
May Terry (Feb 24 2020 at 19:26):
Agreed. I find this is an issue that is cropping up a lot more for us in the CodeX FHIR accelerator. I'm not enough of a genomics expert to be leading such a task on a methodology and best practices but happy to help where I can. Perhaps we can at least use some of the tumor-normal research I'll be doing as a conversation starter?
Bob Dolin (Feb 24 2020 at 19:28):
I agree @Kevin Power , and I think there is sufficient variability out there in how folks name their pipelines that it may be tricky to standardize. @Bob Freimuth has done some nice 'methodology' work in the IM model, and that might be good to review.
May Terry (Feb 24 2020 at 19:29):
and on a related note, @Bob Dolin - I like the idea of leveraging Variant with genomic source class and also a tie to specimen and rolling both variants with their respective tumor and normal specimens up to DiagnosticReport. I'll give that try with examples.
May Terry (Feb 24 2020 at 19:33):
For the curious, below is the clinical use case provided to me for analysis/prototyping:
A 50 year old woman presented to her local emergency department with back and shoulder pain. Initial imaging revealed diffuse lytic lesions through her axial and appendicular skeleton along with a presumed primary, 3cm, breast mass. In addition to addressing her pain, she receives a core needle biopsy which confirmed the diagnosis of ER/PR positive, HER2 negative, breast cancer. She has no family history of cancer. She has two children, a daughter in college and son about to finish high school. She is seen by medical oncology and in additional to other recommendations, she receives a recommendation to undergo genomic testing of her tumor as it may identify additional treatment options including clinical trials.
Branch #1Her tumor tissue is sent to vendor #1 which performs analysis and calls mutations in TP53, PIK3CA, and BRCA1. Vendor #1 notes that BRCA1 may be germline and follow up dedicated germline testing is appropriate.
Branch #2Her tumor tissue and peripheral blood sample are sent to vendor #2 which performs analysis and calls mutations in TP53, PIK3CA, and BRCA1. Vendor #2 notes that BRCA1 is somatic (not found in the peripheral blood, germline cell).
Use cases impacted from the above scenario: A researcher is interested in using mCODE to query for breast cancer patients with somatic BRCA alterations. An implementer wanted to create decision support to identify patients that have been recommended for germline testing but have not yet received it.
Bob Dolin (Feb 24 2020 at 19:37):
Thanks @May Terry . Just out of curiosity, how often would a patient have tumor testing, and not also have germline testing in parallel (or at least prior germline testing for comparison)?
Jamie Jones (Feb 24 2020 at 19:51):
Querying for the first use case is easily supported by our model and should be described on http://build.fhir.org/ig/HL7/genomics-reporting/usecases.html.
The second one is tricky because it naively involves logging and querying for http://build.fhir.org/ig/HL7/genomics-reporting/task-rec-followup.html.
Tasks can be uploaded in the same bundle as the report but aren't necessarily stored together. You could ask a server for all Tasks with code LA14022-0 "Additional testing recommended" and they will hopefully have used "reasonReference" to point to a genomic finding but just getting the patients from the "Task.for" field and then querying for their full genomic reports may be easier and safer.
Side note: it sounds like the result of the report is still a variant that was observed in one sample, so that is the one I'd recommend referencing on the Observation. The "normal" sample(s) could go on the DR if needed, or we may find a better place to slot them.
May Terry (Feb 24 2020 at 19:52):
@Bob Dolin - I'll need to verify, but afaik, the majority of cancer patients would not have germline testing in parallel or done prior for comparison. My understanding from the 2 ASCO oncologists who provided this use case are that tumor-normal sequencing, while not common yet, is emerging. A recently published paper I read on Tumor-Normal Sequencing seems to confirm their comments: "Evolving Significance of Tumor-Normal Sequencing in Cancer Care" https://doi.org/10.1016/j.trecan.2019.11.006.
Bob Freimuth (Feb 24 2020 at 20:07):
Interesting thread. Thanks, @May Terry
I think one of the first questions we'll need to answer is which of the genomic results are in which report(s). It sounds like there could be several reports, some of which test only a single biospecimen while others test both tumor and normal specimens. We'll need to support a single report that has both tumor and normal results, but I suspect we'll also need a way to make higher-level statements about tests that are reported separately. I presume those higher-level statements would not need to model the result, provenance, and specimen info directly, but could simply refer to another Observation that contains that info.
Patrick Werner (Feb 25 2020 at 08:15):
May Terry said:
Bob Dolin - I'll need to verify, but afaik, the majority of cancer patients would not have germline testing in parallel or done prior for comparison. My understanding from the 2 ASCO oncologists who provided this use case are that tumor-normal sequencing, while not common yet, is emerging. A recently published paper I read on Tumor-Normal Sequencing seems to confirm their comments: "Evolving Significance of Tumor-Normal Sequencing in Cancer Care" https://doi.org/10.1016/j.trecan.2019.11.006.
Our partner lab only does tumor-normal sequencing. Currently we are pointing out observations.specimen to the tumor tissue, we don't create observations for the normal specimen.
To mark the origin of a variant we are using the component: https://loinc.org/48002-0/
Patrick Werner (Feb 25 2020 at 08:18):
I think to model this correctly you would have two reports: one for the tumor tissue, one for the normal sample. I then would create a third report with variant observations pointing to the normal sample and the the tumor sample via derived from and will populate the https://loinc.org/48002-0/ component.
Patrick Werner (Feb 25 2020 at 08:20):
Which seemed to be to much work/too complicated. What about an extension on Observation.specimen to point to the normal sample? So we can use one Variant per Variant instead of three, germline, non-germline goes into the source class, and we still can point to the correct normal sample (currently we are only pointing to the tumor sample, which isn't quite right)
Bob Freimuth (Feb 25 2020 at 12:33):
We should probably determine whether or not our report structure is intended to mirror what is signed out by the lab, or if we have the flexibility to re-package reports into structures that match FHIR.
Patrick Werner (Feb 25 2020 at 13:48):
in our case the lab report never mentions the normal sample, it is only included as germline/somatic annotations in variants
Jamie Jones (Feb 25 2020 at 13:55):
If a lab wanted to report every normal (same as every wild type) they could, I don't see anything in the spec stopping them, but agree we could increase our guidance on genomic source class surrounding somatic
Jamie Jones (Feb 25 2020 at 14:02):
The tricky part seems to be making sure the lab can describe uncertainty in the source class with a request/note for additional testing. Would love to get someone to draft an example report/bundle for that out of this discussion, if folks are interested in the use case
Patrick Werner (Feb 25 2020 at 15:42):
Jamie Jones said:
If a lab wanted to report every normal (same as every wild type) they could, I don't see anything in the spec stopping them, but agree we could increase our guidance on genomic source class surrounding somatic
what's missing is an extension on Observation Specimen to point to the normal sample.
Jamie Jones (Feb 25 2020 at 15:48):
One could report the wildtype variant from the normal sample if they wanted to explicitly include it. I think attaching extra samples opens up a lot of room for error unless we do it very carefully.
Kevin Power (Feb 25 2020 at 15:53):
I agree with Jamie. The Observation (Variant) is really about the tumor sample. Why does it need to also refer to the normal sample as well? At this point, this feels more 'methodology' related to me (to indicated the method they used was to compare to the germline and report tumor variants). Maybe?
At the DiagnosticReport level, we can have multiple samples referenced (or multiple nested reports, which ever way we go). So at least at the report level, it would be clear there were two samples.
Lastly, we could also consider using our 'Grouper' profile to group the observations into tumor and normal.
May Terry (Feb 25 2020 at 19:45):
@Kevin Power - yes, I think we need to refer to the normal tumor sample as well. I also agree with Patrick that per the tumor-normal description, it would ideally be 2 tests, but this would indeed be too complex a model.
Looks like there are number of options available based on this thread. Lemme see if I can summarize it for discussion at next Monday's modeling meeting. I can also create a simple starter example based on the initial assumption referencing multiple specimens, multiple variants with different genomic source classes. Can we add it to the next Monday agenda?
Patrick Werner (Feb 25 2020 at 20:05):
Sure. I also want to talk about it. @Jamie Jones ?
Patrick Werner (Feb 25 2020 at 20:09):
I also really don't want to create normal Observations. And Kevin almost convinced me with pointing to both samples in the DR, and in the Observation just to the tumor and filling out the source class. I now think this could be sufficient.
Jamie Jones (Feb 25 2020 at 20:29):
The only concern I have with attaching unreferenced specimens on the DR is that I don't have a good suggestion for how to annotate them to retain meaning.
Jamie Jones (Feb 25 2020 at 20:30):
Specimen.note seems to be the place, but how would one describe the role the specimen had in the tests other than by pointing an Observation at it?
Jamie Jones (Feb 25 2020 at 20:31):
Seems like a question for O&O
Kevin Power (Feb 25 2020 at 20:35):
I think http://build.fhir.org/specimen-definitions.html#Specimen.type and/or http://build.fhir.org/specimen-definitions.html#Specimen.collection.bodySite ?
Jamie Jones (Feb 25 2020 at 20:48):
Yeah, I'm not convinced we need to add complexity to our structures to accommodate this use case (or even to streamline it).
I do definitely look forward to seeing the example report though--and would love to get one up in the IG--so we could give it a small time box on Monday in my opinion.
I'd also love to see someone extend this example to the "trio" testing picture where we have 3 samples in play and are explicitly identifying de novo variants. :grinning_face_with_smiling_eyes:
Kevin Power (Feb 25 2020 at 21:28):
Do I hear 4 samples?!? :slight_smile:
Bob Dolin (Feb 25 2020 at 21:44):
@Jamie Jones I have some examples of trio testing and somatic-normal testing VCF files if that would help. It may not answer the question about how best to represent the pipeline or methodology, but might be useful to look at the variant calls.
Patrick Werner (Feb 25 2020 at 21:59):
Kevin Power said:
Do I hear 4 samples?!? :)
this brings me back to having a (complex) extension on specimen. code: kind of specimen, e.g. normal specimen, maternal, paternal and a reference to a Specimen Resource. The Extension is 0..* and then you can hear 40 samples :-)
Jamie Jones (Feb 25 2020 at 22:00):
I've seen worse extensions.
Patrick Werner (Feb 25 2020 at 22:00):
if you don't like it, don't use it. Just use method.
Patrick Werner (Feb 25 2020 at 22:01):
But it enables an easier use than having 3 variants to describe a germline variant if you want to be precise
Jamie Jones (Feb 25 2020 at 22:06):
I think specimen.note may be ok actually... "Arrived with patient" and "frozen" are examples--don't see how "germline reference" is any different
Kevin Power (Feb 25 2020 at 22:07):
So we would allow a variant found in different samples to be represented as a single observation? That seems so easy to misinterpret on the receiver side.
Patrick Werner (Feb 25 2020 at 22:09):
I don't think so, the method will have to be coded "tumor-normal-test" which involves 2 samples
Patrick Werner (Feb 25 2020 at 22:10):
in reality we are currently using a single variant, pointing to the tumor specimen and having the source class germline.
Patrick Werner (Feb 25 2020 at 22:10):
Also if the receiver doesn't care about the Extension, it will be germline Variant pointing to the tumor sample
Patrick Werner (Feb 25 2020 at 22:14):
Jamie Jones said:
I think specimen.note may be ok actually... "Arrived with patient" and "frozen" are examples--don't see how "germline reference" is any different
i don't like having this information as a non coded note. A possible alternative would be another coded field in specimen, but there is none usable at the moment
Jamie Jones (Feb 25 2020 at 22:16):
I don't think the extension really adds that much... We should just be explicit when we talk about source class. The use case asks to determine if follow-up testing is beneficial, not to capture every possible step of the lab's workflow
Kevin Power (Feb 25 2020 at 22:17):
Patrick Werner said:
in reality we are currently using a single variant, pointing to the tumor specimen and having the source class germline.
So, if we create two new operations in the future: 'find-somatic-variants' and 'find-germline-variants' , would you expect this single variant to be returned for both?
Jamie Jones (Feb 25 2020 at 22:17):
(which is still possible by blowing up that component with an extra Observation)
Kevin Power (Feb 25 2020 at 22:21):
Or even, even easier and scarier, if some did a query by component value of 'germline', this variant in the tumor would not be returned, right?
Jamie Jones (Feb 25 2020 at 22:22):
I wouldn't think a query for somatic variants would go by specimen.type so this would show up as germline
Jamie Jones (Feb 25 2020 at 22:22):
If the lab flagged it as germline, I think that is intended
Kevin Power (Feb 25 2020 at 22:24):
Oh, sorry, my second example was not right:
Or even, even easier and scarier, if someone did a query by component value of 'somatic', this variant that was found in a tumor would not be returned, right?
Or, maybe I am not getting it :slight_smile:
Jamie Jones (Feb 25 2020 at 22:25):
I think this latest version is right too, a "tumor sample" can have germline variants to my knowledge
Kevin Power (Feb 25 2020 at 22:26):
So, anything that queries by 'somatic' should return variants ONLY found in the tumor?
Jamie Jones (Feb 25 2020 at 22:26):
Wait, are we confusing source class and variant origin??
Jamie Jones (Feb 25 2020 at 22:27):
There are overlapping terms.
Kevin Power (Feb 25 2020 at 22:32):
I was talking about 'source class', but you were talking about 'Variant Inheritence', which SO calls variant origin?
Jamie Jones (Feb 25 2020 at 22:37):
A tumor sample presents a variant that is found to be inherited
Jamie Jones (Feb 25 2020 at 22:38):
source class=somatic,
variant inheritance=maternal (eg)??
Kevin Power (Feb 25 2020 at 22:38):
Yes, we do have overlapping terms - so we need to include those in our examples/thinking we are doing.
Kevin Power (Feb 25 2020 at 22:39):
Jamie Jones said:
source class=somatic,
variant inheritance=maternal (eg)??
or
variant inheritance=germline_variant (SO:0001778) (if you don't know parental origin)
Jamie Jones (Feb 25 2020 at 22:41):
I was hasty to claim everything depended on source class, we broke this up into 2 concepts right before publication for a reason!
Kevin Power (Feb 25 2020 at 22:41):
But yea, dang - potential areas of misuse between those two components. urggg. We need to AT LEAST make some good documentation on that one. But, I say we let @May Terry wow us with her write up and examples :slight_smile:
Jamie Jones (Feb 25 2020 at 22:43):
Unknown Variant inheritance is also a good indicator for additional testing
May Terry (Feb 25 2020 at 23:44):
@Kevin Power et al - I'll give it a whirl to present findings and options this Monday but hoping to rely on the team's genomics expertise (exponentially way beyond mine) to help guide it. :-)
Kevin Power (Feb 25 2020 at 23:55):
Thanks @May Terry !!
Patrick Werner (Feb 26 2020 at 08:51):
Jamie Jones said:
I was hasty to claim everything depended on source class, we broke this up into 2 concepts right before publication for a reason!
looking at the two ValueSets and concepts i get the feeling they are the same. If we would extend the Loinc AL with the missing terms from variant origin we could merge them into one. Or am i missing something here?
Patrick Werner (Feb 26 2020 at 08:53):
Kevin Power said:
Patrick Werner said:
in reality we are currently using a single variant, pointing to the tumor specimen and having the source class germline.
So, if we create two new operations in the future: 'find-somatic-variants' and 'find-germline-variants' , would you expect this single variant to be returned for both?
only for find-germline-variants
Patrick Werner (Feb 26 2020 at 08:54):
Kevin Power said:
Or even, even easier and scarier, if someone did a query by component value of 'somatic', this variant that was found in a tumor would not be returned, right?
(if it was a germline mutation -> found in normal and tumor tissue: yes you are right. And i think thats correct. @May Terry what do you think?
Patrick Werner (Feb 26 2020 at 08:57):
Here is our example report:
https://drive.google.com/open?id=1y4E5lzsxLJ644kHpR7fTYN-xoGgPQVmt
Patrick Werner (Feb 26 2020 at 08:57):
Patrick Werner (Feb 26 2020 at 08:58):
the first variant is a germline one.
Kevin Power (Feb 26 2020 at 12:58):
Regarding the two value sets, I was thinking it would be:
Source Class- what was I testing
Variant Inheritance- where did the variant originate
But not sure we need that level of distinction
Jamie Jones (Feb 26 2020 at 13:27):
Source class is captured in specimen.type it seems... Ought to double check the DAM
Jamie Jones (Feb 26 2020 at 13:44):
Specimen Identification is Scenario 1 in the DAM and states a lot of what we have seen in this thread. It mentions the two testing methods and outlines what variants should be marked as somatic either with normal testing or through lab's calculation
Jamie Jones (Feb 26 2020 at 13:45):
I don't see a reason for us to have 2 places to call a variant somatic and think we should use variant inheritance specifically to cover the full logic table for germline inheritance only
Jamie Jones (Feb 26 2020 at 13:47):
For the tumor/normal use case, source class should be appropriate
May Terry (Feb 26 2020 at 14:06):
The oncologist who made the initial inquiry provided this sample report (fictitious patient and approved for distribution) for review by the team. My example will probably leverage some of the example data noted here. sample-tempus-ngs.pdf
Patrick Werner (Feb 26 2020 at 14:30):
Jamie Jones said:
I don't see a reason for us to have 2 places to call a variant somatic and think we should use variant inheritance specifically to cover the full logic table for germline inheritance only
sounds great. and would remove the overlap
Patrick Werner (Feb 26 2020 at 14:33):
i will also try to create an example of our current format for the monday call
Jamie Jones (Feb 26 2020 at 15:01):
Thanks both!
It seems the remaining steps here are to:
- confirm May's 2 use cases are represented in the next version of the DAM
- log a tracker to provide guidance on source class terms "somatic" vs "likely somatic" surrounding this use case (or whatever solution we decide)
- log another to reconcile the concepts https://loinc.org/LL378-1/ and http://www.sequenceontology.org/browser/release_2.5/term/SO:0001762.
- get these example reports FHIR-ized and in the IG
Kevin Power (Mar 02 2020 at 17:27):
One thing hit me just now - Do we have a JIRA (tracker) for this? If we are going to spend much time on this, it seems we need one.
Jamie Jones (Mar 02 2020 at 17:30):
None yet, I outlined 2 to log here but could consolidate and wanted to give it a bit of air time to gauge likely scope of changes.
Kevin Power (Mar 02 2020 at 17:31):
Oh geesh, sorry @Jamie Jones -- I missed your points 2 and 3 above :frown:
Patrick Werner (Mar 09 2020 at 16:17):
asked O&O on their opinion. https://chat.fhir.org/#narrow/stream/179256-Orders-and.20Observation.20WG/topic/tumor-normal.20testing
Bret H (Mar 15 2020 at 16:31):
So, a question for labs and oncology is: Is the TUMOR the same patient as the patient? The specimen identity should be attached to the variant data (we're all agreeing there), but the biggest problem is that we also identify the TUMOR as part of the patient. With a microorganism it is easy to determine who is who. With TRIO analysis, the clinical lab community is in a similar state - consider that the parents genetic sequence may only be recorded in the probands electronic record. But it would be obvious that mom and dad are not the same person as the proband - a smart system would give mom and dad unique identifiers (i.e. unique patient records in the system - yep, even if they are not ever going to be 'legally' treated or seen in the system) and use a family linkage to the proband....find a system that does that!
Bret H (Mar 15 2020 at 16:32):
that will be the group to talk too and get input from
Bret H (Mar 15 2020 at 16:33):
most other places are using the data ephemerally, leaving disambiguation to non-real-time data analysis efforts that are typically research related.
Bret H (Mar 15 2020 at 16:36):
How's it work in Germany @Patrick Werner? where I understand employers have been cited for using genetic data to disqualify applicants. what is done with trio data where one participant does not want their genetic data exposed? is it protected? obfuscated?
Patrick Werner (Mar 16 2020 at 15:39):
great thoughts. I will finalize my example this week. So far my thougts are:
- Observation.specimen always points to the specimen which was in focus (in tumor-normal testing this would be the tumor). All other specimens can be linked through an complex extension which includes:
- type of specimen relationship (coded): normal-specmine|normal-specimen-maternal|normal-specimen-paternal
- reference to the Specimen
Patrick Werner (Mar 16 2020 at 15:42):
So we don't need mum & dad as instances, but we can describe which specimen played which role in the test. If we have Instances of mum&dad we can point to them in Specimen.subject.
Patrick Werner (Mar 24 2020 at 16:54):
Hey @May Terry here is an example on how the multiple specimen extension could look like: https://gist.github.com/patrick-werner/5d715f00c4c0e096be35debcb0962267#file-first-demo
Patrick Werner (Mar 24 2020 at 16:55):
not valid FHIR, tried to condense it to the relevant parts as much as possible. What do you think?
Patrick Werner (Mar 24 2020 at 16:57):
This Extension then has to be accompanied by exact guidance on how to use it; or even better guidance on tumor-normal testing. This guidance also should show how to the same thing with 3 Observations an no Extension: Variants(tumor/normal) and a derived Observation for somatic/germline
Bret H (Mar 31 2020 at 12:30):
You've got the option of using specimen.type = 'tumor -normal' when appropriate
Bret H (Mar 31 2020 at 12:37):
@Patrick Werner sorry to ask for this. but can you use a more specific example of the statement you are trying to make with the multi-specimen? @May Terry there is specimen.type which is extensible and can be given the type tumor-normal. However, I understand the goal is to link together somehow the tumor-normal results and tumor results. Why would it not be sufficient for the 'blood' specimen in the example to appear as a specimen in the diagnostic report? In the example are there any observations made specifically on the blood sample?
Patrick Werner (Mar 31 2020 at 12:42):
I also thought about using the specimen type already..
Patrick Werner (Mar 31 2020 at 12:44):
argument against: if you loose the specimen you loose the type info. On the other hand: you don't need the extension if you don't have specimens.
Patrick Werner (Mar 31 2020 at 12:45):
But: speciment.type is also 0..1. So if i want to use this to code: blood, tissue, liquidBiopsy, .. i can't additionally code: normal tissue, or paternal blood, etc.
Jamie Jones (Mar 31 2020 at 12:47):
Specimen also has a 'note' field for those who don't want to employ an extension
Patrick Werner (Mar 31 2020 at 12:48):
Yes, but note isn't coded. Or did i understood your comment wrong?
Jamie Jones (Mar 31 2020 at 12:51):
I see attaching the additional specimens to the report with decent notes as a fine solution for these use cases. That said, I also like the extension for systems that are expecting to do a lot of these tests
Jamie Jones (Mar 31 2020 at 12:56):
@Bret H I can supply a potential use case where the extension may be helpful--biobanking samples beyond a deidentification workflow
Patrick Werner (Mar 31 2020 at 12:59):
ah now i got your comment. Right, systems that don't need that specific link can ignore the extension and only Link it through DR with some notes. If you need/want to be specific you just use the extension. Nobody will be forced to use-it or incorporate it into their use-case specific ig.
Jamie Jones (Mar 31 2020 at 12:59):
notes can work but if sample tracking is key to the system they will want something more structured (80/20 but that 20 will want an extension and we can centrally provide the definition+url)
Bret H (Mar 31 2020 at 13:00):
@Jamie Jones not sure. Why would the new deidentified sample not have a new identification.
Bret H (Mar 31 2020 at 13:01):
@Patrick Werner why are you losing specimen?
Bret H (Mar 31 2020 at 13:03):
@patrick @Jamie Jones have you reviewed https://www.hl7.org/fhir/family-member-history-genetics.html @May Terry when considering trios?
Jamie Jones (Mar 31 2020 at 13:04):
isn't this pushing complex extensions from resource to resource?
Jamie Jones (Mar 31 2020 at 13:05):
or perhaps that's what we're proposing now haha. Certainly multiple structures are valid for communicating this info
Bret H (Mar 31 2020 at 13:05):
For trio analysis it was handled via family history. Gil has slides circa 2017. But let's leave off Trio analysis here
Jamie Jones (Mar 31 2020 at 13:06):
Trio analysis is my use case...
Bret H (Mar 31 2020 at 13:06):
the topic is tumor-normal sequencing tests.
Bret H (Mar 31 2020 at 13:06):
just saying
Bret H (Mar 31 2020 at 13:06):
and GIl and Grant's past work should be examined.
Last updated: Apr 12 2022 at 19:14 UTC
