Revisions of the DICOM Conformance Statement Template (Work Item C) Concept Presentation

Transcription

1 DICOM WG 31 Revisions of the DICOM Conformance Statement Template (Work Item C) Concept Presentation Jan. 23, 2017 Antje Schroeder, Bruno Laffin, Yogalakshmi Selvarajan, Herve Hoehn, Charles Parisot 1

2 Agenda Background Current Status Open Questions 2

3 Background Goal of Work Item Improve content and structure of DCS to Better meet needs of all user groups (service, R&D, testing, sales ) Better facilitate comparability of different product s DICOM functionality Avoid ambiguities/inconsistencies between different vendor documentation Approach Perform a survey among different user groups to identify areas of improvement Develop a proposal for the structure/content of the new DCS Create an extensive example document for a DCS and use this as a template later on Provide normative text for DICOM PS3.2 Decide on examples and develop them according to the new template 3

4 Current Status The survey was performed and results have been evaluated An initial proposal for the new structure/content was discussed during the WG 31 meeting in Tokyo A sub team for this work item, which meets on a weekly basis, has been formed: Bruno Laffin Agfa Charles Parisot GE Herve Hoehn GE Yogalakshmi Selvarajan Philips Antje Schroeder Siemens Healthineers 4

5 Areas of Improvement Based on a survey the following areas for improvement were identified Less repetitive information More concise representation of information (e.g. in tables) More consistency across vendors Improve PS3.2 Chapter 4: Networking More consistent documentation of IODs created Better documentation of private attributes, SOP Classes Provide documentation of display capabilities Information that belongs together should be in one place More information in overview Provide template in addition to normative text 5

6 Proposed Structure for the DCS 1. Overview 2. Table of Contents 3. Introduction/Disclaimer 4. Product Description 5. Service and Interoperability Description 6. DICOM Configuration 7. Network Communication Details 6

7 4 Product Description High level product and implementation information (textual, graphical) Proposed Structure 4.1 Implementation Model Application Data Flow Diagram Functional Definition of AE s Functional Definition of Application Entity <1> Functional Definition of Application Entity <2> Typical Workflows and Sequencing of Real-World Activities Typical Workflow <w1> Typical Workflow <w2> 4.2 Know deviations Mainly instruction text will be provided (in a different font color), e.g. 4.1 Implementation Model <Summarize here the product architecture (e.g implementation of functionality in separate applications)> 7

8 5 Service and Interoperability Description Documents technical details about the supported DICOM Services (tables) Proposed Structure 5.1 Summary of supported Services Verification Storage Workflow Management Query/Retrieve Printing 5.2 Mapping of Services to Application Entities 5.3 Supported Services Modality Worklist SCU SCP Modality Performed Procedure Step SCU SCP Storage SCU SCP. 5.4 Specific Charactersets 5.5 Support for De-Identification Profiles 8

9 5.1 Summary of supported Services For each Service Group contains a tabular respresentation of supported services, transfer syntax and role, e.g. Storage SOP Classes SOP Class UID Transfer Syntax User of Service (SCU) Provider of Service (SCP) Media Services Create Send Store Display Process FSR FSC FSU Computed Radiography Image Storage Implicit Little Endian Explicit Little Endian Explicit Big Endian (retired) Digital X-Ray Image Storage - For Presentation Implicit Little Endian Explicit Little Endian Explicit Big Endian (retired) Workflow Management SOP Classes SOP Class UID Transfer Syntax User of Service (SCU) Provider of Service (SCP) Modality Worklist Information Model - FIND Modality Performed Procedure Step SOP Class Storage Commitment Push Model SOP Class Implicit Little Endian Explicit Little Endian Explicit Big Endian (retired) Implicit Little Endian Explicit Little Endian Explicit Big Endian (retired) Implicit Little Endian Explicit Little Endian Explicit Big Endian (retired)

10 5.2 Mapping of Services to Application Entities For each application entity on the services being supported by the AE and the roles are defined Application Entity Supported Services Role Storage SCU, SCP Modality Worklist SCU Application Entity MPPS SCU Application Entity 2 Printing SCU 10

11 5.3 Supported Services For each supported service provide a detailed IOD description for each role, e.g.: Modality Worklist SCU: Query Keys, Type, Display on UI, Comments SCP: Matching Keys, Type, Return Key, Comments Storage SCU: IOD definitions, SR Content Sequences, Private Attributes and private SOP Classes SCP: Storage Level, Data Coercion, Display Requirements Query/Retrieve: For all supported SOP Classes SCU: Query Keys, Type, Display on UI, Comments SCP: Matching Keys, Type, Return Key, Comments 11

12 6 DICOM Configuration Lists all configuration parameters in table form organized by Services. Current proposal is, to document for each service local and remote AE Titles and dependent configuration information, e.g. Local Worklist AE configuration parameters Parameter Configurable Default Value Comment Calling AET (SCU) Yes WORKLIST_AE Called AET (SCP) N/A Port N/A Specific worklist parameter x Remote Worklist AE configuration parameters Parameter Configurable Default Value Comment Calling AET (SCU) N/A Called AET (SCP) YES No default Port YES 104 Host Specific worklist parameter x 12

13 7 Network Communication Details Provides technical information organized by AEs Provide Status Code Handling details by Service 7.1 Association Policies General AE Specific AE AE2 7.2 Status Handling Storage SCU Storage SCP Modality Worklist SCU Networking Interfaces Physical Network Interface Additional Protocols 7.4 Security Security Profiles Association Level Security Application Level Security 13

14 7.1 Association Policies If information association information is common to all service only provide once under Section otherwise document in Section x Name Value Networking Services Application Context Name Implementation Class UID Implementation Version Name Maximum number of simultaneous Associations as association initiator Maximum number of simultaneous Associations as association acceptor Maximum number of outstanding asynchronous transactions Media Services File Meta Information Version Implementation Class UID Implementation Version Name In Section x also document Association Initiation and Acceptance behavior 14

15 7.2 Status Handling Current Proposal is to document Status Codes by Service and Role, e.g for Storage SCU: Service Status Further Meaning Success Success 0000 Error Error Error Out of Resources Data Set does not match SOP Class Cannot Understand Error Code Related Fields A700 (0000,0902) A900 (0000,0901) (0000,0902) C000 (0000,0901) (0000,0902) Behavior Also Command Communication Behavior needs to be documented Exception Timeout Association Aborted Behavior <describe product behavior, if a timeout is encountered> <describe product behavior, if an association is aborted> 15

16 Questions Where should we put the Status codes: Associated with each service in section 5 or rather in an Error Handling section under Network Communication details. How to best document application specific behavior (e.g as a footnotes in tables in Section 5.1)? How should web services be documented? Charles Parisot will present his power point outlining the high level issues about claiming conformance in the DCS and conformance to the Standard when implementing web services in products. Are web-services and DIMSE services similar enough, that they could be documented together? 16

17 Open Issues for WG 31 How to best document (configuration) tables: Rather one big table or better separate sections and tables for each AE/Service, or separate by local and remote AEs? Currently Status Codes are documented in tables sorted by Service and Role. Could this be combined into one table? How much information is needed in Chapter 3 in addition to the disclaimer? Would the Glossary be part of it or would it go to an Annex? Detail level of overview: different users expect a different amount of information in the overview, how much detail should we provide? How can measurement information/content sequences of DICOM SRs be best documented 17

18 Closed Issues It was decided to split out AEs from services 18