FFF.2.5.1.4 Example

In this example, the operator identifies the position (i, j) of an object of interest projected on the stored pixel data of an image A, and estimates the magnification of the conic projection by a calibration process.

The operator wants to know the position of the projection of such object of interest on a second image B acquired under different geometry.

The attributes that define the geometry of both images A and B are described in the following figure:

Image A Image B
Columns (0028,0011) = 850 = 1000
Positioner Type (0018,1508) = CARM = CARM
C-arm Positioner Tabletop Relationship (0018,9474) = YES = YES
Detector Binning (0018,701A) = 1.0\1.0 = 2.0\2.0
Detector Element Spacing (0018,7022) = 0.2\0.2 = 0.2\0.2
Detector Active Shape (0018,7024) = RECTANGLE = RECTANGLE
Detector Active Dimension(s) (0018,7026) = 400.0\400.0 = 400.0\400.0
Detector Active Origin (0018,7028) = 25.0\25.0 = 25.0\25.0
Physical Detector Size (0018,9429) = 410.0\410.0 = 410.0\410.0
Position of Isocenter Projection (0018,9430) = 1024.5\1024.5 = 1024.5\1024.5
>Field of View Sequence (0018,9432)
Item 1
Item 1
Item 1
Minimal Scheduler
Worklist Manager
Push Performer
Pull Performer X Self Scheduled Pull Performer X X A system that implements UPS Watch as an SCP will also need to implement UPS Event as an SCP to be able to send Event Reports to the systems from whom it accepts subscriptions. GGG.2.2 Typical Pull Workflow This example shows how a typical pull workflow could be used to manage the work of a 3D Lab. A group of 3D Workstations query a 3D Worklist Manager for work items which they perform and report their progress. In this example, the RIS would be a “Typical Scheduler”, the 3D Workstation is a “Pull Performer” as seen in Table GGG.1-1 and the PACS and Modality do not implement any UPS SOP Classes. We will assume the RIS decides which studies require 3D views and puts them on the worklist once the acquiring modality has reported it’s MPPS complete. The RIS identifies the required 3D views and lists the necessary input objects in the UPS based on the image references recorded in the MPPS. Assume the RIS has subscribed globally for all UPS instances managed by the 3D Worklist Manager. [pic] Figure GGG.2-1 Diagram of Typical Pull Workflow GGG.2.3 Reporting Workflow with “Hand-off” This example shows a reporting workflow with a “hand-off”. Reporting Workstations query a RIS for work items to interpret/report. In this example, the RIS is a “Worklist Manager”, the Reporting Workstation is both a “Pull Performer” and a “Minimal Scheduler” as shown in Table GGG.1-1 and the PACS and Modality do not implement any UPS SOP Classes. A reporting workstation claims Task X but can’t complete it and “puts it back on the worklist” by canceling Task X and creating Task Y as a replacement, recording Task X as the Replaced Procedure Step. Assume the RIS is picking up where example GGG.2.2 left off and was waiting for the 3D view generation task to be complete before putting the study on the reading worklist. The RIS identifies the necessary input objects in the UPS based on the image references recorded in the acquisition MPPS and the 3D UPS. [pic] Figure GGG.3-1 Diagram of Reporting Workflow You could also imagine the 3D workstation is a Mammo CAD workstation. If the first radiologist completed the report, the RIS could easily schedule Task Y as the over-read by another radiologist. For further discussion, refer to the Section GGG.2.7 material on Hand-offs, Fail-overs and Putting Tasks Back on the Worklist. GGG.2.4 Third Party Cancel Cancel requests are always directed to the system managing the UPS instance since it is the SCP. When the UPS is being managed by one system (for example a Treatment Management System) and performed by a second system (for example a Treatment Delivery System), a third party would send the cancel request to the TMS and cancellation would take place as shown below. Performing SCUs are not required to react to cancel requests, or even to listen for them, and in some situations would be unable to abort the task represented by the UPS even if they were listening. In the diagram below we assume the performing SCU is listening, willing, and able to cancel the task. If the User had sent the cancel request while the UPS was still in the SCHEDULED state, the SCP (i.e. the TMS) could simply have canceled the UPS internally. Since the UPS state was IN PROGRESS, it was necessary to send the messages as shown. Note that since the TDS has no need for the UPS instance to persist, it subscribed without setting a Deletion Lock, and so it didn’t need to bother unsubscribing later. [pic] Figure GGG.4-1 Diagram of Third Party Cancel GGG.2.5 Radiation Therapy Dose Calculation Push Workflow In this example, users schedule tasks to a shared dose calculation system and need to track progress. This example is intended as a demonstration of UPS and should not be taken as prescriptive of RT Therapy procedures. Pushing the tasks avoids problems with a pull workflow such as the server having to continually poll worklists on (a large number of) possible clients; needing to configure the server to know about all the clients; reporting results to a user who might be at several locations; and associating the results with clients automatically. Also, when performing machines each have unique capabilities, the scheduling must target individual machines, and there can be advantages for integrating the scheduling and performing activities like this. Although not shown in the diagram, the User could have gone to a User Terminal (“Watcher”) and monitored the progress from there by doing a C-FIND and selecting/subscribing to Task X. [pic] Figure GGG.5-1 Diagram of Radiation Therapy Planning Push Workflow In a second example, the User monitors progress from another User Terminal (“Watcher”) and decides to request cancellation after 3 beams. [pic] Figure GGG.5-2 Diagram of Remote Monitoring and Cancel GGG.2.6 X-Ray Clinic Push Workflow In this example, arriving patients are admitted at the RIS and sent to a specific X-Ray room for their exam. The RIS is shown here subscribing globally for events from each Room. Alternatively the RIS could subscribe individually to each Task right after the N-CREATE is requested. It is left open whether the patient demographics have been previously registered and the patients scheduled on the RIS or whether they are registered on the RIS when they arrive. [pic] Figure GGG.6-1 Diagram of X-Ray Clinic Push Workflow GGG.2.7 Other Examples A wide variety of workflow methods are possible using the UPS SOP Classes. In addition to those diagrammed in the previous sections, a few more are briefly described here. These include examples of ways to handle unscheduled tasks, grouped tasks, append cases, “event forwarding”, etc. Self-Scheduling Push & Pull : Unscheduled and Append Cases In radiation therapy a previously unscheduled ("emergency") procedure may be performed on a Treatment Delivery System. Normally a TDS performs scheduled procedures as a Performing SCU in a Typical Pull Workflow like that shown in GGG.2.2. A TDS that might need to perform unscheduled procedures could additionally implement UPS Push (as an SCU) and push the “unscheduled” procedure to the departmental worklist server then immediately set it IN PROGRESS as a UPS Pull SCU. The initial Push to the departmental server allows the rest of the departmental workflow to “sync up” normally to the new task on the schedule. A modality choosing to append some additional images after the original UPS was completed could use a similar method. Since the original UPS can no longer be modified, the modality could push a new UPS instance to the Worklist Manager and then immediately set it IN PROGRESS. Many of the attribute values in the new UPS would be the same as the original UPS. Note that for a Pull Performer that wants to handle unscheduled cases, this Push & Pull approach is pretty simple to implement. Becoming a UPS Push SCU just requires N-CREATE and N-ACTION (Request Cancel) which are quite similar to the N-SET and N-ACTION it already supports as a UPS Pull SCU. The alternative would be implementing both UPS Watch and UPS Event as an SCP which would be more work. Further, potential listeners would have to be aware of and monitor the performing system to track the unscheduled steps, instead of just monitoring the departmental Pull SCP. Self-Scheduling Performer An example of an alternative method for handling unscheduled procedures is a CAD workstation that decides for itself to perform processing on a study. By implementing UPS Watch as an SCP and UPS Event as an SCP, the workstation can create UPS instances internally and departmental systems such as the RIS can subscribe globally to the workstation to monitor its activities. The workstation might create the UPS tasks in response to having data pushed to it, or potentially the workstation could itself also be a Watch and Event SCU and subscribe globally to relevant modality or PACS systems and watch for appropriate studies. Push Daisy Chain Sometimes the performer of the current task is in the best position to decide what the next task should be. An alternative to centralized task management is daisy-chaining where each system pushes the next task to the next performer upon completion of the current task. Using a workflow similar to the X-Ray Clinic example in GGG.6, a modality could push a task to a CAD workstation to process the images created by the modality. The task would specify the necessary images and perhaps parameters relevant to the acquisition technique. The RIS could subscribe globally with the CAD workstation to track events. Another example of push daisy chain would be for the task completed at each step in a reporting process to be followed by scheduling the next logical task. Hand-offs, Fail-overs and Putting Tasks Back on the Worklist Sometimes the performer of the current task, after setting it to IN PROGRESS, may determine it cannot complete the task and would like the task performed by another system. It is not permitted to move the task backwards to the SCHEDULED state. One approach is for the performer to cancel the old UPS and schedule a new UPS to be pulled off the worklist by another system or by itself at some point in the future. The new UPS would be populated with details from the original. The details of the new UPS, such as the Input Information Sequence (0040,4021), the Scheduled Workitem Code Sequence (0040,4018), and the Scheduled Processing Parameters Sequence (0074,1210), might be revised to reflect any work already completed in the old UPS. By including the “Discontinued Procedure Step rescheduled” code in the Procedure Step Discontinuation Reason Code Sequence (0074,100e) of the old UPS, the performer can allow watchers and other systems monitoring the task to know that there is a replacement for the old cancelled UPS. By referencing the UID of the old UPS in the Replaced Procedure Step Sequence (0074,1224) of the new UPS, the performer can allow watchers and other systems to find the new UPS that replaced the old. A proactive SCP might even subscribe watchers of the old UPS to the new UPS that replaces it. Alternatively, if the performer does not have the capability to create a new UPS, it could include the “Discontinued Procedure Step rescheduling recommended” code in the Procedure Step Discontinuation Reason Code Sequence (0074,100e). A very smart scheduling system could observe the cancellation reason and create the new replacement UPS as described above on behalf of the performer. Another approach is for the performer to “sub-contract” to another system by pushing a new UPS onto that system and marking the original UPS complete after the sub-contractor finishes. Yet another approach would be for the performer to deliver the Locking UID (by some unspecified mechanism) to another system allowing the new system to continue the work on the existing UPS. Coordination and reconciliation would be very important since the new system would need to review the current contents of the UPS, understand the current state, update the performing system information, etc. GGG.3 Other Features GGG.3.1 What was Scheduled vs. What was Performed The performing system for a UPS instance determines what details to put in the attributes of the Performed Procedure Information Module. It is possible that the procedure performed may differ in some details from the procedure scheduled. It is up to the performing system to decide how much the performed procedure can differ from the scheduled procedure before it is considered a different procedure, or how much must be performed before the procedure is considered complete. In the case of cancellation, it is possible that some details of the situation may be undeterminable. Beyond meeting the Final State requirements, accurately reflecting in the CANCELED UPS instance the actual state of the task (e.g. reflecting partial work completed and/or any cleanup performed during cancellation), is at the discretion of the performing system. In general it is expected that: An SCU that completes a UPS differently than described in the scheduled details, but accomplishes the intended goal, would record the details as performed in the existing UPS and set it to COMPLETED. Interested systems may choose to N-GET the Performed Codes from the UPS and confirm whether they match the Scheduled Codes. An SCU that completes part of the work described in a UPS, but does not accomplish the intended goal, would set the Performed Protocol Codes to reflect what work was fully or partially completed, set the Output Sequence to reflect the created objects and set the UPS state to CANCELED since the goal was not completed. An SCU that completes a step with a different intent and scope in place of a scheduled UPS would cancel the original scheduled UPS, listing no work output products, and schedule a new UPS describing what was actually done, and reference the original UPS that it replaces in the Replaced Procedure Step Sequence to facilitate monitoring systems “closing the loop”. An SCU that completes multiple steps, scheduled as separate UPS instances (e.g. a dictation & a transcription & a verification), as a block would individually report each of them as completed. An SCU that completes additional unscheduled work in the course of completing a scheduled UPS would either report additional procedure codes in the completed UPS, or create one or more new UPS instances to record the unscheduled work. GGG.3.2 Complex Procedure Steps There are cases where it may be useful to schedule a complex procedure that is essentially a grouping of multiple workitems. Placing multiple workitem codes in the Scheduled Workitem Code Sequence is not permitted (partly due to the additional complexities that would result related to sequencing, dependency, partial completion, etc.) One approach is to schedule separate UPS instances for each of the component workitems and to identify the related UPS instances based on their use of a common Study UID or Order Number. Another approach is for the site to define a single workitem code that means a pre-defined combination of what would otherwise be separate workitems, along with describing the necessary sequencing, dependencies, etc. GGG.3.3 Gift Subscriptions The UPS Subscription allows the Receiving AE-Title to be different than the AE-Title of the SCU of the N-ACTION request. This allows an SCU to sign up someone else who would be interested for a subscription. For example, a reporting workflow manager could subscribe the RIS to UPSs the reporting workflow manager creates for radiology studies, and subscribe the CIS to UPSs it creates for cardiology studies. Or a RIS could subscribe the MPPS broker or the order tracking system to the high level UPS instances and save them from having independent business logic to determine which ones are significant. This can provide an alternative to systems using global subscriptions to stay on top of things. It also has the benefit of providing a way to avoid having to “forward” events. All interested SCUs get their events directly from the SCP. Instead of SCU A forwarding relevant events to SCU B, SCU A can simply subscribe SCU B to the relevant events.-----------------------
[pic] [pic] [pic] R Establish Baseline B L R R L Change Illumination and Filter L L L L L L L L L L R R ... Drug Injection Acquisition Information A Acquisition Information B Acquisition Information C and drug Information Stereometric Relationship SOP Instance Confirm Stereo Capture Short Term single Eye Angio Capture Long Term Angio Capture OP Sop Instances Stored for: B - Both eyes L - Left eye R - Right eye Pairs of images that are intended for stereo viewing Perfusion Analysis CT/MR Cardiovascular Analysis Report CONTAINER ... TID 1 001 Observation Context Patient Characteristics CONTAINER Patient History CONTAINER Procedure Summary CONTAINER Vascular Morphological Analysis CONTAINER Vascular Functional Analysis CONTAINER Ventricular Analysis CONTAINER Report Summary CONTAINERS Vessel CONTAINERS Vascular Measurements (Vessel Branch) CONTAINERS Lesion Finding CONTAINERS Vessel CONTAINERS Flow Quantification CONTAINER Left Ventricle Analysis CONTAINERS Right Ventricle Analysis CONTAINERS Thickening Analysis CONTAINERS Myocardial Perfusion Analysis CONTAINERS Ventricular Measurements - Absolute CONTAINER Ventricular Measurements - Normalized CONTAINERS Vascular Measurements (Vessel Branch) CONTAINERS Calcium Scoring CONTAINER Calcium Scoring CONTAINER Ventricular Measurements - Normalized CONTAINERS Ventricular Measurements - Absolute CONTAINER a b c d [pic] [pic] ROOT Stress Testing Measurements CONTAINER CONTAINS Patient Characteristics CONTAINER (TID 3602) CONTAINS Patient History CONTAINER (TID 3802) CONTAINS Test Conditions CONTAINER CONTAINS Temporal Phase Findings CONTAINER CONTAINS Procedure Summary CONTAINER CONTAINS Conclusions and Recommendations CONTAINER 1 0 - 1 1 1 - N 0 - 1 0 - 1 CONTAINS Observations NUM, TEXT CONTAINS Observations NUM, CODE, TEXT, DATE 1 - N CONTAINS Stress Monitoring Measurement Group CONTAINER 1 - N CONTAINS Observations NUM, TEXT, CODE 1 - N HAS CONCEPT MOD Phase CODE CONTAINS Comparison to Prior Study CONTAINER 0 - 1 CONTAINS Imaging Measurement Group CONTAINER 1 CONTAINS Observations NUM, TEXT, CODE 1 - N Right Eye Inner Inferior Subfield Outer Inferior Subfield Outer Temporal Subfield Inner Temporal Subfield Outer Superior Subfield Inner Superior Subfield Outer Nasal Subfield Inner Nasal Subfield Center Subfield Center Point Left Eye Inner Inferior Subfield Outer Inferior Subfield Outer Nasal Subfield Inner Nasal Subfield Outer Superior Subfield Inner Superior Subfield Outer Temporal Subfield Inner Temporal Subfield Center Subfield Center Point ROOT Document Title CONTAINER CONT HAS CONCEPT MOD Finding Site CODE CONTAINS Finding CONTAINER CONTAINS Image Entry IMAGE CONTAINS Image Library CONTAINER CONTAINS Measurement Group CONTAINER CONTAINS Observations NUM, CODE CONTAINS Patient Characteristics CONTAINER CONTAINS Observations NUM HAS CONCEPT MOD Target Site CODE HAS CONCEPT MOD Target Site = Cardiac Valve Annulus CONTAINS Cardiac Index NUM HAS CONCEPT MOD Cardiac Cycle Point = End Systole HAS CONCEPT MOD Target Site = Right Superior Pulmonary Vein HAS CONCEPT MOD Cardiac Cycle Point = End Diastole HAS CONCEPT MOD Image Mode = 2D Mode CONTAINS Internal Dimensions NUM CONTAINS A-Wave Duration NUM CONTAINS Tissue Velocity NUM CONTAINS Measurement Group CONTAINER HAS CONCEPT MOD Target Site Modifier = Medial HAS CONCEPT MOD Cardiac Cycle Point = Early Diastole HAS CONCEPT MOD Measurement Method = Teichholz HAS CONCEPT MOD Image Mode = 2D mode 20 30 40 50 60 52.20 mm 1 2 1 2 HPGL Document ID View Orientation
1 MEDIAL-LATERAL
2 ANTERIOR-POSTERIOR

Mating Feature ID: 1
2D Mating Feature Coordinates Sequence
Referenced HPGL Document ID 2D Mating Point 2D Mating Axes
1 6.87 / 44.91 1 / 0 / 0 / 1
2 44.24 / 16.7 0.6947 / 0.7193 / -0.7193 / 0.6947
Mating Feature ID: 2
2D Mating Feature Coordinates Sequence
Referenced HPGL Document ID 2D Mating Point 2D Mating Axes
1 6.87 / 44.23 1 / 0 / 0 / 1
2 43.58 / 16 0.6947 / 0.7193 / -0.7193 / 0.6947

Component Group 2 „Heads“ (Mandatory, Exclusive)

Component Group 1 „Stems“ (Mandatory, Exclusive)

1

2

3

4

5

6

Real-World Implant

Part Number

Implant Template A

ORIGINAL

Version 1

Implant Template A

Manufacturer

Replaced Implant Template

ORIGINAL

Version 2

Implant Template A1

DERIVED

Version 1

Derivation Implant Template

Original Implant Template

Implant Template A1

DERIVED

Version 2

Derivation Implant Template

Original Implant Template

Implant Template A2

DERIVED

Version 2

Derivation Implant Template

Original Implant Template

PACS System Integrator

Replaced Implant Template

issues

issues update

Software Vendor

issues

issues

Bite Plate

Patient(CT Image)

Implant

Dental Drilling Template

Spatial Relation

Spatial Relation

Spatial Relation

Archive

User

Treatment

Management

System (TMS)

Treatment Delivery

System (TDS)

1. ‘List Procedures for Delivery’ on TDS console

2. Query UPS (C-FIND)

3. Receive 0-n UPS

4. ‘Select Procedure’ on TDS console (optional if only one procedure in list)

RT Plan and any other reqd objects

(eg verification images, RT Beam Trmt Recs)

8. ‘Start Treatment Session’ on TDS console

9. Set UPS 0% complete, Beam '1' (N-SET)

13. Change UPS ‘COMPLETED’

(N-ACTION)

11. Store RT Treatment Rec and other result objects (C-STORE)

14. Indicate ‘Treatment Session Completed’ on TDS console

5a. Retrieve Archive objects (C-MOVE)

RT Beams Delivery Instruction

RT Treatment Record Summary

RT Beams Trmt Rec (if not in 5)

7. Retrieve TMS objects (C-MOVE)

DELIVER RADIATION

DELIVER RADIATION

Extract input UIDs from selected UPS

Display list to user

Verify

Verify

9. Set UPS 50% complete, Beam '2' (N-SET)

10. Set UPS 100% complete (N-SET)

Receive UPS details

5. Get UPS details (N-GET)

12. Set UPS to Final State (N-SET)

6. Change UPS ‘IN PROGRESS’(N-ACTION with Transaction UID)

Archive

User

Treatment

Management

System (TMS)

Treatment Delivery

System (TDS)

1. ‘List Procedures for Delivery’ on TDS console

2. Query UPS (C-FIND)

3. Receive 0-n UPS

4. ‘Select Procedure’ on TDS console (optional if only one procedure in list)

RT Plan and any other reqd objects

(e.g. verification images, RT Beam Trmt Recs)

8. ‘Start Treatment Session' on TDS console

9. Set UPS 0% complete, Beam '1' (N-SET)

13. Change UPS ‘COMPLETED’

(N-ACTION)

11. Store other result objects (C-STORE)

14. Indicate ‘Treatment Session Completed’ on TDS console

5a. Retrieve Archive objects (C-MOVE)

RT Beams Delivery Instruction

RT Treatment Record Summary

RT Beams Trmt Rec (if not in 5)

7. Retrieve TMS objects (C-MOVE)

Machine

Parameter

Verifier

External Verification

extensions shown in bold

7a. Communicate UPS and any required

delivery data using a non-specified mechanism

‘8a. Deliver Beam 1’ on TDS console

8b. Create RT Conv. Machine Verification

(N-CREATE)

9a. Set ‘Beam1’ RT Conv. Machine

Verification (N-SET)

9c. Notify Verification Status

(N-EVENT-REPORT, Event Type = ‘Done’,

TVS = VERIFIED)

DELIVER RADIATION

Verify

9e. Store ‘Beam1’ RT Beams Treatment Record (C-STORE)

‘8a. Deliver Beam 2’ on TDS console

DELIVER RADIATION

9e. Store ‘Beam2’ RT Beams Treatment Record (C-STORE)

Extract input UIDs from selected UPS

Display list to user

9. Set UPS 50% complete, Beam '2' (N-SET)

9a. Set ‘Beam2’ RT Conv. Machine

Verification (N-SET)

Verify

9f. Delete RT Conv. Machine Verification

(N-DELETE)

9b. Initiate verification (N-ACTION)

9b. Initiate verification (N-ACTION)

9c. Notify Verification Status

(N-EVENT-REPORT, Event Type = ‘Done’,

TVS = VERIFIED)

9d. Get RT Conv. Machine Verification

(N-GET) – optional instruction

9d. Get RT Conv. Machine Verification

(N-GET) – optional instruction

10. Set UPS 100% complete (N-SET)

Receive UPS details

5. Get UPS details (N-GET)

12. Set UPS to Final State (N-SET)

6. Change UPS ‘IN PROGRESS’(N-ACTION with Transaction UID)