EndoSoft DICOM Conformance Statement EndoSoft © Version 6.0 EndoVault © Version 1.3 Revision 1.10
EndoSoft DICOM Conformance Statement
EndoSoft© Version 6.0
EndoVault© Version 1.3
Revision 1.10
Revision History
Date Notes
01/25/2007 Version 1.3
02/25/2008 Version 1.4
03/06/2008 Version 1.5
05/07/2008 Version 1.6
09/15/2008 Version 1.7
11/23/2008 Version 1.8
03/10/2009 Version 1.9
06/22/2010 Version 1.10 (Added DICOM Encapsulated PDF information)
Table of Contents
1. Introduction 1
1.1. Intended Audience 3
1.2. Scope 3
1.3. Important Remarks 3
1.4. References 4
1.5. Definitions 4
1.6. Modalities supported 5
2. Network Conformance Statement 5
2.1. Implementation Model 5
2.2. Application Data Flow Diagram 6
2.3. Functional Definitions of AE’s 7
2.4. Sequencing of Real‐World Activities
3. AE Specifications 8
3.1. EndoSoft systems Specification 8
3.1.1. Association Establishment Policies 8
3.1.1.1 General 8
3.1.1.2 Number of Associations 8
3.1.1.3 Asynchronous Nature 9
3.1.1.4 Implementation Identifying Information 9
3.1.2. Association Initiation Policy 9
3.1.2.1 Associated Real‐World Activity 9
3.1.2.2 Associated Real‐World Activity
Query Modality Worklist Items from
a remote node 9
3.1.2.3 Associated Real‐World Activity
Store images in a Destination Node 10
3.1.3. Proposed Presentation Contexts 11
3.1.3.2 Association Acceptance Policy 11
3.2. SOP Specific Conformance 11
Table of Contents Continued
3.2.1 SOP Specifics Conformance for Storage SOP Class 11
3.2.1.1 “Secondary Capture” Image Storage
Attributes 11
3.2.1.2 Error Handling 18
3.2.2 SOP Specific Conformance for Modality
Worklist 18
3.2.2.1 Error Handling 19
4. Communication Profiles 19
4.1. Supported Communications Stacks (Part 8) 19
4.2. TCP/IP Stack 19
4.3. Physical Media Support 19
5. Extensions/Specializations/Privatizations 19
6. Configuration 19
7. Support of Extended Character Sets 19
8. Codes and Controlled Terminology 19
1. Introduction
Overview
This DICOM Conformance statement covers the following EndoSoft systems: EndoSoft GI, EndoSoft Urology,
EndoSoft Pulmonary, EndoSoft Pain Management, EndoSoft Orthopaedic, EndoSoft ENT, EndoSoft Cardiology,
EndoSoft Nuclear Medicine, EndoSoft Ophthalmology, EndoSoft Pathology, EndoSoft Dermatology, EndoSoft
General Surgery and EndoSwift© Image management system. Throughout the document these systems will be
collectively referred to as EndoSoft systems.
This DICOM Conformance Statement is divided into sections as described on the next page.
1
Section 1 (Introduction) begins with an overview and then describes the overall structure, intent, and
references for this Conformance Statement.
Section 2 (Network Conformance Statement) begins with an Implementation Model; which contains an
Application Dataflow Diagram. This section also contains the definition of AE’S and sequencing of real world
application.
Section 3 (AE Specifications) describes the overall structure, systems specification, intent, and references for
this Conformance Statement. It also describes the association Policies and SOP specification.
Section 4 (Communication Profiles) specifies the EndoSoft systems compliance to the DICOM requirements
for the implementation of Communications and Networking features.
This document is considered essential to provide interoperability between imaging equipment and modalities
and EndoSoft systems which is necessary for efficient patient care.
EndoSoft systems utilizes a DICOM module in order to communicate and export visible light as well as
ultrasound images to other DICOM compliant systems by which it can fully participate in a DICOM
environment.
The Introduction serves to familiarize the reader with DICOM terminology and general concepts. It should be
read prior to reading the Conformance Statements for the individual products.
In addition, the EndoSoft systems Conformance Statement, specifies the Lower Layer communications that it
supports (e.g., TCP/IP). However, the Technical Specifications are defined in the DICOM Part 8 standard. For
more information including Network Architecture and basic DICOM concepts, please refer to the Introduction.
For more information regarding DICOM, copies of the Standard may be obtained on the Internet at
http://www.medical.nema.org.
Comments on the Standard may be addressed to:
DICOM Secretariat NEMA
1300 N. 17th Street, Suite 1847
Rosslyn, VA 22209 USA
Phone: +1.703.841.3200
1.1 Intended Audience
This Conformance statement is intended for existing or potential users of EndoSoft systems, system
administrators of institutions using EndoSoft systems, as well as developers of systems wishing to
communicate with EndoSoft systems using the DICOM protocol.
The reader of this document is concerned with software design and/or system integration issues. It is assumed
that the reader of this document is familiar with the DICOM Standard and with the terminology and concepts
which are used in that Standard.
If readers are unfamiliar with DICOM terminology they should first refer to the http://www.medical.nema.org
then read the DICOM Standard itself, prior to reading this DICOM Conformance Statement document.
1.2 Scope
It is the intent of this document to provide an unambiguous specification for DICOM implementations of
EndoSoft systems. This specification, called a Conformance Statement, includes a DICOM Conformance
Statement and is necessary to ensure proper processing and interpretation of EndoSoft systems medical data
exchanged using DICOM. The EndoSoft systems DICOM Conformance Statements are available to the public.
1.3 Important Remarks
The use of these DICOM Conformance Statements, by itself, it is not sufficient to ensure that inter‐
operation will be successful. The user (or user's agent) needs to proceed with caution and address at least the
following issues:
• Integration ‐ The integration of any system into an integrated practice, department or enterprise
requires an analysis of the applications requirements. The responsibility to analyze the applications
requirements and to design a solution that integrates EndoSoft systems with the user is strongly
advised to ensure that such an integration analysis is correctly performed.
• Validation ‐ Testing the complete range of possible interactions between any EndoSoft Systems and
non–EndoSoft Systems, before the connection is declared operational, should not be overlooked.
Therefore, the user should ensure that any non–EndoSoft Systems provider accepts full responsibility
for all validation required for their connection with EndoSoft Systems.
This includes the accuracy of the data across the interface, and the suitability of data for the intended
applications. Such a validation is required before any clinical use (diagnosis and/or treatment) is performed.
• Future Evolution ‐ EndoSoft understands that the DICOM Standard will evolve to meet the user's
growing requirements.
• EndoSoft reserves the right to discontinue or make changes to the systems features including those
reflected by this DICOM Conformance statement.
• Interaction – It is the sole responsibility of the Non‐EndoSoft systems providers to ensure that
communication with the interfaced equipment does not cause degradation of EndoSoft systems
performance and/or function.
1.4 References
Digital Imaging and Communications in Medicine (DICOM) standard by the National Electrical Manufacturers
Association (NEMA).
DICOM Standard is available on internet:
http://www.medical.nema.org
1.5 Definitions
Table 1: Definitions and Abbreviations
AE DICOM Application Entity
AET Application Entity Title
DICOM Digital Imaging and Communications in Medicine
FSC File Set Creator
IOD DICOM Information Object Definition
PDU Protocol Data Unit
SCP Service Class Provider
SCU Service Class User
SOP Service Object Pair
TCP/IP Transmission Control Protocol/Internet Protocol
UID Unique Identifier
1.6 Modalities supported
CP = Colposcopy
CS = Cystoscopy
CT = Computed Tomography
DM = Digital Microscopy
ES = Endoscopy
LP = Laparoscopy
NM = Nuclear Medicine
RF = Radio Fluoroscopy
US = Ultrasound
2. Network Conformance Statement This section of the DICOM Conformance Statement specifies the compliance to DICOM conformance
requirements for the relevant Networking features on this EndoSoft Systems product. The EndoSoft Systems
utilize DICOM services to both receive and transfer DICOM data from other compliant DICOM entities over a
network.
Note that the format of this section strictly follows the format defined in DICOM
Standard PS 3.2 (Conformance). Please refer to that part of the standard while reading this section.
2.1 Implementation Model
EndoSoft systems support the DICOM Modality Worklist as well as Storage. It provides following DICOM
Service class.
DICOM Modality Worklist SCU (C‐FIND).
DICOM Storage SCU (C‐STORE).
DICOM Second Capture Image Storage SCU (C‐STORE).
DICOM Encapsulated Document Image Storage SCU (C‐STORE)
Verification SOP Class
5
2.2 Application Data Flow Diagram
This section contains the Application Data Flow model for the EndoSoft systems Application Entity (AE) and
how it works with remote DICOM devices. There is a functional definition of the AE and its Real‐World
Activities, and a description of the Real‐World sequence of events of the AE.
The network application model for the EndoSoft systems is shown in the following Illustration:
The EndoSoft DICOM SERVER Application Entity (AE) is an application that handles DICOM protocol
communication. The DICOM SERVER AE is automatically brought up when the EndoSoft Systems is powered on
and the main application is started.
All remote DICOM entities must be manually entered on the EndoSoft Systems by a system admin or an
EndoSoft field engineer.
6
The DICOM SERVER AE is invoked by the following:
Manual Transmit from the EndoSoft Systems to a Remote Host
For this operation, the user selects a series from the EndoSoft patient database window and then sends the
selected series to a remote DICOM AE. Application selects the host name from a configuration file. To change
the host name, User has to access the menu item on patient data screen under tools by the name “Node” and
changing the Node name as the data destination.
The declaration of the remote host is done through the Node Configuration window that can be accessed
through the System Administration menu. The Node Configuration window is used to configure the local host
and define remote entities.
The status of the transfer is displayed on the status bar of the patient database window. Any error in transfer
is communicated to the user through a pop‐up message indicating the nature of the error.
Only one series at a time may be selected for network transfer, but additional transfers can be initiated while
another data set is being transferred. The series information will be held in a buffer and the additional transfer
requests will be executed in the order that they were initiated as each previous transfer is completed.
2.3 Functional Definitions of AE’s
When EndoSoft systems are invoked, it shall have “Delphi” as it’s calling AE by default. It is configurable and
can be defined at the time of installation. It is capable of utilizing the full 16‐bit range (1‐65535) of port
numbers. EndoSoft systems sends images to remote DICOM AE’s after first converting them to DICOM from
their locally stored file format.
When the modality worklist data is requested, the application initiates the DICOM association request for the
modality worklist service from the remote DICOM Modality Worklist SCP. When the association is established,
the application further issues one or more C‐FIND requests to the remote SCP.
Ones the set of modality items are received from the remote Modality Worklist SCP, the application inserts
these items into the EndoSoft database.
Under EndoSoft DICOM Storage Module, EndoSoft Systems capture Images in jpegs and then converts it into
DICOM images.
Attributes are automatically taken from the modality Worklist item, but the user may enter the performed
procedure data, and certain attributes are pre‐configured. The captures object will be sent to the remote
archive server or image viewer with DICOM C‐STORE service.
7
The modality Worklist, and/or storage commitment transactions may be disabled according to the site.
2.4 Sequencing of Real‐World Activities
EndoSoft systems DICOM AE waits for user requests providing a user interface selection of files to be sent to
remote DICOM entities. After files have been selected and the procedure has been signed off, the DICOM
server running on the server will pick those images and will be send to the selected DICOM Entity.
Likewise for WORKLIST, EndoSoft systems can query for Patient and study information (i.e., issue “C‐FIND”
request). EndoSoft systems can request the list of patients that are scheduled based on certain search criteria.
3 AE Specifications This section describes EndoSoft systems Application Entity.
3.1 EndoSoft Systems Specification
EndoSoft systems provide Standard Conformance to the following DICOM V3.0 SOP Classes as an SCU.
Table 2: SOP Class
SOP Class Name SOP Class UID
Verification SOP class 1.2.840.10008.1.1
Secondary Capture Image Storage 1.2.840.10008.5.1.4.1.1.7
Modality Worklist ‐ Find 1.2.840.10008.5.1.4.31
Encapsulated PDF Storage 1.2.840.10008.5.1.4.1.1.104.1
3.1.1 Association Establishment Policies
3.1.1.1 General
EndoSoft systems will attempt to establish associations whenever it is invoked with appropriate parameters.
The maximum PDU size which EndoSoft systems will use is configurable, with a default of 64K.
3.1.1.2 Number of Associations
There are no inherent limitations on the total number of simultaneous associations which the Application
Entity represented by EndoSoft systems can maintain.
8
3.1.1.3 Asynchronous Nature
EndoSoft systems will not perform asynchronous operations window negotiation. All operations will be
performed synchronously.
3.1.1.4 Implementation Identifying Information
The software version number of the systems using this DICOM software is used as the Implementation Version
Number and a component of the Implementation UID.
This is a 5 digit number that will be updated whenever EndoSoft updates the software version.
• Implementation Class UID: 1.2.826.0.1.3680043.1.1.X…,
• Implementation Version Name : 6.1.5.02
3.1.2 Association Initiation Policy
When the DICOM SERVER Application Entity initiates an Association for any Real‐World Activity, it will
propose the Presentation Contexts for all Real‐World Activities; i.e., there is only a single, comprehensive
Presentation Context Negotiation proposed for the AE.
3.1.2.1 Associated Real‐World Activity
When a DICOM association is requested, an association is initiated so as to check for Validity and verification
of the remote AE’s ability to handle the requested association from EndoSoft systems. Once acceptance of the
association request has been verified, the local DICOM image files stored at the local DICOM AE will be sent to
the remote DICOM AE until finished. If more than a single file is to be sent, each file is first stored Confirmation
of remote storage success received, and then the next file sent until all files are successfully processed.
3.1.2.2 Associated Real‐World Activity ‐ Query Modality Worklist Items from a remote Node
The associated real world activity is a C‐FIND request invoked by EndoSoft Systems. Once the association is
successfully established, EndoSoft sends the C‐FIND request along with Modality Worklist query criteria to the
remote node. When the remote node returns the matched data items with its response EndoSoft systems will
add these data items in the Modality Task Worklist.
9
3.1.2.3 Associated Real‐World Activity ‐ Store images in a Destination Node
The associated real world activity is a C‐Store request invoked by EndoSoft Systems. Once the association is
successfully established, EndoSoft sends the acquired image, which is already processed, to the destination
DICOM node that is assigned to store the image.
3.1.3 Proposed Presentation Contexts
EndoSoft systems will only propose a single Presentation Context in each association. This presentation
context will use the SOP Class UID of the instance to be transmitted as the proposed Abstract Syntax, and the
proposed Transfer Syntaxes will be as shown in Table 3.
Table 3: Proposed Presentation Contexts for EndoSoft systems
Abstract Syntax Transfer Syntax Role Extended Negotiation
Name UID Name List UID List Role
Secondary Capture 1.2.840.10008.5.1.4.1.1.7 Implicit VR Little Endian
1.2.840.10008.1.2
SCU None
MWL 1.2.840.10008.5.1.4.31 Implicit VR Little Endian
1.2.840.10008.1.2.1
SCU None
Verification 1.2.840.10008.1.1 Implicit VR Little Endian
1.2.840.10008.1.2
SCU None
Encapsulated PDF Storage
1.2.840.10008.5.1.4.1.1.104.1 Implicit VR Little Endian
1.2.840.10008.1.2.1
SCU None
Implicit VR Little Endian
1.2.840.1000.8.1.2
SCU None
3.2 SOP Specific Conformance
3.2.1 “SOP Specifics Conformance for Storage SOP Class”
EndoSoft systems do not check, nor modify any elements of the image files it transfers, though it may
compress or decompress the pixel data according to the negotiated transfer syntax.
The content of the images sent/stored therefore depends entirely on the contents of the files provided in the
source directory.
10
3.2.1.1 “Secondary Capture” Image Storage Attributes.
USER – this attribute value source is from User input.
AUTO – this attribute value is generated automatically
IMG File – this attribute value is generated via vendor
MWL – this attribute value is selected from Modality Worklist when enabled
CONFIG – this attribute value source is a configurable parameter
For the Presence of Value Column
ALWAYS – this attribute is always in the SOP Instance and always with a valid value
VNAP – this attribute is always in the SOP Instance but may be "set to"
Zero length (meaning unknown)
EMPTY – this attribute value is always “set to” zero length
ANAP – this attribute is not always present
Table 4:
Patient Module
Attribute
Name
Tag VR Source Presence of
Value
Default Value and Notes
Patient’s name 0010,0010 PN USER/
Img
File/M
WL
ALWAYS Patient Full Name(Table Patients)
Patient ID 0010,0020 LO USER/I
mg File/
MWL
ALWAYS Patient MRN (Table Patients)
Patient’s Birth
Date
0010,0030 DA USER/I
mg File/
MWL
ALWAYS Patient DOB (Table Patients)
Patient’s Sex 0010,0040 CS USER/I
mg File/
MWL
ALWAYS Patient Sex (Table Patients)
Ethnic Group 0010,2160 SH USER/I
mg File/
MWL
ALWAYS Patient Race (Table Patients)
Other Patient
IDs
0010,1000 USER/m
wl
VNAP Account Number field in Patient
Table
Patient
Comments
0010,4000 LT USER VNAP Comments Field (Table Patients)
General Study Module
Attribute
Name
Tag VR Source Presence of
Value
Default Value and Notes
Study Instance
UID
0020,000D UI MWL/
Auto
ALWAYS Identifier Unique to Study – From
Modality or Generated by Device.
Study ID 0020,0010 SH MWL/
Auto
ALWAYS Procedure Number (Procedure
Table)
Study Date 0008,0020 DA USER/I
mg File/
MWL
ALWAYS Date of Procedure (Procedure Table)
Study Time 0008,0030 TM USER/I
mg File/
MWL
ALWAYS Time of Procedure (Procedure Table)
Referring
Physician’s
Name
0008,0090 PN User VNAP Referring Physician (Procedure
Table).Physician making referral
Accession
Number
0008,0050 SH MWL/
User
ANAP From Modality Worklist or user
input
Study
Description
0008,1030 LO User ALWAYS ER_ProcedurePerformed (Procedure
Table)
Reference
study
sequence
0008,1110 SQ MWL ANAP Study Scope sequence
From Modality Worklist
SOP Instance
UID
0008,0018 UI AUTO ALWAYS Identifies the SOP instance uniquely.
Generated by Device.
>Referenced
SOP Class UID
0008,1150 UI MWL VNAP Uniquely identifies the referenced
SOP class. From Modality Worklist
>Referenced
SOP Instance
UID
0008,1155 UI MWL VNAP From Modality Worklist
Physician(s) of
Record
0008,1048 User ALWAYS Physician (Procedure Table).
Responsible for the patient’s overall
care during study.
Patient Study Module
Attribute
Name
Tag VR Source Presence of
Value
Default Value and Notes
Additional
Patient History
0010,21B0 USER/I
mg File/
MWL
ANAP History Field (Table Patients)
General Series Module
Attribute
Name
Tag VR Source Presence of
Value
Default Value and Notes
Modality 0008,0060 CS Auto ALWAYS ES
Series Instance
UID
0020,000E UI Auto ALWAYS Identifier unique to series.
Generated by device
Series Number 0020,0011 IS Auto ALWAYS Series ID number. Generated by
device
Laterality 0020,0062 VNAP
Series Date 0008,0021 DA Auto ALWAYS DateTime series began.
<yyyymmdd>
Series Time 0008,0031 TM Auto ALWAYS Time series began.
<hhmmss>
Series
Description
0008,103E LO User VNAP Description provided by series user.
Maximum 512 characters.
Content Date 0008,0023 DA User ANAP <yyyymmdd>
Content Time 0008,0033 TM User ANAP <hhmmss>
Patient
Position
0018,5100 User ANAP
Patient
Orientation
0020,0020 CS Auto Empty
Abstract
Syntax
(Secondary
Capture Image
Storage)
0008,0016 Auto ALWAYS 1.2.840.10008.5.1.4.1.1.7
Referenced
Study
Component
Sequence
0008,1111 Auto ANAP Uniquely identifies series referenced
study component SOP instance.
>Referenced
SOP Class UID
0008,1150 UI MWL VNAP Uniquely identifies the referenced
SOP class. From Modality Worklist
>Referenced
SOP Instance
UID
0008,1155 UI MWL VNAP Uniquely identifies the referenced
SOP instance. From Modality
Worklist
>Requested
ProcedureID
0040,1001 Auto Identifier used for identification of
requested procedure included in the
Image service request.
>Scheduled
Procedure
Step ID
0040,0009 SH MWL VNAP Classification of Scheduled
Procedure Step Described. From
Modality Worklist
Performed
Procedure
Step Start
Date
0040,0244 DA User ALWAYS Date When the Performed
Procedure Step began. Date of
Procedure (Procedure TABLE)
Performed
Procedure
Step Start
Time
0040,0245 TM User ALWAYS Time When the Performed
Procedure Step began.
TimeofProcedure (Procedure TABLE)
Operator
Name
0008,1070 PN User VNAP Operator field in Study list.
Maximum 64 characters.
Performing
Physician
Name
0008,1050 PN User VNAP Physician field in Study list.
Maximum 64 characters.
Scheduled
Protocol Code
Sequence
0040,0008 SQ MWL VNAP From Modality Worklist
Instance
Number
0008,0013 IS Auto ALWAYS Generated by device
General Equipment Module
Attribute
Name
Tag VR Source Presence of
Value
Default Value and Notes
Manufacturer 0008,0070 LO Auto Always Endosoft systems
Institution
Name
0008,0080 LO Auto VNAP Name of the Hospital. From
Configuration
Station Name 0008, 1010 SH Auto Always Capture Station. From Configuration
Institutional
Department
Name
0008,1040 Auto Always Name of the department at the
Institution where the Equipment
was installed.
Manufacturer
Model Name
0008,1090 LO Auto ANAP Model name given to Equipment by
the manufacturer. From
Configuration
Software
Version(s)
0018,1020 Auto ANAP Software version of the Equipment
that Generated the Digital Image.
General Image Module
Attribute
Name
Tag VR Source Presence of
Value
Default Value and Notes
Instance
Number
0020,0013 IS Auto Always Generated by device
Patient
Orientation
0020,0020 CS Auto EMPTY Set Length=0 if no value can be
specified when an image is created.
Image Date 0008,0023 DA Auto Always Sets the date of start of image
generation.
Image Time 0008,0033 TM Auto Always Sets the Time of start of image
generation.
Conversion
Type
0008,0064 Auto Always WSD
Image Type 0008,0008 CS Auto VNAP
Acquisition
Number
0020,0012 IS Auto Always Issues numbers sequentially in units
of IPs read at the Image Reader.
Generated by device
Acquisition
Date
0008,0022 DA Auto VNAP Sets date of start of IP reading.
Acquisition
Time
0008,0032 TM Auto VNAP Sets Time of start of IP reading.
>Referenced
SOP Class UID
0008,1150 UI Auto Always From referenced image,
>Referenced
SOP Instance
UID
0008,1155 UI Auto Always From referenced image,
Lossy Image
Compression
0028.2110 ANAP Clarifies whether image has been
subjected to irreversible
compression
Pixel Spacing 0028,0030 DS Auto ANAP Physical distance, within the patient,
between the center’s of each pixel.
Image
Comment
0020,4000 LT User ANAP User‐defined comment on the
image. From user input. Maximum
1024 characters.
16
Image Pixel Module
Attribute Name Tag VR Source Presence of
Value
Default Value and Notes
Samples per Pixel 0028, 0002 US Auto Always 3 (Number of sample surfaces image
has)
Pixel Representation 0028, 0003 US Auto Always 0,1
Photometric
Interpretation
0028, 0004 CS Auto Always RGB
Planar Configuration 0028, 0006 0
Rows 0028,0010 US Auto Always Number of Rows in an image
Column 0028,0011 US Auto Always Number of Column in an image,
Bits allocated 0028, 0100 US Auto Always 8
Bits stored 0028, 0101 US Auto Always 8
High bits 0028, 0102 US Auto Always 7
Encapsulated DICOM Module
Attribute Name Tag VR Source Presence of
Value
Default Value and Notes
Burned In Annotation 0028, 0301 CS Auto Always NO
Document Title 0042, 0010 ST Auto Always Report Title
Concept Name Code
Sequence
0040, A043 SQ Auto Always Null
Encapsulated Document stream
0042, 0011 OB Auto Always containing a document encoded according to the MIME Type
MIME Type Encapsulated Document
0042, 0012
LO Auto Always application/pdf
17
Copyright © 1997‐2011 EndoSoft, LLC
3.2.1.2 Error Handling
EndoSoft systems are able to abort the association when a time out or an error occurs.
If the C‐STORE operation is not successful, the image(s) are set to “Not Send” status in the database. A
user‐configured number of additional attempt are made to store the image(s). If these attempts fail the
user must select the job and press “Retry Job” to complete the C‐STORE operation. A complete log file
gets created which a support team can analyze.
3.2.2 SOP Specific Conformance for Modality Worklist
Modality Worklist enables EndoSoft systems to query (using C‐FIND) for Patient Demographics and Study
Details from the MWL SCP, normally part of the PACS. The modality asks for a list of patients with chosen
criteria via Standard C‐FIND operation and Modality Worklist responds accordingly.
EndoSoft Systems Encodes the key listed in Table 5 in the query criteria.
Table 5: Query Key Attributes in Modality Worklist Query
Attribute Name Tag Matching Type
Scheduled Procedure
Step
Schedule Procedure Step
Sequence
(0040,0100)
> Schedule Procedure Step
Start Time
(0040,0002)
> Schedule Procedure Step
Stop Time
(0040,0003)
> Modality (0008,0060)
Patient Identification Patient’s Name (0010,0010)
Patient ID (0010,0020)
Other Patient Ids (0010,1040)
Patient Demographics Patient Birth Date (0010,0030)
Patient Sex (0010,0040)
Imaging Service request Accession Number (0008,0050)
Referring Physicians Name (0008,0090)
Requested Procedure Requesting Physician (0032,1032)
18
Copyright © 1997‐2011 EndoSoft, LLC
3.2.2.1 Error Handling
If an error occur when processing a Worklist response message, this message is skipped and EndoSoft
system proceeds to the next message.
4 Communication Profiles
4.1 Supported Communications Stacks
EndoSoft systems provide DICOM V3.0 TCP/IP Network Communication Support as defined in PS 3.8.
4.2 TCP/IP Stack
EndoSoft systems inherit its TCP/IP stack from the Windows system upon which it executes.
4.3 Physical Media Support
EndoSoft systems are indifferent to the physical medium over which TCP/IP executes; it inherits this from
the Windows system upon which it executes.
5 Extensions/Specializations/Privatizations
Not Applicable.
6 Configuration
EndoSoft systems obtains configuration information from an ini file located in its root directory name
EndoLocl.ini as well as from the Incident table in the database and only system admin can configure it.
7 Support of Extended Character Sets
EndoSoft systems does not, itself, generate or use extended character sets, but if present in any DICOM
instances received are preserved.
8 Codes and Controlled Terminology
No codes or controlled terminology are used by EndoSoft systems itself, though such codes present in any
DICOM instances received are preserved.
19