Dear DICOM experts,

I am not 100% sure, but this appears to be a bug in the DICOM Standard.

We are implementing the Performed Imaging Agent Administration SR (PS3.3, A.35.20 and PS2.16, TID 11020).

Table A.35.20.3.1.3 describes the content item relationship constraints for this IOD. As defined by this table, the relationship HAS OBS CONTEXT is not allowed to relate a CONTAINER as a child of a parent CONTAINER.

However, the root template (TID 11020) includes TID 1002 with relationship type HAS OBS CONTEXT and nesting level (NL) 0, which in turn includes TID 1004 (Device Observer Context) with NL 0. Row 10 in TID 1004 inherits the relationship (HAS OBS CONTEXT)
and is a container item.

It this some misconception on my end? Or is this really an inconsistency?

By the way: I wonder why the creators of the standard have chosen to not encapsulate the observer context in a container. Not only would this make it more clear which attributes belong to which observer (and drop the "significant" order of content items),
but it would also allow to convey that the templates TID 1002, 1003 and 1004 are used.

Thank you very much for your guidance,

Markus

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is something we screwed up in CP-1856 when adding (multiple) UDIs in a CONTAINER.

It probably affects every SR IOD since it is a now a general problem with Device Observer Context.

I will put in a CP.

And yes, in retrospect, we could have done a better job of designing observation context in the first place.

David

On Tuesday, October 6, 2020 at 6:42:12 AM UTC-4, marku...@gmail.com wrote:

Dear DICOM experts,

I am not 100% sure, but this appears to be a bug in the DICOM Standard.

We are implementing the Performed Imaging Agent Administration SR (PS3.3, A.35.20 and PS2.16, TID 11020).

Table A.35.20.3.1.3 describes the content item relationship constraints for this IOD. As defined by this table, the relationship HAS OBS CONTEXT is not allowed to relate a CONTAINER as a child of a parent CONTAINER.

However, the root template (TID 11020) includes TID 1002 with relationship type HAS OBS CONTEXT and nesting level (NL) 0, which in turn includes TID 1004 (Device Observer Context) with NL 0. Row 10 in TID 1004 inherits the relationship (HAS OBS CONTEXT)

and is a container item.

It this some misconception on my end? Or is this really an inconsistency?

By the way: I wonder why the creators of the standard have chosen to not encapsulate the observer context in a container. Not only would this make it more clear which attributes belong to which observer (and drop the "significant" order of content

items), but it would also allow to convey that the templates TID 1002, 1003 and 1004 are used.

Thank you very much for your guidance,

Markus

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank you very much for the swift response, David.

Just one question (since we are currently implementing it and have tight schedules as always): I guess the CP will update the relationship constraints in PS3.3 to allow "CONTAINER -> HAS OBS CONTEXT -> CONTAINER" - right?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To whom it may concern: David sent me the CP via e-mail. It will add the relationship CONTAINER -> HAS OBS CONTEXT -> CONTAINER to the relationship constraints tables of all SR IODs. It not available through the DICOM Standard Status page yet.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)