Материал: part02

•​Character set configuration capabilities, if any, shall be specified.​

•​Mapping and/or conversion of character sets across Services and Instances shall be specified.​

•​Query capabilities for attributes that include non-default character sets, both for the Worklist service class and Query service class​ shall be specified. Behavior of attributes using extended character sets by a C-FIND, both as SCU and SCP request and response,​ shall be specified. In particular the handling of Person Names (VR of PN) shall be specified.​

•​The presentation of the characters to a user, i.e., capabilities, font limitations and/or substitutions shall be specified.​

A.8 Security​

A.8.1 Security Profiles​

Any support for Security Profiles as defined in PS3.15 shall be described here. Any extensions to Security Profiles shall be described,​ e.g., extended schema for audit trail messages.​

An implementation shall declare which level of security features it supports, including such things as:​

a.​The conditions under which the implementation preserves the integrity of Digital Signatures (e.g., is the implementation bit-pre-​ serving).​

b.​The conditions under which the implementation verifies incoming Digital Signatures.​

c.​The conditions under which the implementation replaces Digital Signatures.​

d.​IPv6 Security capabilities​

A.8.2 Association Level Security​

Any support for security at the Association level (e.g., allowing only certain AE-titles and/or IP addresses to open an Association)​ shall be specified here.​

A.8.3 Application Level Security​

Any support for additional application level security as it applies to the DICOM communication (e.g., passwords, biometrics) can be​ described here.​

A.9 Annexes​

A.9.1 IOD Contents​

A.9.1.1 Created SOP Instance(s)​

This section specifies each IOD created (including Private IODs). It should specify the Attribute Name, tag, VR, and Value. The Value​ shouldspecifytherangeandsource(e.g.,Userinput,ModalityWorklist,automaticallygenerated,etc.).Forcontentitemsintemplates,​ the range and source of the concept name and concept values should be specified. Whether the value is always present or not shall​ be specified.​

Recommended abbreviations to be used for the tables are:​

VNAP Value Not Always Present (attribute sent zero length if no value is present)​

ANAP Attribute Not Always Present​

ALWAYS Always Present with a value​

EMPTY Attribute is sent without a value​

Recommended abbreviations to be used for the source of the data values in the tables are:​

- Standard -​

USER the attribute value source is from User input​

AUTO the attribute value is generated automatically​

MWL,MPPS, etc. the attribute value is the same as the value received using a DICOM service such as Modality Worklist, Modality​ Performed Procedure Step, etc.​

CONFIG the attribute value source is a configurable parameter​

Specification of a company web address can refer to sample SOP Instances that are available.​

Private attributes should be specified.​

A.9.1.2 Usage of Attributes From Received IODs​

EachApplicationthatdependsoncertainfieldstofunctioncorrectlyshouldspecifywhichonesarerequiredforittoperformitsintended​ function.​

A.9.1.3 Attribute Mapping​

When attributes are used by different SOP Classes, e.g., Modality Worklist, Storage and Modality Performed Procedure Step, this​ mapping shall be specified. For devices that specify other external protocols, such as HL7, mapping of their fields into the DICOM​ attributes is not required but highly recommended.​

A.9.1.4 Coerced/Modified Fields​

ASCUmightcoercecertainAttributes,e.g.,thePatientName.ASCPmightprovideadifferentvalueofanAttributethanwasreceived.​ These changes shall be specified here. An example is Patient Name, which could be modified using available information from either​ an internal database or obtained from an Information System/Information Manager. Another example is the generation of a new SOP​ Instance UID for an existing instance. The conditions influencing such coercion should be specified..​

A.9.2 Data Dictionary of Private Attributes​

Any private Attributes should be specified, including their VR, VM and which are known to be safe from identity leakage. Private SOP​ Classes and Transfer syntaxes should be listed. Whether or not private Attributes are described in Private Data Element Character-​ istics Sequence (0008,0300) should be specified in Section A.9.1 IOD Contents.​

A.9.3 Coded Terminology and Templates​

Support for Coded Terminology and templates shall be described here.​

A.9.3.1 Context Groups​

Each Context Group (i.e., use of coded terminology in a specific context) shall be specified here with its default value set, and​ whether the value set is configurable. The configurable options are specified.​

Table A.9.3-1. Context Groups​

- Standard -​

The Default Value Set may be an extension of a standard context group ("extended CID xxx"). If used, a table shall be provided​ specifying the extended context group, the Context Group Local Version (0008,0107) value and the Context Group Creator UID​ (0008,010D).​

Thissectiondescribesthespecificationofanyprivatecontextgroupsthatareused.Itshallfollowtheformatforcontextgroupsspecified​

in PS3.16.​

A.9.3.2 Template Specifications​

This section specifies any extensions to standard templates and/or any private templates that are used, and defines them. Definitions​ shall follow the format for templates specified in PS3.16​

A.9.3.3 Private Code Definitions​

This section specifies any private codes used and their definitions.​

A.9.4 Grayscale Image Consistency​

Any support for the DICOM Grayscale Standard Display Function will be specified in this section.​

A.9.5 Standard Extended/Specialized/Private SOP Classes​

This section describes Standard Extended SOP Class, Specialized SOP Class, or Private SOP Class that are used.​

A.9.5.1 Standard Extended/Specialized/Private SOP <i>​

This section describes a particular Standard Extended SOP Class, Specialized SOP Class, or Private SOP Class.​

A.9.6 Private Transfer Syntaxes​

This section describes any private Transfer Syntaxes that are listed in the Transfer Syntax Tables.​

A.9.6.1 Private Transfer Syntax <i>​

This section describes particular private transfer syntax. It shall follow the guidelines specified in PS3.5.​

- Standard -​

- Standard -​

BConformanceStatementSampleIntegrated​

Modality (Informative)​

Disclaimer:​

ThisdocumentisanexampleDICOMConformanceStatementforafictionalimageacquisitionmodalitycalledEXAMPLE-INTEGRATED-​ MODALITY 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.​

B.0 Cover Page​

Company Name: EXAMPLE-IMAGING-PRODUCTS.​

Product Name: SAMPLE INTEGRATED MODALITY​

Version: 1.0-rev. A.1​

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

Date: YYYYMMDD​

B.1 Conformance Statement Overview​

This fictional product EXAMPLE-INTEGRATED-MODALITY implements the necessary DICOM services to download work lists from​ an information system, save acquired RF images and associated Presentation States to a network storage device or CD-R, print to​ a networked hardcopy device and inform the information system about the work actually done.​

Table B.1-1 provides an overview of the network services supported by EXAMPLE-INTEGRATED-MODALITY.​

Table B.1-1. Network Services​

1.​Support for the Print Services is a separately licensable option. Details about licensable options can be found under:ht-​ tp://www.example-imaging-products.nocom/exampleintegrated-modality/licence-options​

- Standard -​