One should determine what DICOM functionality is needed based on workflow requirements and specify that to a PACS and Modality provider prior to purchase. The DICOM services based on this workflow can be identified based on use profiles.  It is helpful to specify use profiles, based on intended use and functionality. When specifying the DICOM services, one should define whether a device supports it as a client or server (i.e. Service Class User or Service Class Provider).

 Modality Push application is an example of a Basic Use Profile. It is the most basic DICOM functionality one would need. The requirement is that the modality shall push images for softcopy display, and/or storage to the PACS. It shall function as a Service Class User (SCU) of the DICOM Storage Service and communicate with the remote storage Service Class Provider (SCP) at the receiver (usually the PACS) for sending the images.

Limitations of this profile are that the modality push application does not have a provision to print directly to a networked DICOM compatible printer; previous studies cannot be pulled nor pushed to this device, and patient demographic information from the Information System cannot be made available at this station.  

The application of modality push profile should be limited to, for example, a remote outpatient clinic or an ER for which the scanning protocol is very well known and images of previous studies are not necessary. A major limitation is also the lack of patient demographics (DICOM worklist) which often causes data-inconsistency.

• Service Class User , PACS , Modality , Workflow , Service Class Provider , SCU , SCP , Storage , Modality Push