-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] Add sample metadata to MRI and PET #1593
[ENH] Add sample metadata to MRI and PET #1593
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1593 +/- ##
=======================================
Coverage 87.97% 87.97%
=======================================
Files 16 16
Lines 1356 1356
=======================================
Hits 1193 1193
Misses 163 163 ☔ View full report in Codecov by Sentry. |
aaf2fc3
to
59e08c9
Compare
@neurolabusc I would appreciate your review on this one. I understood from #1396 that this was the easy bit, but I don't want to presume too far on a couple posts from 7 months ago. |
@effigies I only have minor comments.
|
I am having trouble unwinding what exactly is being proposed in this and #1569. Would it be possible for someone to recap what is being proposed in the two PRs and what is already in BIDS? I generally support adding A second question is that |
This PR takes metadata terms that already exist in BIDS introduced for microscopy data:
and makes them "official" BIDS metadata for MRI and PET so they could be listed and validated in the JSON sidecar of any MRI and PET data. From my understanding #1569 would like to introduced a new entity for body part.
Currently microscopy points to the DICOM terms: https://bids-specification.readthedocs.io/en/latest/modality-specific-files/microscopy.html#sample But I see nothing wrong with allowing some flexibility as to what ontology / vocab to use.
See my response above. This PR is very MRI and PET centric so that's why DICOM comes up but I don't think that we should necessarily say that when it comes to BodyPart, BIDS should cover DICOM only. |
59e08c9
to
779df20
Compare
Sounds good. Would you like a PR against the QA or dcm2niix repositories, or just an agreement that merging this means you could move in that direction?
Yes, I think directly using the values of
My interpretation is that this would be up to an annotator (person or tool). Given that Table L1 lists SNOMED terms, it would be reasonable for @VisLab Have your questions been adequately addressed? |
Yes this was helpful. Thx
…On Tue, Jan 16, 2024 at 10:37 AM Chris Markiewicz ***@***.***> wrote:
@neurolabusc <https://github.com/neurolabusc>:
1. For `BodyPart` I do think that any field that corresponds to a DICOM tag should have a validation dataset that includes both the source DICOM as well as the expected BIDS. Examples of source DICOMs could include [UIH](https://github.com/neurolabusc/dcm_qa_uih) data where the body part is `HEAD` or [Siemens](https://github.com/neurolabusc/dcm_qa_xa30) data where the body part is `BRAIN`.
Sounds good. Would you like a PR against the QA or dcm2niix repositories,
or just an agreement that merging this means you could move in that
direction?
I assume that this field is expected to be all capitals and correspond to
the values in DICOM part 16 Table L1
<https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html#chapter_L>.
My sense is that providing both a source DICOM and the desired BIDS
provides a Rosetta Stone, providing a concrete mapping from one structure
to the other.
Yes, I think directly using the values of (0018,0015) Body Part Examined
makes sense, and that appears to be all capitals, corresponding to the
values of part 16 table L1, column "Body Part Examined".
2. `BodyPartDetails` and `BodyPartDetailsOntology` are loosely defined - are values completely up to user, are values expected to be all capitals. Should these generally follow the style of the DICOM `BodyPart`?
My interpretation is that this would be up to an annotator (person or
tool). Given that Table L1 lists SNOMED terms, it would be reasonable for
dcm2niix to select https://bioportal.bioontology.org/ontologies/SNOMEDCT
as its ontology and use "Code meaning" for BodyPartDetails.
@VisLab <https://github.com/VisLab> Have your questions been adequately
addressed?
—
Reply to this email directly, view it on GitHub
<#1593 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJCJOW2FFUJ4IS2UKNXQDTYO2UF3AVCNFSM6AAAAAA34JA2EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGEYDMNZWGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
779df20
to
88436c5
Compare
Co-authored-by: Chris Markiewicz <[email protected]>
88436c5
to
fafad25
Compare
Adds
BodyPart
,BodyPartDetails
andBodyPartDetailsOntology
to MRI and PET imaging, taken from additions in BEP 031 - Microscopy.BodyPart
corresponds to a DICOM tag (0018, 0015Body Part Examined
), while the others are for additional annotation when this is insufficient detail.The more straightforward part of #1396. This complements #1586, which proposes to use the
chunk-<index>
entity to identify different fields of view in MRI, which we expect will most commonly be used for spinal cord imaging.This also lays some groundwork for BEP22 (MRS), which is waiting on a release with motion before starting their final review process.