Stream: genomics / eMerge Pilot
Topic: Guidance re region studied
Mullai Murugan (May 08 2019 at 23:32):
We would like to represent information about the regions studied, associated gene, transcript and coverage info for a subject as part of genetic test results. Generally the information we provide includes fields as illustrated in the screenshot Screen-Shot-2019-05-08-at-5.38.56-PM.png. Fields in the screenshot are chromosome, gene, transcript, CDS, start position, end position and coverage. Though the region studied resource does seem like a possible candidate to represent this information, if we have to create a separate region studied resource for each of the regions that are in this test, that might run into 100s or 1000s of region studied resources and might not be a scalable solution. My apologies for my somewhat basic question - what was the intention of this profile? Was it to represent info about each region (singular) or regions? Ideally, it might be helpful to have a resource which we can use to include all the regions covered as part of the test. If that is not immediately available, our alternate option would be attach our regions covered in a file format as a related artifact or similar to either the Diagnostic Report itself or possibly to the Region Studied resource? If we were to include our regions covered file as an attachment to the region studied, would that be a correct representation considering the region studied seems to refer to a single region instead of multiple regions. If not, is attaching our file to the Diagnostic Report as a relatedartifact, the more expedient solution?
- @Bob Dolin.
Bob Dolin (May 09 2019 at 15:34):
Hi @Mullai Murugan ,
If the intent is that this information is computable by the recipient, then I think we'd ultimately want to either model it or define a file format type for the attachment.
Another option is to create a single region-studied profile for "100% coverage", where we just list the 100% covered regions using a datatype that supports lists. There could be a region-covered for each tier of coverage.
Mullai Murugan (May 09 2019 at 23:46):
@Bob Dolin the intent is for this information to be computable, agree that modeling this info seems to be appropriate long term solution. CG members, to meet our immediate implementation need, following up on Bob's suggestion of a defined file format, what would be the appropriate data type and resource to include, say, a tsv of csv file?
Kevin Power (May 10 2019 at 17:56):
My first suggestion is to echo @Bob Dolin -- use the Region Studied profile for as much as you can, up to and including the new components that will be added with GF#19845
Second, if you want to still include you TSV/CSV file, you could point to a Media or DocumentReference resource from your region-studied profile using .derivedFrom() as the link.
I think this sort of topic came up at the WGM, so perhaps there are other thoughts from some of the attendees? Tagging the other co-chairs: @ Bob Milius @Bob Freimuth @Patrick Werner @Gil Alterovitz
Mullai Murugan (May 12 2019 at 17:27):
I would prefer to use Region Studied with the document attached to the derivedFrom() but the region studied profile seems to be architected to house one region (I apologize if my understanding is incorrect)? Would it be an incorrect use of this profile to load all regions as a derivedFrom attachment?
Kevin Power (May 13 2019 at 16:50):
There are a variety of ways to express the region using this profile. The easiest is to list the genes as component values, which you can do multiple since it is 0..*. If you choose that way, you could create a single instance of a Region Studies observation and list all of the genes.
As a single observation, all of the data delivered has to be related. For example, if you wanted to use the "Region Coverage" component, and your coverage was the same for all genes, you can still use a single instance. However, if you had multiple coverages, you would have to use multiple instances. However, even if you have multiple Region Studied instances, you can still deliver your CSV/TSV as a single resource (DocumentReference or Media), and have each Region Studied instance refer to your single CSV/TSV file.
This is one of the tradeoffs of using Observation and components the way we do. We might find in the longer term that we need a more specific information model to appropriately deliver this information. When/If we do, we will have to work out what that should look like.
Last updated: Apr 12 2022 at 19:14 UTC
