This operation allows an SCU to instruct an SCP to create a Unified Procedure Step. This operation shall be invoked by the SCU through the DIMSE N-CREATE Service.
An Application Entity that claims conformance to the UPS Push SOP Class as an SCU shall provide all Required Attributes as specified in Table CC.2.5-3. Additional Attributes defined by the UPS IOD may be provided as well.
An Application Entity that claims conformance to the UPS Push SOP Class as an SCP shall support all required Attributes as specified in Table CC.2.5-3. Additional Attributes defined by the UPS IOD may be supported as well.
COMPLETED and CANCELED are Final States for a UPS instance. The attributes and values of the UPS instance must meet certain requirements before it may be placed in either of the Final States.
Note: A UPS instance is in the SCHEDULED state when created. See CC.1.1 for rules governing state transitions.
Attributes shall be valued as indicated by the Final State Codes in the Final State Column of Table CC.2.5-3 before the Procedure Step State (0074,1000) may be set to COMPLETED or CANCELED (i.e. Final State).
Performing systems are encouraged to ensure that the values for all attributes reasonably reflect what was done and the Final State of the UPS. This may include blanking attributes which are permitted to be empty and for which no reasonable value can be determined. The UPS contents should make it clear whether the step was completed, what work was done, what results were produced and whether the results are usable. See PS 3.17 Section GGG.7 for a discussion of methods to convey things like partial completion.
Note: The SCU may choose not to distribute, or otherwise make available, some or all instances created during the procedure step and referenced in the Output Information Sequence (0040,4033).
Final State Codes
|Final State Code||Meaning|
|R||The UPS State shall not be set to COMPLETED or CANCELED if this attribute does not have a value.|
|RC||The UPS State shall not be set to COMPLETED or CANCELED if the condition is met and this attribute does not have a value.|
|P||The UPS State shall not be set to COMPLETED if this attribute does not have a value, but may be set to CANCELED.|
|X||The UPS State shall not be set to CANCELED if this attribute does not have a value, but may be set to COMPLETED.|
|O||The UPS State may be set to either COMPLETED or CANCELED if this attribute does not have a value.|
To reduce the size and complexity of Table CC.2.5-3, a macro notation is used.
For example, in Table CC.2.5-3, a table entry specifying “Include Code Sequence Macro Table CC.2.5-2a” should be interpreted as including the following table of text as a substitution. The nesting level for the sequence inclusion is indicated by the nesting level on the reference to the macro. Where the matching key type requirement is “*” it should be replaced with the matching key type requirement of the sequence attribute that incorporates this macro.
For code sequences that have requirements for N-CREATE, N-SET, N-GET, or C-FIND behavior that differ from the Macro, the code sequence contents are explicitly listed in the Table rather than specifying inclusion of the Macro.
Table CC.2.5-2aUPS Code Sequence Macro
Table CC.2.5-2c Referenced Instances and Access Macro
|>Assigning Jurisdiction Code Sequence||(0040,0039)|
|>Assigning Agency or Department Code Sequence||(0040,003A)|
Table CC.2.5-2f SOP Instance Reference Macro
|Specific Character Set|
|Scheduled Procedure Step Priority|
|Scheduled Station Name Code Sequence|
|Scheduled Station Class Code Sequence|
|Scheduled Station Geographic Location Code Sequence|
|Scheduled Human Performers Sequence|
|>Human Performer’s Name|
|Comments on the Scheduled Procedure Step|
|Study Instance UID|
|Other Patient IDs Sequence|
|Patient’s Birth Date|
|Admitting Diagnoses Description|
|Referenced Request Sequence|
|>Placer Order Number/Imaging Service Request|
|>Filler Order Number/Imaging Service Request|
|>Requested Procedure ID|
|>Reason for the Requested Procedure|
|>Requested Procedure Comments|
|Procedure Step State|
|Unified Procedure Step Performed Procedure Information Module|
|Unified Procedure Step Performed Procedure Sequence|
|>>Human Performer’s Name|
|>Performed Station Class Code Sequence|
|>Performed Station Geographic Location Code Sequence|
|>Performed Procedure Step Start DateTime|
|>Performed Processing Parameters Sequence|
|>Performed Procedure Step End DateTime|
An SCU uses N-CREATE to request the SCP schedule a new UPS.
The SCU shall specify in the N-CREATE request primitive the UPS Push SOP Class UID and the SOP Instance UID for the UPS which is to be created and for which Attribute Values are to be provided. See CC.3.1 for further discussion of UPS SOP Class UIDs.
The SCU shall provide Attribute values in the N-CREATE request primitive for all required UPS Attributes as specified in Table CC.2.5-3. Additionally, values may be provided for optional Attributes as specified in Table CC.2.5-3.
The SCU shall specify a value of “SCHEDULED” for the attribute Procedure Step State (0074,1000) in the N-CREATE request primitive.
The SCP shall create and maintain UPS instances as instructed by N-CREATE requests and as specified by Table CC.2.5-3.
The SCP shall return, via the N-CREATE response primitive, the N-CREATE Response Status Code applicable to the associated request.
The SCP shall accept N-CREATE request primitives only if the value of the Procedure Step State (0074,1000) attribute is “SCHEDULED”. If the Procedure Step State attribute has another value, the SCP shall fail the N-CREATE.
The SCP may modify Attributes of a UPS instance, e.g., to correct invalid attribute values. A description of the modifications the SCP may perform shall be documented in the conformance statement of the SCP.
The SCP may also create and maintain UPS instances without receiving a UPS instance N-CREATE request, e.g., based on internal logic, operator inputs or HL7 messages. The contents of the instance created by the SCP must still comply with the N-CREATE requirements in Table CC.2.5-3.
Upon creating a new UPS Instance, the SCP shall update UPS Subscription Status of the Instance for each AE with a Global Subscription as described in CC.2.3.
Upon creating a new UPS Instance, the SCP shall send UPS State Reports (if it supports the UPS Event SOP Class) as described in CC.2.4.3 regardless of whether the creation was based on an N-CREATE or on internal logic.
Bi-directional Authentication of machines/users/applications is possible at association time (see PS 3.7 and PS 3.15). PS 3.7 provides a “Refused: Not Authorized” error code. There are no specific requirements to perform authorization.
The status values which are specific for this DIMSE operation are defined in Table CC.2.5-4.
|Success||The UPS was created as requested||0000|
|Warning||The UPS was created with modifications||B300|
|Failure||Refused: The provided value of UPS State was not “SCHEDULED”.||C309|