DCSPower/DwightASimon/Merge-eFilm - 1

1
DICOM Conformance Statement(DCS)A Proven Power
within DICOM

• Dwight A. Simon,
• Medical Standards Director Senior Integration
  Specialist
• Merge eFilm

2
A 10 year Proven track record of Power

• It is Required
• It is a Public document
• It describes the DICOM Features / Functions
  implemented in a Product
• It allows connectivity comparisons
• It defines the information that is required to
  perform specific functions

3
Content of DCS Using 2003 Publication of Std

• A brief introduction that is specified in general
  terms
• A simple data flow diagram and description
• The functional definition of each DICOM feature
• More detail on specifics later
• How this product communicates to another product

4
Content of DCS Using 2003 Std continued

• Specification of any enhancements or changes to
  standard DICOM features
• A list of configurable parameters
• A list of character sets that are supported
  (i.e., Japanese or French)
• Any codes and controlled terminology
• A specification of all DICOM security features

5
Functional Definitions more detail

• Specification of each feature/function within the
  application
• Utilizes specific terminology of DICOM
• Benefit - defined in an unambiguous way
• Disadvantage - must understand the terminology
  in order to get all the information one needs to
• Understand the products DICOM features
• Compare this DICOM product with another

6
Almost Everyone follows the Templates from the
Standard for writing a DCS

• The common format is a huge benefit
• Easy to find information, because always in same
  place
• Easy to compare one DICOM product with another

7
Who has ability to use this information with a
high degree of understanding?

• Those that have taken DICOM training
• Those that have read and understood the DICOM
  Standard
• Unfortunately, the common healthcare user who
  does not have this background can probably only
  understand less than 40 of the information in
  the DCS

8
Presentation Context Tables
Association Initiation
Presentation Context Table - Proposed
Abstract Syntax
Transfer Syntax
Role
Expanded
Name
UID
Name List
UID List
Negotiation
X-ray RF Image
1.2.840.10008.5.1.4.1.1.12.2
Implicit VR LE
1.2.840.10008.1.2
SCU
None
Storage

JPEG-14
1.2.840.10008.1.2.4.70
Lossless (70)
Secondary
1.2.840.10008.5.1.4.1.1.7
Implicit VR LE
1.2.840.10008.1.2
SCU
None
Capture Image
Explicit VR BE
1.2.840.10008.1.2.2
Storage
Association Acceptance
9
Other Likely Unknown Terms

• AE Specification
• Application Entity Title
• Application Profile
• SOP Class
• SOP Instance
• Standard Extended SOP Class
• Unique Identifier (UID)

10
After 10 yearsDICOM Conformance Statement has
become even more Powerful

• It includes an enhanced template
• It has a wider range of examples that deal with
  the majority of possible DICOM features
• It has grown from 50 pages to over 330 pages

11
Enhancement is called Supplement 64

• Already balloted and approved to become part of
  the DICOM Standard
• Minor corrections and editing still to be done by
  Working Group 6 prior to making it a final
  document

12
Supplement 64 Enhancements (Sup64)

• Will benefit the non-DICOM literate user directly
• Will enable the DICOM literate user to more
  easily find and compare DICOM features
• Will be additive to most of what is in the
  current 2003 publication

13
Sup64 New Additions

• DICOM Conformance Statement Overview
• Includes a description of the implementation in
  "layman's terms
• Requires that the tables for both Networking and
  Media Storage
• List all used DICOM features (SOP Classes)
• List be organized and grouped by categories

14
Sup64 New Additions continued

• Requires a Table of Contents (some vendors
  already do this)
• New "Introduction" section
• The "Definitions, Terms and Abbreviations" item
  will be one key addition for the non-DICOM
  literate
• If vendors do a good job with this item, then
  these users should be able to have an 80 or
  higher understanding of the DCS

15
Sup64 New Additions continued

• Enhancements to "Sequencing of Real-World
  Activities"
• Defines interactions between this products
  various DICOM connections and other products
• It is strongly recommended to incorporate UML
  Sequence Diagrams
• Sequence diagrams emphasize the sequence of the
  DICOM messages between two products
• Even without a formal understanding of the
  Unified Modeling Language (UML) the average user
  should be able to interpret the diagrams

16
UML Sequencing Diagram
StorageApplication
Image / Info Manager
1. Open Association
2. C-STORE (CT Image) 1 to N images to be sent
3. C-STORE (GSPS) 1 to N grayscale image
consistency information sets to be sent
4. N-ACTION (Storage Commitment Request for
Images GSPS) Are they reliably stored
5. N-EVENT-REPORT (Storage Commitment Response)
Each are or are not reliably stored
6. Close Association
17
Sup64 New Additions continued

• The "Configuration" section has also been
  enhanced.
• Requires a much more definitive description of
  the configurable parameters that the application
  will utilize when it is running
• The parameters refer to application name(s),
  networking relationships, remote application
  connectivity, node level security, etc.
• There is a recommended set of operational
  parameters that are required to be represented

18
Sup64 New Additions continued

• The powerful "Annexes" section helps define some
  of the operational aspects of the product
• Within the Annexes one must describe
• the data that is created,
• put in the DICOM message and
• sent to another product.

19
Sup64 New Additions continued

• Within the Annexes" each piece of information
  (called an attribute) must be specified
• by name and
• DICOM identifier (called attribute tag),
• range of values that might be present
• type of value
• person name
• date
• time
• floating point double precision number
• integer number

20
Sup64 New Additions continued

• Within the Annexes each attribute must be defined
  
• whether it will or will not exist within a DICOM
  message and under what conditions it will exist
• If its value is present, then from where will it
  come
• from user input
• be generated automatically
• come from functional information like a work list
  
• be a configurable parameter.

21
Sup64 New Additions continued

• other important items within "Annexes"
• specification of attributes that are required
• mapping of attributes between different
  information sets
• HL7 mapped into a DICOM work list
• DICOM work list mapped into a CT image
• specify whether key attributes are allowed to be
  modified
• patient name
• patient identifier
• study instance UID

22
Sup64 New Additions continued

• A data dictionary of all private attributes
• The support of coded terminology and/or
  templates, if utilized
• The support for "Grayscale Image Consistency", if
  applicable
• A definition of any enhancements or changes to
  standard DICOM features that have been
  implemented, including feature specialization or
  new private features
• All private encoding of information that is
  support, if applicable

23
Sup64 New Additions continued

• Many informative sections in PS3.2
• specifically to give examples of DICOM
  Conformance Statements for various types of
  products
• a huge benefit to both the vendors and the users
• for the vendors, they are used as a guideline for
  interpreting the DCS template for a specific kind
  of product
• for the user, it will insure that multiple
  vendors with similar products will have DCSes
  that look alike.

24
DCS Examples available in Sup64

• A DICOM modality that has connectivity to an
  archive, a workflow manager and a print server,
  along with have the capability to create a DICOM
  generic CD-Rs
• A product that interfaces to a Radiology
  Information System via DICOM
• A DICOM image viewer that can handle a wide range
  of modality images, including radiation therapy
  planning information. It also can query and
  retrieve information from a remote application
  and can read both DICOM generic CD-R and DVD-RAM
• A DICOM print server
• A DICOM query/retrieve server

25
DICOM would truly only have Half the Power it
currently has without the DICOM Conformance
Statement!
26
With the Enhanced DICOM Conformance Statement

• ability to better understand how products connect
  to each other via DICOM
• what information they communicate and under what
  conditions
• what information must be received for the
  application to function properly
• how parameters must be configured to make the
  application function in specific ways
• a formal way to describe the sequencing of
  messages between DICOM applications