PS-2020a / part02

D.4.3.2 Additional Protocols​

When host names rather than IP addresses are used in the configuration properties to specify presentation addresses for remote​ AEs, the application is dependent on the name resolution mechanism of the underlying operating system.​

D.4.3.3 IPv4 and IPv6 Support​

This product supports both IPv4 and IPv6. It does not utilize any of the optional configuration identification or security features of IPv6.​

D.4.4 Configuration​

All configuration is performed through the use of Java properties file(s) stored in pre-defined locations that are specific to the under-​ lying operating system. Refer to the Release Notes for specific details.​

D.4.4.1 AE Title/Presentation Address Mapping​

The Calling AE Title of the local application is configurable in the preferences file, and is shared by all of the AEs. The mapping of​ thelogicalnamebywhichremoteAEsaredescribedintheuserinterfacetoCalledAETitlesaswellaspresentationaddress(hostname​ or IP address and port number) is configurable in the preferences file.​

D.4.4.2 Parameters​

Table D.4.4-1. Configuration Parameters Table​

- Standard -​

Note​

ThoughtheapplicationcansupportunlimitedPDUsizes,itwillneverofferaMaximumReceivedPDULengthofzero(unlimited)​ since this triggers a bug in some older systems.​

D.5 Media Interchange​

D.5.1 Implementation Model​

D.5.1.1 Application Data Flow​

Figure D.5.1-1. Implementation Model​

The application is a single pure Java application that provides a user interface, network support and media support as a File Set​ Reader.​

Conceptually it may be modeled as the following single AE:​

•​MEDIA-FSR, which loads a user-selected PS3.10 compliant file, which may be a DICOMDIR or an image or spectroscopy object,​ eitherfromthelocalfilesystemorfromPS3.12compliantmediaaccordingtooneoftheGeneralPurposeMediaApplicationProfiles​ of PS3.11 (CD-R or DVD-RAM)​

Ineffect,theapplicationismedia-neutral,sincetheuserisrequiredtobrowseandlocatetheDICOMDIRfile.Furthermore,anyDICOM​ image or spectroscopy object encoded in one of the standard uncompressed Transfer Syntaxes may be loaded, even in the absence​ of a PS3.10 compliant meta-information header, in which case a "best guess" at the Transfer Syntax will be made.​

Compressed Transfer Syntaxes are not supported, which limits the Media Application Profiles supported.​

D.5.1.2 Functional Definitions of AEs​

D.5.1.2.1 MEDIA-FSR​

MEDIA-FSR is activated through the user interface to select directories, images and spectra for display, import into the local database​ or network transmission.​

D.5.1.3 Sequencing of Real-World Activities​

All FSR activities are sequentially initiated in the user interface, and another activity may not be initiated until the prior activity has​ completed.​

D.5.2 AE Specifications​

D.5.2.1 MEDIA-FSR​

MEDIA-FSR provides standard conformance to the Media Storage Service Class.​

Table D.5.2-1. Application Profiles, Activities, and Roles for MEDIA-FSR​

- Standard -​

Note​

The application is media neutral and dependent on the underlying hardware. Any (non-secure) General Purpose Profile can​ be supported.​

D.5.2.1.1 File Meta Information for the Application Entity​

Not applicable, since MEDIA-FSR is not an FSC or FSU.​

D.5.2.1.2 Real World Activities​

D.5.2.1.2.1 Activity - Load Directory or File​

MEDIA-FSR is activated through the user interface when a user selects the File load operation.​

If the loaded file is a DICOMDIR, a browser will be displayed, from which instances may be selected and in turn loaded for display,​ imported into the local database or sent to a remote AE over the network.​

If the file is an image or spectroscopy instance, it will be loaded and displayed.​

D.5.2.1.2.1.1 Application Profile Specific Conformance​

There are no extensions or specializations.​

D.5.3 Augmented and Private Profiles​

D.5.3.1 Augmented Profiles​

None.​

D.5.3.2 Private Profiles​

None.​

D.5.4 Media Configuration​

None.​

D.6 Support of Character Sets​

D.6.1 Overview​

The application supports all extended character sets defined in the DICOM 2002 standard, including single-byte and multi-byte​ character sets as well as code extension techniques using ISO 2022 escapes.​

Support extends to correctly decoding and displaying the correct symbol for all names and strings found in the DICOMDIR, in storage​ instances from media and received over the network, and in the local database.​

No specific support for sorting of strings other than in the default character set is provided in the browsers.​

D.6.2 Character Sets​

In addition to the default character repertoire, the Defined Terms for Specific Character Set in Table D.6.2-1 are supported:​

Table D.6.2-1. Supported Specific Character Set Defined Terms​

- Standard -​

D.6.3 Character Set Configuration​

Whether or not characters are displayed correctly depends on the presence of font support in the underlying operating system. Typ-​ ically, as described in the Release Notes, it may be necessary for the user to add one of the "all Unicode" fonts to their system con-​ figuration in order to correctly display characters that would not typically be used in the default locale.​

D.7 Security​

D.7.1 Security Profiles​

None supported.​

D.7.2 Association Level Security​

None supported.​

Any Calling AE Titles and/or IP addresses may open an Association.​

D.7.3 Application Level Security​

None supported.​

- Standard -​

D.8 Annexes​

D.8.1 IOD Contents​

D.8.1.1 Created SOP Instances​

None.​

D.8.1.2 Usage of Attributes From Received IODs​

No SOP Class specific fields are required.​

The local database, remote query and directory browsers make use of the conventional identification attributes to distinguish patients,​ studies, series and instances. In particular, if two patients have the same value for Patient ID, they will be treated as the same in the​ browser and the local database.​

D.8.1.3 Attribute Mapping​

Not applicable.​

D.8.1.4 Coerced/Modified Fields​

No coercion is performed.​

D.8.2 Data Dictionary of Private Attributes​

No private attributes are defined.​

D.8.3 Coded Terminology and Templates​

ThevalueforCodeMeaningwillbedisplayedforallcodesequences.Nolocallexiconisprovidedtolookupalternativecodemeanings.​

D.8.4 Grayscale Image Consistency​

The high resolution display monitor attached to the product can be calibrated according to the Grayscale Standard Display Function​ (GSDF). The Service/Installation Tool is used together with a luminance meter to measure the Characteristic Curve of the display​ systemandthecurrentambientlight.SeetheproductServiceManualfordetailsonthecalibrationprocedureandsupportedcalibration​ hardware. The result of the calibration procedure is a Monitor Correction LUT that will be active within the display subsystem after a​ system reboot.​

D.8.5 Standard Extended/Specialized/Private SOP Classes​

None​

D.8.6 Private Transfer Syntaxes​

None.​

- Standard -​

- Standard -​

E Conformance Statement Example Print​

Server (Informative)​

Disclaimer:​

ThisdocumentisasampleDICOMConformanceStatementforafictionalPrintServer(SCP)ManagementSystem,calledEXAMPLE-​

PRINT-SERVER-MANAGEMENT (also called Print Server) produced by a fictional vendor called EXAMPLE-IMAGING-PRODUCTS.​

As stated in the annex title, this document is truly informative, and not normative. A conformance statement of an actual product might​ implement additional services and options as appropriate for its specific purpose. In addition, an actual product might implement the​ servicesdescribedinadifferentmannerand,forexample,withdifferentcharacteristicsand/orsequencingofactivities.Inotherwords,​ this conformance statement example does not intend to standardize a particular manner that a product might implement DICOM​ functionality.​

E.0 Cover Page​

Company Name: EXAMPLE-PrintingPRODUCTS.​

Product Name: EXAMPLE-PRINT-SERVER​

Version: 1.0-rev. A.1​

Internal document number: 4226-xxx-yyy-zzz rev 1​

Date: YYYYMMDD​

E.1 Conformance Statement Overview​

This fictional product EXAMPLE-PRINT-SERVER-MANAGEMENT implements the necessary DICOM services to facilitate the Print​ (SCP)ImagingManagementinthehealthcaredepartments,managingPrintimagingoveranetworkonMedicalLaserImagingSystems.​ It enables the capabilities to capture images at any networked DICOM modality and then print them anywhere they're needed in the​ medical facility.​

Furthermore, before sending the images to be printed the EXAMPLE-PRINT-SERVER-MANAGEMENT will apply image processing,​ using presentation parameters and LUT to improve the image presentation quality and consistency. Moreover, it will manage the​ printing presentation format and the Printer queue and Configuration.​

Table E.1-1 provides an overview of the network services supported by EXAMPLE-PRINT-SERVER-MANAGEMENT.​

Table E.1-1. Network Services​

E.2 Table of Contents​

A table of contents shall be provided to assist readers in easily finding the needed information.​

- Standard -​

E.3 Introduction​

E.3.1 Revision History​

Table E.3.1-1. Revision History​

E.3.2 Audience, Remarks, Terms and Definitions, Basics of DICOM Communication, Abbrevi-​ ations, References​

See example text in Section A.3.​

E.3.3 Additional Remarks for This Example​

ThisdocumentisasampleDICOMConformanceStatementcreatedforDICOMPS3.2.Itistobeusedsolelyasanexampletoillustrate​ how to create a DICOM Conformance Statement for a print server system supporting DICOM Print Services. The subject of the doc-​ ument, EXAMPLE-PRINT-SERVER-MANAGEMENT, is a fictional product.​

E.4 Networking​

E.4.1 Implementation Model​

E.4.1.1 Application Data Flow​

This implementation model uses the DICOM Basic Print Management Meta SOP Class to receive studies for the Medical Imager.​ Multiple associations to Print SCUs are supported.​

Figure E.4.1-1. Application Data Flow Diagram​

The Print Server is receiving the Images with the Presentation and Annotation information, it Apply it on the images and creates a​ print-jobwithintheprintqueue,containingoneormorefilmpagescomposedfromimagesselectedbytheclientPrintSCU.Furthermore,​ it also manages the Printer Status and Configuration.​

- Standard -​

E4.1.2 Functional Definition of AEs​

E.4.1.2.1 Functional Definition of Print Server (SCP) Application Entity​

ThePrintServerSystemacquirestheimageswiththedemographicsandpresentationinformationfromtheconnectedPrintComposer​ (SCU)thatisGroupedwithaWorkstationoranArchivedevice.Studiesaretemporarilystoredondisk.Theimagesarethenprocessed​ and formatted and finally queued as a print job on the Printer queue. If the Printer is operating normally, then the film sheets described​ in the print-job will be printed. Changes in the Printer operation status will be detected (e.g., film Magazine empty) and reported back​ to the Print SCU. If the Printer is not operating normally, then the print-job will be set to an error state and can be restarted by the​ user via the job control interface.​

The Print Server Management includes:​

•​DICOM Association and Negotiation Management​

•​Image Buffering​

•​Image Processing (Windowing level, P-LUT, GSDF, Annotation, etc)​

•​Image Formatting (Film sheet format)​

•​Printing​

•​Print Job Status Tracking​

•​Print Status Tracking​

•​Printer Configuration Tracking​

The Printer Status and Configuration can be requested at any time by the Print SCU, while the Print Server will update the Print SCU​ asynchronously whenever the Printer status get changed. Furthermore, the Print Server provides in addition a Service operation of​ checking the networking connectivity to it's Print SCU using the Verification SOP Class.​

- Standard -​

E.4.1.3 Sequencing of Real-World Activities​

** DICOM Printer Status N-GET

1.DICOM Film Session N-CREATE

2.DICOM Presentation LUT N-CREATE

3.DICOM Film Box N-CREATE

4.Create Image Boxes & Annotation Boxes

5.DICOM Image Box N-SET

6.DICOM Annotation Box N-SET

7.DICOM Film Session N-ACTION

(or) 8. DICOM Film Box N-ACTION

9. Create Print Job

10. DICOM Film Session N-DELETE

* DICOM Print Job N-GET

* DICOM Print Job N-EVENT-REPORT

** DICOM Printer Status N-GET

** DICOM Printer Configuration N-GET

** DICOM Printer Status N-EVENT-REPORT

Figure E.4.1-2. Print Server Management Sequence​

Note​

1.​The Print Job N-GET and N-EVENT-REPORT are Asynchronous messages that may occur at any time after the Print​ Job was created.​

2.​The Printer Status & Configuration N-GET and the N-EVENT-REPORT are Asynchronous messages that may occur​ at any time it is needed during the Print sequence.​

The Print Server Management workflow activities in the sequence order as described in Figure E.4.1-2 apply:​ 1.​DICOM Film Session N-CREATE​

2.​DICOM Presentation LUT N-CREATE​ 3.​DICOM Film Box N-CREATE​ 4.​Create Image Boxes & Annotation Boxes​ 5.​DICOM Image Box N-SET​

6.​DICOM Annotation Box N-SET​

7.​DICOM Film Session N-ACTION, A print job is created for each Film Session N-action.​ 8.​DICOM Film Box N-ACTION, A print job is created for each Film Box N-action.​ 9.​Create Print Job​

10.​DICOM Film Session N-DELETE.​

- Standard -​