HE/001177 Page 1 of 21 Document no : 001177 rev 1.1 NodeID Livelink : 19850754 Agfa HealthCare 20 September, 2010 AGFA HEALTHCARE DICOM Conformance Statement ORBIS RIS (NICE) Released Document no : 001177 rev 1.1 NodeID Livelink : 19850754 When printed, this is NOT a controlled copy
23
Embed
AGFA HEALTHC DICOM Conformance Statement · ORBIS RIS is able to forward MPPS messages to the PACS since it is an IHE MPPS manager. 2.1.2 Functional Definitions of AE’s 2.1.2.1
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
HE/001177 Page 1 of 21Document no : 001177 rev 1.1
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.
1 Introduction ............................................................................................61.1 Revision Record ................................................................................................... 61.2 Purpose and Intended Audience of this Document................................................ 61.3 General Remarks ................................................................................................. 61.3.1 Integration and Validation Activities.................................................................. 61.3.2 Future Evolution .............................................................................................. 61.4 Acronyms and Abbreviations ................................................................................ 71.5 Related Documents .............................................................................................. 7
2 Networking .............................................................................................82.1 Implementation Model .......................................................................................... 82.1.1 Application Data Flow Diagram........................................................................ 82.1.2 Functional Definitions of AE’s .......................................................................... 92.1.2.1 Functional Capability of RIS Application Entity ............................................ 92.1.3 Sequencing of Real World Activities................................................................. 92.2 AE Specifications.................................................................................................102.2.1 RIS Application Entity Specification.................................................................102.2.1.1 SOP Classes Supported ............................................................................102.2.1.2 Association Establishment Policies ............................................................102.2.1.2.1 General ................................................................................................102.2.1.2.2 Number of Associations ........................................................................102.2.1.2.3 Asynchronous Nature ...........................................................................102.2.1.2.4 Implementation Identifying Information..................................................112.2.1.3 Association Initiation Policies .....................................................................112.2.1.4 Association Acceptance Policies................................................................122.2.1.4.1 Receive Query for Worklist ...................................................................122.2.1.4.1.1 Description and Sequencing of Activity 122.2.1.4.1.2 Accepted Presentation Contexts 122.2.1.4.1.3 SOP Specific Conformance - Modality Worklist SOP Class 132.2.1.4.2 Receive MPPS .....................................................................................152.2.1.4.2.1 Description and Sequencing of Activity 152.2.1.4.2.2 Accepted Presentation Contexts 162.2.1.4.2.3 SOP Specific Conformance - MPPS 162.3 Network Interfaces...............................................................................................162.3.1 Physical Medium Support ...............................................................................162.4 Configuration.......................................................................................................172.4.1 AE Title/ Presentation Mapping.......................................................................172.4.1.1 Local AE Titles ..........................................................................................172.4.1.2 Remote AE Titles.......................................................................................172.4.2 Configuration Parameters...............................................................................17
3 Media Interchange................................................................................18
4 Support for Extended Character Sets...................................................19
1.1 Revision RecordRevision Number Date Reason for Change
1.0 February 28, 2007 Initial revision created by R&D RIS group in Vienna1.1 July 27, 2010 Update tables 2.4-1 and 2.4-2 : correct port numbers
1.2 Purpose and Intended Audience of this DocumentThis 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
1.3.1 Integration and Validation ActivitiesThe 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.
1.3.2 Future EvolutionAs 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.
HE/001177 Page 7 of 21Document no : 001177 rev 1.1
1.4 Acronyms and AbbreviationsDefinitions, terms and abbreviations used in this document are defined within the different parts of the DICOM standard. Abbreviations and terms are as follows:
AE DICOM Application Entity
AET Application Entity Title
ASCE Association Control Service Element
CD-R Compact Disk Recordable
DICOM Digital Imaging and Communications in Medicine
DIMSE DICOM Message Service Element
FSC File-Set Creator
FSU File-Set Updater
FSR File-Set Reader
GSDF Grayscale Standard Display Function
GSPS Grayscale Softcopy Presentation State
IE Information Entity
IOD (DICOM) Information Object Definition
ISO International Standard Organization
MPPS Modality Performed Procedure Step
MSPS Modality Scheduled Procedure Step
MWL Modality Worklist
PDU DICOM Protocol Data Unit
RIS Radiology Information System
SCU DICOM Service Class User (DICOM client)
SCP DICOM Service Class Provider (DICOM server)
SOP DICOM Service-Object Pair
UID Unique Identifier
VR Value Representation
1.5 Related Documents ACR-NEMA Digital Imaging and Communications in Medicine (DICOM) V3.0. 2006.
IHE Radiology Technical Framework Revision 7 – Final Text, May 2006
HE/001177 Page 8 of 21Document no : 001177 rev 1.1
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.
2.1.2 Functional Definitions of AE’s
2.1.2.1 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.
2.1.3 Sequencing of Real World Activities
3. Select Workitem (SPS)
Modality
1. Query RIS
2. Provide Worklist
4. ReceiveMPPS
5. Store MPPS
RIS
Figure 2.1-2: sequencing constraints
Under normal scheduled workflow conditions the sequencing constraints illustrated in Figure 2.1-2 apply:1. Query RIS2. Provide Worklist3. Select Workitem4. Receive MPPS5. Store MPPS
HE/001177 Page 10 of 21Document no : 001177 rev 1.1
2.2.1.1 SOP Classes SupportedThis 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 ManagementModality Worklist Information Model - FIND 1.2.840.10008.5.1.4.31 No YesModality Performed Procedure Step SOP Class 1.2.840.10008.3.1.2.3.3 No YesVerification SOP Class 1.2.840.10008.1.1 No Yes
2.2.1.2 Association Establishment Policies
2.2.1.2.1 GeneralThe DICOM standard Application context shall be specified.
Table 2.2-2: DICOM Application Context
Application Context Name 1.2.840.10008.3.1.1.1
2.2.1.2.2 Number of AssociationsRIS 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 10
2.2.1.2.3 Asynchronous NatureRIS Application Entity does not support asynchronous communication. Multiple outstanding transactionsare 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
HE/001177 Page 11 of 21Document no : 001177 rev 1.1
Table 2.2-5: DICOM implementation Class and Version for RIS Application Entity
Implementation Class UID 1.2.40.0.13.1.1
Implementation Version Name dcm4che2-2.0.10
2.2.1.3 Association Initiation PoliciesThe 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">172.25.12.149</param> </method> <method name = "setPort">
2.2.1.4.1.1 Description and Sequencing of ActivityThe 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.
2.2.1.4.1.3 SOP Specific Conformance - Modality Worklist SOP Class
Matching Key TypesSV or S Single Value MatchingWC wild card matchUI or L List of UID matchingSQ sequence matchDR date range matchR Range MatchingNONE Indicates that no matching is
supported, but that values for this Element are requested to be returned (i.e. universal matching)
* Wildcard MatchingUNIQUE 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.
Attribute Name Tag VR Types of MatchingSpecific Character Set 0008,0005 CS NONEScheduled station AE title 0040,0001 AE SScheduled Procedure Step Start Date 0040,0002 DA S,RScheduled Procedure Step Start Time 0040,0003 TM S,RScheduled Performing Physician's Name 0040,0006 PN S,*Modality 0008,0060 CS SAccession Number 0008,0050 SH SPatient's Name 0010,0010 PN S,*Patient's ID 0010,0020 LO SAll others NONE
HE/001177 Page 14 of 21Document no : 001177 rev 1.1
Table 2.2-8: Modality Worklist C-FIND Response status handling behavior
ServiceStatus
Further Meaning ErrorCode
Behavior
Success Matching iscomplete
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 Identifier does not match SOP Class
A900 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 Identifier does not match SOP Class
C000 –CFFF
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.
Cancel Matchingterminated due to Cancel request
FE00 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.
Pending Matches arecontinuing
FF00 The worklist item contained in the Identifier is collected for later display or further processing.
Pending Matches arecontinuing –Warning that one or more Optional Keys were notsupported
FF01 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
* * Any otherstatuscode.
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.
HE/001177 Page 15 of 21Document no : 001177 rev 1.1
2.2.1.4.2.1 Description and Sequencing of ActivityAfter 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
HE/001177 Page 16 of 21Document no : 001177 rev 1.1
Table 2.2-9: Presentation Contexts Proposed by RIS AE
Presentation Context Table
Abstract Syntax Transfer Syntax
Name UID Name List UID ListRole Extended
Negotiation
Modality Performed Procedure Step
1.2.840.10008.3.1.2.3.3 Implicit VR Little EndianExplicit VR Little Endian
1.2.840.10008.1.2
1.2.840.10008.1.2.1
SCP None
2.2.1.4.2.3 SOP Specific Conformance - MPPSThe 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 InterfacesORBIS 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.
2.3.1 Physical Medium SupportORBIS 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.
HE/001177 Page 17 of 21Document no : 001177 rev 1.1
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 PortMWL No Default 11112MPPS No Default 11112
2.4.1.2 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.
2.4.2 Configuration Parameters
Table 2.4-2: Configuration Parameter Table
Parameter Configurable (Yes/No)
Default Value
General ParametersDicom server port YES 11112Socket close delay YES 50Called AET titles YES AnyCalling AET titles YES Any
AE Specific ParametersMaximum PDU size the AE can receive YES 16384Maximum PDU size the AE can send YES 16384Number of simultaneous Associations by Service and/or SOP Class
YES 10
<Transfer Syntax support>, e.g. JPEG, Explicit VR, when configurable
Livelink ID: 19850754Version#: 4Version Date: 2010/07/27 04:35 PM CETStatus: Approved on 2010/09/20 11:25 AM CET Owner: Peter Buytaert (awabr)Created By: Peter Buytaert (awabr)Created Date: 2007/10/16 04:56 PM CETPDF Creation Date: 2010/09/20 11:27 AM CET