Shravan Kumar Tirumala: Cis000-6 MSC Thesis

CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Shravan Kumar Tirumala

0816185
Building a DICOM Indexed Store.

MSC Thesis
MSC Computer Science

Department of Computer Science & Technology
Supervisor: Dr. Nik Bessis.
2009/10
Page 1 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
CONTENTS
1 Introduction..................................................................................................................................................... 4
1.1 Overview..................................................................................................................................................... 4
1.2 Planning & Summary.................................................................................................................................. 5
2 Research Review.......................................................................................................................................... 6
2.1 DICOM........................................................................................................................................................ 6
2.1.1 Definition............................................................................................................................................................. 6
2.1.2 DICOM Standard Vs ACR-NEMA Standard.......................................................................................................6
2.1.3 Scope and Field of application...........................................................................................................................7
2.1.4 Goals of DICOM Standard.................................................................................................................................. 7
2.2 OGSA-DAI.................................................................................................................................................. 8
2.2.1 Using OGSA-DAI................................................................................................................................................ 8
3 Research methodology.............................................................................................................................. 10
3.1 Deploying OGSA-DAI............................................................................................................................... 10
3.2 Troubles deploying OGSA-DAI................................................................................................................. 11
3.3 Why ASP.Net over OGSA-DAI?................................................................................................................ 11
4 Design Strategy.......................................................................................................................................... 11
4.1 Application description.............................................................................................................................. 11
4.1.1 Features............................................................................................................................................................ 11
4.1.2 Services............................................................................................................................................................ 12
4.2 Design....................................................................................................................................................... 12
4.2.1 DICOM Server.................................................................................................................................................. 12
4.2.2 Diagnostic centre.............................................................................................................................................. 12
4.2.3 Hospital............................................................................................................................................................. 15
5 Tools & Techniques used.......................................................................................................................... 15

5.1 Tools used................................................................................................................................................ 15
5.1.1 Tools Overview................................................................................................................................................. 15
5.1.2 Database Engine.............................................................................................................................................. 16
5.1.3 Web Design...................................................................................................................................................... 16
5.1.4 Server scripting................................................................................................................................................. 16
5.2 Techniques used....................................................................................................................................... 16
5.2.1 Definitions......................................................................................................................................................... 16
5.2.2 DICOM Server.................................................................................................................................................. 17
5.2.3 Diagnostic Centre............................................................................................................................................. 18
5.2.4 Hospital............................................................................................................................................................. 19
6 Database Design......................................................................................................................................... 20
6.1 Table Structure & Definitions.................................................................................................................... 20
6.1.1 DICOM Server.................................................................................................................................................. 20
6.1.2 DIAOGCENTRE............................................................................................................................................... 24
6.1.3 Hospital............................................................................................................................................................. 27
7 Actual Implementation............................................................................................................................... 29
7.1 Technical Aspects..................................................................................................................................... 29
7.1.2 Hospital............................................................................................................................................................. 30
7.1.3 DICOM Server.................................................................................................................................................. 31
Page 2 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
7.2 Use Case Diagram’s................................................................................................................................. 31

7.2.1 Hospital............................................................................................................................................................. 31
7.2.3 DICOM Server.................................................................................................................................................. 32
7.3 User Manual.............................................................................................................................................. 33
7.3.1 User.................................................................................................................................................................. 33
7.3.2 Admin................................................................................................................................................................ 34
7.3.3 Doctor............................................................................................................................................................... 35
8 Testing and Results................................................................................................................................... 35

8.1 Testing...................................................................................................................................................... 35
8.2 Results...................................................................................................................................................... 35
9 Conclusion.................................................................................................................................................. 35
9.1 Goals......................................................................................................................................................... 36
9.1.1 Goals Set.......................................................................................................................................................... 36
9.1.2 Goal Achieved.................................................................................................................................................. 36
9.1.3 Goals Changed................................................................................................................................................. 36
9.2 Future Recommendations......................................................................................................................... 36
10 References............................................................................................................................................... 36
11 Appendices.............................................................................................................................................. 37
11.1 OGSA-DAI............................................................................................................................................. 37
11.1.1 Scenario – 1...................................................................................................................................................... 37
11.1.2 Scenario – 2...................................................................................................................................................... 41
11.1.3 Scenario – 3...................................................................................................................................................... 43
11.1.4 Scenario – 4...................................................................................................................................................... 48
11.2 DICOM.................................................................................................................................................. 50
11.2.1 Value Representations..................................................................................................................................... 50
11.2.2 Data Dictionary................................................................................................................................................. 50
Page 3 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
1 Introduction
This is composed of the documentation of the DICOM indexed store, implemented as a web application using
ASP.Net and SQL Server.
The Indexed store has the following features
 The store maintains patient’s information securely in a centralised database. Any diagnostic centre,
hospital or any health organisation implementing DICOM can access the information trough a unique
identification number.
 The follows the DICOM structure to store and pass patient data.
 The store implements user login system to avoid unauthorised access.
 User roles (admin/user/doctor) are implemented to provide access to data as per user requirements.
 Patient id is embedded in the DICOM image, so that the image is never separated from patient records.
 Data transfer is implemented using web servers (HTTP and SOAP)
 Patient’s CT report/X-Ray is stored in the database as per DICOM standards.
 The reports can be accessed or modified by only doctors.
Initially the implementation was planned to be done using OGSA-DAI, but after some research it was found that
implementation would be easier and cheaper in ASP.Net /SQL Server when compared to OGSA-DAI. The store
was implemented and tested for different user roles.
1.1 Overview
The objective of this task is to design and develop a DICOM indexed store for hospital and other medical
organisations. The implementation can be divided into three parts a Diagnostic Centre, Hospital and DICOM
Server. All three have different functionalities.
The main objectives can be summarised as:
DICOM Server
This is the main server which stores the patient information and also patient’s medical records and images.
Apart from that it provides several features:
 Store: is used to send patient information or other objects in DICOM structured format to the database
server and store the data..
 Query/Retrieve: is used to get the stored images and all other objects from the database.
 Printing: the DICOM printing service is used to send the images too DICOM printer, normally to print X-
Ray films.
 Offline media (DICOM files): it explains how to store the DICOM data sets on removable media.
Diagnostic Centre
 When the patient visits for the first time, a new patient record is generated.
 The record is structured as per DICOM standard, and sent to the DICOM Server to store it into the
database.
 Patient account information is stored in the local database, which may be retrieved based on the
requirement.
 Patient’s medical reports along with images are structured as per DICOM standard and sent to the
DICOM Server to store it in the database. However neither patient’s personal data nor medical data can
be retrieved or modified here.
 Separate section is available for admin type users, who can add, remove and edit users.
 Users and admin can communicate using inter application message service.
Page 4 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Hospital
 When the patient visits for the first time, a new patient record is generated.
 The record is structured as per DICOM standard, and sent to the DICOM Server to store it into the
database.
 Patient account information is stored in the local database, which may be retrieved based on the
requirement.
 Patient’s personal and medical data can be accessed by doctors.
 The data is retrieved from the DICOM Server and is converted into normal text and is displayed for
doctor’s view.
 Medical images and reports are also retrieved from DICOM Server and are presented in normal user
viewable type.
 Doctor’s can edit patient’s personal data to certain extent.
 Doctor’s can update the medical reports and print the medical images.
 Except doctor’s no one can view/edit patient’s medical reports/images.
 Separate section is available for admin type users, who can add, remove and edit users.
 Users, doctors and admin can communicate using inter application message service.
1.2 Planning & Summary

The application was developed in several stages. The stages can be briefly discussed as:
Research:
An intense research was carried out; this was needed to gain knowledge about DICOM. Major source of the
research material was the various articles published on DICOM standards by the DICOM owner, the National
Electrical Manufacturers Association (NEMA) published in January 2008 available on the official DICOM
website.
Research Methodology:
After gaining some knowledge on DICOM standard, some research was done on the technology to be used for
the implementation. Initially OGSA-DAI, was opted as appropriate technology to implement the DICOM store.
Later it was found that implementation was simple and cost effective on ASP.Net platform with SQL Server as
database. Hence the implementation was started on the .Net platform.
Data Accumulation:
DICOM maintains a data dictionary, which is to be followed to store data in the DICOM standard. Value
Representations are also used to get the data types used in DICOM. As the data dictionary was a huge set of
data most commonly used data is stored in the DICOM Server database and the rest is maintained as CSV files
in the server. All the VR’s are defined in the DICOM Server database.
Database Design:
Three separate databases were designed, one for each phase i.e. Diagnostic centre, Hospital and DICOM
Server.
Tools & Techniques used:
Page 5 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
The database was designed in Microsoft SQL Server. The application was implemented in ASP.Net with C# as
server side code. Web service was used to implement the DICOM Server services.
Testing:
The application was tested for all services and defects were rectified.
2 Research Review
A research was carried out on DICOM and al the information required for building a DICOM based indexed
store was collected. Then the implementation was planned to b done in OGSA DAI. The concepts of DICOM
and OGS-DAI can be briefly described as:
2.1 DICOM
2.1.1 Definition
“DICOM stands for Digital Imaging and Communications in Medicine. It is a standard for transferring medical
images between health organizations. Apart from that it also provides many services which include storing,
query, printing reports, printing and data backup. It typically consists of a file format and a network protocol for
data exchange. DICOM is particularly useful in exchange and storage of image data. For example a patient’s X-
Ray or CT scan can be shared between diagnostic centers and hospitals. [1]
2.1.1.1 History
With the introduction of computed tomography (CT) followed by other digital diagnostic imaging modalities
in the 1970's, and the increasing use of computers in clinical applications, the American College of Radiology
(ACR) and the National Electrical Manufacturers Association (NEMA) recognized the emerging need for a
standard method for transferring images and associated information between devices manufactured by various
vendors. These devices produce a variety of digital image formats. [1]
The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA)
formed a joint committee in 1983 to develop a standard to:
 Promote communication of digital image information, regardless of device manufacturer.
 Facilitate the development and expansion of picture archiving and communication systems
(PACS) that can also interface with other systems of hospital information.
 Allow the creation of diagnostic information databases that can be integrated over a wide
variety of devices distributed geographically. [1]
ACR-NEMA published outcomes of meetings held by professionals as standards. These specify a hardware
instance, a minimum set of software commands and a consistent set of data formats.[1]
2.1.2 DICOM Standard Vs ACR-NEMA Standard

The DICOM standard for digital medical images has lot of features which are not part of previous ACR-NEMA
standards. The enhancements can be briefly stated as;
1. ACR-NEMA standard was applicable in point to point communication system and to use it in a network
a special network unit was required whereas DICOM is applicable in network communication using
TCP/IP or HTTP.
2. DICOM specifies a file type so that the data can be stored in any device off-line. The previous ACR-
NEMA standard is not applicable for offline media environment.
3. Trough the concept of service classes, DICOM clearly shows the data associated to service commands
and data exchange.
Page 6 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
4. It shows levels of conformance.

5. It introduces explicit information objects for not only for images and graphics but also for waveforms,
reports, printing etc.
6. It specifies an established technique to identify a unique object.[2]
2.1.3 Scope and Field of application

The DICOM Standard facilitates interoperability of medical imaging equipment by specifying:
 For network communications, a set of protocols to be followed by devices claiming conformance
to the standard.
 The syntax and semantics of commands and associated information which can be exchanged
using these protocols.
 For media communications, a set of media storage services to be followed by devices claiming
conformance to the standard as well as file format and a medical directory structure to facilitate
access to the images and related information stored on interchange media.
 Information that must be supplied with an implementation for which conformance to the
standard is claimed.
The DICOM Standard does not specify:

 The implementation details of any features of the standard on a device claiming conformance.
 The overall set of features and functions to be expected from a system implemented by
integrating a group of devices each claiming DICOM conformance.
 A testing validation procedure to assess an implementation’s conformance to the standard.
The DICOM Standard pertains to the field of Medical Informatics. Within that field, it addresses the exchange of
digital information between medical imaging equipment and other systems. Because such equipment may
interoperate with other medical devices, the scope of this Standard needs to overlap with other areas of medical
informatics. However, the DICOM Standard does not address the breadth of this field.[1]
2.1.4 Goals of DICOM Standard

The DICOM Standard facilitates interoperability of devices claiming conformance. In particular, it:
 Addresses the semantics of Commands and associated data. For devices to interact, there
must be standards on how devices are expected to react to Commands and associated data,
not just the information which is to be moved between devices;
 Addresses the semantics of file services, file formats and information directories necessary for
off-line communication;
 Is explicit in defining the conformance requirements of implementations of the Standard. In
particular, a conformance statement must specify enough information to determine the functions
for which interoperability can be expected with another device claiming conformance.
 Facilitates operation in a networked environment.
 Is structured to accommodate the introduction of new services, thus facilitating support for
future medical imaging applications.
 Makes use of existing international standards wherever applicable, and itself conforms to
established documentation guidelines for international standards.
Even though the DICOM Standard has the potential to facilitate implementations of PACS solutions, use
of the Standard alone does not guarantee that all the goals of a PACS will be met. This Standard facilitates
interoperability of systems claiming conformance in a multi-vendor environment, but does not, by itself,
guarantee interoperability.
This Standard has been developed with an emphasis on diagnostic medical imaging as practiced in radiology,
cardiology and related disciplines; however, it is also applicable to a wide range of image and non-image related
information exchanged in clinical and other medical environments.[2]
Page 7 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Typical DICOM communication model can be summarized in a figure as shown in below figure:
figure 1 general DICOM communication model
[1,2,3]
2.2 OGSA-DAI
OGA-DAI stands for Open Grid Services Architecture-Data Access and Integration. OGSA-DAI is an extensible
framework accessed via web services that execute data centric workflows that involves heterogeneous data
resources. It provides services like data access, integration, transformation and delivery within a grid. It acts like
a toolkit for building high level application specific data services.[6]
2.2.1 Using OGSA-DAI

OGSA-DAI is all about sharing structured data resources. Before going into details of using OGSA-DAI some
important definitions are to be described:[6]
2.2.1.1 Definitions
2.2.1.1.1 Activities
An activity can be called as a named unit of functionality. Example activities include
 Executing a SQL query
 ZIP a batch of data
 Deliver data to FTP server
 List the files in a directory
An activity may have 0 or more named input or output parameters. Blocks of data passes from an
activities output to another’s input.
2.2.1.1.2 Workflow
Page 8 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Workflow can be defined as a group of activities running for a particular definition. An example of
OGSA-DAI workflow can be shoen in the figure below:
figure 2 OGSA-DAI Workflow
2.2.1.1.3 Data Streaming

Data streams in an activity in a pipeline like way. Each activity operates on a different data stream.
2.2.1.1.4 Types of Workflow
2.2.1.1.4.1 Pipeline Workflow

A set of chained activities executed in parallel with data flowing in between the activities.
2.2.1.1.4.2 Sequence Workflow

A set of Sub-Workflows each executed in a sequence. For example
 Sub-Workflow – 1: create database tables
 Sub-Workflow – 2: load data into the table
2.2.1.1.4.3 Parallel Workflow

A set of Sub-Workflows executed in parallel.
2.2.1.2 Executing Workflow

The execution of workflow follows the following steps
 Client submits workflow (request) to data request execution service.
Page 9 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
 Data request execution service (DRES), normally defined in a web service exposes a
data request execution resource (DRSR).
 Request status is returned to the client.
 Status of execution of each activity in a workflow is maintained.
 Status of execution of whole workflow, which is derived from the status of its activities,
is maintained.
 DRER performs following operations
o Parses workflow.
o Creates activities
o Provides activities with target resources (if any).
o Executes workflow.
o Builds request status..
 Data resource provides access to the data.”[6]
[6]
3 Research methodology
After the required research work, the implementation was planned to be done using OGSA-DAI. Both the front
end and database was planned to be implemented using OGSA-DAI.
3.1 Deploying OGSA-DAI

The work started with deploying OGSA-DAI on the system. Deployment method was described in the OGSA-
DAI blogs as certain steps, which were followed. These can be summarised as:
 Installing prerequisite software
o Download and install java.
o Set environmental variables JAVA_HOME, PATH and CLASSPATH.
o Download and install tomcat.
o Download and install Apache Ant.
o Set environmental variable ANT_HOME and change the environmental variable
PATH.
o Download and install MySQL.
 Deploy OGSA-DAI Axis
o Download and deploy OGSA-DAI.
o Download database driver.
 Configuring server
o Configure and deploy a relational resource file.
o Configure and deploy file system resource file.
 Test OGSA-DAI Server deployment
o Test web access.
o Create test databases.
o Test server client
o Test SQL client
o Test File client.
Reference: “steps to deploy OGSA-DAI”

Available at: http://blog.ogsadai.org.uk/?p=352.
Page 10 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
3.2 Troubles deploying OGSA-DAI

While trying to deploy OGSA-DAI, many issues were to be faced. Initially many errors occurred, then, I
registered in the official OGSA-DAI mailing list at ogsa-dai-users@lists.sourceforge.net and then took help from
experts. With help of them could continue deploying, but later at a stage further research was conducted and
was concluded that building a DICOM indexed store on ASP.Net and SQL Server is much better option than in
OGSA-DAI.
Details of errors faced and email lists, showing communications with OGSA-DAI users can be seen in section
11.1 of this document.
3.3 Why ASP.Net over OGSA-DAI?

After further research on the implementation base, ASP.Net was found as a better alternative to OGSA-DAI.
The following key factors laid a strong foundation for the decision.
 OGSA-DAI is very powerful in managing data resource sharing, but is not that good to
develop user interface for applications.
 ASP.Net provides is a powerful development tool, it provides simple ways to design a
very good user interface and also perform powerful programming.
 Using C#, we can define all the required services accurately and ADO concepts of
ASP.Net provide a powerful way to interact with databases.
 SQL Server provides a powerful database engine, wherein one can store, retrieve,
modify and do custom actions on data.
 ASP.Net also provides a platform to implement the communication protocol, which is
essential for DICOM indexed store.
 On top of all ASP.Net has vast tech support. As OGSA-DAI is a new and upcoming
technology, not much support is available. Support, not only web but books,
publications etc.
4 Design Strategy
4.1 Application description
What is a DICOM indexed store? What features or services are expected from a DICOM indexed store?
A DICOM indexed store can be described as a central server where all patient information, medical records,
images etc are stored in a standard format.
4.1.1 Features
Let’s assume a real world DICOM indexed store. There would be several health organizations which
are registered with DICOM service or use the DICOM service. The following would be the expected
features of the store:
 Patient visiting for the first time must be provided with an unique identification.
 Re-visiting patient’s details must be accessible trough the unique ID.
 Patient’s medical records, images and reports must be accessed by the doctor’s trough
the same ID.
Page 11 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
 Every record, image or report must be embedded with the patient id so that they are not
separated with patient’s details; this ensures minimal mistakes in identifying correct
patient reports.
 Doctor’s must be able to update medical reports, dosage information, next visit date,
prescriptions etc.
 Diagnostic centers must be able to add new images and reports to existing patient.
 New patient can be added both at diagnostic centre and hospitals.
 If a patient is added from any one organization, others must be able to recognize them
as existing patient.
 Every user must only be allowed to access data he is allowed to and all the data must
be prevented from unauthorized access.
 Not all users must be able to update all data.
4.1.2 Services
A DICOM server is expected to facilitate the following services:
 Store the patient personal data, medical reports, images and records.
 Retrieve the patient personal and medical data
 Update patient personal and medical data.
 Send and receive data in DICOM format.
 Convert DICOM formatted data into normal form and normal data into DICOM format.
4.2 Design
Our application’s design is divided into three parts; the basic structure composes of a DICOM server, Diagnostic
centre and a hospital.
The design of each part can be described briefly as:
4.2.1 DICOM Server

As the DICOM server operates as a pure backend side not much design is involved. DICOM server is
a web application, wherein all the services provided are written in a web service.
An admin section is provided to have control over the data dictionary, value representations etc. the
admin can add new fields in VR and Data dictionary.
4.2.2 Diagnostic centre

When the Diagnostic centre website runs, it first presents a login form where it checks the user
authenticity. The design of this section can be described with the following aspects;
 The home page has the message box wherein it shows all the messages sent to that
user by all other users or by admin.
 It shows options to reply to the sender or compose a new message.
 The page displays navigations to other pages.
 In the patients page it shows all the existing patients and have an option to search the
patient with ID
Page 12 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
 A link is provided to add patients, wherein new patient information can be added.
 Patients account information may be retrieved.
 Admin home page is also a login page, then a message box.
 Admin can view users, edit them and delete them.
4.2.2.1 Screenshots
The following are the design screenshots:
4.2.2.1.1 Home page
4.2.2.1.2 Message box page
Page 13 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
4.2.2.1.3 Patient page
4.2.2.1.4 Edit patient
Page 14 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
4.2.2.1.5 Update patient
4.2.2.1.6 Add report
4.2.3 Hospital
The design part of the hospital is similar to that of the diagnostic centre. It also contains the same
page structure which adds, edits patients. Additional design part is where doctors can view images
and edit reports.
5 Tools & Techniques used

This section deals with all the tools used and the exact working part of the application.
5.1 Tools used
5.1.1 Tools Overview

Tools used to build the application are:
Page 15 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
 Microsoft SQL Server

 Microsoft Visual Studio 2008
 Internet Information Services.
5.1.2 Database Engine

The application uses three different databases one each for DICOM Server, Diagnostic centre and
Hospital. All the databases are designed using Microsoft SQL Server.
5.1.3 Web Design

The design part is done using ASP.Net, which intern uses HTML & DHTML. Styling is done using
CSS files.
5.1.4 Server scripting

All the server side scripting/code is written in C#.
5.2 Techniques used

Before going in details of the techniques used in various parts of the application it is useful to know some
technical aspects of the heart of our application DICOM.
5.2.1 Definitions
Let us define some key words.
5.2.1.1 Value Representation

Abbreviated as VR, represents the type of data examples include patient name, date etc.
5.2.1.2 Data Tag

A data tag is a unique id representing the data field. These tags are defined in the data dictionary of
DICOM. Data tag is formed with a combination of 8 bytes. The first 4 bytes represent the group which
the data belongs to and the next 4 bytes represent the data field.
For example, {0010,0020} represents patient id. Where the 4 bytes i.e. 0010 represents data group
patient’s information and the next 4 bytes 0020 represents the field is id.
5.2.1.3 Data Set

All the information stored in DICOM format is stored in the form of data sets. Each data set consists of
set of data elements.
5.2.1.4 Data Element

Group of data elements comprises a data set. A data element contains a data tag, value
representation, value length and a field indicating that for one id there can be one or multiple values.
Example telephone numbers, for one patient there may be many telephone numbers.
The technical flow of the application is described in this section.
Page 16 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
5.2.2 DICOM Server
5.2.2.1 Functionality
The DICOM Server receives patient information or patient medical records from either diagnostic
centre or hospital in the DICOM format. It then converts it into normal format and stores in the
database. Images are stored using metadata like images are received as set of byte values, they are
then formed into an image and stored in the database.
On retrieval the DICOM server gets the data from the database, converts it into the DICOM standard
and then sends it to the Diagnostic centre or hospital.
5.2.2.2 Technology
The server is implemented as three tier architecture. The three layers can be described as:
5.2.2.2.1 Layer – 1 (Service layer)

All the methods to provide desired services by DICOM Server are defined in this layer. A web server
is used for this purpose. All the methods providing services are written in the web server and can be
accessed by all the health organisations registered with DICOM.
5.2.2.2.2 Layer – 2 (DICOM layer)

DICOM data elements and data sets are defined in this layer. A data element is defined as a class
with all the required patient information as attributes. A dataset is defined as a class which has a
group of data elements as attributes.
5.2.2.2.3 Layer – 3 (Database layer)

Database connecting string is defined in this layer. All the methods which require connecting to
database to get data from database or insert data into database are defined here. Any functionality
which requires connection to database has to use methods defined in this layer. No other layer has
methods defined to access database directly.
5.2.2.3 Technical flow

The web server receives the patient information in the form of an object of data set class. It then
sends the object to DICOM layer where the object is converted to normal information format. It then
sends the normal information to the database layer to store it in the database.
Technical flow can be shown as:
Page 17 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
5.2.3 Diagnostic Centre
Anyone who needs to access or use the Diagnostic services has to login. After login a user can add
new patient, edit patient details and add new medical reports to existing patients. They can also add
images like X-Ray scan etc. to existing patients. Patients account information can be updated. Users
can exchange messages among them and also with admin.
An admin can create, edit or delete a user. Perform all the activities done by users and exchange
messages.
All the patient personal and medical information is not stored in the local database; instead it is
formatted into DICOM structure and send to the DICOM Server. So, all the data is stored there. Only
the patient account information like last visited date, last bill amount etc is viewable and editable.
Any type of user in the Diagnostic centre has no authority to retrieve or edit patient personal and
medical information.
5.2.3.2 Technology
5.2.3.2.1 Layer – 1 (User Interface layer)

This layer includes a design part wherein a user can browse trough and access the services provided.
There are several forms designed in this layer like add patient form etc.



The user interface layer connects to the database layer for any database related queries and
connects to DICOM layer to convert data into DICOM format.
Page 18 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
5.2.4 Hospital
Anyone who needs to access or use the Hospital services has to login. After login a user can add new
patient, edit patient details, and add/edit medical reports to existing patients.. Patients account
information can be updated. Users can exchange messages among them and also with admin and
doctors.
An admin can create, edit or delete a user. Perform all the activities done by users and exchange
messages.
All the patient personal and medical information is not stored in the local database; instead it is
formatted into DICOM structure and send to the DICOM Server. So, all the data is stored there. Only
the patient account information like last visited date, last bill amount etc is viewable and editable.
Any type of users except doctors in the Hospital has no authority to retrieve or edit patient personal
and medical information.
Doctors can view and edit patient medical information. They still cannot edit medical images or
reports, but can update the dosages, prescriptions etc.
5.2.4.2 Technology
5.2.4.2.1 Layer – 1 (User Interface layer)

This layer includes a design part wherein a user can browse trough and access the services provided.
There are several forms designed in this layer like add patient form etc.


Page 19 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store

The user interface layer connects to the database layer for any database related queries and
connects to DICOM layer to convert data into DICOM format.
6 Database Design
Three different databases have been created one each for Diagnostic Centre, Hospital and DICOM Server. The
table and field names are discussed in this section.
6.1 Table Structure & Definitions
6.1.1 DICOM Server
6.1.1.1 Table - 1
Table name DATAELEMENTS
DE_TAG Unique identifier, used to identify a field. It is a combination of 8 bytes, the first four bytes
represent the data group and the rest define the field.
DE_NAME Name of the Data Element.
DE_VR Defines the Value Representation of the data element.
DE_VM Determines whether the record contains single or multiple values. For example a patient may
have multiple phone numbers but has only one Date of Birth.
This table stores the data dictionary of the DICOM Standard. All the data that comes in is in the form of data
elements, by using the tag values the data field is identified.
Example
DE_TAG DE_NAME DE_VR DE_VM
0010,0010 Patient Name PN 1
Page 20 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
In the above example, the tag 0010,0010 represents patient’s name, which is of PN DICOM data type and one
record can have only single value.
6.1.1.2 Table - 2
Table name MESSAGES
USERID ID of the recipient
SUB subject of the message
MSG actual message
FROMID ID of the sender
ISREAD a flag specifying whether the message is read or unread
MSGTYPE specifies either the message is sent, received etc.
DATE date when the message is sent
The table stores messages sent and received by users. The field MSGTYPE specifies whether the message is
sent or received. If the message is sent type then it is shown in the sent section of the message box page in the
application.
Example
USERID SUB MSG FROMID ISREAD MSGTYPE DATE

2 Hi Hi 1 N Inbox 2009-09-14
20:29:57.560
The above example shows a sample record in the messages table.
6.1.1.3 Table - 3
Table name PATIENTS
PID ID of the patient
PNAME patient’s name
PDOB patient’s date of birth
PSEX patient’s gender
PINSURANCE patient’s insurance reference number
PBIRTHNAME patient’s birth name (if different from present name)
PAGE patient’s age
PWEIGHT patient’s weight
PADDRESS patient’s residential address
PMOTHERSBNAME patient mother’s birth name
Page 21 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
PALERGIES any allergies possessed by patient

PTELEPHONE patient’s phone number
PETHINIC patient’s ethnic group
POCCUPATION patient’s occupation
PSMOKING patient’s smoking status
PADDITIONALHISTORY patient’s additional history, which describes whether the patient had suffered
from any serious accident, heart attack or any other serious health problems in
the past.
PPREGNANCY patient’s pregnancy status (N/A if not applicable)
PCOMMENTS any additional comments made by patient.
The table stores the entire patient’s personal information. The information can be added or modified from front
end.
Example
PID PNAME PDOB PSEX PINSURANCE PBIRTHNAME PAGE PWEIGHT PADDRESS

1 Alex 24/04/1984 M INS0876 25 89 215, park
street Luton
PMOTHERSBNAME PALERGIES PTELEPHONE PETHINIC POCCUPATION PSMOKING

Jennie n/a 07566397440 Catholic Student Y
PADDITIONALHISTORY PPREGNANCY PCOMMENTS

Had a minor accident last year n/a Suffering from severe stomach
ache since one week
The above example shows a sample record in the patient’s table.
6.1.1.4 Table - 4
Table name USER_DETAILS
FIRSTNAME first name of the user
LASTNAME last name of the user
MIDDLENAME middle name of the user
FULLNAME full name of the user
MB mobile number of the user
PH additional phone number of the user
ADDRESS user residential address
Page 22 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
EMAIL user email
The table stores the personal details of the users

Example
USERID FIRSTNAME LASTNAME MIDDDLENAME FULLNAME MB PH

2 Shravan Tirumala Kumar Shravan 07599397430 01582524673
kumar
Tirumala
ADDRESS EMAIL
80, crawley road, Luton 0816185@beds.ac.uk
The above example shows a sample record in the user_details table.
6.1.1.5 Table - 5
Table name USERS
USERNAME username of the user
PASSWORD password of the user
USERTYPE type of user
This table stores login information. The USERTYPE field specifies whether the user is an admin or a normal
user. This table returns a unique id for each user, when newly added.
Example
USERNAME PASSWORD USERTYPE

Admin Admin Admin
The above example shows a sample record in the users table.
6.1.1.6 Table – 6
Table name VALUEREPRESENTATIONS
VR_NAME gives value representation name
VR_DESCRIPTION gives value representation description
VR_DEFINITION gives value representation definition
VR_LENGTH gives value representation length in bytes
VR_ISFIXED specifies whether the value representation’s value is fixed or variable.
Page 23 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
This table stores all the value representations. VR’s are the standard DICOM data types. Name, description,
definition and length are the typical fields of this table. Whenever a DICOM data set is transformed into normal
data, this table is referred for getting the data types.
Example
VR_NAME VR_DESCRIPTION VR_DEFINITION VR_LENGTH VR_ISFIXED

AE String A string of 16 Maximum
characters
Application Entity
representing an
application
entity. A value
consisting solely
of spaces is not
allowed.
The above example shows a sample record in the valuerepresentation table.
6.1.2 DIAOGCENTRE
6.1.2.1 Table – 1
Table name MESSAGES
MSG actual message
application.
Example

2 Hi Hi 1 N Inbox 2009-09-14
20:29:57.560
Page 24 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
6.1.2.2 Table – 2
EMAIL user email

Example

kumar
Tirumala
ADDRESS EMAIL
6.1.2.3 Table - 3
Table name USERS
Example
Page 25 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store

Admin Admin Admin
6.1.2.4 Table – 4
Table Name PATIENTS
LASTVISITED date of last visit
BILL bill amount on last visit
SERVICESUSED list of services used by the patient
The table stores patient’s account information showing last visit date, bill etc. SERVICESUSED field
lists all the services like X-Ray, CT_Scan etc used by the patient.
Example
PNAME LASTVISITED BILL SERVICESUSED

Alex 2009-09-15 $100 X-Ray
23:59:04.000
The above example shows a sample record in the patients table.
6.1.2.5 Table - 5
Table name DICOMDATADICTONARY
DE_NAME Name of the Data Element
Example
Page 26 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
6.1.3 Hospital
6.1.3.1 Table – 1
Table name MESSAGES
MSG actual message
application.
Example

2 Hi Hi 1 N Inbox 2009-09-14
20:29:57.560
6.1.3.2 Table – 2
EMAIL user email
Page 27 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store

Example

Kumar
Tirumala
ADDRESS EMAIL
6.1.3.3 Table - 3
Table name USERS
Example

Admin Admin Admin
6.1.3.4 Table – 4
Table Name PATIENTS
LASTVISITED date of last visit
BILL bill amount on last visit
SERVICESUSED list of services used by the patient
The table stores patient’s account information showing last visit date, bill etc. SERVICESUSED field
lists all the services like X-Ray, CT_Scan etc used by the patient.
Page 28 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Example
PNAME LASTVISITED BILL SERVICESUSED

Alex 2009-09-15 $100 X-Ray
23:59:04.000
The above example shows a sample record in the patients table.
6.1.3.5 Table - 5
Table name DICOMDATADICTONARY
DE_NAME Name of the Data Element
Example
7 Actual Implementation
This section gives technical overview of the implementation and also describes the user manual of the
application.
We shall discuss the technical aspects in all three sections briefly
7.1 Technical Aspects

On the left pane of every page in the application, there are links to the messages and patients pages.
On the top right part of the page a logout button is provided.
7.1.1.1 Message Box

To view the sent and received messages a message box is provided. This message box is basically
an asp GridView, which is bounded to the database table messages. It shows the from user id,
Page 29 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
subject and date. All three fields of the grid are hyperlinked to message details page where the
message is shown. The GridView is bounded with the data table on the page load event.
Link buttons are provided to compose, sent etc.
7.1.1.2 Patient’s Page

A GridView is used to display all the patients registered in the centre. A textbox and a button are
provided, to search a patient by id. Link buttons are provided to add patient and add medical records.
7.1.1.3 Add Patient

A patient form is provided with all required fields and a add button. On button click, all the patient
information is encapsulated as an object of data element class. All the data elements are objects are
intern encapsulated as an object of data set and the object of data set is then sent to the DICOM
server for saving patient information.
7.1.1.4 Add Patient Medical Records

A form is provided to add patient id, upload images and records. An asp fileuploader is used to take in
the uploaded file. Medical images are taken as an array of bytes and encapsulated as an DICOM
record object and set as value for DIOCM data element.
7.1.2 Hospital
7.1.2.1 Message Box

7.1.2.2 Patient’s Page

A GridView is used to display all the patients registered in the centre. A textbox and a button are
provided, to search a patient by id. Link buttons are provided to add patient and add medical records.
7.1.2.3 Add Patient

A patient form is provided with all required fields and a add button. On button click, all the patient
information is encapsulated as an object of data element class. All the data elements are objects are
intern encapsulated as an object of data set and the object of data set is then sent to the DICOM
server for saving patient information.
7.1.2.4 Add Patient Medical Records

A form is provided to add patient id, upload images and records. An asp fileuploader is used to take in
the uploaded file. Medical images are taken as an array of bytes and encapsulated as an DICOM
record object and set as value for DIOCM data element.
7.1.2.5 View or Edit Patient Medical Records

If the user type is doctor then he may view or edit patient medical records. On request patient
information is retrieved from DICOM Server as an object of data set class then it is converted as
normal data and is displayed. When the data is edited it is encapsulated and sent to DICOM server
for updates.
Page 30 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
7.1.3 DICOM Server
7.1.3.1 Message Box

7.1.3.2 Background Scripting

Most of the functionality done by the DICOM Server is defined in the web server. It receives patient
information as an object of data set class. It then gets the original data and updates the database. In
the same way it sends the data to other places as objects of data set class.
7.2 Use Case Diagram’s
7.2.1 Hospital
The following figure shows the use case diagram:
Page 31 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store

7.2.3 DICOM Server

Page 32 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
7.3 User Manual

There are two types of user roles in the application one is admin and the other user. In both diagnostic centre
and hospital there are two sections one for admin and other for normal users.
There is an additional user role in hospital that’s doctor. The user manual basically divided into three sections
normal user, admin and doctor. Then these sections are divided into further sections describing the manual for
these roles in diagnostic centre and hospital.
As DICOM server is run only at the back end no user manual is required.
7.3.1 User
7.3.1.1 Diagnostic Centre

When the user starts using the application he goes through the following pages.
 First a login page is displayed, where one needs to enter username and password. If
the username and password are correct then he is moved to next page.
 If the details are incorrect then an error message is displayed.
 Then the user is in message box page where he can view summarised view of
messages received. One can click on the message to view it, and then he has an
option of replying the message.
 In the same page options are provided to view sent messages, compose new message.
 Then a user can view patients by clicking patients tab on the left pane. There options
are provided to add new patient and new patient medical records.
 User has an option to logout on the top right pane of every page. Once logged out he
needs to login again to use the services.
Page 33 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
7.3.1.2 Hospital
When the user starts using the application he goes through the following pages.
 Then the user is in message box page where he can view summarised view of
 Then a user can view patients by clicking patients tab on the left pane. There options
are provided to add new patients.
 User has an option to logout on the top right pane of every page. Once logged out he
7.3.2 Admin

When an admin starts using the application he goes through the following pages.
 Then the admin is in message box page where he can view summarised view of
 Then the admin can view patients by clicking patients tab on the left pane. There
options are provided to add new patients.
 Admin can view the users, edit their information and delete them.
 Admin has an option to logout on the top right pane of every page. Once logged out he
7.3.2.2 Hospital
When an admin starts using the application he goes through the following pages.
 Then the admin is in message box page where he can view summarised view of
 Then the admin can view patients by clicking patients tab on the left pane. There
Page 34 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
 Admin can view the users, edit their information and delete them.
7.3.3 Doctor

There is no user role for doctor in this area of application.
7.3.3.2 Hospital
When a doctor starts using the application he goes through the following pages.
 Then the doctor is in message box page where he can view summarised view of
 Then the doctor can view patients by clicking patients tab on the left pane. There
 The doctor can view and edit patient records, images and reports.
8 Testing and Results

8.1 Testing
Testing was performed to verify all basic functionalities were working well. Validations were implemented in all
the pages where required.
8.2 Results
Outcome of the testing was positive most of the times. Initially some errors were encountered, they were
rectified later.
9 Conclusion
Several goals were set to be achieved in this project. Most of them were achieved and some were failed. Some
future recommendations are suggested for further enhancement of the project.
Page 35 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
9.1 Goals
9.1.1 Goals Set

A DICOM indexed store was planned to be build. Main goals were to obtain DICOM structured data exchange
between health organisations and a centralised server, where all the data is stored. User roles were to be
defined to restrict access.
Initially the indexed store was planned in OGSA-DAI. Medical images were stored with metadata. Patient id is
embedded in the report or an image so that the image is never lost.
A network protocol is to be defined to achieve data transfer.
9.1.2 Goal Achieved

A DICOM indexed store was successfully build with all features as per requirements. Medical reports and
images were saved in the database. Patient id was made as an internal part of the image or report so that they
never got separated.
No separate protocol was defined but web services were used which intern uses HTTP and SOAP protocols.
9.1.3 Goals Changed

As per the initial plan the indexed store was not build using OGS-DAI. Considering the time limit of the
project and also inferring with later research that implementing the project on ASP.Net is much better
option.
Not implementing the project on OGSA-DAI was later proved as a good decision as the
implementation was quite successful and is very good in performance aspects also.
9.2 Future Recommendations

The following enhancements can be made in future
 TCP/IP protocol can be implemented for data exchange.
 An data encoding decoding mechanism can be implemented.
 DICOM modalities can be implemented.
 Structured reports can be made
10 References
Reference – 1: “PS 3.1 Introduction and Overview”, “part of ACR-NEMA standard release”,
http://dicom.nema.org/
Reference – 2: “PS 3.3 Information Object Definitions”, “part of ACR-NEMA standard release”,
Reference – 3: “PS 3.5 Data Structure and Encoding”, “part of ACR-NEMA standard release”,
Reference – 4: “PS 3.6 Data Dictionary”, “part of ACR-NEMA standard release”,

Page 36 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Reference – 5: “PS 3.7 Message Exchange”, “part of ACR-NEMA standard release”,

Reference – 6: “OGSA-DAI tutorial presentation at Nottingham”,

http://www.ogsadai.org.uk/documentation/presentations/
11 Appendices
11.1 OGSA-DAI
This section shows screen shots of errors and emails trough which OGSA-DAI users were communicated.
Attached below are the screens shots of errors occurred and email communication with OGSA-DAI users.
11.1.1 Scenario – 1
11.1.1.1 Error
Page 37 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
11.1.1.2 Mail List
Page 38 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 39 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 40 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
11.1.2.1 Error
Page 41 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
11.1.2.2 Mailing Lists
Page 42 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
11.1.3.1 Error
Page 43 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 44 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 45 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 46 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 47 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
11.1.4.1 Error
This is the stage wherein the implementation was shifted to ASP.Net.
Page 48 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
Page 49 of 50
CIS000-6 0816185
MSc Thesis
DICOM Indexed Store
11.2 DICOM
11.2.1 Value Representations

Some sample DICOM VR’s are used in our application. Full range DICOM VR’s can be found in the
DICOM Standard release document named “PS 3.5 Data Structure and Encoding” available at
“medical.nema.org/”
11.2.2 Data Dictionary

Some6sample DICOM Data Dictionary is used in our application. Full range DICOM Data Dictionary
can be found in the DICOM Standard release document named “PS 3.5 Data Dictionary” available at
“medical.nema.org/”
Page 50 of 50

Shravan Kumar Tirumala: Cis000-6 MSC Thesis

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Shravan Kumar Tirumala: Cis000-6 MSC Thesis

Hochgeladen von

Copyright:

Verfügbare Formate

CIS000-6 0816185

DICOM Indexed Store