PS-2020a / part04

Q.4.3.3 SOP Classes​

The Relevant Patient Information Model SOP Classes in the Relevant Patient Information Query Service Class identify the Relevant​ Patient Information Model, and the DIMSE-C operation supported. In some instances a Root template is specified. The Standard​ SOP Classes are defined in Table Q.4-3:​

Table Q.4-3. SOP Classes for the Relevant Patient Information Model​

Note​

The list of Root templates for the General Relevant Patient Information Query is extensible.​

Q.5 Relevant Patient Information Query Example (Informative)​

Moved to PS3.17.​

- Standard -​

- Standard -​

R Instance Availability Notification Service​

Class (Normative)​

R.1 Overview​

R.1.1 Scope​

The Instance Availability Notification Service Class defines an application-level class-of-service that allows one DICOM AE to notify​ another DICOM AE of the presence and availability of SOP instances that may be retrieved. The AE from which such SOP Instances​ can later be retrieved may or may not be the SCU performing the notification.​

Note​

An example of usage of this Service Class is for the receiver of the instances to provide notification of their arrival and​ availability for subsequent workflow steps to a different entity, such as a separate workflow manager.​

The SCU implementation defines the conditions under which it provides the notification. Certain SCUs may provide notification for​ arbitrary sets of SOP Instances, while other SCUs may provide notification when they determine that the instances associated with​ aProcedureSteporaRequestedProcedureareavailable.TheSCUisrequiredtodocumentinitsConformanceStatementthenature​ of its notification decisions (e.g., frequency of notifications, retrieve capabilities and latency, etc.).​

Once the SCU has provided notification about availability of the SOP Instances, the SCP may use that information in directing further​ workflow, such as in populating the Input Information Sequence when forming a Unified Procedure Step. These types of policies are​ outside the scope of this Standard, however, the SCP is required to document these policies in its Conformance Statement.​

The SCU of this Service Class is not required to assure that the study, procedure step or any workflow-related entity is "complete";​ indeed no semantics other than the concept of "availability" is expressed or implied by the use of this service.​

Note​

1.​The Performed Workitem Code Sequence (0040,4019) Attribute of a referenced GP-PPS instance may provide the​ specific description of the work item that triggered the Instance Availability Notification.​

2.​The Instance Availability Notification is typically a service of the composite instance Storage SCP, since that application​ is responsible for making the instances available. The Instance Availability Notification allows that application to report​ the specific Retrieve AE Title, which may differ from the Storage Service AE Title, and may vary with different instance​ SOP Classes, or may vary over time.​

R.2 Conformance Overview​

The Instance Availability Notification Service Class consists of a single SOP Class: the Instance Availability Notification SOP Class.​

The SOP Class specifies Attributes, operations, and behavior applicable to the SOP Class. The conformance requirements shall be​ specified in terms of the Service Class Provider (SCP) and the Service Class User (SCU).​

The Instance Availability Notification Service Class uses the Instance Availability Notification IOD as defined in PS3.3 and the N-​ CREATE DIMSE Service specified in PS3.7.​

R.3 Instance Availability Notification SOP Class​

R.3.1 DIMSE Service Group​

TheDIMSEServicesshowninTable R.3.1-1areapplicableto theInstanceAvailabilityNotificationIODundertheInstanceAvailability​

Notification SOP Class.​

- Standard -​

Page 274​ DICOM PS3.4 2020a - Service Class Specifications​

Table R.3.1-1. DIMSE Service Group Applicable to Instance Availability Notification​

Though the terminology "notification" is used for this Service Class, the notification is in fact performed through Operations​ rather than Notifications.​

R.3.2 Operations​

The Application Entity that claims conformance to this SOP Class as an SCU shall be permitted to invoke the following operations​ and the Application Entity that claims conformance as an SCP shall be capable of providing the following operations.​

R.3.2.1 N-CREATE Instance Availability Notification SOP Instance​

This operation allows an SCU to create an instance of the Instance Availability Notification SOP Class and to provide availability in-​ formation about Instances that are under the control of the SCU. This operation shall be invoked through the DIMSE N-CREATE​ Service.​

R.3.2.1.1 Attributes​

The Attribute list of the N-CREATE is defined as shown in Table R.3.2-1.​

Table R.3.2-1. Instance Availability Notification SOP Class N-CREATE Attributes​

>>Include Table 8-1a “Enhanced SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”​

- Standard -​

R.3.2.1.2 Service Class User​

The SCU shall specify in the N-CREATE request primitive the SOP Class and SOP Instance UIDs of the Instance Availability Notific-​ ation SOP Instance that is created and for which Attribute Values are to be provided.​

The SCU shall provide Attribute Values for the Instance Availability Notification SOP Class Attributes as specified in Table R.3.2-1.​

The use of additional optional Attributes by the SCU is forbidden.​

Note​

The reason for forbidding optional Attributes is to prevent the use of Standard Extended SOP Classes that might add con-​ textual information such as patient and procedure identifiers.​

The encoding rules for Instance Availability Notification Attributes are specified in the N-CREATE request primitive specification in​ PS3.7.​

There are no requirements on when N-CREATE requests are required to be performed.​

In particular, there are no requirements that notification about the availability of the first instance of a Performed Procedure Step or​ Studybeprovideduponitsreception,northatavailabilitynotificationbeprovidedwhenanentiresetofinstancescomprisingacompleted​ Performed Procedure Step or Study are available, though these are typical and common scenarios.​

R.3.2.1.3 Service Class Provider​

The SCP shall return, via the N-CREATE response primitive, the N-CREATE Response Status Code applicable to the associated​ request.​

R.3.2.1.4 Status Codes​

There are no specific status codes. See PS3.7 for response status codes.​

R.3.3 Instance Availability Notification SOP Class UID​

The Instance Availability Notification SOP Class shall be uniquely identified by the Instance Availability Notification SOP Class UID,​ which shall have the value "1.2.840.10008.5.1.4.33".​

R.3.4 Conformance Requirements​

Implementations shall include within their Conformance Statement information as described below.​

An implementation may conform to this SOP Class as an SCU or as an SCP. The Conformance Statement shall be in the format​ defined in Annex A “DICOM Conformance Statement Template (Normative)” in PS3.2.​

R.3.4.1 SCU Conformance​

An implementation that is conformant to this SOP Class as an SCU shall meet conformance requirements for the operations that it​ invokes.​

R.3.4.1.1 Operations​

Any Attributes for which Attribute Values may be provided (using the N-CREATE) by the SCU shall be enumerated in the SCU Con-​ formance Statement. The SCU Conformance Statement shall be formatted as defined in Annex A “DICOM Conformance Statement​ Template (Normative)” in PS3.2.​

- Standard -​

An implementation that conforms to this SOP Class as an SCU shall specify under which conditions during the performance of real-​ world activities it will create the SOP Class Instance.​

The SCU Conformance Statement shall specify what is meant by each reported value of Instance Availability (0008,0056).​

The SCU Conformance Statement shall describe the relationship between the Instance Availability Notification and the Performed​ Procedure Step SOP Classes, if the latter are supported.​

R.3.4.2 SCP Conformance​

An implementation that is conformant to this SOP Class as an SCP shall meet conformance requirements for the operations that it​ performs.​

R.3.4.2.1 Operations​

The SCP Conformance Statement shall be formatted as defined in Annex A “DICOM Conformance Statement Template (Normative)”​

in PS3.2.​

The SCP Conformance Statement shall provide information on the behavior of the SCP (in terms of real world activities) for each re-​ ported value of Instance Availability (0008,0056).​

The SCP Conformance Statement shall describe the behavioral relationship between the Instance Availability Notification and the​ Performed Procedure Step SOP Classes, if the latter are supported.​

- Standard -​

SMediaCreationManagementServiceClass​ (Normative)​

S.1 Overview​

S.1.1 Scope​

The Media Creation Management Service Class defines a mechanism by which an SCU can instruct a device to create Interchange​ MediacontainingasetofCompositeSOPInstancesthathavealreadybeentransferredtothemediacreationdeviceusingtheStorage​ Service Class.​

ThisServiceClassdoesnotaddressarchivalstoragerequirements.Itisintendedonlyforthemanagementofmediacreationdevices.​ ThereisnorequirementbytheStandardthatanSCPofthisServiceClasswillcommittotakingresponsibilityforarchivalofComposite​ Instances, such that an SCU may then discard them. Such behavior is entirely outside the scope of the Standard. In other words,​ Media Creation does not imply Storage Commitment.​

The application profile(s) for the set of instances, which implies the form of the media created (i.e., CD, DVD or MOD), can either be​ left to the discretion of the SCP, or explicitly specified in the media creation request. In the latter case, if the device is unable to create​ the requested profiles, an error shall be returned.​

Note​

1.​More than one profile may be requested or used by default, since the requested set of instances may not be compatible​ with a single profile. DICOM media may always contain instances written by more than one profile. See PS3.2.​

2.​It is the responsibility of the SCU to negotiate and store instances with an appropriate Transfer Syntax should a specific​ Transfer Syntax be required by a requested profile. The SCP is not required to support compression or decompression​ of stored instances in order to convert stored instances into a form suitable for a requested profile. It may do so, if so​ requested, but the level of lossy compression would be at the discretion of the SCP. If the degree of compression is​ important to the application, then the SCU may compress the images before sending them to the SCP.​

The request controls whether or not a label is to be generated on the media, be it from information contained in the instances (such​ as patient demographics) or from text explicitly specified in the request.​

Note​

1.​AnSCPmayormaynotbephysicallycapableoflabelingthemedia.Thiscapabilityisoutsidethescopeofconformance​ to the Standard. Inability to create a label is not an error.​

2.​De-identification of instances (and labels), such as for teaching file media or clinical trial media is the responsibility of​ the SCU and is outside the scope of this service. That is, the SCU must de-identify the composite instances before​ sending them, prior to the media creation request.​

The Service Class contains a limited capability to return status information. A media creation request may initially either fail or be​ accepted. Subsequently, the SCP may be polled as to the status of the request (idle, pending/creating, successful or failed) by the​ SCU on the same or on a separate Association. There is no asynchronous notification. There is no dependence on the duration or​ persistence of an Association.​

Note​

There is no requirement to manage the handling of transient failures (such as an empty supply of blank media or labels or​ ink). Whether or not the SCP queues stored instances and requests in such cases, or fails to accept the request, is outside​ the scope of the Standard.​

S.2 Conformance Overview​

The application-level services addressed by this Service Class are specified via the Media Creation Management SOP Class.​

- Standard -​

TheMediaCreationManagementSOPClassspecifiesAttributes,operationsandbehaviorapplicabletotheSOPClass.Theconform-​ ance requirements shall be specified in terms of the Service Class Provider (SCP) and the Service Class User (SCU).​

The Media Creation Management Service Class uses the Media Creation Management IOD as defined in PS3.3 and the N-CREATE,​ N-ACTION and N-GET Services specified in PS3.7.​

S.2.1 Association Negotiation​

AssociationestablishmentisthefirstphaseofanyinstanceofcommunicationbetweenpeerDICOMAEs.TheAssociationnegotiation​ rules as specified in PS3.7 shall be used to negotiate the supported SOP Classes.​

Support for the SCP/SCU role selection negotiation is not applicable. The SOP Class Extended Negotiation is not defined for this​ Service Class.​

S.3 Media Creation Management SOP Class​

The SCU transmits the SOP Instances to the SCP using the Storage Service Class. The request for media creation is transmitted to​ theSCPandcontainsalistofreferencestooneormoreSOPInstances.Successorfailureofmediacreationissubsequentlyindicated​ by the SCU requesting the status from the SCP on the same or a separate association.​

S.3.1 DIMSE Service Group​

The following DIMSE-N Services are applicable to the Media Creation Management SOP Class.​

Table S.3.1-1. DIMSE Service Group Applicable to Media Creation Management​

S.3.2 Operations​

The DICOM AEs that claim conformance to this SOP Class as an SCU shall invoke the N-CREATE and the N-ACTION operations.​ The DICOM AEs that claim conformance to this SOP Class as an SCP shall support the N-CREATE, the N-ACTION and the N-GET​ operations.​

S.3.2.1 Create a Media Creation Request​

The Create a Media Creation Request operation allows an SCU to create an instance of the Media Creation Management SOP Class​ and initialize Attributes of the SOP Class. The SCP uses this operation to create a new media creation request containing the set of​ SOP Instances that shall be included in the Interchange Media. This operation shall be invoked through the N-CREATE primitive​

S.3.2.1.1 Attributes​

The DICOM AEs that claim conformance to this SOP Class as an SCU may choose to provide a subset of the Attributes maintained​ by the SCP. The DICOM AEs that claim conformance to this SOP Class as an SCP shall support a subset of the Media Creation​ Management specified in Table S.3.2.1.1-1.​

Table S.3.2.1.1-1. Media Creation Management - N-CREATE Attributes​

- Standard -​

S.3.2.1.1.1 Storage Media File-Set Attributes​

Ifpresent,theStorageMediaFile-SetID(0088,0130)andStorageMediaFile-SetUID(0088,0140)shallbeusedonthemediacreated.​ If absent, the media shall contain values generated by the SCP.​

- Standard -​

If the media request will not fit on a single volume (single piece or side of media), then whether or not the SCP ignores Storage Media​ File-Set ID (0088,0130), or uses it as a prefix and appends information to distinguish volumes, is implementation dependent. Different​ values of Storage Media File-Set UID (0088,0140) shall be used for different volumes.​

If multiple copies are requested, the same Storage Media File-Set ID (0088,0130) and Storage Media File-Set UID (0088,0140) shall​ be used on all copies.​

Note​

Care should be taken with multiple copies written to rewritable media that their contents do not diverge even though their​ identifiers are identical.​

S.3.2.1.1.2 Requested Media Application Profile​

The Requested Media Application Profile (2200,000C), if present, shall be used by the SCP for the specified SOP Instance. If absent​ for a particular instance, the choice of Media Application Profile for that instance shall be at the discretion of the SCP.​

Note​

1.​Different Media Application Profiles may be used for different instances on the same piece of media.​

2.​The form of the DICOMDIR directory records that the SCP must create may be significantly influenced by the media​ application profiles used.​

S.3.2.1.1.3 Icon Image Sequence​

The Icon Image Sequence (0088,0200), if present:​

•​shall be used by the SCP for inclusion in the instance-level DICOM Directory Record for the specified SOP Instance, if the Media​ Application Profile requires its inclusion, and the icon supplied by the SCU meets the requirements of the profile​

•​may be used by the SCP for inclusion in the instance-level DICOM Directory Record for the specified SOP Instance, if the Media​ Application Profile does not require its inclusion​

If absent for a particular instance, the choice of Media Application Profile for that instance dictates whether or not the SCP is required​ to create its own Icon Image Sequence (0088,0200) from the contents of the SOP Instance.​

Note​

1.​Some Media Application Profiles require the inclusion of an Icon Image Sequence (0088,0200) in the directory records.​

2.​Some Media Application Profiles specify constraints on the form of the Icon Image Sequence (0088,0200).​

3.​The SCP may choose to extend the Media Application Profile by generating and including icons anyway.​

S.3.2.1.1.4 Labeling​

The SCP may or may not have the capability to print a label on (or for) the media. If it does, then the following SCP behavior shall​ apply and the specified Attributes are required to be supported by the SCP.​

The Label Using Information Extracted From Instances (2200,0001) Attribute is a flag that instructs the SCP whether or not to create​ any label using the Patient and Study information contained within the instances themselves.​

Note​

The SCP may implement whatever it considers to be an appropriate subset of any Attributes of any Modules at the Patient,​ Specimen and Study entities in the DICOM Information Model specified in PS3.3. Typically included are such Attributes as​ Patient Name (0010,0010), Patient ID (0010,0020), Study ID (0020,0010), and Study Date (0008,0020).​

The Label Text (2200,0002) Attribute is additional text that the SCP shall include on any label, either in addition to or instead of any​ extracted demographics, depending on the value of Label Using Information Extracted From Instances (2200,0001).​

The Label Style Selection (2200,0003) Attribute is a code string, which if present, may be used by the SCP to choose one or more​ implementation-dependent styles of labeling.​

- Standard -​