Материал: part02

Скачать

Заказать новую работу

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

 

DICOM PS3.2 2020a - Conformance​

Page 61​

UID Value​

UID Name​

Category​

1.2.840.10008.5.1.4.20.1​

DefinedProcedureProtocolInformationModel-FINDSOP​Query/Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.20.2​

Defined Procedure Protocol Information Model - MOVE​ Query/Retrieve​

 

SOP Class​

 

1.2.840.10008.5.1.4.20.3​

DefinedProcedureProtocolInformationModel-GETSOP​Query/Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.1.1.200.4​

Protocol Approval Information Model - FIND SOP Class​ Query/Retrieve​

1.2.840.10008.5.1.4.1.1.200.5​

Protocol Approval Information Model - MOVE SOP Class​Query/Retrieve​

1.2.840.10008.5.1.4.1.1.200.6​

Protocol Approval Information Model - GET SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.31​

Modality Worklist Information Model - FIND SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.32.1​

General Purpose Worklist Information Model - FIND SOP​Workflow Management​

 

Class (Retired)​

 

1.2.840.10008.5.1.4.32.2​

General Purpose Scheduled Procedure Step SOP Class​Workflow Management​

 

(Retired)​

 

1.2.840.10008.5.1.4.32.3​

General Purpose Performed Procedure Step SOP Class​Workflow Management​

 

(Retired)​

 

1.2.840.10008.5.1.4.32​

General Purpose Worklist Management Meta SOP Class​Workflow Management​

 

(Retired)​

 

1.2.840.10008.5.1.4.33​

Instance Availability Notification SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.6.1​

Unified Procedure Step - Push SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.6.2​

Unified Procedure Step - Watch SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.6.3​

Unified Procedure Step - Pull SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.6.4​

Unified Procedure Step - Event SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.6.5​

Unified Procedure Step - Query SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.7​

RT Beams Delivery Instruction Storage SOP Class​

Transfer​

1.2.840.10008.5.1.4.34.8​

RT Conventional Machine Verification SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.9​

RT Ion Machine Verification SOP Class​

Workflow Management​

1.2.840.10008.5.1.4.34.10​

RT Brachy Application Setup Delivery Instruction Storage​Transfer​

 

SOP Class​

 

1.2.840.10008.5.1.4.37.1​

General Relevant Patient Information Query SOP Class​ Query/Retrieve​

1.2.840.10008.5.1.4.37.2​

Breast Imaging Relevant Patient Information Query SOP​Query/Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.37.3​

Cardiac Relevant Patient Information Query SOP Class​ Query/Retrieve​

1.2.840.10008.5.1.4.38.1​

Hanging Protocol Storage SOP Class​

Transfer​

1.2.840.10008.5.1.4.38.2​

Hanging Protocol Information Model - FIND SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.38.3​

Hanging Protocol Information Model - MOVE SOP Class​Query/Retrieve​

1.2.840.10008.5.1.4.39.1​

Color Palette Storage SOP Class​

Transfer​

1.2.840.10008.5.1.4.39.2​

Color Palette Information Model - FIND SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.39.3​

Color Palette Information Model - MOVE SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.39.4​

Color Palette Information Model - GET SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.41​

Product Characteristics Query SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.42​

Substance Approval Query SOP Class​

Query/Retrieve​

1.2.840.10008.5.1.4.43.1​

Generic Implant Template Storage SOP Class​

Transfer​

- Standard -​

Page 62​

DICOM PS3.2 2020a - Conformance​

 

UID Value​

UID Name​

Category​

1.2.840.10008.5.1.4.43.2​

Generic Implant Template Information Model - FIND SOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.43.3​

GenericImplantTemplateInformationModel-MOVESOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.43.4​

Generic Implant Template Information Model - GET SOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.44.1​

Implant Assembly Template Storage SOP Class​

Transfer​

1.2.840.10008.5.1.4.44.2​

ImplantAssemblyTemplateInformationModel-FINDSOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.44.3​

Implant Assembly Template Information Model - MOVE​ Query / Retrieve​

 

SOP Class​

 

1.2.840.10008.5.1.4.44.4​

ImplantAssemblyTemplateInformationModel-GETSOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.45.1​

Implant Template Group Storage SOP Class​

Transfer​

1.2.840.10008.5.1.4.45.2​

Implant Template Group Information Model - FIND SOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.45.3​

Implant Template Group Information Model - MOVE SOP​Query / Retrieve​

 

Class​

 

1.2.840.10008.5.1.4.45.4​

Implant Template Group Information Model - GET SOP​ Query / Retrieve​

 

Class​

 

A table of Supported Media Storage Application Profiles (with roles) is provided, organized in categories:​

•​Compact Disk - Recordable​

•​Magneto-Optical Disk​

•​DVD​

•​BD​

•​USB and Flash Memory​

•​Email​

•​Other Media​

Table A.1-3. Media Services​

Media Storage Application Profile​

Write Files (FSC or FSU)​

Read Files (FSR)​

Compact Disk - Recordable​

 

 

General Purpose CD-R​

Option​

Yes​

Magneto-Optical Disk​

 

 

CT/MR 2.3 GB MOD​

Yes​

Yes​

DVD​

 

 

General Purpose DVD-RAM​

Yes​

Yes​

BD​

 

 

General Purpose BD Interchange with MPEG-4 AVC/H.264​

Yes​

Yes​

BD-Compatible HiP@Level4.1​

 

 

USB and Flash Memory​

 

 

General Purpose USB Media Interchange with JPEG​

Yes​

Yes​

- Standard -​

DICOM PS3.2 2020a - Conformance​

Page 63​

Media Storage Application Profile​

Write Files (FSC or FSU)​

Read Files (FSR)​

Email​

 

 

General Purpose MIME Interchange​

Yes​

No​

General Purpose ZIP Email​

Yes​

No​

A.2 Table of Contents​

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

A.3 Introduction​

The introduction specifies product and relevant disclaimers as well as any general information that the vendor feels is appropriate.​

The following subsections are suggested:​

A.3.1 Revision History​

The revision history provides dates and differences of the different releases of the product and the Conformance Statement.​

A.3.2 Audience​

The audience is specified with their assumed pre-knowledge. The following example may be used as a template:​

This document is written for the people that need to understand how <Product Name> will integrate into their healthcare facility. This​ includesboththoseresponsibleforoverallimagingnetworkpolicyandarchitecture,aswellasintegratorswhoneedtohaveadetailed​ understanding of the DICOM features of the product. This document contains some basic DICOM definitions so that any reader may​ understand how this product implements DICOM features. However, integrators are expected to fully understand all the DICOM ter-​ minology, how the tables in this document relate to the product's functionality, and how that functionality integrates with other devices​ that support compatible DICOM features.​

A.3.3 Remarks​

Any important remarks, disclaimers, and general information are specified. The following example may be used as a template:​

The scope of this DICOM Conformance Statement is to facilitate integration between <Product Name> and other DICOM products.​ The Conformance Statement should be read and understood in conjunction with the DICOM Standard. DICOM by itself does not​ guarantee interoperability. The Conformance Statement does, however, facilitate a first-level comparison for interoperability between​ different applications supporting compatible DICOM functionality.​

ThisConformanceStatementisnotsupposedtoreplacevalidationwithotherDICOMequipmenttoensureproperexchangeofintended​ information. In fact, the user should be aware of the following important issues:​

•​The comparison of different Conformance Statements is just the first step towards assessing interconnectivity and interoperability​ between the product and other DICOM conformant equipment.​

•​Test procedures should be defined and executed to validate the required level of interoperability with specific compatible DICOM​ equipment, as established by the healthcare facility.​

If the product has an IHE Integration Statement, the following statement may be applicable:​

<Product Name> has participated in an industry-wide testing program sponsored by Integrating the Healthcare Enterprise (IHE). The​ IHE Integration Statement for <Product Name>, together with the IHE Technical Framework, may facilitate the process of validation​ testing.​

A.3.4 Terms and Definitions​

Terms and definitions should be listed here. The following example may be used as a template:​

- Standard -​

Page 64​

DICOM PS3.2 2020a - Conformance​

InformaldefinitionsareprovidedforthefollowingtermsusedinthisConformanceStatement.TheDICOMStandardistheauthoritative​ source for formal definitions of these terms.​

Abstract Syntax​

The information agreed to be exchanged between applications, generally equivalent to a​

 

Service/ObjectPair(SOP)Class.Examples:VerificationSOPClass,ModalityWorklistInformation​

 

Model Find SOP Class, Computed Radiography Image Storage SOP Class.​

Application Entity (AE)​

AnendpointofaDICOMinformationexchange,includingtheDICOMnetworkormediainterface​

 

software; i.e., the software that sends or receives DICOM information objects or messages. A​

 

single device may have multiple Application Entities.​

Application Entity Title (AET)​

TheexternallyknownnameofanApplicationEntity,usedtoidentifyaDICOMapplicationtoother​

 

DICOM applications on the network.​

Application Context​

The specification of the type of communication used between Application Entities. Example:​

 

DICOM network protocol.​

Association​

A network communication channel set up between Application Entities.​

Attribute​

A unit of information in an object definition; a data element identified by a tag. The information​

 

may be a complex data structure (Sequence), itself composed of lower level data elements.​

 

Examples: Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation​

 

(0028,0004), Procedure Code Sequence (0008,1032).​

Information Object Definition​

The specified set of Attributes that comprise a type of data object; does not represent a specific​

(IOD)​

instanceofthedataobject,butratheraclassofsimilardataobjectsthathavethesameproperties.​

 

The Attributes may be specified as Mandatory (Type 1), Required but possibly unknown (Type​

 

2), or Optional (Type 3), and there may be conditions associated with the use of an Attribute​

 

(Types 1C and 2C). Examples: MR Image IOD, CT Image IOD, Print Job IOD.​

Joint Photographic Experts​

A set of standardized image compression techniques, available for use by DICOM applications.​

Group (JPEG)​

 

Media Application Profile​

The specification of DICOM information objects and encoding exchanged on removable media​

 

(e.g., CDs).​

Module​

A set of Attributes within an Information Object Definition that are logically related to each other.​

 

Example: Patient Module includes Patient Name, Patient ID, Patient Birth Date, and Patient Sex.​

Negotiation​

First phase of Association establishment that allows Application Entities to agree on the types of​

 

data to be exchanged and how that data will be encoded.​

Presentation Context​

ThesetofDICOMnetworkservicesusedoveranAssociation,asnegotiatedbetweenApplication​

 

Entities; includes Abstract Syntaxes and Transfer Syntaxes.​

Protocol Data Unit (PDU)​

A packet (piece) of a DICOM message sent across the network. Devices must specify the​

 

maximum size packet they can receive for DICOM messages.​

Security Profile​

A set of mechanisms, such as encryption, user authentication, or digital signatures, used by an​

 

Application Entity to ensure confidentiality, integrity, and/or availability of exchanged DICOM​

 

data.​

Service Class Provider (SCP)​

Role of an Application Entity that provides a DICOM network service; typically, a server that​

 

performs operations requested by another Application Entity (Service Class User). Examples:​

 

Picture Archiving and Communication System (image storage SCP, and image query/retrieve​

 

SCP), Radiology Information System (modality worklist SCP).​

Service Class User (SCU)​

Role of an Application Entity that uses a DICOM network service; typically, a client. Examples:​

 

imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image​

 

query/retrieve SCU).​

- Standard -​

 

DICOM PS3.2 2020a - Conformance​

Page 65​

Service/Object Pair Class (SOP​

The specification of the network or media transfer (service) of a particular type of data (object);​

Class)​

thefundamentalunitofDICOMinteroperabilityspecification.Examples:UltrasoundImageStorage​

 

Service, Basic Grayscale Print Management.​

 

Service/Object Pair Instance​

Aninformationobject;aspecificoccurrenceofinformationexchangedinaSOPClass.Examples:​

(SOP Instance)​

a specific x-ray image.​

 

Tag​

A 32-bit identifier for a data element, represented as a pair of four digit hexadecimal numbers,​

 

the "group" and the "element". If the "group" number is odd, the tag is for a private​

 

 

(manufacturer-specific) data element. Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel​

 

Data], (0019,0210) [private data element].​

 

Transfer Syntax​

TheencodingusedforexchangeofDICOMinformationobjectsandmessages.Examples:JPEG​

 

compressed (images), little endian explicit value representation.​

 

Unique Identifier (UID)​

A globally unique "dotted decimal" string that identifies a specific object or a class of objects; an​

 

ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOP Instance UID.​

Value Representation (VR)​

The format type of an individual DICOM data element, such as text, an integer, a person's name,​

 

or a code. DICOM information objects can be transmitted with either explicit identification of the​

 

type of each data element (Explicit VR), or without explicit identification (Implicit VR); with Implicit​

VR, the receiving application must use a DICOM data dictionary to look up the format of each​ data element.​

A.3.5 Basics of DICOM Communication​

A layman's introduction to DICOM may be included here. The following example may be used as a template:​

ThissectiondescribesterminologyusedinthisConformanceStatementforthenon-specialist.ThekeytermsusedintheConformance​ Statement are highlighted in italics below. This section is not a substitute for training about DICOM, and it makes many simplifications​ about the meanings of DICOM terms.​

Two Application Entities (devices) that want to communicate with each other over a network using DICOM protocol must first agree​ on several things during an initial network "handshake". One of the two devices must initiate an Association (a connection to the​ other device), and ask if specific services, information, and encoding can be supported by the other device (Negotiation).​

DICOM specifies a number of network services and types of information objects, each of which is called an Abstract Syntax for the​ Negotiation. DICOM also specifies a variety of methods for encoding data, denoted Transfer Syntaxes. The Negotiation allows the​ initiating Application Entity to propose combinations of Abstract Syntax and Transfer Syntax to be used on the Association; these​ combinations are called Presentation Contexts. The receiving Application Entity accepts the Presentation Contexts it supports.​

For each Presentation Context, the Association Negotiation also allows the devices to agree on Roles - which one is the Service​ Class User (SCU - client) and which is the Service Class Provider (SCP - server). Normally the device initiating the connection is the​ SCU, i.e., the client system calls the server, but not always.​

The Association Negotiation finally enables exchange of maximum network packet (PDU) size, security information, and network​ service options (called Extended Negotiation information).​

TheApplicationEntities,havingnegotiatedtheAssociationparameters,maynowcommenceexchangingdata.Commondataexchanges​ includequeriesforworklistsandlistsofstoredimages,transferofimageobjectsandanalyses(structuredreports),andsendingimages​ to film printers. Each exchangeable unit of data is formatted by the sender in accordance with the appropriate Information Object​ Definition, and sent using the negotiated Transfer Syntax. There is a Default Transfer Syntax that all systems must accept, but it may​ not be the most efficient for some use cases. Each transfer is explicitly acknowledged by the receiver with a Response Status indic-​ ating success, failure, or that query or retrieve operations are still in process.​

TwoApplicationEntitiesmayalsocommunicatewitheachotherbyexchangingmedia(suchasaCD-R).SincethereisnoAssociation​ Negotiation possible, they both use a Media Application Profile that specifies "pre-negotiated" exchange media format, Abstract​ Syntax, and Transfer Syntax.​

- Standard -​

Смотрите также:

«ДОХОДЫ, РАСХОДЫ И ПРИБЫЛЬ КОММЕРЧЕСКОГО БАНКА.»
«ДОХОДЫ, РАСХОДЫ И ПРИБЫЛЬ КОММЕРЧЕСКОГО БАНКА.»
Значение, сущность и содержание социально — педагогической деятельности в организации для детей-сирот и детей, оставшихся без попечения родителей
__RGR2
__RGR2
_11_А. Франс для эл версии
_индив анализ данных
- Интерфейс 485 и оптопорт 11
:Конвергентный подход к проектированию дополнительных общеобразовательных общеразвивающих программ