PS-2020a / part17

CC Storage Commitment (Informative)​

CC.1 Storage Commitment Examples (Informative)​

This Section and its sub-sections contain examples of ways in which the Storage Commitment Service Class could be used. This is​ not meant to be an exhaustive set of scenarios but rather a set of examples.​

CC.1.1 Push Model Example​

Figure CC.1-1 is an example of the use of the Storage Commitment Push Model SOP Class.​

1.Storage of images, overlays, etc.

2.N-ACTION (request storage commitment)

3.N-EVENT-REPORT (results status)

Figure CC.1-1. Example of Storage Commitment Push Model SOP Class​

Node A (an SCU) uses the services of the Storage Service Class to transmit one or more SOP Instances to Node B (1). Node A then​ issuesanN-ACTIONtoNode B(anSCP)containingalistofreferencestoSOP Instances, requestingthat theSCPtakeresponsibility​ for storage commitment of the SOP Instances (2). If the SCP has determined that all SOP Instances exist and that it has successfully​ completed storage commitment for the set of SOP Instances, it issues an N-EVENT-REPORT with the status successful (3) and a​ list of the stored SOP Instances. Node A now knows that Node B has accepted the commitment to store the SOP Instances. Node​ A might decide that it is now appropriate for it to delete its copies of the SOP Instances. The N-EVENT-REPORT may or may not​ occur on the same Association as the N-ACTION.​

If the SCP determines that committed storage can for some reason not be provided for one or more SOP Instances referenced by​ the N-ACTION request, then instead of reporting success it would issue an N-EVENT-REPORT with a status of completed - failures​ exists. With the EVENT-REPORT it would include a list of the SOP Instances that were successfully stored and also a list of the SOP​ Instances for which storage failed.​

CC.1.2 Pull Model Example (Retired)​

A Pull Model was defined in earlier versions, but has been retired. See PS3.4-2001.​

CC.1.3 Remote Storage of Data by The SCP​

Figure CC.1-3 explains the use of the Retrieve AE Title. Using the push model a set of SOP Instances will be transferred from the​ SCU to the SCP. The SCP may decide to store the data locally or, alternatively, may decide to store the data at a remote location.​ This example illustrates how to handle the latter case.​

- Standard -​

1.N-ACTION (request storage commitment)

2.Transfer of SOP Instances to Node C

3.N-EVENT-REPORT containing the AE Title of Node C (response status)

Figure CC.1-3. Example of Remote Storage of SOP Instances​

Node A, an SCU of the Storage Commitment Push Model SOP Class, informs Node B, an SCP of the corresponding SOP Class, of​ its wish for storage commitment by issuing an N-ACTION containing a list of references to SOP Instances (1). The SOP Instances​ will already have been transferred from Node A to Node B (Push Model) (2). If the SCP has determined that storage commitment has​ been achieved for all SOP Instances at Node C specified in the original Storage Commitment Request (from Node A), it issues an​ N-EVENT-REPORT (3) like in the previous examples. However, to inform the SCU about the address of the location at which the​ data will be stored, the SCP includes in the N-EVENT-REPORT the Application Entity Title of Node C.​

The Retrieve AE Title can be included in the N-EVENT-REPORT at two different levels. If all the SOP Instances in question were​ stored at Node C, a single Retrieve AE Title could be used for the whole collection of data. However, the SCP could also choose not​ to store all the SOP Instances at the same location. In this case the Retrieve AE Title Attribute must be provided at the level of each​ single SOP Instance in the Referenced SOP Instance Sequence.​

This example also applies to the situation where the SCP decides to store the SOP Instances on Storage Media. Instead of providing​ the Retrieve AE Title, the SCP will then provide a pair of Storage Media File-Set ID and UID.​

CC.1.4 Storage Commitment in Conjunction With Use of Storage Media​

Figure CC.1-4 is an example of how to use the Push Model with Storage Media to perform the actual transfer of the SOP Instances.​

1.Storage of images, overlays, etc. on Storage Media by off-line means

2.N-ACTION (request storage commitment) including Storage Media file-set ID/UID

(3) N-EVENT-REPORT (response status)

Figure CC.1-4. Example of Storage Commitment in Conjunction with Storage Media​

Node A (an SCU) starts out by transferring the SOP Instances for which committed storage is required to Node B (an SCP) by off-​ line means on some kind of Storage Media (1). When the data is believed to have arrived at Node B, Node A can issue an N-ACTION​ to Node B containing a list of references to the SOP Instances contained on the Storage Media, requesting that the SCP perform​ storage commitment of these SOP Instances (2). If the SCP has determined that all the referenced SOP Instances exist (they may​ alreadyhavebeenloadedintothesystemortheymaystillresideontheStorageMedia)andthatithassuccessfullycompletedstorage​ commitmentfortheSOPInstances,itissuesanN-EVENT-REPORTwiththestatussuccessful(3)andalistofthestoredSOPInstances​ like in the previous examples.​

If the Storage Media has not yet arrived or if the SCP determines that committed storage can for some other reason not be provided​ foroneormoreSOPInstancesreferencedbytheN-ACTIONrequestitwouldissueanN-EVENT-REPORTwithastatusofcompleted​ - failures exists. With the EVENT-REPORT it would include a list of the SOP Instances that were successfully stored and also a list​ of the SOP Instances for which storage failed. The SCP is not required to wait for the Storage Media to arrive (however it may chose​

- Standard -​

to wait) but is free to reject the Storage Commitment request immediately. If so, the SCU may decide to reissue another N-ACTION​ at a later point in time.​

- Standard -​

- Standard -​

DD Worklists (Informative)​

DD.1 Examples For The Usage of The Modality Worklist (Informative)​

These typical examples of Modality Worklists are provided for informational purposes only.​

•​A Worklist consisting of Scheduled Procedure Step entities that have been scheduled for a certain time period (e.g., "August 9,​ 1995"), and for a certain Scheduled Station AE title (namely the modality, where the Scheduled Procedure Step is going to be​ performed). See Figure DD.1-1.​

•​A Worklist consisting of the Scheduled Procedure Step entities that have been scheduled for a certain time period (e.g., "August​ 9, 1995"), and for a certain Modality type (e.g., CT machines). This is a scenario, where scheduling is related to a pool of modality​ resources, and not for a single resource.​

•​A Worklist consisting of the Scheduled Procedure Step entities that have been scheduled for a certain time period (e.g., "August​ 9, 1995"), and for a certain Scheduled Performing Physician. This is a scenario, where scheduling is related to human resources​ and not for equipment resources.​

•​A Worklist consisting of a single Scheduled Procedure Step entity that has been scheduled for a specific Patient. In this scenario,​ the selection of the Scheduled Procedure Step was done beforehand at the modality. The rationale to retrieve this specific worklist​ is to convey the most accurate and up-to-date information from the IS, right before the Procedure Step is performed.​

The Modality Worklist SOP Class User may retrieve additional Attributes. This may be achieved by Services outside the scope of the​ Modality Worklist SOP Class.​

1.Query IS for Scheduled Procedure Step entities

-specific time period (e.g., April 04, 2014)

-particular Station AE (modality, where the Procedure Step is to be performed)

2. Worklist Response:

- Scheduled Procedure: Step 1

- Requested Procedure: 123

- Imaging Service Request: 5578

- Patient: “JONES”

- Visit: 05081234

REPEAT

... Worklist Response:

- Scheduled Procedure: Step __ - Requested Procedure: __

- Imaging Service Request: __ - Patient: __

- Visit: __

N. Worklist Response:

- Scheduled Procedure: Step n

- Requested Procedure: 345

- Imaging Service Request: 3422

- Patient: “MILLER”

- Visit: 95080476

Network

Boundary

Figure DD.1-1. Modality Worklist Message Flow Example​

DD.2 General Purpose Worklist Example (Informative) (Retired)​

Retired. See PS3.17-2011.​

- Standard -​

- Standard -​

EE Relevant Patient Information Query​ (Informative)​

EE.1 Relevant Patient Information Query Example (Informative)​

The following is a simple and non-comprehensive example of a C-FIND Request for the Relevant Patient Information Query Service​ Class,specificallyfortheBreastImagingRelevantPatientInformationQuerySOPClass,requestingaspecificPatientID,andrequiring​ that any matching response be structured in the form of TID 9000 “Relevant Patient Information for Breast Imaging”.​

The following is a simple and non-comprehensive example of a C-FIND Response for the Relevant Patient Information Query Service​ Class, answering the C-FIND Request listed above, and structured in the form of TID 9000 “Relevant Patient Information for Breast​ Imaging” as required by the Affected SOP Class.​

- Standard -​

- Standard -​

- Standard -​

- Standard -​