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 indeterminable. 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.
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.
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.