PS-2020a / part04

Some Failure Status Codes are implementation specific.​

An SCP implementation shall assign specific failure status codes by replacing each 'x' symbol with a hexadecimal digit in the range​ from 0 to F. An SCP implementation wishing to differentiate between causes of "Failed: Unable to process" Failure Meaning shall​ assign those causes specific Status Code Values within valid range specified in Table Y.4-2.​

An SCU implementation shall recognize any Failure Status Code within the value range specified in Table Y.4-2 as an indicator of​ the Failure Meaning stated in the table. There is no requirement for an SCU implementation to differentiate between specific Status​ Codes within the valid range.​

Z.4.2.1.5 Number of Remaining Sub-Operations​

Inclusion of the Number of Remaining Sub-operations shall be as specified in Section C.4.3.1.5​

Z.4.2.1.6 Number of Completed Sub-Operations​

Inclusion of the Number of Completed Sub-operations shall be as specified in Section C.4.3.1.6​

Z.4.2.1.7 Number of Failed Sub-Operations​

Inclusion of the Number of Failed Sub-operations shall be as specified in Section C.4.3.1.7​

Z.4.2.1.8 Number of Warning Sub-Operations​

Inclusion of the Number of Warning Sub-operations shall be as specified in Section C.4.3.1.8.​

Z.4.2.2 C-GET SCU and C-STORE SCP Behavior​

Z.4.2.2.1 Baseline Behavior of SCU​

An SCU conveys the following semantics with a C-GET request:​

•​The SCU shall specify one Instance UID or a list of Instance UIDs.​

•​The SCU shall have proposed sufficient presentation contexts at Association establishment time to accommodate expected C-​ STORE sub-operations that will occur over the same Association. The SCU of the Query/Retrieve Service Class shall serve as the​ SCP of the Storage Service Class.​

- Standard -​

•​The SCP of the Storage Service Class shall not store the incomplete SOP Instance; rather the behavior is implementation defined.​

•​TheSCUshallacceptC-GETresponseswithstatusequaltoPendingduringtheprocessingoftheC-STOREsub-operations.These​ responses indicate the number of Remaining, Completed, Failed and Warning C-STORE sub-operations.​

•​The SCU shall interpret a C-GET response with a status equal to Success, Warning, Failure, or Refused as a final response. The​ final response indicates the number of Completed sub-operations and the number of Failed C-STORE sub-operations resulting​ from the C-GET operation. The SCU shall interpret a status of:​

•​Success to indicate that all sub-operations were successfully completed​

•​Failure or Refused to indicate all sub-operations were unsuccessful​

•​Warning in all other cases. The Number of Completed Sub-Operations (0000,1021), Number of Warning Sub-Operations​ (0000,1023), Number of Failed Sub-Operations (0000,1022) can be used to obtain more detailed information.​

•​The SCU may cancel the C-GET operation by issuing a C-GET-CANCEL request at any time during the processing of the C-GET​ request. A C-GET response with a status of Canceled shall indicate to the SCU that the retrieve was canceled. Optionally, the C-​ GET response with a status of Canceled shall indicate the number of Completed, Failed, and Warning C-STORE sub-operations.​ If present, the Remaining sub-operations count shall contain the number of C-STORE sub-operations that were not initiated due​ to the C-GET-CANCEL request.​

•​The SCP of the Storage Service Class shall not return a status of "Error: Data Set does not match SOP Class" (A9xx) or "Warning:​ Data Set does not match SOP Class" (B007) due to the absence of the Attributes described in Section Z.1.3.​

Z.4.2.2.2 Extended Behavior of SCU​

The extended behavior of the SCU shall be as specified in Section C.4.3.2.2, except that Relational-retrieve shall not be supported.​

Z.4.2.3 C-GET SCP and C-STORE SCU Behavior​

Z.4.2.3.1 Baseline Behavior of SCP​

An SCP conveys the following semantics with a C-GET response:​

•​The SCP shall identify a set of Entities at the level of the transfer based upon the values in the Unique Keys in the Identifier of the​ C-GET request.​

•​The SCP shall initiate C-STORE sub-operations for the identified SOP Instances, but shall not include in this C-STORE sub-oper-​ ation the Attributes described in section Section Z.1.3. The SCP of the Query/Retrieve Service Class shall serve as an SCU of the​ Storage Service Class.​

•​ApartfromtheAttributeslistedinsectionSectionZ.1.3,theSOPInstancesentviatheC-STOREsub-operationshallbeunchanged,​ and no corresponding changes to other Attributes shall be made.​

Note​

In particular, the Study, Series and SOP Instance UIDs and SOP Class UID will not be altered.​

•​The SCP shall initiate C-STORE sub-operations over the same Association for all SOP Instances specified in the C-GET request.​

•​A sub-operation is considered a Failure if the SCP is unable to initiate a C-STORE sub-operation because the Query/Retrieve SCU​ did not offer an appropriate presentation context for a given stored SOP Instance.​

•​Optionally, the SCP may generate responses to the C-GET with status equal to Pending during the processing of the C-STORE​ sub-operations.TheseresponsesshallindicatethenumberofRemaining,Completed,Failure,andWarningC-STOREsub-operations.​

•​WhenthenumberofRemainingsub-operationsreacheszero,theSCPshallgenerateafinalresponsewithastatusequaltoSuccess,​ Warning or Failed. The status contained in the C-GET response shall contain:​

•​Success if all sub-operations were successfully completed​

- Standard -​

•​Failure if all sub-operations were unsuccessful​

•​Warning in all other cases.​

•​The SCP may receive a C-GET-CANCEL request at any time during the processing of the C-GET request. The SCP shall interrupt​ all C-STORE sub-operation processing and return a status of Canceled in the C-GET response. The C-GET response with a status​ of Canceled shall contain the number of Completed, Failed, and Warning C-STORE sub-operations. If present, the Remaining sub-​ operations count shall contain the number of C-STORE sub-operations that were not initiated due to the C-GET-CANCEL request.​

•​If the SCP manages images in multiple alternate encodings (see Section C.6.1.1.5.1), only one of the alternate encodings of an​ image shall be used as the existing SOP Instance from which frames are to be extracted.​

Z.4.2.3.2 Extended Behavior of SCP​

The extended behavior of the SCP shall be as specified in Section C.4.3.3.2, except that Relational-retrieve shall not be supported.​

Z.5 Association Negotiation​

Association establishment is the first phase of any instance of communication between peer DICOM AEs. AEs supporting DICOM​ Query/Retrieve SOP Classes utilize Association establishment negotiation by defining the use of Application Association Information.​ See PS3.7 for an overview of Association negotiation.​

SOP Classes of the Composite Instance Retrieve Without Bulk Data Service, which include retrieval services based on the C-GET​ operation, use the SCP/SCU Role Selection Sub-Item to identify the SOP Classes that may be used for retrieval.​

Z.5.1 Association Negotiation for C-GET SOP Classes​

Rules are as specified in Section C.5.3, except that the extended negotiation sub-item, if used, shall be used as defined in Sec-​ tion Y.5.1.1.​

Note​

1.​Though converted images may be specified by their SOP Instance UID in the Request Identifier, which is always at the​ instance level, there remains a need for extended negotiation and specification of the Query/Retrieve View in order to​ assurethatreferentialintegrityismaintainedwithinthereturnedSOPInstances(e.g.,thatareferencetoaSOPInstance​ UID is to a converted image or not, as appropriate).​

2.​Relational-retrieval is not applicable to this SOP Class, hence the Extended Negotiation Sub-Item does not include the​ use of that byte.​

Z.6 SOP Class Definitions​

Z.6.1 Composite Instance Retrieve Without Bulk Data SOP Class Group​

In the Composite Instance Retrieve Without Bulk Data Only Information Model, only a single Retrieve Level is used.​

Table Z.6.1-1. Retrieve Level Value for Retrieve Without Bulk Data​

The use of the word "IMAGE" rather than "Composite Instance" is historical to allow backward compatibility with previous​ editions of the Standard. It should not be taken to mean that Composite Instances of other than image type are not included​ at the level indicated by the value IMAGE.​

- Standard -​

Z.6.1.1 Composite Instance Retrieve Without Bulk Data Information Model​

Z.6.1.1.1 E/R Model​

The Composite Instance Retrieve Without Bulk Data Only Information Model has only a single level: IMAGE.​

Z.6.1.1.2 Composite Instance Level​

Table Z.6-1 defines the keys at the Composite Instance level of the Composite Instance Retrieve Without Bulk Data Query/Retrieve​ Information model.​

TableZ.6-1.CompositeInstanceLevelKeysfortheCompositeInstanceRootQuery/RetrieveInformation​

Model​

Z.6.1.1.3 Scope of the C-GET Commands and Sub-Operations​

A C-GET request may only be performed at the IMAGE level of the Query/Retrieve Model. A C-GET indicates that selected individual​ Composite Instances, without bulk data Attributes shall be transferred.​

Z.6.1.2 Conformance Requirements​

An implementation may conform to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group​ as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.​

Z.6.1.2.1 SCU Conformance​

An implementation that conforms to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group​ as an SCU shall support retrievals against the Query/Retrieve Information Model described in Section Z.6.1.1 using the C-GET SCU​ BehaviordescribedinSectionZ.4.2.2.AnimplementationthatconformstooneoftheSOPClassesoftheCompositeInstanceRetrieve​ WithoutBulkDataSOPClassGroupasanSCU,andthatgeneratesretrievalsusingtheC-GEToperation,shallstateinitsConformance​ Statement the Storage Service Class SOP Classes under which it shall support the C-STORE sub-operations generated by the C-​ GET.​

Z.6.1.2.2 SCP Conformance​

An implementation that conforms to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group​ as an SCP shall support retrievals against both levels of the Retrieve Information Model described in Section Z.6.1.1 using the C-​ GETSCPBehaviordescribedinSectionZ.4.2.3.AnimplementationthatconformstooneoftheSOPClassesoftheCompositeInstance​ Retrieve Without Bulk Data SOP Class Group as an SCP, and that satisfies retrievals using the C-GET operation, shall state in its​ ConformanceStatementtheStorageServiceClassSOPClassesunderwhichitshallsupporttheC-STOREsub-operationsgenerated​ by the C-GET.​

Z.6.1.3 SOP Classes​

The SOP Classes in the Composite Instance Retrieve Without Bulk Data SOP Class Group of the Query/Retrieve Service Class​ identify the Composite Instance Retrieve Without Bulk Data Only Information Model, and the DIMSE-C operations supported. The​ Standard SOP Classes are listed in Table Z.6.1.3-1.​

Table Z.6.1.3-1. SOP Classes for Composite Instance Query/Retrieve Root​

- Standard -​

AA Ophthalmic Refractive Measurements​

Storage SOP Classes (Normative)​

AA.1 Scope​

Refractive instruments are the most commonly used instruments in eye care. At present many of them have the capability for digital​ output,buttheirdataismostoftenaddressedbymanualinputintoapaperorelectronicrecord.Lensometry,Autorefraction,Keratometry,​ Subjective Refraction, and Visual Acuity Measurements Storage SOP Classes support devices such as lensometers, auto-refractors,​ keratometers, autophoropters, and autoprojectors.​

AA.2 Behavior of a SCP​

For a device that is both a SCU and a SCP of the aforementioned Storage SOP Classes, in addition to the behavior for the Storage​ Service Class specified in Section B.2.2, the following additional requirements are specified for Structured Reporting Storage SOP​ Classes:​

•​A SCP of these SOP Class shall support Level 2 Conformance as defined in Section B.4.1.​

Note​

ThisrequirementmeansthatallType1,Type2,andType3AttributesdefinedintheInformationObjectDefinitionandPrivate​ Attributes associated with the SOP Class will be stored and may be accessed.​

- Standard -​

- Standard -​

BB Implant Template Query/Retrieve Service​

Classes​

BB.1 Overview​

BB.1.1 Scope​

The Implant Template Query/Retrieve Service Classes define application-level classes-of-service that facilitate access to Implant​ Template and Implant Assembly Template composite objects.​

BB.1.2 Conventions​

KeyAttributesservetwopurposes;theymaybeusedasMatchingKeyAttributesorasReturnKeyAttributes.MatchingKeyAttributes​ may be used for matching (criteria to be used in the C-FIND request to determine whether an entity matches the query). Return Key​ AttributesmaybeusedtospecifydesiredreturnAttributes(whatelementsinadditiontotheMatchingKeyAttributeshavetobereturned​ in the C-FIND response).​

Note​

Matching Keys are typically used in an SQL 'where' clause. Return Keys are typically used in an SQL 'select' clause to​ convey the Attribute Values.​

Matching Key Attributes may be of Type "required" (R) or "optional" (O). Return Key Attributes may be of Type 1, 1C, 2, 2C, 3 as​ defined in PS3.5.​

BB.1.3 Query/Retrieve Information Model​

In order to serve as an SCP of the Implant Template Query/Retrieve Service Class, a DICOM AE possesses information about the​ Attributes of a number of Implant Template or Implant Assembly Template composite SOP Instances. The information is organized​ into an Information Model. The Information Models for the different SOP Classes specified in this Annex are defined in Section BB.6.​

BB.1.4 Service Definition​

Two peer DICOM AEs implement a SOP Class of an Implant Template or Implant Assembly Template Query/Retrieve Service Class​ with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Implant Template and Implant Assembly​ Template Query/Retrieve Service Classes are implemented using the DIMSE-C C-FIND, C-MOVE and C-GET services as defined​ in PS3.7.​

An SCP of this SOP Class shall support Level-2 conformance as defined in Section B.4.1.​

The semantics of the C-FIND service are the same as those defined in the Service Definition of the Basic Worklist Management​ Service Class.​

The semantics of the C-MOVE service are the same as those defined in the Service Definition of the Query/Retrieve Service Class,​ with the exception that there is only one level of retrieval.​

The semantics of the C-GET service are the same as those defined in the Service Definition of the Query/Retrieve Service Class,​ with the exception that there is only one level of retrieval.​

BB.2 Implant Template Information Models Definitions​

The Implant Template, Implant Assembly Template, and Implant Template Group Information Models are identified by the SOP Class​ negotiated at Association establishment time. Each SOP Class is composed of both an Information Model and a DIMSE-C Service​ Group.​

- Standard -​

The Implant Template, Implant Assembly Template, and Implant Template Group Information Models are defined in Section BB.6,​ with the Entity-Relationship Model Definition and Key Attributes Definition analogous to those defined in the Worklist Information​ Model Definition of the Basic Worklist Management Service.​

BB.3 Implant Template Information Models​

The Implant Template Information Models are based upon a one level entity:​

•​Implant Template object instance.​

The Implant Template object instance contains Attributes associated with the Implant Template object IE of the Composite IODs as​ defined in PS3.3.​

The Implant Assembly Template Information Model is based upon a one level entity:​

•​Implant Assembly Template object instance.​

The Implant Assembly Template object instance contains Attributes associated with the Implant Assembly Template object IE of the​ Composite IODs as defined in PS3.3.​

The Implant Assembly Group Information Model is based upon a one level entity:​

•​Implant Template Group object instance.​

The Implant Template Group object instance contains Attributes associated with the Implant Template Group object IE of the Com-​ posite IODs as defined in PS3.3.​

BB.4 DIMSE-C Service Groups​

BB.4.1 C-FIND Operation​

See the C-FIND Operation definition for the Basic Worklist Management Service Class (K.4.1), and substitute "Implant Template" for​ "Worklist". The "Worklist" Search Method shall be used.​

The SOP Class UID identifies the Implant Template or Implant Assembly Template, respectively Information Model against which the​ C-FIND is to be performed. The Key Attributes and values allowable for the query are defined in the SOP Class definitions for the​ Implant Template and Implant Assembly Template Information Model.​

BB.4.1.1 Service Class User Behavior​

When receiving several Implant Template Instances with the same Implant Part Number, the receiving application shall use Effective​ DateTime (0068,6226) to determine the appropriate Instance.​

BB.4.1.2 Service Class Provider Behavior​

An SCP of this SOP Class shall support Level-2 conformance as defined in Section B.4.1.​

BB.4.2 C-MOVE Operation​

See the C-MOVE Operation definition for the Query/Retrieve Service Class (C.4.2). No Extended Behavior or Relational-Retrieve is​ defined for the Implant Template and Implant Assembly Template Query/Retrieve Service Classes.​

Query/Retrieve Level (0008,0052) is not relevant to the Implant Template and Implant Assembly Template Query/Retrieve Service​ Classes, and therefore shall not be present in the Identifier. The only Unique Key Attribute of the Identifier shall be SOP Instance UID​ (0008,0018). The SCU shall supply one UID or a list of UIDs.​

Note​

More than one entity may be retrieved, using List of UID matching.​

- Standard -​

BB.4.3 C-GET Operation​

See the C-GET Operation definition for the Query/Retrieve Service Class (C.4.2). No Extended Behavior or Relational-Retrieve is​ defined for the Implant Template and Implant Assembly Template Query/Retrieve Service Classes.​

Note​

More than one entity may be retrieved, using List of UID matching.​

BB.5 Association Negotiation​

See the Association Negotiation definition for the Basic Worklist Management Service Class (K.5).​

BB.6 SOP Class Definitions​

BB.6.1 Implant Template Information Model​

BB.6.1.1 E/R Models​

The Implant Template Information Model consists of a single entity. In response to a given C-FIND request, the SCP shall send one​ C-FIND response per matching Implant Template Instance.​

Defined

Procedure

Protocol

Figure BB.6-1. Implant Template Information Model E/R Diagram​

The Implant Assembly Template Information Model consists of a single entity. In response to a given C-FIND request, the SCP shall​ send one C-FIND response per matching Implant Assembly Template Instance.​

Implant Assembly

Template

Figure BB.6-2. Implant Assembly Template Information Model E/R Diagram​

The Implant Template Group Information Model consists of a single entity. In response to a given C-FIND request, the SCP shall​ send one C-FIND response per matching Implant Template Group Instance.​

Implant Template

Group

Figure BB.6-3. Implant Template Group Information Model E/R Diagram​

BB.6.1.2 Implant Template Attributes​

BB.6.1.2.1 Generic Implant Template Attributes​

Table BB.6-1 defines the Attributes of the Generic Implant Template Information Model:​

- Standard -​

Page 350​ DICOM PS3.4 2020a - Service Class Specifications​

Table BB.6-1. Attributes for the Implant Template Information Model​

>>Include Table 8-1a “Enhanced SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”​

>Include Table 8-1a “Enhanced SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”​

>Include Table 8-1a “Enhanced SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”​

>Include Table 8-1a “Enhanced SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”​

- Standard -​