Reporting measures derived from multiple regions

[jeffduda]

Hi @fedorov, I have a question regarding tid1500writer. I am currently using a modified version of the CT liver example template to generate a DICOM SR that reports (from a segmented CT image) volume and mean attenuation coefficient in the liver and also in the spleen. For the spleen measurements I created a second measurements group that is basically identical to the group for liver measurements, except for the ‘TrackingIdentifier’, ‘FindingSite’ and ‘ReferencedSegment’. I would also like to report the mean attenuation in the liver divided by mean attenuation in the spleen (this relates to liver fat content). I was wondering if it is currently possible to define a measurement group that refers to multiple ‘ReferencedSegments,’, and if so how? Any guidance you have on the appropriate properties (quantity, units, derivationModifier, etc) for this measure would also be greatly appreciated. Thank you

[fedorov]

For the spleen measurements I created a second measurements group that is basically identical to the group for liver measurements, except for the ‘TrackingIdentifier’, ‘FindingSite’ and ‘ReferencedSegment’.

Yes, this makes sense.

I would also like to report the mean attenuation in the liver divided by mean attenuation in the spleen (this relates to liver fat content). I was wondering if it is currently possible to define a measurement group that refers to multiple ‘ReferencedSegments’, and if so how?

This is an interesting question that did not come up before. I do not know the answer, so below are just my thoughts.

No, I don't think it is allowed by the standard to refer to multiple segments while describing a single measurements: row 7 in TID 1411 has VM of 1.

There is TID 1420, which is intended to report measurements derived from multiple ROIs, but from the description of it, it is not clear if it is the right fit for your use case:

This Template encodes measurements for some metric, e.g., density, flow, or concentration, which are acquired over some defined sampling (e.g., over successive time slots in a dynamic contrast enhanced acquisition).

Even if it is, dcmqi currently does not support this specific sub-template.

I think I will need to summon expertise of @dclunie to help with this. Stay tuned, we will get you a more complete answer.

[jeffduda]

Thanks for the fast response. I did notice that for TID 1419 Rows 2,9 the description says: "Finding site may be multiple when a region of interest spans multiple anatomical locations and there is not a single pre-coordinated code describing the combination of locations. E.g., when a malignant, inflammatory or traumatic process spans actual or defined anatomical boundaries. There is no requirement that the multiple locations be contiguous." It wasn't clear (to me) which, if either, of those (TID1419/TID1420) would be appropriate for my case. Looking forward to hearing more.

[fedorov]

Right, multiple finding sites are allowed, but not multiple segments, as far as I can tell. I will respond as soon as I get a chance to discuss with David Clunie.

[dclunie]

Hi Jeffrey

TID 1420 was indeed intended to described derived measurements that are computed from other measurements, assuming that those measurements (and the ROIs from which they are determined) are also recorded.

However:

• it references separate instantiations of the ROI templates using the "by-reference" "R-INFERRED FROM" - i.e., it makes the report a DAG rather than a simple tree

• it references the entire invocation of TID 1410 or TID 1411, each of which may be an ROI with multiple measurements, without specifying which of those multiple measurements is the source of the derivation (i.e., it is probably a flawed design, and should instead reference the source NUM content item within TID 1410 or TID 1411 directly)

I don't know if anyone has ever used TID 1420, or if the dcmqi tool can cope with it.

Alternatively, once could use TID 300 invoked by TID 1501 from TID 1500, which allows for "derivation" in Rows 9 and 10, and in Row 10 in particular could reference the source liver and spleen measurements elsewhere in the tree (also creating a DAG).

The foregoing assumes that you do record the ROI and mean attenuation in the liver, and the ROI and mean attenuation in the spleen, and want to indicate that the derived ratio comes from these.

If so, then you don't need to refer to multiple segments, since each of the source ROIs would refer to its own single segment.

E.g., using TID 300 via TID 1501:

Measurement Group for ROI liver (TID 1410 or 1411) NUM "attenuation" "derivation: mean" lll "[hnsf'U]"

Measurement Group for ROI spleen (TID 1410 or 1411) NUM "attenuation" "derivation: mean" sss "[hnsf'U]"

Measurement Group for other stuff (TID 1501) NUM attenuation ratio = 111/sss "{ratio}" ref: liver NUM above ref: spleen NUM above

David

PS. Note that for the individual organ measurements you can either post-coordinate the concept name:

(112031, DCM, "Attenuation Coefficient") (121401, DCM, "Derivation") = (373098007, SCT, "Mean")

or pre-coordinate it:

(112181, DCM, "Mean Attenuation Coefficient")

PPS. For a code for the ratio, I don't know of one specific to the "ratio of the mean attenuation coefficients of the liver and spleen", but there is the generic:

(118586006, SCT, "Ratio")

and you could then rely on the referenced source NUM's own concept name, finding site and derivation modifiers to provide the context.

Alternatively you could make up your own pre-coordinated private code.

On Jeffrey Duda wrote:

I would also like to report the mean attenuation in the liver divided by mean attenuation in the spleen (this relates to liver fat content). I was wondering if it is currently possible to define a measurement group that refers to multiple ‘ReferencedSegments’, and if so how?

On 1/24/20 6:20 PM, Andrey Fedorov wrote:

There is TID 1420 http://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_A.html#sect_TID_1420, which is intended to report measurements derived from multiple ROIs, but from the description of it, it is not clear if it is the right fit for your use case:

[fedorov]

Thank you David for the response.

None of those capabilities (TID1420 or TID300 invoked from TID1501) are supported in dcmqi right now, so we would need to implement this as a new feature.

[jeffduda]

Thanks so much for the detailed response. I would be happy to take a swing at, or help out with, implementing some new features. Based on the discussion above and the fact that dcmtk appears to have existing support to TID300, it seems like that approach may be the best. If there is an appropriate commit you could point me to for a similar issue that would be very helpful (if such an example exists).

[fedorov]

@jeffduda, contributions are most welcomed!

I think the first step would be to dig a bit into dcmtk and confirm all of the features needed for this part are actually implemented. At least when we worked with @jriesmeier, we prioritized specific capabilities of TID 1500 et al based on the use cases we had for the project, so you cannot expect everything to be available.

If dcmtk support is in place, writing this content should be rather easy. It is reading and reconstructing the SR tree that is the hardest (i.e., figuring out what tree element belongs to which template and template component), since you would need to deduce what goes where based on concept names, relative positions of items, etc. At least in the past, when I was adding new functionality, I tried to add both reading and writing at the same time.

I think a relevant PR to consider is this one: https://github.com/QIICR/dcmqi/pull/353. It will also give you the idea of the various pieces involved in adding new functionality (schema update, tests, cmake, read/write).

Let me know what you think!

[jriesmeier]

The documentation of DCMTK's TID1500_MeasurementReport class should provide all information on the supported features (content items and included sub-templates).

[jeffduda]

It looks like the current implementation of TID300 can be integrated relatively easily. It currently lacks implementation for referring to other measurements "by-reference" but it does allow "by-value" so it should be sufficient, though not as elegant as the "by-reference" method. I'll work on getting an initial PR put together, based upon the provided example.

[fedorov]

@jeffduda thank you for investigating!

Before you dive into the implementation, I would want to confirm with @dclunie that it is a good idea to follow the "by-value" approach.

I personally think it is not quite what we would want to have here, since you will not have a way to reference the segments used for the source measurements, and it will probably be problematic to unambiguously communicate that the measurements referenced "by-value" map to the measurements accompanied by links to segments elsewhere in the document. I wonder if it would be better (although, I am sure a lot more difficult) to try to add support for "by-reference" to DCMTK TID 300?

[dclunie]

In the absence of dcmqi support, if you are dependent on dcmqi, I don't see that you have much choice than to use the by-value approach.

Don't forget to validate it with the SR template validator in pixelmed.jar.

[fedorov]

In the absence of dcmqi support, if you are dependent on dcmqi, I don't see that you have much choice than to use the by-value approach.

The choice is between directing efforts to add by-reference capabilities to DCMTK, and then reuse from dcmqi, or to use the by-value approach.

@jeffduda, since David has no objections regarding by-value, please choose whatever approach is more appealing to you!

[jriesmeier]

Actually, DCMTK's underlying SR implementation (module "dcmsr") does support by-reference relationships. So, it is more a question of how to offer this functionality in an easy-to-use way on the higher-level API of SR templates (submodule "dcmsr/cmr").