Stream: genomics
Topic: R5 changes - MolecularSequence and 'Genomics Guidance'
Kevin Power (Mar 24 2022 at 19:41):
There have been significant changes to the 'genomics guidance' and 'MolecularSequence' pages the last couple of days. Can't say it is all good yet, but I welcome review and feedback:
https://build.fhir.org/branches/bmilius_molseq_r5/molecularsequence.html
https://build.fhir.org/branches/bmilius_molseq_r5/genomics.html
These changes are all under the 'simplfy MolSeq' banner. This work is independent of the other changes we are considering for R5 which include 'introduce GenomicsStudy' and 'completely align with IM (overhaul MolSeq and introduce MolecularVariation)'
Arthur Hermann (Mar 24 2022 at 20:04):
Kevin Power said:
There have been significant changes to the 'genomics guidance' and 'MolecularSequence' pages the last couple of days. Can't say it is all good yet, but I welcome review and feedback:
https://build.fhir.org/branches/bmilius_molseq_r5/molecularsequence.html
https://build.fhir.org/branches/bmilius_molseq_r5/genomics.htmlThese changes are all under the 'simplfy MolSeq' banner. This work is independent of the other changes we are considering for R5 which include 'introduce GenomicsStudy' and 'completely align with IM (overhaul MolSeq and introduce MolecularVariation)'
Excellent Work! Thank you to all who have been developing this information. A question - on the "genomics guidance" page - the link is to the STU version of the IG. Can and will that be updated to our new version when published? Is the intention to update that link as new versions of the IG are published (and will that be allowed)?
Kevin Power (Mar 24 2022 at 20:55):
Arthur Hermann said:
Excellent Work! Thank you to all who have been developing this information. A question - on the "genomics guidance" page - the link is to the STU version of the IG. Can and will that be updated to our new version when published? Is the intention to update that link as new versions of the IG are published (and will that be allowed)?
The link to the IG will be the latest 'published' version of the IG. So, once we have released STU2, they would be directed to STU2.
Bret H (Mar 28 2022 at 01:24):
https://build.fhir.org/branches/bmilius_molseq_r5/genomics.html looks better than it has in years :wink: Nice work in clarifying!
Kevin Power (Mar 28 2022 at 13:44):
Thanks @Bret H - Any input on the MolecularSequence page?
Kevin Power (Mar 28 2022 at 22:01):
I just pushed a change to the Genomics page, changing the introduction to match up to what @Bob Dolin put together in the past. We will need the confluence page created to link to, and have it contain the right other projects, use cases/examples, etc ...
Kevin Power (Mar 28 2022 at 22:01):
The build will take a while...
Kevin Power (Mar 29 2022 at 20:42):
The update finally built, any further input on the genomics page, other than the need to create the Confluence page and link to it?
CC: @Bob Dolin @Jamie Jones @Bret H
Kevin Power (Mar 29 2022 at 21:30):
Also, a question. We considered on the Monday call replacing the 'repository' element with a FHIR Attachment. However, in retrospect, would a DocumentReference make more sense?
Kevin Power (Mar 29 2022 at 22:47):
I think Attachment is OK, I am making a change now and hope to commit before I wrap up for the day.
Bob Dolin (Mar 30 2022 at 16:45):
Thanks @Kevin Power . Looks good! No further input from me.
Jamie Jones (Mar 31 2022 at 15:59):
@Kevin Power Our use of DocRef is a little untested but I think having the extra metadata to wrap the attachment may be very helpful
Kevin Power (Mar 31 2022 at 16:33):
Easy enough to switch over. I wasn't sure if we had enough of the metadata already in MolSeq or not.
Jamie Jones (Mar 31 2022 at 16:36):
Good point. I think we're close
Kevin Power (Mar 31 2022 at 17:24):
It actually would take me a bit more than I thought to switch over, but still not bad. Anyone else think it should be DocRef over Attachment? I saw @John Moehrke gave a thumbs up, any other thoughts John? Knowing you may not be as familiar with all the details of our use case, but still would be great to get your insights.
John Moehrke (Mar 31 2022 at 17:26):
First, I am the owner of the DocumentReference resource... so it is my responsibility to promote it at all times.... Got that out, so people can't claim I am bias...I am... but...
Kevin Power (Mar 31 2022 at 17:27):
It is important to have good evangelists :smile:
John Moehrke (Mar 31 2022 at 17:27):
I think the benefit of using DocumentReference enables for reuse and reference to the content. Thus multiple analysis (MolecularSequence(s), or other) can be made based on the same reference to the DocumentReference... So, reuse.
John Moehrke (Mar 31 2022 at 17:28):
Moving this content out into a DocumentReference, or better into a Binary<-DocumentRefererence<-MoliecularSequeence helps keep bloat down.
John Moehrke (Mar 31 2022 at 17:29):
The use of Binary also enables reading the content in native mime type, as when one pulls (http GET) a copy of Binary, if you indicate in the http GET that you accept the mime-type that is native to the content in the Binary, you will get just that content... meaning it is retrievalbe in a form that is not base64 encoded.
Kevin Power (Mar 31 2022 at 18:55):
Thanks John, very helpful. We anticipate that if someone was going to make the larger genomic data files available, they would do so via a URL to another system managing the larger files (rather than moving the content into a FHIR based server). There might be some cases where they might directly upload the content if the files are smaller(ish) -- which in this world, smaller(ish) might mean 100s of MBs.
John Moehrke (Mar 31 2022 at 20:06):
even better. DocumentReference.content.attachment.url can point at that content elsewhere... it does not need to point to a Binary, simply something that one who has rights can simply do a http GET on.
Kevin Power (Mar 31 2022 at 21:35):
If we directly used Attachment, we could do the same thing right? It still comes down to the question the reuse of the content via a DocRef reference and the metadata on the DocRef and the value that provides to us, over and above the 'metadata' we have in MolecularSequence.
John Moehrke (Mar 31 2022 at 21:39):
yes. sadly that is the point given that the Attachment datatype exists.. in my view that was a mistake FHIR core made.
Jamie Jones (Apr 11 2022 at 16:04):
Group talked today about moving the 'referenceSeq' element from https://build.fhir.org/branches/bmilius_molseq_r5/molecularsequence.html#resource to within the 'edit' element to align with the IM group's logical model. I wanted to comment that 'coordinateSystem' element likely ought to follow suit
Kevin Power (Apr 11 2022 at 16:05):
Suggestions on naming the higher level backbone element?
Jamie Jones (Apr 11 2022 at 16:06):
I like the IM suggestion: 'Relative -- A Sequence defined relative to another Sequence'
Kevin Power (Apr 12 2022 at 02:39):
First round of these changes made.
https://build.fhir.org/branches/bmilius_molseq_r5/molecularsequence.html
Bob Milius (Apr 12 2022 at 14:43):
Jamie Jones said:
Group talked today about moving the 'referenceSeq' element from https://build.fhir.org/branches/bmilius_molseq_r5/molecularsequence.html#resource to within the 'edit' element to align with the IM group's logical model. I wanted to comment that 'coordinateSystem' element likely ought to follow suit
I would also suggest moving coordinateSystem be under relative. It makes no sense to require a coordinateSystem if all I do is provide a literal, formatted, or pointer
Kevin Power (Apr 12 2022 at 15:11):
Yup, just committed that change this morning, build is in progress.
Last updated: Apr 12 2022 at 19:14 UTC
