EndoSoft DICOM Conformance 2012utilize DICOM services to both receive and transfer DICOM data from...

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


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.


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


Value


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


Value


Additional

Patient History

0010,21B0 USER/I

mg File/

MWL

ANAP History Field (Table Patients)

General Series Module

Attribute

Name


Value


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


SOP class. From Modality Worklist

>Referenced

SOP Instance

UID


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.


Performing

Physician

Name

0008,1050 PN User VNAP Physician field in Study list.


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


Value


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


Value


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


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


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

EndoSoft DICOM Conformance 2012utilize DICOM services to both receive and transfer DICOM data from...

Documents

Transcript of EndoSoft DICOM Conformance 2012utilize DICOM services to both receive and transfer DICOM data from...