Transcription
Vidar Dicom ViewerDicom Conformance StatementDocument Version:1.0Product Name(s):Vidar Dicom ViewerRelease:3.0Date:January 23, 2018
1. COMFORMANCE STATEMENT OVERVIEWThe application supports long term storage of images, waveforms, reports, and measurements.Table 1-1NETWORK SERVICESUser of Service(SCU)SOP ClassesProvider ofService(SCP)Image torage cineImageStorage retiredUltrasoundImageStorage phicBiPlaneImageStorage Yes
YesWaveforms, Notes, Reports, Measurements esYesYes
tandaloneOverlayStorage retiredStandaloneCurveStorage StandaloneModalityLUTStorage retiredStandaloneVOILUTStorage YesYes
eProtocolStorageStandalonePETCurveStorage esYes
2. Table of Contents1. COMFORMANCE STATEMENT OVERVIEW . 22. Table of Contents . 63. INTRODUCTION . 83.1 REVISION HISTORY . 83.2 AUDIENCE . 83.3 REMARKS . 83.4 TERMS AND DEFINITIONS . 83.5 BASICS OF DICOM COMMUNICATION . 103.6 ABBREVIATIONS . 103.7 REFERENCES . 124. NETWORKING . 134.1 IMPLEMENTATION MODEL . 134.1.1Application Data Flow . 134.1.2Functional Definitions of AE’s . 134.1.3Sequencing of Real-World Activities . 144.2 AE SPECIFICATIONS . 144.2.1ECHO-SCP . 144.2.2STORAGE-SCP . 164.2.3STORAGE-SCU. 184.3 NETWORK INTERFACES . 204.3.1Physical Network Interface . 204.3.2Additional Protocols . 204.3.3IPv4 and IPv6 Support . 204.4 CONFIGURATION . 204.4.1AE Title/Presentation Address Mapping . 21
4.4.2Parameters . 215. MEDIA INTERCHANGE . 226. SUPPORT OF CHARACTER SETS . 236.1 OVERVIEW . 236.2 CHARACTER SETS . 236.3 CHARACTER SET CONFIGURATION . 247. SECURITY . 257.1 SECURITY PROFILES . 257.2 ASSOCIATION LEVEL SECURITY . 257.3 APPLICATION LEVEL SECURITY. 258. ANNEXES. 268.1 IOD CONTENTS. 268.1.1Coerced/Modified fields . 268.2 DATA DICTIONARY OF PRIVATE ATTRIBUTES . 268.3 CODED TERMINOLOGY AND TEMPLATES . 268.4 GRAYSCALE IMAGE CONSISTENCY . 268.5 STANDARD EXTENDED/SPECIALIZED/PRIVATE SOP CLASSES . 268.6 PRIVATE TRANSFER SYNTAXES . 26
3. INTRODUCTION3.1 REVISION HISTORYDocumentVersion1.0Date of IssueJanuary 23, 2018AuthorAlex GavrilovDescriptionVersion for Final Review3.2 AUDIENCEThis document is written for the people that need to understand how Vidar Dicom Viewer will integrateinto their healthcare facility. This includes both those responsible for overall imaging network policyand architecture, as well as integrators who need to have a detailed understanding of the DICOMfeatures of the product. This document contains some basic DICOM definitions so that any readermay understand how this product implements DICOM features. However, integrators are expected tofully understand all the DICOM terminology, how the tables in this document relate to the product’sfunctionality, and how that functionality integrates with other devices that support compatible DICOMfeatures.3.3 REMARKSThe scope of this DICOM Conformance Statement is to facilitate integration between the Vidar DicomViewer and other DICOM products. The Conformance Statement should be read and understood inconjunction with the DICOM Standard. DICOM by itself does not guarantee interoperability. TheConformance Statement does, however, facilitate a first-level comparison for interoperability betweendifferent applications supporting compatible DICOM functionality.This Conformance Statement is not supposed to replace validation with other DICOM equipmentto ensure proper exchange of intended information. In fact, the user should be aware of thefollowing important issues:— The comparison of different Conformance Statements is just the first step towards assessinginterconnectivity and interoperability between the product and other DICOM conformantequipment.— Test procedures should be defined and executed to validate the required level of interoperabilitywith specific compatible DICOM equipment, as established by the healthcare facility.3.4 TERMS AND DEFINITIONSInformal definitions are provided for the following terms used in this Conformance Statement. TheDICOM Standard is the authoritative source for formal definitions of these terms.Abstract Syntax – the information agreed to be exchanged between applications, generally equivalentto a Service/Object Pair (SOP) Class. Examples : Verification SOP Class, Modality Worklist InformationModel Find SOP Class, Computed Radiography Image Storage SOP Class.Application Entity (AE) – an end point of a DICOM information exchange, including the DICOMnetwork or media interface software; i.e., the software that sends or receives DICOM information objectsor messages. A single device may have multiple Application Entities.Application Entity Title – the externally known name of an Application Entity, used to identify a DICOMapplication to other 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. Theinformation 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 (IOD) – the specified set of Attributes that comprise a type of data object;does not represent a specific instance of the data object, but rather a class of similar data objects thathave the same properties. The Attributes may be specified as Mandatory (Type 1), Required but possiblyunknown (Type 2), or Optional (Type 3), and there may be conditions associated with the use of anAttribute (Types 1C and 2C). Examples: MR Image IOD, CT Image IOD, Print Job IOD.Joint Photographic Experts Group (JPEG) – a set of standardized image compression techniques,available for use by DICOM applications.Media Application Profile – the specification of DICOM information objects and encoding exchanged onremovable 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 thetypes of data to be exchanged and how that data will be encoded.Presentation Context – the set of DICOM network services used over an Association, as negotiatedbetween Application Entities; includes Abstract Syntaxes and Transfer Syntaxes.Protocol Data Unit (PDU) – a packet (piece) of a DICOM message sent across the network. Devicesmust 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 DICOMdata.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/retrieveSCP), Radiology Information System (modality worklist SCP).Service Class User (SCU) – role of an Application Entity that uses a DICOM network service; typically, aclient. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation(image query/retrieve SCU).Service/Object Pair (SOP) Class – the specification of the network or media transfer (service) of aparticular type of data (object); the fundamental unit of DICOM interoperability specification. Examples:Ultrasound Image Storage Service, Basic Grayscale Print Management.Service/Object Pair (SOP) Instance – an information object; a specific occurrence of informationexchanged in a SOP Class. Examples: 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 dataelement]Transfer Syntax – the encoding used for exchange of DICOM information objects and messages.
Examples: JPEG compressed (images), little endian explicit value representation.Unique Identifier (UID) – a globally unique “dotted decimal” string that identifies a specific object or aclass of objects; an ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOPInstance UID.Value Representation (VR) – the format type of an individual DICOM data element, such as text, aninteger, a person’s name, or a code. DICOM information objects can be transmitted with either explicitidentification 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 eachdata element.3.5 BASICS OF DICOM COMMUNICATIONThis section describes terminology used in this Conformance Statement for the non-specialist. The keyterms used in the Conformance Statement are highlighted in italics below. This section is not a substitutefor 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 DICOMprotocol must first agree on several things during an initial network “handshake”. One of the two devicesmust initiate an Association (a connection to the other device), and ask if specific services, information, andencoding can be supported by the other device (Negotiation).DICOM specifies a number of network services and types of information objects, each of which is calledan 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 proposecombinations of Abstract Syntax and Transfer Syntax to be used on the Association; these combinationsare called Presentation Contexts. The receiving Application Entity accepts the Presentation Contexts itsupports.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, securityinformation, and network service options (called Extended Negotiation information).The Application Entities, having negotiated the Association parameters, may now commence exchangingdata. Common data exchanges include queries for worklists and lists of stored images, transfer of imageobjects and analyses (structured reports), and sending images to film printers. Each exchangeable unit ofdata is formatted by the sender in accordance with the appropriate Information Object Definition, and sentusing 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 thereceiver with a Response Status indicating success, failure, or that query or retrieve operations are still inprocess.Two Application Entities may also communicate with each other by exchanging media (such as a CD-R).Since there is no Association Negotiation possible, they both use a Media Application Profile thatspecifies “pre-negotiated” exchange media format, Abstract Syntax, and Transfer Syntax.3.6 ABBREVIATIONSAbbreviations should be listed here. These may be taken from the following list, deleting terms that are notused within the Conformance Statement, and adding any additional terms that are used:AEAETApplication EntityApplication Entity Title
CADCDACD-RComputer Aided DetectionClinical Document ArchitectureCompact Disk RecordableCSECustomer Service ISOIOJPEGLUTMPEGMGMPPSMRMSPSMTUComputed RadiographyComputed TomographyDynamic Host Configuration ProtocolDigital Imaging and Communications in MedicineDomain Name SystemDigital X-rayGrayscale Softcopy Presentation StateHospital Information SystemHealth Level 7 StandardIntegrating the Healthcare EnterpriseInformation Object DefinitionInternet Protocol version 4Internet Protocol version 6International Organization for StandardsIntra-oral X-rayJoint Photographic Experts GroupLook-up TableMoving Picture Experts GroupMammography (X-ray)Modality Performed Procedure StepMagnetic Resonance ImagingModality Scheduled Procedure StepMaximum Transmission Unit (IP)MWLNMNTPModality W orklistNuclear MedicineNetwork Time ProtocolOOptional (Key Attribute)OPOSIPACSPETPDUROphthalmic PhotographyOpen Systems InterconnectionPicture Archiving and Communication SystemPositron Emission TomographyProtocol Data UnitRequired (Key Attribute)RFRISRadiofluoroscopyRadiology Information System.RTSCRadiotherapySecondary CaptureSCPService Class ProviderSCUService Class UserSOPSPSService-Object PairScheduled Procedure Step
SRTCP/IPUStructured ReportingTransmission Control Protocol/Internet ProtocolUnique (Key Attribute)ULUSVLVRXAUpper LayerUltrasoundVisible LightValue RepresentationX-ray Angiography3.7 REFERENCESNEMA PS3Digital Imaging and Communications in Medicine (DICOM) Standard, available freeat http://medical.nema.org/
4. NETWORKING4.1 IMPLEMENTATION MODEL4.1.1 Application Data FlowFigure 4.1-1IMPLEMENTATION MODELThe application is a native application that provides a native gui user interface, local database (SQLite)and network listener that spawns additional threads as necessary to handle incoming connections.Conceptually, the network services may be modeled as the following separate AEs, though in fact all theAEs share a single (configurable) AE Title (AE VDVIEWER by default):— ECHO-SCP, which responds to verification requests— STORAGE-SCP, which receives incoming composite instances— STORAGE-SCU, which sends outbound composite instances4.1.2 Functional Definitions of AE’s4.1.2.1 ECHO-SCPECHO-SCP waits in the background for connections, will accept associations with Presentation Contextsfor the SOP Class of the Verification Service Class, and will respond successfully to echo requests.
4.1.2.2 STORAGE-SCPSTORAGE-SCP waits in the background for connections, will accept associations with PresentationContexts for SOP Classes of the Storage Service Class, and will store the received instances to the localdatabase where they may subsequently be listed and viewed through the user interface.4.1.2.3 STORAGE-SCUSTORAGE-SCU is activated through the user interface when a user selects studies from the localdatabase and requests that they be sent to a remote AE (selected from a pre-configured list).4.1.3 Sequencing of Real-World ActivitiesAll SCP activities are performed asynchronously in the background and are not dependent on anysequencing.All SCU activities are initiated through the user interface.4.2 AE SPECIFICATIONS4.2.1 ECHO-SCP4.2.1.1 SOP ClassesECHO-SCP provides Standard Conformance to the following SOP Class(es):Table 4.2-1SOP CLASSES SUPPORTED BY ECHO-SCPSOP Class NameSOP Class UIDVerification SOP Class1.2.840.10008.1.14.2.1.2 Association Policies4.2.1.2.1GeneralECHO-SCP accepts but never initiates associations.Table 4.2-2MAXIMUM PDU SIZE RECEIVED AS A SCP FOR ECHO SCPMaximum PDU size received65kB (approximate)4.2.1.2.2Number of AssociationsTable 4.2-3NUMBER OF ASSOCIATIONS AS A SCP FOR ECHO-SCPMaximum number of simultaneous associations14.2.1.2.3Asynchronous NatureECHO-SCP will only allow a single outstanding operation on an Association. Therefore, ECHO-SCPwill not perform asynchronous operations window negotiation.4.2.1.2.4Implementation Identifying Information
Table 4.2-4DICOM IMPLEMENTATION CLASS AND VERSION FOR ECHO-SCPImplementation Class UID2.16.643.1.2.3Implementation Version NameVIDAR 034.2.1.3 Association Initiation PolicyECHO-SCP does not initiate associations.4.2.1.4 Association Acceptance PolicyWhen ECHO-SCP accepts an association, it will respond to echo requests. If the Called AE Title doesnot match the pre-configured AE Title shared by all the SCPs of the application, the association willNOT be rejected. All request are accepted.4.2.1.4.1Activity – Receive Echo Request4.2.1.4.1.1Description and Sequencing of ActivitiesAs requests are received, they are responded to immediately.4.2.1.4.1.2Accepted Presentation ContextsTable 4.2-5ACCEPTABLE PRESENTATION CONTEXTS FOR ECHO-SCP AND RECEIVE ECHO REQUESTPresentation Context TableAbstract SyntaxNameVerificationUID1.2.840.10008.1.1Transfer SyntaxNameRoleUIDExtendedNegotiationImplicit VR LittleEndian1.2.840.10008.1.2SCPNoneExplicit VR 1 Extended NegotiationNo extended negotiation is performed.4.2.1.4.1.3SOP Specific Conformance4.2.1.4.1.3.1 SOP Specific Conformance to Verification SOP ClassECHO-SCP provides standard conformance to the Verification Service Class.4.2.1.4.1.3.2 Presentation Context Acceptance CriterionECHO-SCP will only accept a Presentation Context compatible with the one listed in Table 4.2-5.4.2.1.4.1.3.3 Transfer Syntax Selection PoliciesIf proposed, ECHO-SCP prefers the Explicit VR Little Endian Transfer Syntax.ECHO-SCP will accept duplicate Presentation Contexts; that is, if it is offered multiple PresentationContexts, each of which offers acceptable Transfer Syntaxes, it will accept all Presentation Contexts,
applying the same method for selecting a Transfer Syntax for each.4.2.2 STORAGE-SCP4.2.2.1 SOP ClassesSTORAGE-SCP provides Standard Conformance to the SOP Classes given in table 1-1.4.2.2.2 Association Policies4.2.2.2.1GeneralSTORAGE-SCP accepts but never initiates associations.Table 4.2-6MAXIMUM PDU SIZE RECEIVED AS A SCP FOR STORAGE SCPMaximum PDU size received65kB (approximate)4.2.2.2.2Number of AssociationsTable 4.2-7NUMBER OF ASSOCIATIONS AS A SCP FOR STORAGE-SCPMaximum number of simultaneous associations14.2.2.2.3Asynchronous NatureSTORAGE-SCP will only allow a single outstanding operation on an Association. Therefore,STORAGE- SCP will not perform asynchronous operations window negotiation.4.2.2.2.4Implementation Identifying InformationTable 4.2-8DICOM IMPLEMENTATION CLASS AND VERSION FOR STORAGE-SCPImplementation Class UID2.16.643.1.2.3Implementation Version NameVIDAR 034.2.2.3 Association Initiation PolicySTORAGE-SCP does not initiate associations.4.2.2.4 Association Acceptance PolicyWhen STORAGE-SCP accepts an association, it will respond to storage requests. If the Called AETitle does not match the pre-configured AE Title shared by all the SCPs of the application, theassociation will not be rejected.4.2.2.4.1Activity – Receive Storage Request4.2.2.4.2Description and Sequencing of ActivitiesAs instances are received, they are copied to the local file system and a record inserted into thelocal database.4.2.2.4.2.1Accepted Presentatio
Viewer 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 .
![Radiant Dicom Viewer Cracked Rib [REPACK]](/img/39/evemelt.jpg)
