Please explain PS3.3-6.1.1 and PS3.3-6.1.2 - DICOM

This is a discussion on Please explain PS3.3-6.1.1 and PS3.3-6.1.2 - DICOM ; PS3.3-6.1.1 reads: ...When an instance of a Composite IOD is communicated, this entire context is exchanged between Application Entities.... PS3.3-6.1.2 reads: ...When an instance of a Normalized IOD is communicated, the context for that instance is not actually exchanged. Instead, ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Please explain PS3.3-6.1.1 and PS3.3-6.1.2

  1. Please explain PS3.3-6.1.1 and PS3.3-6.1.2

    PS3.3-6.1.1 reads: ...When an instance of a Composite IOD is
    communicated, this entire context is exchanged between Application
    Entities....

    PS3.3-6.1.2 reads: ...When an instance of a Normalized IOD is
    communicated, the context for that instance is not actually exchanged.
    Instead, the context is provided through the use of pointers to
    related Normalized IOD instances.

    If I understand it correctly, 6.1.1 says the composite object has all
    the info needed to fully understand the IOD. But I can't quite figure
    out what 6.1.2 is saying.

    By a "Pointer", Is it saying that where related data is indicated, you
    will find data that identifies another, normalized IOD - like a
    foreign key in a Normalized database? If so, what will that ID look
    like? Is it a UID? (Would make sense because otherwise, how would
    the SCP be able to look this IOD up?)

    Or am I totally missing the point?

  2. Re: Please explain PS3.3-6.1.1 and PS3.3-6.1.2

    sendjunktodp@hotmail.com (Mr. P) wrote in message news:<8cba616e.0410181142.1dfefb14@posting.google.com>...
    > PS3.3-6.1.1 reads: ...When an instance of a Composite IOD is
    > communicated, this entire context is exchanged between Application
    > Entities....
    >
    > PS3.3-6.1.2 reads: ...When an instance of a Normalized IOD is
    > communicated, the context for that instance is not actually exchanged.
    > Instead, the context is provided through the use of pointers to
    > related Normalized IOD instances.
    >
    > If I understand it correctly, 6.1.1 says the composite object has all
    > the info needed to fully understand the IOD. But I can't quite figure
    > out what 6.1.2 is saying.
    >
    > By a "Pointer", Is it saying that where related data is indicated, you
    > will find data that identifies another, normalized IOD - like a
    > foreign key in a Normalized database? If so, what will that ID look
    > like? Is it a UID? (Would make sense because otherwise, how would
    > the SCP be able to look this IOD up?)
    >
    > Or am I totally missing the point?


    Hi Mr. P.

    Actually you got it right. This is one of the reason Normalized SOPs
    are unpopular, the SCP is responsible for keeping track of the
    Affected SOP Instance UIDs of other normalized objects. The pointers
    are always UIDs. And yes they are like FK constraints in an RDBMS.

    With composite IODs you get all the information needed to insert it
    into its place in the real world model.


    dee
    ;-D

  3. Re: Please explain PS3.3-6.1.1 and PS3.3-6.1.2

    > Hi Mr. P.
    >
    > Actually you got it right.


    Many thanks.

    P

+ Reply to Thread