The request for a Worklist Update is initiated by user interaction, i.e., pressing the buttons "Worklist Update"/"Patient Worklist Query" or automatically at specific time intervals, configurable by the user. With "Worklist Update" the automated query mechanism is performed immediately on request, while with "Patient Worklist Query" a dialog to enter search criteria is opened and an interactive query can be performed.
The interactive Patient Worklist Query will display a dialog for entering data as search criteria. When the Query is started on user request, only the data from the dialog will be inserted as matching keys into the query.
With automated worklist queries (including "Worklist Update") the EXAMPLE-INTEGRATED-MODALITY always requests all items for a Scheduled Procedure Step Start Date (actual date), Modality (RF) and Scheduled Station AE Title. Query for the Scheduled Station AE Title is configurable by a Service Engineer.
Upon initiation of the request, the EXAMPLE-INTEGRATED-MODALITY will build an Identifier for the C-FIND request, will initiate an Association to send the request and will wait for Worklist responses. After retrieval of all responses, EXAMPLE-INTEGRATED-MODALITY will access the local database to add or update patient demographic data. To protect the system from overflow, the EXAMPLE-INTEGRATED-MODALITY will limit the number of processed worklist responses to a configurable maximum. During receiving the worklist response items are counted and the query processing is canceled by issuing a C-FIND-CANCEL if the configurable limit of items is reached. The results will be displayed in a separate list, which will be cleared with the next worklist update.
EXAMPLE-INTEGRATED-MODALITY will initiate an Association in order to issue a C-FIND request according to the Modality Worklist Information Model.
A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g., a device such as a RIS or HIS that supports the Modality Worklist SOP Class as an SCP) is illustrated in the Figure above:
-
The Worklist AE opens an association with the Departmental Scheduler
-
The Worklist AE sends a C-FIND request to the Departmental Scheduler containing the Worklist Query attributes.
-
The Departmental Scheduler returns a C-FIND response containing the requested attributes of the first matching Worklist Item.
-
The Departmental Scheduler returns another C-FIND response containing the requested attributes of the second matching Worklist Item.
-
The Departmental Scheduler returns another C-FIND response with status Success indicating that no further matching Worklist Items exist. This example assumes that only 2 Worklist items match the Worklist Query.
-
The Worklist AE closes the association with the Departmental Scheduler.
-
The user selects a Worklist Item from the Worklist and prepares to acquire new images.
EXAMPLE-INTEGRATED-MODALITY will propose Presentation Contexts as shown in the following table:
The behavior of EXAMPLE-INTEGRATED-MODALITY when encountering status codes in a Modality Worklist C-FIND response is summarized in the Table below. If any other SCP response status than "Success" or "Pending" is received by EXAMPLEINTEGRATED-MODALITY, a message "query failed" will appear on the user interface.
Table B.4.2-22. Modality Worklist C-FIND Response Status Handling Behavior
The behavior of EXAMPLE-INTEGRATED-MODALITY during communication failure is summarized in the Table below.
Table B.4.2-23. Modality Worklist Communication Failure Behavior
Acquired images will always use the Study Instance UID specified for the Scheduled Procedure Step (if available). If an acquisition is unscheduled, a Study Instance UID will be generated locally.
The Table below provides a description of the EXAMPLEINTEGRATED-MODALITY Worklist Request Identifier and specifies the attributes that are copied into the images. Unexpected attributes returned in a C-FIND response are ignored.
Requested return attributes not supported by the SCP are set to have no value. Non-matching responses returned by the SCP due to unsupported optional matching keys are ignored. No attempt is made it filter out possible duplicate entries.
Note
If an extended character set is used in the Request Identifier, Specific Character Set (0008,0005) will be included in the Identifier with the value "ISO_IR 100" or "ISO_IR 144" (see Section B.6). Otherwise, Specific Character Set (0008,0005) will not be sent
The above tables should be read as follows:
- Module Name
-
The name of the associated module for supported worklist attributes.
- Attribute Name
-
Attributes supported to build an EXAMPLEINTEGRATED-MODALITY Worklist Request Identifier.
- Tag
- VR
- M
-
Matching keys for (automatic) Worklist Update. A "S" will indicate that EXAMPLE-INTEGRATED-MODALITY will supply an attribute value for Single Value Matching, a "R" will indicate Range Matching and a "*" will denote wild card matching. It can be configured if "Scheduled Station AE Title" is additionally supplied "(S) " and if Modality is set to RF or SC.
- R
-
Return keys. An "x" will indicate that EXAMPLE-INTEGRATED-MODALITY will supply this attribute as Return Key with zero length for Universal Matching. The EXAMPLE-INTEGRATED-MODALITY will support retired date format (yyyy.mm.dd) for "Patient's Birth Date" and "Scheduled Procedure Step Start Date" in the response identifiers. For "Scheduled Procedure Step Start Time" also retired time format as well as unspecified time components are supported.
- Q
-
Interactive Query Key. An "x" " will indicate that EXAMPLE-INTEGRATED-MODALITY will supply this attribute as matching key, if entered in the Query Patient Worklist dialog. For example, the Patient Name can be entered thereby restricting Worklist responses to Procedure Steps scheduled for the patient.
- D
-
Displayed keys. An "x" indicates that this worklist attribute is displayed to the user during a patient registration dialog. For example, Patient Name will be displayed when registering the patient prior to an examination.
- IOD
-
An "x" indicates that this Worklist attribute is included into all Object Instances created during performance of the related Procedure Step.
The default Query Configuration is set to "Modality" (RF) and "Date" (date of today). Optionally, additional matching for the own AET is configurable.
After Patient registration, the EXAMPLE-INTEGRATED-MODALITY is awaiting the 1st application of X-Ray Dose to the patient. The trigger to create a MPPS SOP Instance is derived from this event. An Association to the configured MPPS SCP system is established immediately and the related MPPS SOP Instance will be created.
A manual update can be performed with the MPPS user interface where is it possible to set the final state of the MPPS to "COMPLETED" or "DISCONTINUED". In the "Discontinued" case the user can also select the discontinuation reason from a list corresponding to CID 9300 “Procedure Discontinuation Reasons”. A MPPS Instance that has been sent with a state of "COMPLETED" or "DISCONTINUED" can no longer be updated.
The EXAMPLE-INTEGRATED-MODALITY will support creation of "unscheduled cases" by allowing MPPS Instances to be communicated for locally registered Patients.
The EXAMPLE-INTEGRATED-MODALITY only supports a 0-to-1 relationship between Scheduled and Performed Procedure Steps.
EXAMPLE-INTEGRATED-MODALITY will initiate an Association to issue an:
A possible sequence of interactions between the Workflow AE and a Departmental Scheduler (e.g., a device such as a RIS or HIS that supports the MPPS SOP Class as an SCP) is illustrated in Figure B.4.2-4:
-
The Worklist AE opens an association with the Departmental Scheduler
-
The Worklist AE sends an N-CREATE request to the Departmental Scheduler to create an MPPS instance with status of "IN PROGRESS" and create all necessary attributes. The Departmental Scheduler acknowledges the MPPS creation with an N-CREATE response (status success).
-
The Worklist AE closes the association with the Departmental Scheduler.
-
The Worklist AE opens an association with the Departmental Scheduler.
-
The Worklist AE sends an N-SET request to the Departmental Scheduler to update the MPPS instance with status of "COMPLETED" and set all necessary attributes. The Departmental Scheduler acknowledges the MPPS update with an N-SET response (status success).
-
The Worklist AE closes the association with the Departmental Scheduler.
EXAMPLE-INTEGRATED-MODALITY will propose Presentation Contexts as shown in the following table:
The behavior of EXAMPLE-INTEGRATED-MODALITY when encountering status codes in an MPPS N-CREATE or N-SET response is summarized in Table B.4.2-26. If any other SCP response status than "Success" or "Warning" is received by EXAMPLEINTEGRATED-MODALITY, a message "MPPS update failed" will appear on the user interface.
Table B.4.2-26. MPPS N-CREATE / N-SET Response Status Handling Behavior
The behavior of EXAMPLE-INTEGRATED-MODALITY during communication failure is summarized in the Table below:
Table B.4.2-28 provides a description of the MPPS N-CREATE and N-SET request identifiers sent by EXAMPLE-INTEGRATED-MODALITY. Empty cells in the N-CREATE and N-SET columns indicate that the attribute is not sent. An "x" indicates that an appropriate value will be sent. A "Zero length" attribute will be sent with zero length.
Table B.4.2-28. MPPS N-CREATE / N-SET Request Identifier
|
From Modality Worklist or user input (all 5 components). The user can modify values provided via Modality Worklist. |
||||
|
From Modality Worklist or user input. The user can modify values provided via Modality Worklist. |
||||
|
From Modality Worklist or user input. The user can modify values provided via Modality Worklist. |
||||
|
From Modality Worklist or user input. The user can modify values provided via Modality Worklist. |
||||
|
From Modality Worklist or user input. The user can modify values provided via Modality Worklist. |
||||
|
Performed Procedure Step Discontinuation Reason Code Sequence |
If Performed Procedure Step Status (0040,0252) is "DISCONTINUED" then a single item will be present containing a user-selected entry drawn from CID 9300 “Procedure Discontinuation Reasons”. |
|||
|
From Modality Worklist or user input. The user can modify the description provided via Modality Worklist. |
||||
|
From Modality Worklist or user input. The user can modify values provided via Modality Worklist. |
||||