Stream: genomics
Topic: attaching genomic files
Andrew Patterson (Sep 20 2018 at 00:24):
Just side tracking from the Sequence/Observation discussion but on related issues. People have mentioned storage/reference of Fastq, BAM etc (ignoring VCF for the moment)
Our context is slightly different from purely at the reporting end - our system allows our users to submit fastqs (and bams) which we process through pipelines and then store the generated artifacts for them (accessible via FHIR apis). So they can submit the location of a fastq, then when the pipeline has finished, ask about where the bams generated now live (along with the fastqs). We also do the reporting bit at the end - but to solve our input/storage problem we just made some extensions that utilise location urls (s3://.... etc).
However, our modelling suggested these artifacts are properties of Specimens, NOT properties of Patients. i.e a Fastq pair belongs to a specimen. DocumentReference doesn't allow the subject of document to be a Specimen. Are we wrong in our modelling? Or is this a use case to extend the subject types of DocumentReference? Or should we be doing this entirely differently?
Kevin Power (Sep 20 2018 at 13:59):
Thanks @Andrew Patterson for breaking out this conversation. You touch on some important considerations.
- How should we handle FASTQ/BAM type files in FHIR?
I have thought "no" - partially because I wasn't sure how well it aligned with FHIR in general, partially because I wasn't sure we wanted VERY large bulky items in FHIR, but mostly because it seems to fall into the GA4GH realm.
The first point should probably be asked/debated on the #implementers channel.
The second point could be mitigated by not including the contents but instead a url.
I still can't quite get past the third point, and I think part of our other discussion (my point #4 about documenting the boundaries between FHIR and GA4GH).
- If I assume we can/should consider this, your question about DocumentReference is a good one, and one that makes me wonder how good of a match it is for these sorts of use cases. There would be other options:
Sequence.repository (which may be awkward since there really isn't a call sequence yet when you are talking about some of these artifacts.
Observation.derivedFrom(Media).content(Attachment).url
Observation.derivedFrom(DocumentReference).content.attachment(Attachment).url
DiagnosticReport.media(Media).content(Attachment).url
Do others have thoughts?
Patrick Werner (Sep 20 2018 at 14:19):
here is a related chat from implementers about Observation.attachment
https://chat.fhir.org/#narrow/stream/4-implementers/subject/Observation.20value.20attachment
Joel Schneider (Sep 20 2018 at 19:35):
In addition to the generic Media and Attachment resources, it may also be worthwhile to review the Imaging Integration WG's DICOM efforts with the ImagingStudy and ImagingManifest resources, to look for any useful comparisons or parallels.
Last updated: Apr 12 2022 at 19:14 UTC
