AGFA HEALTHCARE DICOM Conformance Statement

Transcription

1 HE/ Page 1 of 21 AGFA HEALTHCARE DICOM Conformance Statement ORBIS RIS (NICE) Released When printed, this is NOT a controlled copy

2 HE/ Page 2 of 21 Document Information Service-related contact information worldwide All service-related contact information is available on this URL Issued by: Agfa HealthCare SIV Connectivity Septestraat 27 B-2640 Mortsel Belgium tel: connectivity@agfa.com Agfa shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this publication. Agfa reserves the right to revise this publication and to make changes to its content at any time, without obligation to notify any person or entity of such revisions and changes. This publication may only be used in connection with the promotion, sales, installation and use of Agfa equipment. Copyright September, 10 Agfa HealthCare All rights reserved

3 HE/ Page 3 of 21 Conformance Statement Overview The ORBIS RIS (Radiology Information System) provides a Modality Worklist and computes received MPPS messages. Table 1.1-1: Network Services Supported SOP Classes User of Service (SCU) Provider of Service (SCP) Workflow Management Modality Worklist Information Model FIND Modality Performed Procedure Step SOP Class No Yes Yes Yes

4 HE/ Page 4 of 21 Table of Contents 1 Introduction Revision Record Purpose and Intended Audience of this Document General Remarks Integration and Validation Activities Future Evolution Acronyms and Abbreviations Related Documents Networking Implementation Model Application Data Flow Diagram Functional Definitions of AE s Functional Capability of RIS Application Entity Sequencing of Real World Activities AE Specifications RIS Application Entity Specification SOP Classes Supported Association Establishment Policies General Number of Associations Asynchronous Nature Implementation Identifying Information Association Initiation Policies Association Acceptance Policies Receive Query for Worklist Description and Sequencing of Activity Accepted Presentation Contexts SOP Specific Conformance - Modality Worklist SOP Class Receive MPPS Description and Sequencing of Activity Accepted Presentation Contexts SOP Specific Conformance - MPPS Network Interfaces Physical Medium Support Configuration AE Title/ Presentation Mapping Local AE Titles Remote AE Titles Configuration Parameters Media Interchange Support for Extended Character Sets Security...20

5 HE/ Page 5 of Security Profiles Association Level Security Application Level Security Annexes...21

6 HE/ Page 6 of 21 1 INTRODUCTION 1.1 Revision Record Revision Number Date Reason for Change 1.0 February 28, 2007 Initial revision created by R&D RIS group in Vienna 1.1 July 27, 2010 Update tables and : correct port numbers 1.2 Purpose and Intended Audience of this Document This document is a DICOM Conformance Statement for the DICOM Services of the ORBIS RIS product. The user of this document is involved with system integration and/or software design. We assume that the reader is familiar with the terminology and concepts that are used in the DICOM 3.0 standard and the IHE Technical Framework. Readers not familiar with DICOM 3.0 terminology should first read the appropriate parts of the DICOM standard itself, prior to reading this conformance statement. Although the use of this conformance statement in conjunction with the DICOM 3.0 standard is intended to facilitate communication with ORBIS RIS, it is not sufficient to guarantee, by itself, the inter-operation of the connection. 1.3 General Remarks Integration and Validation Activities The integration of any device into a system of interconnected devices goes beyond the scope of the DICOM 3.0 standard and this conformance statement when interoperability is desired. The responsibility for analyzing the applications requirements and developing a solution that integrates the Agfa equipment with other vendors systems is the user s responsibility and should not be underestimated. In some circumstances it might be necessary to perform a validation to make sure that functional interoperability between the Agfa equipment and non-agfa devices works as expected. The user should ensure that any non-agfa provider accepts responsibility for any validation required for their connection with the Agfa equipment Future Evolution As the DICOM 3.0 standard evolves to meet the user s growing requirements and to incorporate new features and technologies, Agfa will follow the evolution of the standard. This evolution of the standard may require changes to devices that have implemented DICOM 3.0. The user should ensure that any non-agfa provider, who connects with Agfa devices, also plans for future evolution of the DICOM standard. A refusal to do so may result in the loss of functionality and/or connectivity between the different products.

7 HE/ Page 7 of Acronyms and Abbreviations Definitions, terms and abbreviations used in this document are defined within the different parts of the DICOM standard. Abbreviations and terms are as follows: AE AET ASCE CD-R DICOM DIMSE FSC FSU FSR GSDF GSPS IE IOD ISO MPPS MSPS MWL PDU RIS SCU SCP SOP UID VR DICOM Application Entity Application Entity Title Association Control Service Element Compact Disk Recordable Digital Imaging and Communications in Medicine DICOM Message Service Element File-Set Creator File-Set Updater File-Set Reader Grayscale Standard Display Function Grayscale Softcopy Presentation State Information Entity (DICOM) Information Object Definition International Standard Organization Modality Performed Procedure Step Modality Scheduled Procedure Step Modality Worklist DICOM Protocol Data Unit Radiology Information System DICOM Service Class User (DICOM client) DICOM Service Class Provider (DICOM server) DICOM Service-Object Pair Unique Identifier Value Representation 1.5 Related Documents ACR-NEMA Digital Imaging and Communications in Medicine (DICOM) V IHE Radiology Technical Framework Revision 7 Final Text, May 2006

8 HE/ Page 8 of 21 2 NETWORKING 2.1 Implementation Model Application Data Flow Diagram Remote AE Query Modality Worklist Query RIS database for Worklist Remote AE send MPPS Create / update ORBIS RIS Application Entity Store MPPS to RIS database Remote AE Receive MPPS Create / update DICOM Standard Interface Legend Local Application Entity Real World Activity Association Negotiation Internal Communication Figure 2.1-1: Functional Overview Application Data Flow

9 HE/ Page 9 of 21 The RIS Application Entity receives a Query for the Worklist from a remote application and provides the set of worklist items matching the query request to the remote application. When a remote application sends an MPPS message, the data of this message is stored to the database and viewed in the RIS in a data entry form when pressing a button in this form. ORBIS RIS is able to forward MPPS messages to the PACS since it is an IHE MPPS manager Functional Definitions of AE s Functional Capability of RIS Application Entity The RIS Application Entity waits for other applications to connect at the presentation address configured for its Application Entity Title. When another application connects, the RIS Application Entity expects it to be a DICOM application. The RIS Application Entity will accept Associations with Presentation Contexts for SOP Classes of the Modality Worklist Service Classes. When a Modality Worklist Find request is received, RIS Application Entity will query the local database for a list of Scheduled Procedure Steps matching the query and will return a pending C-Find response for each match. The RIS Application Entity will also accept Associations with Presentation Contexts for SOP Classes of the Modality Performed Procedure Step Service Classes. The RIS Application Entity stores the received MPPS instances in the local database and shows the data in GUI of the CRIS Sequencing of Real World Activities RIS Modality 1. Query RIS 2. Provide Worklist 3. Select Workitem (SPS) 4. ReceiveMPPS 5. Store MPPS Figure 2.1-2: sequencing constraints Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure apply: 1. Query RIS 2. Provide Worklist 3. Select Workitem 4. Receive MPPS 5. Store MPPS

10 HE/ Page 10 of AE Specifications RIS Application Entity Specification SOP Classes Supported This Application Entity provides Standard Conformance to the following SOP Class(es): Table 2.2-1: SOP Classes for RIS Application Entity SOP Class Name SOP Class UID SCU SCP Workflow Management Modality Worklist Information Model - FIND No Yes Modality Performed Procedure Step SOP Class No Yes Verification SOP Class No Yes Association Establishment Policies General The DICOM standard Application context shall be specified. Table 2.2-2: DICOM Application Context Application Context Name Number of Associations RIS Application Entity can support multiple simultaneous Associations requested by peer AEs. Default is 10. This value can be configured through the attribute "setmaxclients" in the JAIF.xml configuration file. Table 2.2-3: Number of Associations as an Association Acceptor for RIS Application Entity Maximum number of simultaneous associations accepted Asynchronous Nature RIS Application Entity does not support asynchronous communication. Multiple outstanding transactions are not supported. It allows up to one invoked and one performed operation on an Association (it is synchronous). Asynchronous mode of operation is not supported. Table 2.2-4: Asynchronous Nature as an Association Initiator for RIS Application Entity Maximum number of outstanding asynchronous transactions 1

11 HE/ Page 11 of Implementation Identifying Information Table 2.2-5: DICOM implementation Class and Version for RIS Application Entity Implementation Class UID Implementation Version Name dcm4che Association Initiation Policies The RIS Application Entity forwards the MPPS to the PACS (Image Manager). In this case the MPPS acts as an SCU. The MPPS Manager will initiate an association with image manager to the given ip address and the given port. The following entries in the jaif.xml are necessary for this communication: <processor> <class name = "ag.gwi.app.comm.jaif.components.dicom.processor.mppsmanager"> <config> <method name = "setname"> <param type="java.lang.string">dicom_mpps_manager</param> </method> <method name = "sethostname"> <param type = "java.lang.string"> </param> </method> <method name = "setport"> <param type = "int">11499</param> </method> <method name="setcalledaet"> <param>mesa_imgmgr</param> </method> <method name="setcallingaet"> <param>orbis_ris</param> </method> </config> </class> </processor> <connection> <sender name="dicom_mpps_reader"/> <receiver name="dicom_mpps_processor"/> <receiver name="dicom_mpps_manager"/> </connection> <connection> <sender name="dicom_mpps_processor"/> <receiver name="dicom_writer"/> </connection>

12 HE/ Page 12 of Association Acceptance Policies Receive Query for Worklist Description and Sequencing of Activity The request for Query RIS is initiated by an external peer. The query is based on filter arguments like date, modality or Scheduled Station AE title. When Modality Worklist SCUs query the Modality Worklist of the RIS AE the queries run against the MWL items in the local database. RIS AE MWL SCU 1. Open Association 2. C-FIND Request (Worklist query) 3. C-FIND Response(Worklist item)-status = pending 4. C-FIND Response(Worklist item)-status = pending 5. C-FIND Response - status = success 6. Close Association Figure 2.2-1: RIS AE MWL Sequencing Diagram Accepted Presentation Contexts The RIS Application Entity is capable of proposing the Presentation Contexts shown in the following table: Table 2.2-6: Presentation Contexts Proposed by RIS AE Abstract Syntax Presentation Context Table Transfer Syntax Name UID Name List UID List Modality Worklist Information Model FIND Implicit VR Little Endian Explicit VR Little Endian Role SCP Extended Negotiation None

13 HE/ Page 13 of SOP Specific Conformance - Modality Worklist SOP Class SV or S WC UI or L SQ DR Matching Key Types Single Value Matching wild card match List of UID matching sequence match date range match R Range Matching NONE Indicates that no matching is supported, but that values for this Element are requested to be returned (i.e. universal matching) * Wildcard Matching UNIQUE Indicates that this is the Unique Key for that query level, in which case Universal Matching or Single Value Matching is used depending on the query level. Table 2.2-7: Modality Worklist C-FIND SCP Supported matching keys Attribute Name Tag VR Types of Matching Specific Character Set 0008,0005 CS NONE Scheduled station AE title 0040,0001 AE S Scheduled Procedure Step Start Date 0040,0002 DA S,R Scheduled Procedure Step Start Time 0040,0003 TM S,R Scheduled Performing Physician's Name 0040,0006 PN S,* Modality 0008,0060 CS S Accession Number 0008,0050 SH S Patient's Name 0010,0010 PN S,* Patient's ID 0010,0020 LO S All others NONE

14 HE/ Page 14 of 21 Table 2.2-8: Modality Worklist C-FIND Response status handling behavior Service Status Success Further Meaning Matching is complete Error Code Behavior 0000 The SCP has completed the matches. Worklist items are available for display or further processing. Refused Out of Resources A700 The Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged. Failed Failed Cancel Pending Identifier does not match SOP Class Identifier does not match SOP Class Matching terminated due to Cancel request Matches are continuing A900 C000 CFFF FE00 FF00 The Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged. The Association is aborted using A-ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged. If the query was cancelled due to too may worklist items then the SCP has completed the matches. Worklist items are available for display or further processing. Otherwise, the Association is aborted using A- ABORT and the worklist query is marked as failed. The status meaning is logged and reported to the user if an interactive query. The worklist item contained in the Identifier is collected for later display or further processing. Pending Matches are continuing Warning that one or more Optional Keys were not supported FF01 * * Any other status code. The worklist item contained in the Identifier is collected for later display or further processing. The status meaning is logged only once for each C-FIND operation The Association is aborted using A-ABORT and the worklist is marked as failed. The status meaning is logged and reported to the user if an interactive query. Any additional error information in the Response will be logged.

15 HE/ Page 15 of Receive MPPS Description and Sequencing of Activity After a modality has started the performance of a Procedure Step it should inform the RIS by sending an N- CREATE service request to the RIS Application Entity. At the end of the Performed Procedure Step the modality should send an N-SET command with all other mandatory attributes to RIS Application Entity. If the RIS Application Entity receives a valid Modality Performed Procedure Step SOP instance the information is stored into a structure of several database tables. This data is then shown in the GUI of the RIS. Modality RIS AE 1. Open Association 2. N-CREATE (MPPS) - IN PROGRESS 3. Close Association 4. Aquire Images() 5. Open Association 6. N-SET (MPPS) - COMPLETED 7. Close Association Figure 2.2-2: Sample Sequencing Diagram for MPPS

16 HE/ Page 16 of Accepted Presentation Contexts Presentation Context Table Table 2.2-9: Presentation Contexts Proposed by RIS AE Abstract Syntax Transfer Syntax Name UID Name List UID List Modality Performed Procedure Step Implicit VR Little Endian Explicit VR Little Endian Role SCP Extended Negotiation None SOP Specific Conformance - MPPS The RIS Application Entity can receive the following DIMSE services: N-CREATE N-SET An N-CREATE allows RIS Application Entity to create an instance of the Modality Performed Procedure Step SOP Class and provide information about a specific real-world Performed Procedure Step that is under control of RIS Application Entity. A N-SET allows RIS Application Entity to set Attribute Values of an instance of the Modality Performed Procedure Step SOP Class and provide information about a specific real-world Modality Performed Procedure Step that is under control of RIS Application Entity. 2.3 Network Interfaces ORBIS RIS provides DICOM V3.0 TCP/IP Network Communication Support as defined in PS 3.8 of the DICOM Standard. ORBIS RIS inherits its TCP/IP stack from the computer system upon which it executes Physical Medium Support ORBIS RIS is indifferent to the physical medium over which TCP/IP executes; it inherits the medium from the computer system upon which it is being executed.

17 HE/ Page 17 of Configuration AE Title/ Presentation Mapping Local AE Titles The local AE Titles and TCP ports are configurable in the JAIF.xml Table 2.4-1: AE Title Configuration Table Application Entity Default AE Title Default TCP/IP Port MWL No Default MPPS No Default Remote AE Titles Remote AE Titles, TCP/IP addresses and ports can be configured in the JAIF.xml. In the default configuration, Association Requests with any Calling AET will be accepted Configuration Parameters Table 2.4-2: Configuration Parameter Table Parameter Configurable (Yes/No) Default Value General Parameters Dicom server port YES Socket close delay YES 50 Called AET titles YES Any Calling AET titles YES Any AE Specific Parameters Maximum PDU size the AE can receive YES Maximum PDU size the AE can send YES Number of simultaneous Associations by Service and/or SOP YES 10 Class <Transfer Syntax support>, e.g. JPEG, Explicit VR, when configurable YES ExplicitVRLittleEndian, ImplicitVRLittleEndian Maximum time in milliseconds that an association may remain idle. The timeout in milliseconds for receiving DIMSE-RSP on an open association. YES YES 60000

18 HE/ Page 18 of 21 3 MEDIA INTERCHANGE ORBIS RIS does not support Media Services.

19 HE/ Page 19 of 21 4 SUPPORT FOR EXTENDED CHARACTER SETS ORBIS RIS supports the following character sets: ISO-IR 6 (default) Basic G0 Set ISO-IR 100 Latin Alphabet No. 1

20 HE/ Page 20 of 21 5 SECURITY 5.1 Security Profiles Security is not supported by this first implementation 5.2 Association Level Security 5.3 Application Level Security

21 HE/ Page 21 of 21 6 ANNEXES None

22 Document Metadata Title: Livelink ID: Version#: 4 Version Date: Status: Owner: Created By: Created Date: PDF Creation Date: Details as of PDF Creation Date _ORBIS RIS (NICE) DICOM Conformance Statement 2010/07/27 04:35 PM CET Approved on 2010/09/20 11:25 AM CET Peter Buytaert (awabr) Peter Buytaert (awabr) 2007/10/16 04:56 PM CET 2010/09/20 11:27 AM CET This document was approved by: Signatures: 1. Bruno Laffin (nawyv) on 2010/08/17 06:07 PM CET 2. Dirk Banik (awpsj) on 2010/09/17 08:44 AM CET Detailed Approver History: Approval Workflow started on 2010/07/27 04:37 PM CET Approval task originally assigned to Mario Girsch (awpps) Approval task reassigned to Dirk Banik (awpsj) on 2010/08/26 04:17 PM CET Approval task completed by Dirk Banik (awpsj) on 2010/09/17 08:44 AM CET Approval task originally assigned to and completed by Bruno Laffin (nawyv) on 2010/08/17 06:07 PM CET Version & Status History Version# Date Created Status /07/27 04:35 PM CET Approved /09/ /10/19 04:27 PM Obsolescence Check Event Completed /10/22

23 2 1 CET Approved /10/ /10/16 05:00 PM CET 2007/10/16 04:56 PM CET Rejected /10/19