Материал: part02

An implementation claiming conformance with a Standard Extended SOP Class shall identify in its Conformance Statement the​ Standard SOP Class being extended, the options, roles, and behavior selected, and describe the Attributes being added with the​ Standard SOP Class's IOD Model and Modules.​

Specialized SOP Classes shall:​

a.​be completely conformant to relevant Parts of the DICOM Standard;​

b.​be based on a Standard SOP Class, i.e.:​

•​contain all the Type 1, 1C, 2, and 2C Attributes of Standard SOP Class on which it is based;​

•​not change the semantics of any Standard Attribute;​

•​use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);​

c.​be based on the DICOM Information Model in PS3.3 and PS3.4.​

Specialized SOP Classes may:​

a.​contain additional Standard and/or Private Type 1, 1C, 2, or 2C Attributes;​

b.​add Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.​

Note​

The usage of any unpublished Attributes may be ignored by other users and providers of the Specialized SOP Class.​

c.​enumerate the permitted values for Attributes within the set allowed by the Standard SOP Class;​

d.​enumerate the permitted Templates for Content Items within the set allowed by the Standard SOP Class.​

An implementation claiming conformance with a Specialized SOP Class shall include in its Conformance Statement the identity of​ the Standard SOP Class being specialized, a description of usage of all Standard and Private Type 1, 1C, 2, and 2C Attributes in the​ Specialized SOP Class, a description of the constraints on Attributes values and Templates, and the associated Privately Defined​ UID.​

Private SOP Classes shall:​

a.​becompletelyconformanttorelevantPartsoftheDICOMStandardwiththepossibleexceptionthatsupportoftheDICOMDefault​ Transfer Syntax or a Transfer Syntax mandated by a media storage Application Profile is not required;​

b.​not change the PS3.6 specification of any Standard Attributes;​

c.​use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);​

d.​not change existing DIMSE Services or create new ones;​

e.​not change existing DICOM File Services defined in PS3.10 or extend them in a manner that jeopardizes interoperability.​

Private SOP Classes may:​

a.​use or apply DIMSE Services to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);​

b.​use or apply Media Storage Operations to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP​ Class);​

c.​designate any Standard Attribute as Type 1, 1C, 2, or 2C regardless of the Type of the Attribute in other IODs;​

d.​define Private Attributes as Type 1, 1C, 2, or 2C;​

e.​include Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.​

- Standard -​

An implementation claiming conformance with a Private SOP Class shall provide a PS3.3, PS3.4, and PS3.6-like description of the​ Private SOP Class in the implementation's Conformance Statement, including descriptions of the usage of all Standard and Private​ Type 1, 1C, 2, or 2C Attributes in the SOP Class, the DICOM Information Model, and the Privately Defined UIDs.​

Note​

Unpublished SOP Classes (i.e., SOP Classes that are not defined in the DICOM Standard and are not defined in the Con-​ formance Statement) are permitted in order to allow an implementation to support other abstract syntaxes within the DICOM​ Application Context. Such unpublished SOP Classes would utilize Privately Defined UIDs. The presence of an unpublished​ SOP Class does not prevent the implementation from being DICOM conformant but would have no meaning to other imple-​ mentations and may be ignored.​

7.4 Rules Governing Types of Application Profiles​

ApplicationProfileusedinaConformanceStatementshallbeofoneofthreebasictypes.EachApplicationProfileinanimplementation​ claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of Ap-​ plication Profile.​

7.4.1 Standard Application Profile​

A Standard Application Profile shall:​

a.​conform to all relevant Parts of DICOM with no changes;​

b.​support only one of the Physical Media and associated Media Format, as specified by PS3.12.​

To claim conformance to a Standard Application Profile, an implementation shall make a declaration of this fact in its Conformance​ Statement, and identify its selected options, roles, and behavior.​

An implementation of a Standard Application Profile may extend Standard SOP Classes of this Standard application profile. Such​ Standard Extended SOP Classes shall meet the requirements specified in Section 7.3.​

7.4.2 Augmented Application Profile​

An Augmented Application Profile shall:​

a.​be a proper super set of the Standard Application Profile. It adds the support of additional Standard or Standard Extended SOP​ Classes;​

b.​use the same Physical Media and its associated Media Format specified in the corresponding Standard Application Profile;​

c.​not include Specialized or Private SOP Classes.​

An Augmented Application Profile may:​

a.​include one or more Standard or Standard Extended SOP Classes in addition to those of the corresponding Standard Application​ Profile. These additional SOP Classes may be mandatory or optional;​

b.​include the extensions (e.g., additional required keys, additional directory records) to the Basic Directory Information Object​ corresponding to the SOP Classes defined in a);​

c.​add one or more new roles (FSC, FSR, FSU).​

ToclaimconformancetoanAugmentedApplicationProfile,animplementationshallmakeadeclarationofthisfactinitsConformance​ Statement, and shall identify the Standard Application Profile from which it is derived and specify the augmentations. The implement-​ ation shall also identify its selected options, roles, and behavior.​

An implementation of a Augmented Application Profile may:​

a.​extend Standard SOP Classes of the corresponding Standard application profile. Such Standard Extended SOP Classes shall​ meet the requirements specified in Section 7.3;​

- Standard -​

b.​also claim conformance to the Standard Application Profile on which this Augmented Profile is based. In this case, FSC and FSU​ implementations shall be able to restrict their behavior to the Standard Application Profile (i.e., provide a means to write only the​ Standard or Standard Extended SOP Classes defined in the corresponding Standard Application Profile).​

7.4.3 Private Application Profile​

A Private Application Profile:​

•​conforms to PS3.10 and to the Media Storage Service Class specified in PS3.4;​

•​support only one of the Physical Media and associated Media Format, as specified by PS3.12;​

Note​

The intent of these two conditions is to ensure that at least the DICOMDIR is readable by other APs.​

•​complies with the rules governing SOP Classes in Section 7.3.​

To claim conformance to a Private Application Profile, an implementation shall make a declaration of this fact in its Conformance​ Statement, and shall provide a description of the Application Profile patterned after the descriptions in PS3.11. The implementation​ shall also identify its selected options, roles, and behavior.​

Note​

AnimplementationthatdoesnotmeettheprovisionsofSection7,includingthetypesofApplicationProfile,isnotconformant​ to DICOM and so is outside the scope of DICOM conformance. Such an implementation is not an Application Profile in​ DICOM terminology. For example, if an implementation chooses to write DICOM files onto media that is not in PS3.12, or​ use a file system not defined for a specific media type in PS3.12, then that implementation cannot claim that it conforms to​ the DICOM Standard using that media or file system.​

7.5 Conformance of DICOM Media​

DICOM does not define conformance of a piece of medium in a generic sense. DICOM conformance of a piece of medium can only​ be evaluated within the scope of one or more media storage Application Profiles that define specific contexts for interoperability.​

Note​

One may accept the statement "this is a DICOM CD-R" when pointing to a storage medium. However, one should not state​ "thisCD-RisDICOMconformant",butrather"thisCD-RconformstotheBasicCardiacX-rayAngiographicDICOMApplication​ Profile".​

7.6 Security Profiles​

DICOMspecifiesmethodsforprovidingsecurityatdifferentlevelsoftheISOOSIBasicReferenceModelthroughtheuseofmechanisms​ specific to a particular layer. The methods for applying these mechanisms are described in the various parts of the DICOM Standard.​ SomemechanismsandalgorithmsarespecifiedinPS3.15asSecurityProfiles.Animplementation'sConformanceStatementdescribes​ which Security Profiles can be used by that application.​

Note​

Forexample,theBasicTLSSecureTransportConnectionProfiledefinesamechanismforauthenticatingentitiesparticipating​ in the exchange of data, and for protecting the integrity and confidentiality of information during interchange.​

An implementation shall list in its Conformance Statement any Security Profiles that it supports, how it selects which Security Profiles​ it uses, how it uses features of that Security Profile, and any extensions it makes to that Security Profile.​

An implementation shall list in its Conformance Statement any additional use of the User Identity association negotiation sub-item​ that is not specified in a standard Security Profile.​

- Standard -​

7.7 Transformation of DICOM SR to CDA​

DICOM specifies the transformation of DICOM SR objects to CDA documents in PS3.20.​

This transformation is unidirectional (DICOM SR to HL7 CDA). Conformance statements shall at a minimum state conformance to​ the top level templates used for the SR document and the CDA document.​

- Standard -​

A DICOM Conformance Statement Template​ (Normative)​

This Annex is a template that shall be used to generate a DICOM Conformance Statement. The document is hierarchically structured​ in three different levels:​

•​A DICOM Conformance Statement Overview, which is typically one page, geared towards people that want to get a quick overview​ of the functionality and services.​

•​For Networking and Media, the relationship between the AEs, followed by the information for each AE​

•​For the services supported as SCU and SCP all the SOP specific details​

Annexes are provided to specify the Object descriptions (IODs), with specifics about the field usage as well as the data dictionaries.​

Note​

The numbering scheme for numbering paragraphs in this document is to be used as a guideline in preparing the outline of​ the Conformance Statement. Although strongly encouraged, the Conformance Statement is not required to have exactly the​ sameparagraphnumbersbecauseaparticularConformanceStatementmighthavespecialconsiderations,whichwillcause​ the outline to differ in certain details from the outline of this document. In addition, a vendor might have internal company​ guidelinesprescribingaspecificformat.Notehowever,thattheoverallstructure,tables,definitionofvariablesandinformation​ such as headers, should be strictly followed.​

A.0 Cover Page​

A DICOM Conformance Statement may have a cover page, which, if present, shall include:​

a.​Thecommercialnameandversion(s)oftheconcernedproductorproducts(ifapplicabletoseveralproducts)includingalloptional​ features. The product version shall correspond to the functionality as described in this conformance statement.​

b.​Date of the document​

A.1 Conformance Statement Overview​

The Overview consist of typically 5-10 lines describing the network services and media storage capabilities supported by the product​ in layman's terms (i.e., no DICOM acronyms should be used).​

A table of Supported Networking DICOM Service (SOP) Classes is provided with roles (User/Provider), organized in 4 categories:​

•​Transfer​

•​Query/Retrieve​

•​Workflow Management​

•​Print Management​

The first column shall specify the SOP Classes exactly as named in PS3.6., Registry of DICOM Unique Identifiers. The phrase "and​ specializations" may be added to indicate support of all specializations negotiated through the SOP Class Common Extended Nego-​ tiation.IftheimplementationsupportsallSOPClassesofaparticularServiceClassthroughSOPClassCommonExtendedNegotiation,​ the first column shall specify "All services of the <x> Service Class".​

Table A.1-1. Network Services​

Transfer​

- Standard -​