ABSTRACT

ABSTRACT
Digital Imaging and Communications in Medicine
Purpose
DICOM is a standard for handling, storing, and transmitting information in medical imaging. It
includes a file format definition and a network communication protocol. The communication protocol is
an application protocol that uses TCP/IP to communicate between systems. DICOM files can be
exchanged between two entities that are capable of receiving image and patient data in DICOM (.dcm)
format.
Problem and existing system
We have many healthcare centers which take care of our lives in our busy lifecycle schedule. We
consult these healthcare centers in our lifetime when we suffer from any small disease. The doctors only
give medicines when it is the case of fever, cold or cough, but when the case of chronic diseases like
cancer or cardiac problems like heart attacks comes into picture, x-ray of the affected parts are to be
taken, which help us to locate the exact position of the area. By using these x-rays either the doctors or
patients can consult other doctors for seeking their advices.
Problems:
i. Data is lost while transmitting x-ray from one doctor’s hand to another.

ii. x- Ray format differs from one healthcare center to another.

Proposed System
DICOM (Digital Imaging and Communications in Medicine) overcomes the above said problems.
DICOM is a standard for handling, storing, printing, transmitting information in medical imaging. It
includes a file format definition and a network communication protocol. The communication protocol is
an application protocol that uses TCP/IP to communicate between systems. DICOM files can be
exchanged between two entities that are capable of receiving image and patient data in DICOM format.
Thus we can prevent the data from being lost.
DICOM enables the integration of scanners, servers, workstations, printers and network
hardware from multiple manufacturers in a picture archiving and communication system. The
differentdevices come with DICOM conformance statements which clearly state the DICOM classes
they support. DICOM has been widely adopted by hospitals and is making inroads in smaller
applications like dentists’ and doctors’ offices.

2
Table of Contents

Article II. JDBC Basics - Java Database Connectivity Steps...................................................22

Section II.2 Java JDBC Connection Example, JDBC Driver Example.................................................. 24

1. INTRODUCTION

1.1 PURPOSE

DICOM is a product for handling, storing, and transmitting information in medical

imaging. It includes a file format definition and a network communication protocol. The
communication protocol is an application protocol that uses TCP/IP to communicate between
systems. DICOM files can be exchanged between two entities that are capable of receiving
image and patient data in DICOM (.dcm) format.

1.2 SCOPE OF THE PROJECT

1.2.1Problem and existing system

We have many healthcare centers which take care of our lives in our busy lifecycle
schedule. We consult these healthcare centers in our lifetime when we suffer from any small
disease. The doctors only give medicines when it is the case of fever, cold or cough, but when
the case of chronic diseases like cancer or cardiac problems like heart attacks comes into picture,
x-ray of the affected parts are to be taken, which help us to locate the exact position of the area.
By using these x-rays either the doctors or patients can consult other doctors for seeking their
advices.
Problems:

 Data is lost while transmitting x-ray from one doctor’s hand to another.

 x- Ray format differs from one healthcare center to another.

1.2.2 Proposed System

DICOM (Digital Imaging and Communications in Medicine) overcomes the above said
problems. DICOM is a standard for handling, storing, printing, transmitting information in
medical imaging. It includes a file format definition and a network communication protocol. The
communication protocol is an application protocol that uses TCP/IP to communicate between
systems. DICOM files can be exchanged between two entities that are capable of receiving
image and patient data in DICOM format. Thus we can prevent the data from being lost.

3
 DICOM enables the integration of scanners, servers, workstations, printers and network
hardware from multiple manufacturers in a picture archiving and communication system. The
different devices come with DICOM conformance statements which clearly state the DICOM
classes they support. DICOM has been widely adopted by hospitals and is making inroads in
smaller applications like dentists’ and doctors’ offices.

Over 750 technical and medical experts participate in more than 20 active DICOM working
groups. As a consequence of their efforts, the DICOM Standard is up-dated four to five times
each year and re-published approximately once every year or two.

Modality Description

Modality of type Bio-magnetic Imaging

BI

Modality of type Color Flow Doppler-Retired 2008

CD
CR Modality of type Computed Radiography
CT Modality of type Computed Tomography
DD Modality of type Duplex Doppler-Retired 2008
DG Modality of type Diaphangraphy
EC Modality of type Echo cardiography – Retired
EM Modality of type Electron Microscope

4
1.3 DEFINITIONS FOR DOMAIN SPECIFIC TERMINOLOGY

DICOM: Digital Imaging and Communications in Medicine (DICOM) is a

standard for handling, storing, printing, and transmitting information in medical.

CT SCAN: Computed tomography scan. A series of detailed pictures of areas inside the
body, taken from different angles; the pictures are created by a computer linked to an x-
ray machine. Also called computerized tomography and computerized axial tomography
(CAT) scan.

MRI: Magnetic resonance imaging scan. A diagnostic technique that uses high
frequency radio waves and a computer to visualise the organs of the body.

X-RAYS: X-radiation (composed of X-rays) is a form of electromagnetic radiation. X-

rays have a wavelength in the range of 10 to 0.01 nanometers, corresponding to
frequencies in the range 30 petahertz to 30 exahertz (3 × 1016 Hz to 3 × 1019 Hz) and
energies in the range 120 eV to 120 keV. They are shorter in wavelength than UVrays. In
many languages, X-radiation is called Rontgen radiation after Wilhelm Conrad
Rontgen, who is generally credited as their discoverer, and who had called them X-rays
to signify an unknown type of radiation.
TCP/IP: Transmission control protocol: a protocol developed for the internet to get data
from one network device to another; "TCP uses a retransmission strategy to insure that
data will not be lost in transmission"
API: Application programming interface (API) is an interface in computer science that
defines the ways by which an application program may request services from libraries
and/or operating systems. An API determines the vocabulary and calling conventions the
programmer should employ to use the services. It may include specifications for routines,
data structures, object classes and protocols used to communicate between the requesting
software and the library.

1.4 : ABBREVATIONS, ACRONYMS

5
  DICOM- Digital Imaging and Communication in Medicine
 CT- Computed Tomography
 CR- Computed Radiography
 MRI- Mental Representation Image
 NEMA- National Electrical Manufacturers Association
 TCP/IP- Transmission Control Protocol/Internet Protocol
 HL7- Health Level Seven
 CPOE- Computerized Physician Order Entry
 API- Application Programming Interface
 LOINC- Laboratory Observation Identifiers, Names, and Codes
 SNOMED- Systematized Nomenclature of Medicine
 JPEG- Joint Photographic Experts Group
 MPEG- Motion Picture Experts Group

1.5 REFERENCES
http://www.dclunie.com/
http://medical.nema.org/dicom.html
http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html
http://www.rsna.org/Technology/DICOM/
http://DICOM.nema.org/
Clunie, David A.; DICOM Structured Reporting; Pixel Med Publishing,
NEMA PS 3 – Digital Imaging and Communications in Medicine; 2004 Ed.

1.6 DESCRIPTION ABOUT OTHER CONTENTS

1.6.1 OVERALL DESCRIPTION

Here we explain the product perspective, product functionality, general
constraints, design constraints and abbreviations, definitions, acronyms.

1.6.2 SPECIFIC REQUIREMENTS

Here we explain external interface requirements, functional requirements,
software requirements, hardware requirements and other requirements.
6
 1.6.3 APPENDIX
Here we explain more detailed information like history of Dicom, services that
are provided etc…

2. HARDWARE / SOFTWARE REQUIREMENTS

7
 2.1 SOFTWARE REQUIREMENTS

• Operating System: Windows XP

• Language: jdk 1.6, DICOM API

• Data Base: Oracle 10g

• Tool: Rational Rose, Net Beans

2.2 HARDWARE REQUIREMENTS

• P IV Processor

• 512 MB of RAM

• 40 GB OF HARDDISK

3. LITERATURE SURVEY

8
 3.1 INTRODUCTION TO JAVA

Java is an object-oriented programming language developed by James Gosling

and colleagues at Sun Microsystems in the early 1990s. Unlike conventional languages which are
generally designed either to be compiled to native (machine) code, or to be interpreted from source
code at runtime, Java is intended to be compiled to a byte code , which is then run (generally using
JIT compilation) by a Java Virtual Machine.

The language itself borrows much syntax from C and C++ but has a simpler object model and fewer
low-level facilities. Java is only distantly related to JavaScript, though they have similar names and
share a C-like syntax.

Java was started as a project called "Oak" by James Gosling in June 1991. Gosling's goals were to
implement a virtual machine and a language that had a familiar C-like notation but with greater
uniformity and simplicity than C/C++. The first public implementation was Java 1.0 in 1995. It
made the promise of "Write Once, Run Anywhere", with free runtimes on popular platforms. It was
fairly secure and its security was configurable, allowing for network and file access to be limited.
The major web browsers soon incorporated it into their standard configurations in a secure "applet"
configuration. popular quickly. New versions for large and small platforms (J2EE and J2ME) soon
were designed with the advent of "Java 2". Sun has not announced any plans for a "Java 3"

In 1997, Sun approached the ISO/IEC JTC1 standards body and later the Ecma International to
formalize Java, but it soon withdrew from the process. Java remains a proprietary de facto standard
that is controlled through the Java Community Process. Sun makes most of its Java implementations
available without charge, with revenue being generated by specialized products such as the Java
Enterprise System. Sun distinguishes between its Software Development Kit (SDK) and Runtime
Environment (JRE) which is a subset of the SDK, the primary distinction being that in the JRE the
compiler is not present.

There were five primary goals in the creation of the Java language:

1. It should use the object-oriented programming methodology.

2. It should allow the same program to be executed on multiple operating systems.
3. It should contain built-in support for using computer networks.
4. It should be designed to execute code from remote sources securely.

9
5. It should be easy to use by selecting what was considered the good parts of other object-oriented
languages.

To achieve the goals of networking support and remote code execution, Java programmers
sometimes find it necessary to use extensions such as CORBA, Internet Communications Engine, or
OSGi.

Object orientation

The first characteristic, object orientation ("OO"), refers to a method of programming and language
design. Although there are many interpretations of OO, one primary distinguishing idea is to design
software so that the various types of data it manipulates are combined together with their relevant
operations. Thus, data and code are combined into entities called objects. An object can be thought
of as a self-contained bundle of behavior (code) and state (data). The principle is to separate the
things that change from the things that stay the same; often, a change to some data structure requires
a corresponding change to the code that operates on that data, or vice versa. This separation into
coherent objects provides a more stable foundation for a software system's design. The intent is to
make large software projects easier to manage, thus improving quality and reducing the number of
failed projects.

Another primary goal of OO programming is to develop more generic objects so that software can
become more reusable between projects. A generic "customer" object, for example, should have
roughly the same basic set of behaviors between different software projects, especially when these
projects overlap on some fundamental level as they often do in large organizations. In this sense,
software objects can hopefully be seen more as pluggable components, helping the software industry
build projects largely from existing and well-tested pieces, thus leading to a massive reduction in
development times. Software reusability has met with mixed practical results, with two main
difficulties: the design of truly generic objects is poorly understood, and a methodology for broad
communication of reuse opportunities is lacking. Some open source communities want to help ease
the reuse problem, by providing authors with ways to disseminate information about generally
reusable objects and object libraries.

Platform independence
10
The second characteristic, platform independence, means that programs written in the Java language
must run similarly on diverse hardware. One should be able to write a program once and run it
anywhere.

This is achieved by most Java compilers by compiling the Java language code "halfway" to bytecode
(specifically Java bytecode)—simplified machine instructions specific to the Java platform. The
code is then run on a virtual machine (VM), a program written in native code on the host hardware
that interprets and executes generic Java bytecode. Further, standardized libraries are provided to
allow access to features of the host machines (such as graphics, threading and networking) in unified
ways. Note that, although there's an explicit compiling stage, at some point, the Java bytecode is
interpreted or converted to native machine instructions by the JIT compiler.

There are also implementations of Java compilers that compile to native object code, such as GCJ,
removing the intermediate bytecode stage, but the output of these compilers can only be run on a
single architecture.

Sun's license for Java insists that all implementations be "compatible". This resulted in a legal
dispute with Microsoft after Sun claimed that the Microsoft implementation did not support the RMI
and JNI interfaces and had added platform-specific features of their own. In response, Microsoft no
longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot
support Java applets without a third-party plug-in. However, Sun and others have made available
Java run-time systems at no cost for those and other versions of Windows.

The first implementations of the language used an interpreted virtual machine to achieve portability.
These implementations produced programs that ran more slowly than programs compiled to native
executables, for instance written in C or C++, so the language suffered a reputation for poor
performance. More recent JVM implementations produce programs that run significantly faster than
before, using multiple techniques.

The first technique is to simply compile directly into native code like a more traditional compiler,
skipping bytecodes entirely. This achieves good performance, but at the expense of portability.
Another technique, known as just-in-time compilation (JIT), translates the Java bytecodes into native
11
code at the time that the program is run which results in a program that executes faster than
interpreted code but also incurs compilation overhead during execution. More sophisticated VMs use
dynamic recompilation, in which the VM can analyze the behavior of the running program and
selectively recompile and optimize critical parts of the program. Dynamic recompilation can achieve
optimizations superior to static compilation because the dynamic compiler can base optimizations on
knowledge about the runtime environment and the set of loaded classes. JIT compilation and
dynamic recompilation allow Java programs to take advantage of the speed of native code without
losing portability.

Portability is a technically difficult goal to achieve, and Java's success at that goal has been mixed.
Although it is indeed possible to write programs for the Java platform that behave consistently
across many host platforms, the large number of available platforms with small errors or
inconsistencies led some to parody Sun's "Write once, run anywhere" slogan as "Write once, debug
everywhere".

Platform-independent Java is however very successful with server-side applications, such as Web
services, servlets, and Enterprise JavaBeans, as well as with Embedded systems based on OSGi,
using Embedded Java environments.

Automatic garbage collection

One idea behind Java's automatic memory management model is that programmers should be spared
the burden of having to perform manual memory management. In some languages the programmer
allocates memory to create any object stored on the heap and is responsible for later manually
deallocating that memory to delete any such objects. If a programmer forgets to deallocate memory
or writes code that fails to do so in a timely fashion, a memory leak can occur: the program will
consume a potentially arbitrarily large amount of memory. In addition, if a region of memory is
deallocated twice, the program can become unstable and may crash. Finally, in non garbage
collected environments, there is a certain degree of overhead and complexity of user-code to track
and finalize allocations.

In Java, this potential problem is avoided by automatic garbage collection. The programmer
determines when objects are created, and the Java runtime is responsible for managing the object's
12
lifecycle. The program or other objects can reference an object by holding a reference to it (which,
from a low-level point of view, is its address on the heap). When no references to an object remain,
the Java garbage collector automatically deletes the unreachable object, freeing memory and
preventing a memory leak. Memory leaks may still occur if a programmer's code holds a reference to
an object that is no longer needed—in other words, they can still occur but at higher conceptual
levels.

The use of garbage collection in a language can also affect programming paradigms. If, for example,
the developer assumes that the cost of memory allocation/recollection is low, they may choose to
more freely construct objects instead of pre-initializing, holding and reusing them. With the small
cost of potential performance penalties (inner-loop construction of large/complex objects), this
facilitates thread-isolation (no need to synchronize as different threads work on different object
instances) and data-hiding. The use of transient immutable value-objects minimizes side-effect
programming.

Comparing Java and C++, it is possible in C++ to implement similar functionality (for example, a
memory management model for specific classes can be designed in C++ to improve speed and lower
memory fragmentation considerably), with the possible cost of extra development time and some
application complexity. In Java, garbage collection is built-in and virtually invisible to the developer.
That is, developers may have no notion of when garbage collection will take place as it may not
necessarily correlate with any actions being explicitly performed by the code they write. Depending
on intended application, this can be beneficial or disadvantage.

Syntax

The syntax of Java is largely derived from C++. However, unlike C++, which combines the syntax
for structured, generic, and object-oriented programming, Java was built from the ground up to be
virtually fully object-oriented: everything in Java is an object with the exceptions of atomic
datatypes (ordinal and real numbers, boolean values, and characters) and everything in Java is
written inside a class.

13
Look and feel

The default look and feel of GUI applications written in Java using the Swing toolkit is very
different from native applications. It is possible to specify a different look and feel through the
pluggable look and feel system of Swing. Clones of Windows, GTK and Motif are supplied by Sun.
Apple also provides an Aqua look and feel for Mac OS X. Though prior implementations of these
look and feels have been considered lacking, Swing in Java SE 6 addresses this problem by using
more native widget drawing routines of the underlying platforms. Alternatively, third party toolkits
such as wx4j or SWT may be used for increased integration with the native windowing system.

Lack of OO purity and facilities

Java's primitive types are not objects. Primitive types hold their values in the stack rather than being
references to values. This was a conscious decision by Java's designers for performance reasons.
Because of this, Java is not considered to be a pure object-oriented programming language.
However, as of Java 5.0, autoboxing enables programmers to write as if primitive types are their
wrapper classes, and freely interchange between them for improved flexibility. Java designers
decided not to implement certain features present in other OO languages, including:

(a) multiple inheritance

(b) operator overloading
(c) class properties
(d) tuples

Java Runtime Environment

The Java Runtime Environment or JRE is the software required to run any application deployed on
the Java Platform. End-users commonly use a JRE in software packages and Web browser plugins.
Sun also distributes a superset of the JRE called the Java 2 SDK (more commonly known as the
JDK), which includes development tools such as the Java compiler, Javadoc, and debugger.

3.2 INTRODUCTION TO SWINGS IN JAVA

14
 Java Swing is a GUI toolkit for Java. Swing is one part of the Java Foundation
Classes (JFC). Swing includes graphical user interface (GUI) widgets such as text boxes, buttons,
split-panes, and tables.

Swing widgets provide more sophisticated GUI components than the earlier Abstract Window
Toolkit. Since they are written in pure Java, they run the same on all platforms, unlike the AWT
which is tied to the underlying platform's windowing system. Swing supports pluggable look and
feel – not by using the native platform's facilities, but by roughly emulating them. This means you
can get any supported look and feel on any platform. The disadvantage of lightweight components is
possibly slower execution. The advantage is uniform behavior on all platforms.

History

The Internet Foundation Classes (IFC) were a graphics library for Java originally developed by
Netscape Communications Corporation and first released on Dec 16, 1996.

On April 2, 1996, Sun Microsystems and Netscape Communications Corporation announced their
intention to combine IFC with other technologies to form the Java Foundation Classes. In addition to
the components originally provided by IFC, Swing introduced a mechanism that allowed the look
and feel of every component in an application to be altered without making substantial changes to
the application code. The introduction of support for a pluggable look and feel allowed Swing
components to emulate the appearance of native components while still retaining the benefits of
platform independence. This feature also makes it easy to have an individual application's
appearance look very different from other native programs.
Originally distributed as a separately downloadable library, Swing has been included as part of the
Java Standard Edition since release 1.2. The Swing classes are contained in the javax.swing package
hierarchy.
Architecture

The Swing library makes heavy use of the Model/View/Controller software design pattern, which
attempts to separate the data being viewed from the method by which it is viewed. Because of this,
most Swing components have associated models (typically as interfaces), and the programmer can
use various default implementations or provide their own. For example, the JTable has a model
called TableModel that describes an interface for how a table would access tabular data. A default
implementation of this operates on a two-dimensional array.

Swing favors relative layouts (which specify the positional relationships between components), as
opposed to absolute layouts (which specify the exact location and size of components). The
motivation for this is to allow Swing applications to work and appear visually correct regardless of
the underlying systems colors, fonts, language, sizes or I/O devices. This can make screen design
somewhat difficult and numerous tools have been developed to allow visual designing of screens.

Swing also uses a publish subscribe event model (as does AWT), where listeners subscribe to events
15
that are fired by the application (such as pressing a button, entering text or clicking a checkbox). The
model classes typically include, as part of their interface, methods for attaching listeners (this is the
publish aspect of the event model).

The frequent use of loose coupling within the framework makes Swing programming somewhat
different from higher-level GUI design languages and 4GLs. This is a contributing factor to Swing
having such a steep learning curve.

Look and feel

Swing allows one to specialize the look and feel of widgets, by modifying the default (via runtime
parameters), deriving from an existing one, by creating one from scratch, or, beginning with J2SE
5.0, by using the skinnable Synth Look and Feel, which is configured with an XML property file.
The look and feel can be changed at runtime, and early demonstrations of Swing would frequently
provide a way to do this.

Relationship to AWT

Since early versions of Java, a portion of the Abstract Windowing Toolkit (AWT) has provided
platform independent APIs for user interface components. In AWT, each component is rendered and
controlled by a native peer component specific to the underlying windowing system.

By contrast, Swing components are often described as lightweight because they do not require
allocation of native resources in the operating system's windowing toolkit. The AWT components
are referred to as heavyweight components.

Much of the Swing API is generally a complementary extension of the AWT rather than a direct
replacement. In fact, every Swing lightweight interface ultimately exists within an AWT
heavyweight component because all of the top-level components in Swing (JApplet, JDialog,
JFrame, and JWindow) extend an AWT top-level container. The core rendering functionality used
by Swing to draw its lightweight components is provided by Java2D, another part of JFC. However,
the use of both lightweight and heavyweight components within the same window is generally
discouraged due to Z-order incompatibilities.

Relationship to SWT

The Standard Widget Toolkit (SWT) is a competing toolkit originally developed by IBM and now
maintained by the Eclipse Foundation. SWT's implementation has more in common with the
heavyweight components of AWT. This confers benefits such as more accurate fidelity with the
underlying native windowing toolkit, at the cost of an increased exposure to the native resources in
the programming model.

The advent of SWT has given rise to a great deal of division among Java desktop developers with
many strongly favouring either SWT or Swing. A renewed focus on Swing look and feel fidelity
with the native windowing toolkit in the approaching Java SE 6 release (as of February 2006) is
probably a direct result of this.

Example

16
The following is a Hello World program using Swing.

import javax.swing.JFrame;
import javax.swing.JLabel;

public final class HelloWorld extends JFrame {

private HelloWorld() {
setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
getContentPane().add(new JLabel("Hello, World!"));
pack();
setLocationRelativeTo(null);
}

public static void main(String[] args) {

new HelloWorld().setVisible(true);
}
}

3.3 INTRODUCTION TO APPLETS IN JAVA

A Java applet is an applet delivered in the form of Java bytecode. Java applets can run in a
Web browser using a Java Virtual Machine (JVM), or in Sun's AppletViewer, a stand alone tool to
test applets. Java applets were introduced in the first version of the Java language in 1995. Java
applets are usually written in the Java programming language but they can also be written in other
languages that compile to Java bytecode such as Jython.
Applets are used to provide interactive features to web applications that cannot be provided
by HTML. Since Java's bytecode is platform independent, Java applets can be executed by browsers
for many platforms, including Windows, Unix, Mac OS and Linux. There are open source tools like
applet2app which can be used to convert an applet to a stand alone Java application/windows
executable. This has the advantage of running a Java applet in offline mode without the need for
internet browser software.
A Java Servlet is sometimes informally compared to be "like" a server-side applet, but it is
different in its language, functions, and in each of the characteristics described here about applets.
Technical information

Java applets are executed in a sandbox by most web browsers, preventing them from accessing local
data. The code of the applet is downloaded from a web server and the browser either embeds the
applet into a web page or opens a new window showing the applet's user interface. The applet can be
displayed on the web page by making use of the deprecated applet HTML element or the
recommended object element. This specifies the applet's source and the applet's location statistics.

A Java applet extends the class java.applet.Applet, or in the case of a Swing applet,

17
javax.swing.JApplet. The class must override methods from the applet class to set up a user interface
inside itself (Applet is a descendant of Panel which is a descendant of Container).
Advantages of applets

A Java applet can have any or all of the following advantages:

* it is simple to make it work on Windows, Mac OS and Linux, i.e. to make it cross platform
* the same applet can work on "all" installed versions of Java at the same time, rather than just the
latest plug-in version only. However, if an applet requires a later version of the JRE the client will be
forced wait during the large download.
* it runs in a sandbox, so the user does not need to trust the code, so it can work without security
approval
* it is supported by most web browsers
* it will cache in most web browsers, so will be quick to load when returning to a web page
* it can have full access to the machine it is running on if the user agrees
* it can improve with use: after a first applet is run, the JVM is already running and starts quickly,
benefiting regular users of Java
* it can run at a comparable (but generally slower) speed to other compiled languages such as C++
* it can be a real time application
* it can move the work from the server to the client, making a web solution more scalable with the
number of users/clients

Disadvantages of applets

A Java applet is open to any of the following disadvantages:

* it requires the Java plug-in, which isn't available by default on all web browsers
* it can't start up until the Java Virtual Machine is running, and this may have significant startup
time the first time it is used
* if it is uncached, it must be downloaded (usually over the internet), and this takes time
* it is considered more difficult to build and design a good user interface with applets than with
HTML-based technologies
* if untrusted, it has severely limited access to the user's system - in particular having no direct
access to the client's disc or clipboard
* some organizations only allow software installed by the administrators. As a result, many users
cannot view applets by default.
* applets may require a specific JRE.

Compatibility issues

Sun has made a considerable effort to ensure compatibility is maintained between Java versions as
they evolve. For example, Microsoft's Internet Explorer, the most popular web browser since the late
1990s, used to ship with Microsoft's own JVM as the default. The MSJVM had some extra non-Java
features added which, if used, would prevent MSJVM applets from running on Sun's Java (but not
the other way round). Sun sued for breach of trademark, as the point of Java was that there should be
no proprietary extensions and that code should work everywhere. Development of MSJVM was
frozen by a legal settlement, leaving many users with an extremely outdated Java virtual machine.
Later, in October 2001, MS stopped including Java with Windows, and for some years it has been
18
left to the computer manufacturers to ship Java independently of the OS. Most new machines now
ship with official Sun Java.

Some browsers (notably Firefox) do not do a good job of handling height=100% on applets which
makes it difficult to make an applet fill most of the browser window (Javascript can, with difficulty,
be used for this). Having the applet create its own main window is not a good solution either, as this
leads to a large chance of the applet getting terminated unintentionally and leaves the browser
window as a largely useless extra window.

Alternatives

Alternative technologies exist (for example, DHTML and Flash) that satisfy some of the scope of
what is possible with an applet.

Another alternative to applets for client side Java is Java Web Start, which runs outside the browser.
In addition to the features available to applets, a simple permissions box can give Java Web Start
programs read and/or write access to specified files stored on the client, and to the client's clipboard.

3.4. SQL SERVER

A database management, or DBMS, gives the user access to their data and helps them transform
the data into information. Such database management systems include dBase, paradox, IMS, SQL
Server and SQL Server. These systems allow users to create, update and extract information from
their database.
A database is a structured collection of data. Data refers to the characteristics of people, things
and events. SQL Server stores each data item in its own fields. In SQL Server, the fields relating to
a particular person, thing or event are bundled together to form a single complete unit of data, called
a record (it can also be referred to as raw or an occurrence). Each record is made up of a number of
fields. No two fields in a record can have the same field name.
During an SQL Server Database design project, the analysis of your business needs identifies all
the fields or attributes of interest. If your business needs change over time, you define any
additional fields or change the definition of existing fields.

SQL SERVER TABLES

SQL Server stores records relating to each other in a table. Different tables are created for the
various groups of information. Related tables are grouped together to form a database.

PRIMARY KEY
19
 Every table in SQL Server has a field or a combination of fields that uniquely identifies each
record in the table. The Unique identifier is called the Primary Key, or simply the Key. The primary
key provides the means to distinguish one record from all other in a table. It allows the user and the
database system to identify, locate and refer to one particular record in the database.

RELATIONAL DATABASE
Sometimes all the information of interest to a business operation can be stored in one table. SQL
Server makes it very easy to link the data in multiple tables. Matching an employee to the
department in which they work is one example. This is what makes SQL Server a relational
database management system, or RDBMS. It stores data in two or more tables and enables you to
define relationships between the table and enables you to define relationships between the tables.

FOREIGN KEY
When a field is one table matches the primary key of another field is referred to as a foreign key.
A foreign key is a field or a group of fields in one table whose values match those of the primary key
of another table.

REFERENTIAL INTEGRITY
Not only does SQL Server allow you to link multiple tables, it also maintains consistency
between them. Ensuring that the data among related tables is correctly matched is referred to as
maintaining referential integrity.

DATA ABSTRACTION
A major purpose of a database system is to provide users with an abstract view of the data. This
system hides certain details of how the data is stored and maintained. Data abstraction is divided into
three levels.
Physical level: This is the lowest level of abstraction at which one describes how the data are
actually stored.
Conceptual Level: At this level of database abstraction all the attributed and what data are actually
stored is described and entries and relationship among them.
View level: This is the highest level of abstraction at which one describes only part of the database.

ADVANTAGES OF RDBMS
20
• Redundancy can be avoided
• Inconsistency can be eliminated
• Data can be Shared
• Standards can be enforced
• Security restrictions ca be applied
• Integrity can be maintained
• Conflicting requirements can be balanced
• Data independence can be achieved.
DISADVANTAGES OF DBMS
A significant disadvantage of the DBMS system is cost. In addition to the cost of purchasing of
developing the software, the hardware has to be upgraded to allow for the extensive programs and
the workspace required for their execution and storage. While centralization reduces duplication, the
lack of duplication requires that the database be adequately backed up so that in case of failure the
data can be recovered.

3.5 JDBC CONNECTIVITY

The JDBC ( Java Database Connectivity) API defines interfaces and classes for writing
database applications in Java by making database connections. Using JDBC you can send SQL,
PL/SQL statements to almost any relational database. JDBC is a Java API for executing SQL
statements and supports basic SQL functionality. It provides RDBMS access by allowing you to
embed SQL inside Java code. Because Java can run on a thin client, applets embedded in Web pages
can contain downloadable JDBC code to enable remote database access. You will learn how to
create a table, insert values into it, query the table, retrieve results, and update the table with the help
of a JDBC Program example.
Although JDBC was designed specifically to provide a Java interface to relational
databases, you may find that you need to write Java code to access non-relational
databases as well.
(a) JDBC Architecture

21
Java application calls the JDBC library. JDBC loads a driver which talks to the database. We can change
database engines without changing database code.
Article II. JDBC Basics - Java Database Connectivity Steps
Before you can create a java jdbc connection to the database, you must first import the
java.sql package.
import java.sql.*; The star ( * ) indicates that all of the classes in the package java.sql are to be imported.
1. Loading a database driver,
In this step of the jdbc connection process, we load the driver class by calling Class.forName() with the
Driver class name as an argument. Once loaded, the Driver class creates an instance of itself. A client
can connect to Database Server through JDBC Driver. Since most of the Database servers support
ODBC driver therefore JDBC-ODBC Bridge driver is commonly used.
The return type of the Class.forName (String ClassName) method is “Class”. Class is a class in
java.lang package.
try {
Class.forName(”sun.jdbc.odbc.JdbcOdbcDriver”); //Or any
other driver
}
catch(Exception x){
System.out.println( “Unable to load the driver
class!” );
}
2. Creating a oracle jdbc Connection

The JDBC DriverManager class defines objects which can connect Java applications to a JDBC driver.
DriverManager is considered the backbone of JDBC architecture. DriverManager class manages the
JDBC drivers that are installed on the system. Its getConnection() method is used to establish a
connection to a database. It uses a username, password, and a jdbc url to establish a connection to the
database and returns a connection object. A jdbc Connection represents a session/connection with a
specific database. Within the context of a Connection, SQL, PL/SQL statements are executed and results
are returned. An application can have one or more connections with a single database, or it can have
many connections with different databases. A Connection object provides metadata i.e. information
about the database, tables, and fields. It also contains methods to deal with transactions.
JDBC URL Syntax:: jdbc: <subprotocol>: <subname>
JDBC URL Example:: jdbc: <subprotocol>: <subname>•Each driver has its own subprotocol
•Each subprotocol has its own syntax for the source. We’re using the jdbc odbc subprotocol, so the
DriverManager knows to use the sun.jdbc.odbc.JdbcOdbcDriver.
try{
Connection
dbConnection=DriverManager.getConnection(url,”loginName”,”Password”)
}
catch( SQLException x ){
System.out.println( “Couldn’t get connection!” );
}

22
3. Creating a jdbc Statement object,
Once a connection is obtained we can interact with the database. Connection interface defines methods
for interacting with the database via the established connection. To execute SQL statements, you need to
instantiate a Statement object from your connection object by using the createStatement() method.
Statement statement = dbConnection.createStatement();
A statement object is used to send and execute SQL statements to a database.
Three kinds of Statements
Statement: Execute simple sql queries without parameters.
Statement createStatement()
Creates an SQL Statement object.
Prepared Statement: Execute precompiled sql queries with or without parameters.
PreparedStatement prepareStatement(String sql)
returns a new PreparedStatement object. PreparedStatement objects are precompiled
SQL statements.
Callable Statement: Execute a call to a database stored procedure.
CallableStatement prepareCall(String sql)
returns a new CallableStatement object. CallableStatement objects are SQL stored procedure call
statements.
4. Executing a SQL statement with the Statement object, and returning a jdbc resultSet.
Statement interface defines methods that are used to interact with database via the execution of SQL
statements. The Statement class has three methods for executing statements:
executeQuery(), executeUpdate(), and execute(). For a SELECT statement, the method to use is
executeQuery . For statements that create or modify tables, the method to use is executeUpdate. Note:
Statements that create a table, alter a table, or drop a table are all examples of DDL
statements and are executed with the method executeUpdate. execute() executes an SQL
statement that is written as String object.
ResultSet provides access to a table of data generated by executing a Statement. The table rows are
retrieved in sequence. A ResultSet maintains a cursor pointing to its current row of data. The next()
method is used to successively step through the rows of the tabular results.
ResultSetMetaData Interface holds information on the types and properties of the columns in a
ResultSet. It is constructed from the Connection object.

23
 (a) Test JDBC Driver Installation

import javax.swing.JOptionPane;

public class TestJDBCDriverInstallation_Oracle {

public static void main(String[] args) {

StringBuffer output = new StringBuffer();
output.append(”Testing oracle driver
installation \n”);
try {
String className =
“sun.jdbc.odbc.JdbcOdbcDriver”;
Class driverObject =
Class.forName(className);
output.append(”Driver :
“+driverObject+”\n”);
output.append(”Driver Installation
Successful”);
JOptionPane.showMessageDialog(null,
output);
} catch (Exception e) {
output = new StringBuffer();
output.append(”Driver Installation
FAILED\n”);
JOptionPane.showMessageDialog(null,
output);
System.out.println(”Failed: Driver Error: ” +
e.getMessage());
}
}
}

Section II.2 Java JDBC Connection Example, JDBC Driver Example

24
25
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.DriverManager;
import java.sql.SQLException;

public class JDBCDriverInformation {

static String userid=”scott”, password = “tiger”;
static String url = “jdbc:odbc:bob”;
static Connection con = null;
public static void main(String[] args) throws Exception {
Connection con = getOracleJDBCConnection();
if(con!= null){
System.out.println(”Got Connection.”);
DatabaseMetaData meta = con.getMetaData();
System.out.println(”Driver Name :
“+meta.getDriverName());
System.out.println(”Driver Version :
“+meta.getDriverVersion());

}else{
System.out.println(”Could not Get Connection”);
}
}

public static Connection getOracleJDBCConnection(){

try {
Class.forName(”sun.jdbc.odbc.JdbcOdbcDriver”);
} catch(java.lang.ClassNotFoundException e) {
System.err.print(”ClassNotFoundException: “);
System.err.println(e.getMessage());
}

try {
con = DriverManager.getConnection(url, userid,
password);
} catch(SQLException ex) {
System.err.println(”SQLException: ” +
ex.getMessage());
}

return con;
}

26
4.OVERALL DESCRIPTION

4.1 PRODUCT PERSEPECTIVE

PROBLEM AND EXISTING SYSTEM

We have many healthcare centers which take care of our lives in our busy
lifecycle schedule. We consult these healthcare centers in our lifetime when we suffer
from any small disease. The doctors only give medicines when it is the case of fever, cold
or cough, but when the case of chronic diseases like cancer or cardiac problems like heart
attacks comes into picture, x-ray of the affected part are to be taken, which help us to
locate the exact position of the area. By using these x-rays either the doctors or patients
can consult other doctors for seeking their advices.

PROBLEMS

 Data is lost while transmitting x-ray from one doctor’s hand to another.

 x- Ray format differs from one healthcare center to another.

PROPOSED SYSTEM

DICOM (Digital Imaging and Communications in Medicine) overcomes

the above said problems. DICOM is a standard for handling, storing, printing,
transmitting information in medical imaging. It includes a file format definition
and a network communication protocol. The communication protocol is an
application protocol that uses TCP/IP to communicate between systems. DICOM
files can be exchanged between two entities that are capable of receiving image
and patient data in DICOM format. Thus we can prevent the data fromi.being
lost.DICOM enables the integration of scanners, servers, workstations, printers
and network hardware from multiple manufacturers in a picture archiving and
communication system. The different devices come with DICOM conformance
statements which clearly state the DICOM classes they support. DICOM has been
27
 widely adopted by hospitals and is making inroads in smaller applications like
dentists’anddoctors’offices.
Data is lost while transmitting x-ray from one doctor’s hand to another.

4.2 PRODUCT FUNCTIONALITIES

DICOM is a comprehensive set of standards for handling, storing and transmitting

information in medical imaging. It includes a file format definition and a network
communication protocol. It is based on the OSI model (Open System Interconnect)
and falls into layer 7 the application layer. It is an object-oriented framework in
which information and functions or routines that operate on the information are
grouped together in easy to manage packets called objects. It specifies a non-
proprietary data interchange protocol and image format for medical images and image
related information. The information is modeled with entity-relationship (E-R) model.
It is based on HL7 format.

DICOM SERVICES

DICOM consists of many different services, most of which involve transmission

of data over a network, and the file format below is a later and relatively minor addition
to the standard.

(a) STORE
The DICOM Store service is used to send images or other persistent objects
(structured reports, etc.) to a PACS or workstation.

(b) STORAGE COMMITMENT

The DICOM storage commitment service is used to confirm that an image has
been permanently stored by a device (either on redundant disks or on backup media, e.g.
burnt to a CD). The Service Class User (SCU - similar to a client), a modality or
workstation, etc., uses the confirmation from the Service Class Provider (SCP - similar to
a server), an archive station for instance, to make sure that it is safe to delete the images
locally.
28
 (c) OUERY/RETRIEVE

This enables a workstation to find lists of images or other such objects and then retrieve
them from a PACS.

(d) MODALITY WORK TEST

This enables a piece of imaging equipment (a modality) to obtain details of

patients and scheduled examinations electronically, avoiding the need to type such
information multiple times (and the mistakes caused by retyping).

(f) PRINTING

The DICOM Printing service is used to send images to a DICOM Printer,

normally to print an "X-Ray" film. There is a standard calibration (defined in DICOM) to
help ensure consistency between various display devices, including hard copy printout.

(g) OFF-LINE MEDIA (DICOM FILES)

The off-line media files correspond to Part of the DICOM standard. It describes
how to store medical imaging information on removable media. Except for the data set
containing, for example, an image and demography, it's also mandatory to include the
File Meta Information.

DICOM restricts the filenames on DICOM media to 8 characters (many people

wrongly use 8.3, but this is not legal). No information must be extracted from these
names (PS10:6.2.3.2). This is a common source of problems with media created by
developers who did not read the specifications carefully. This is a historical requirement
to maintain compatibility with older existing systems. It also mandates the presence of a
media directory, the DICOMDIR file, that provides index and summary information for
all the DICOM files on the media. The DICOMDIR information provides substantially
greater information about each file than any filename could, so there is less need for
meaningful file names.

DICOM files typically have a .dcm file extension.

29
 The MIME type for DICOM files is defined by RFC 3240 as application/dicom.

There is also an ongoing media exchange test and "connectathon" process for CD
media and network operation that is organized by the IHE organization..

4.3 USER CHARACTERSITCS

The users of the DICOM are:

 Doctors

 Technical Department

 Administrators

Scope Of Doctors Using DICOM : Doctors use DICOM for reading the X-Rays,
MRI Scans, CRI Scans.

Scope Of Technical Department: Technical Department people will transfer the

X-rays, MRI Scans ,CRI Scans to the doctor from the network and if the doctor is
not available then the technical department people will store it in a data base of
Doctor’s account.

Scope Of The Administrator: Administrators will maintain the Login Details Of

Doctors and Technical Department people, and they have the rights to access
every thing.

4.4 GENERAL CONSTRAINTS

 Communication Protocol-TCP/IP
 File Format Definitions- .dcm format
 FTP

The communication protocol is an application protocol that uses TCP/IP to communicate

between systems. DICOM files can be exchanged between two entities that are capable of
receiving image and patient data in DICOM (.dcm) format.

30
4.5 ANY ASSUMPTIONS AND DEPENDENCIES
Here we first consider the platform for running of the project. They include –
 Java 6.0
 DICOM API
Java 6.0 is used because it is more suitable for this application and also has many
advanced features like security, portability etc..
DICOM API is used as it acts as an interface which converts the images into .dcm format
that a system can understand.

31
5. SPECIFIC REQUIREMENTS
5.1 EXTERNAL INTERFACES
5.1.1 USER INTERFACE REQUIREMENTS
In the login page, the user need to enter the login details such as username
and password and then press submit button .If the details are valid then user can proceed
to next page. Here users are the lab assistants and doctors working in hospitals, diagnostic
centers etc.

5.1.2COMMUNICATION REQUIREMENTS
• Communication Protocol : TCP/IP
• Communication Standard : Http
• ftp

32
5.2 FUNCTIONAL REQUIREMENTS:

MODULE 1:
5.2.1 REGISTRATION

DESCRIPTION AND PRIORITY

Registration is a module which allows the patient to get registered
him/herself. It is of high priority.

FUNCTIONAL REQUIREMENTS
These can be broadly classified into following five categories:

PROVISIONING
 Patient name
 Patient ID
 Date of birth
 Gender
 Address
 Blood group

PURPOSE For Registrations.

I/P’s Patient Name, Patient ID, D.O.B, Gender, Address,
Blood Group.
PROCESS The Values Entered Are Stored In a Data Base.
OUTPUT Registration Is Successful.

FUNCTIONALITY
 Providing the registration form
 Assign ID

33
 QUERIES
 No. of patients registered
 No. of patients of a particular blood group

ALERTS
 Information is not complete
Rare blood group is found

REPORTS
 Male and female patients in particular age group, with a particular
blood group.

MODULE2:

5.2.2 WRITE DICOM FILE OR READ DICOM FILE

DESCRIPTION AND PRIORITY

Patient Record Updating is the module for updating the information from
patient. This is a high priority module.

FUNCTIONAL REQUIREMENTS

PROVISIONING
 Study ID
 Study date
 Serial number
 Modality
 Image file path

34
 PROCESS Updating The Patients Record.
I/P’S Study ID, Study Date, Serial Number, Modality, Image File
Path.
PROCESS Compares The I/P’s Entered And Updates The Patient
Record.
OUTPUT Patients Recorded Updated.

FUNCTIONALITY
 Diagnosing the record
 Write patient details, study report and image into .dcm format.
 Read the existing .dcm file with image details, patient details and study
report.
QUERIES
 No. of records updated in a week.

ALERTS
 Record is updated
A new record is found
REPORTS
 No. of records updated in a week

MODULE 3
5.2.3 DATA TRANSMISSION
DESCRIPTION AND PRIORITY
Data Transmission is a module for transmitting the patient’s data. This
module is of high priority.
FUNCTIONAL REQUIREMENTS
PROVISIONING
 DICOM transmitter

35
 PROCESS Transmitting the patient’s data.
I/P’S DICOM Transmitter.
PROCESS The X-rays/MRI scans/CRI Scans Are
Transmitted And No. Of. Patients With Common
Symptoms Are Checked.
OUTPUT Doctor Checks the data and give prescriptions.

FUNCTIONALITY
 Transmitting data in HL7 format

QUERIES
 No. of patients with common symptoms

ALERTS
 Data not in HL7 format
REPORTS
Patients with common symptoms

NON-FUNCTIONAL REQUIREMENTS

5.3.1 ATTRIBUTES OF THE PROJECT

A daptability: DICOM works with other standards development organizations

such as LOINC, SNOMED, JPEG, MPEG, BIRADES, TCP/IP and other internet standards.
 Usability: DICOM is used in radiology, oncology, neurology, cardiology,
ophthalmology.
 Interoperability: Since we are using the programming language Java which
operates in an open source environment, we can say that DICOM satisfies interoperability.
 Reliability: Since the communication protocol is Http, reliability is satisfied.

36
  Reusability: Since Java is an object oriented programming language, it can be
reusable.
 Portability: Since Java interpreter can execute Java byte codes on any machine
to which the interpreter has been ported, it can be portable.

5.4 OTHER REQUIREMENTS

 Data base: Oracle 10g
 DICOM transmitter
 DICOM receiver
 DICOM API

6. Software Design
37
 6.1 Design Objectives

• Design models help us to visualize a system as it is or as we want it to be.

• Design models permits us to specify the structure or behavior of the system.
• Design models give us a template that guides us in constructing a system.
• Design models document the decision we have made.

6.2 UML
Unified Modeling Language (UML) is a standardized visual specification language for
object modeling. UML is a general-purpose modeling language that includes a graphical notation
used to create an abstract model of a system, referred to as a UML model.
UML diagrams represent three different views of a system model:

Functional requirements view

Emphasizes the functional requirements of the system from the user's point of view.
Includes use case diagrams.

Static structural view

Emphasizes the static structure of the system using objects, attributes, operations, and
relationships. Includes class diagrams and composite structure diagrams.

Dynamic behavior view

Emphasizes the dynamic behavior of the system by showing collaborations among objects
and changes to the internal states of objects. Includes sequence diagrams, activity diagrams and
state machine diagrams.

6.2.1 DATA FLOW DIAGRAMS

38
Level 0 DICOM
In the diagram shown below, DICOM database can be accessed by the user (Doctor/Lab
technician), admin. DICOM file management which is used to maintain the details of the
patient, image and study details of the patient.
Fi

DICOM

DICOM
3 1
File Admin
Managemen
t User
2
(Doctor/Lab
Tech)

DICOM DB

g: 6.2.1 Level 0 DICOM

39
Level 1 DICOM

In this Administrator had the following services: Remove user, Update user, creating a
new server, Login and Logout. And the corresponding result are displayed.
USER: DICOM File management can manage the services like .dcm file receive, .dcm file
transmit, writing .dcm file, reading .dcm file and the retrieval and the storage are done from
DICOM file store.

Administrator
Message
Logout

1.5
1 Logou
Admin t
Services

1.2
Create
1.3 New
1.4 Updat User
Remo 1.1
e
ve User
User Login

Result
Result
Update
USER MASTER
TABLE
40
 Result
Result
Update
USER MASTER
TABLE

Fig: 6.2.2 Level 1 DICOM ADMIN

Level 2: DICOM – USER (D/L)

In this the user (Doctor/ Lab technician) has the authority to remove the patient
details, register the patient and update the details of the patient and the corresponding
changes are updated in the patient-master table.

41
 Doctor Lab - Tech

3
User
(D/L)

3.4 3.1
Remo Login
ve 3.3 3.2
patient Updat Patien
e t
Patien Reg
t
Detail
s
User Master
Table

Patient Master Table

Fig:6.2.3 Level 2: DICOM – USER (D/L)

Level3: DICOM –DICOM FILE MAGEMENT-WRITE DICOMFILE

In this the users such as doctors and lab technicians can diagnose the entire record and
can write details into the .dcm file format that is stored in DICOM file store.

42
 Doctor

2.1.2
2.1.1 Write
Diognising details
Record into
.dcm file

LabTech.

DICOM File
Store

Fig: 6.2.4 Level3 DICOM –DICOM File Management -WRITE DICOMFILE

Level 3: DICOM-DICOM FILE MANAGEMENT READ .dcm file

In this the users such as doctors, lab technicians can read the patient
details, study details, and image details of the specified .dcm file and the respective details
are retrieved from the DICOM file store.

43
 Doctor

2.2.1 Dicom file

Read store
Patien
t
Detail
s

Lab Tech. Details

Patieny

Fig: 6.2.5 Level 3: DICOM-DICOM FILE MANAGEMENT READ .dcm file

Level3: DICOM-DICOMFILEMANAGEMENT-TRANSMITTING .dcm FILE

In this the Doctors or the lab technicians can read the details from DICOM file
store and while transmitting, the details are converted into Health Level 7 format (HL7) and are
maintained in the DICOM file store.
44
 Doctor
DICOM file
2.2.1 Store
Read
Patien
t
details

Lab Tech

2.2.2
Convert
data into
HL7
Format

2.2.3
Transmit
details

DICOM file
Store

Fig: 6.2.6 Level3: DICOM-DICOM File management- Transmitting .dcm file

Level 4: DICOM-DICOMFILEMANAGEMENT RECEPTION

In this the doctors or the lab technicians can retrieve the required HL7 format
details from the DICOM file store and then converts into the .dcm file format to display on the
receiver side.
45
 DICOM File
Doctor Store

2.4.1
Display .
dcm file

2.4.2
Lab Retrieve
Tech Required
HL7
Format

Fig: 6.2.7 Level 3: DICOM-DICOMFILEMANAGEMENT RECEPTION

6.3 System Level Use Case Diagram

A Use Case is a series of steps an actor performs on a system to achieve a goal. Actors are
"objects" of any type, such as people, parts or other systems.

46
Use Case Diagram1:

Doc tor
Regis tration

Databas e
A s s igning id A dm inis trator
patient

Use Case Diagram2:

Patient
Consulting

Prescribing

doctor

testing

<<includes>>

Examining Report
<<includes>>

reporting

Updating Report

6.4 UML Diagrams

SEQUENCE DIAGRAMS:

47
A sequence Diagram is an Interaction Diagram that emphasizes the time ordering of messages.
Graphically, a Sequence Diagram is a table that shows objects arranged along the X-axis and messages,
ordered in increasing time, along the Y-axis.

Database Form : Patient form : Doctor JDBC : Database : Data

admin:admin Patient : Patient Doctor : Doctor Registration Registration Database base

update()

enterData()
establishConnection( )
getDBConnection( )

executeUpdate()
update successfully
AssignId
()
closeConnection()

enterData()
establishConnection(getDBConnection(
) )

executeUpdate()
update successfully
assignId()
closeConnection()

48
 Prescription : Test : Test Report : Report Consultation :
Patient : Patient Doctor : Doctor
Prescription Consultation

consults()
generatePrescription( )
has

undergoes()
generates()

examineReport( )

updateReport( )
update successfully

gives()

receives()

6.5 CLASS DIAGRAM:

49
A class is a description of a set of objects that share the same attributes, operations, relationships and
semantics. A class implements one or more interfaces.

P a t ie n t R e g is t ra t io n D a t a b a s e C o n n e c t ivit y
nam e d rive r c la s s D o c to r R e g is t ra t io n
dob c o n n e c t io n nam e
gender s ta te m e n t a d d re s s
a d d re s s p re p a re d s t a t e m e n t s e c ia liz a t io n
c o n ta c t n o
g e t D B C o n n e c t io n () r e g is t ra t io n ()
r e g is t ra t io n () e x e c u t e Q u e ry ( ) a s s ig n in g id ()
a s s ig n in g id () e x e c u t e U p d a t e ()

C o n s u lt a t io n

d ia g n o s in g ()

P r e s c rip t io n
p re s c rip t io n d a te
g e n e ra t e p re s c rip t io n ()
a s s ig n in g id ()
R e p o rt
Te s t
r e p o rt d a t e D a t a T ra n s m is s io n D a t a R e c e p t io n
tes t nam e
t e s t d e s c rip t io n
a s s ig n in g id () t ra n s m it t in g d a ta ( ) re c e ivin g d a ta ()
e x a m in in g re p o r t()
a s s ig n in g id ()
u p d a t in g re p o rt ()

6.6 Activity Diagram

50
 Start

Login Page

Enter User Id and

Password

If
Vali No
d

Yes

Open Home
Page

Select a task

Registration Write Read Transmissio Reception

n

Stop

6.7 OOAD OVERVIEW

51
 Object-oriented analysis and design implies three specific areas that we will concentrate on:

• analysis

• design

• the object-oriented
paradigm

There are three purposes to analysis and design:

• to transform the
requirements into a design of the system to be

• to evolve a robust
architecture for the system to adapt the design (fine tune it) to match the implementation
environment

6.8 DATA BASE DESIGN

6.8.1 ENTITIES

1. Patient
2. Doctor
3. Registration
4. Study

6.8.2 ENTITIES AND THEIR ATTRIBUTES

1. Patient

• Name
• Gender
• Address
• Date of Birth
52
 • Blood Group

2. Doctor

• Name
• Specialization
• Address
• Email ID
• Contact No

3. Registration

• Regno*

4. Study

• Study ID*
• Study Details
• Parts examined
• Institution

6.8.3 ENTITY RELATIONSHIP DIAGRAMS

The Entity-Relationship(ER) diagram allows us to describe the data involved in real-

world enterprise in terms of objects (entities) and their relationships, and is widely used to develop
an initial database design.

The ER model is important for its role in database design. It provides useful
concepts that allow changing the detailed and informal description of what users want to a precise
and formal description that can be implemented in a DBMS. Within the overall design process,
the ER model is used in a phase called conceptual database design.

53
 Even though the ER model describes the physical database model, it is basically useful in
the design and communication of the logical database model.

The ER diagram is built up from the following components:

• Rectangles: represent entity sets.

• Diamonds: represents relationships among entity sets, which are connected to the
rectangles by lines.
• Ellipses: represent attributes, and are connected to the entities or relationship by lines.
• Lines: link attributes to entity sets to relationships.

54
 Patient
Registration
Name
Gender
Address
Date of Birth Reg no*
Blood Group

Fig: 6.8.1 Patient-registration: one-one

Doctor
Registration
Name
Specialization
Address Reg no*
Email ID
Contact No

Fig: 6.8.2 Doctor-Registration: one-one

55
 Patient
Doctor

id
Name id
Gender Name
Address Study Specialization
Date of Birth Address
Blood Group Study ID* Email ID
Parts examined Contact No
Description
Institution name

Fig: 6.8.3 Study Details of the Patient

DATABASE TABLES

FIELD NAME TYPE CONSTRAINTS DESCRIPTION

P ID NUMBER NOT NULL PRIMARY KEY

NAME TEXT NOT NULL

Address VARCHAR NOT NULL

Date of Birth NUMBER NOT NULL

BLOOD GROUP CHAR NOT NULL

Table: 6.8.1 Patients

56
 FIELD NAME TYPE

Study ID* NUMBER

Study Details TEXT

Parts examined TEXT

Institution TEXT

Table: 6.8.2 Study Details

FIELD NAME TYPE

Regno* VARCHAR

Table: 6.8.3 Registrations

TESTING
57
 7.1. INTRODUCTION

Software testing is a critical element of software quality assurance and represents the
ultimate review of specification, design and coding. In fact, testing is the one step in the software
engineering process that could be viewed as destructive rather than constructive.

A strategy for software testing integrates software test case design methods into a well-
planned series of steps that result in the successful construction of software. Testing is the set of
activities that can be planned in advance and conducted systematically. The underlying motivation of
program testing is to affirm software quality with methods that can economically and effectively
apply to both strategic to both large and small-scale systems.

7.2. STRATEGIC APPROACH TO SOFTWARE TESTING

The software engineering process can be viewed as a spiral. Initially system engineering
defines the role of software and leads to software requirement analysis where the information
domain, functions, behavior, performance, constraints and validation criteria for software are
established. Moving inward along the spiral, we come to design and finally to coding. To develop
computer software we spiral in along streamlines that decrease the level of abstraction on each turn.

A strategy for software testing may also be viewed in the context of the spiral. Unit testing
begins at the vertex of the spiral and concentrates on each unit of the software as implemented in
source code.Testing progress by moving outward along the spiral to integration testing, where the
focus is on the design and the construction of the software architecture. Talking another turn on
outward on the spiral we encounter validation testing where requirements established as part of
software requirements analysis are validated against the software that has been constructed. Finally
we arrive at system testing, where the software and other system elements are tested as a whole.

58
 UNIT TESTING

MODULE
TESTING

Component
Testing SUB-SYSTEM
TESING

SYSTEM
Integration Testing TESTING

ACCEPTANCE
TESTING
User
Testing
7.3. Unit Testing

Unit testing focuses verification effort on the smallest unit of software design, the module. The unit
testing we have is white box oriented and some modules the steps are conducted in parallel.

1. WHITE BOX TESTING

This type of testing ensures that
• All independent paths have been exercised at least once
• All logical decisions have been exercised on their true and false sides
• All loops are executed at their boundaries and within their operational bounds
• All internal data structures have been exercised to assure their validity.
To follow the concept of white box testing we have tested each form .we have created independently
to verify that Data flow is correct, All conditions are exercised to check their validity, All loops are
executed on their boundaries.

2. BASIC PATH TESTING

59
 Established technique of flow graph with Cyclomatic complexity was used to derive test cases for all
the functions. The main steps in deriving test cases were:
Use the design of the code and draw correspondent flow graph.
Determine the Cyclomatic complexity of resultant flow graph, using formula:

V(G)=E-N+2 or V(G)=P+1 or V(G)=Number Of Regions

Where V(G) is Cyclomatic complexity,

E is the number of edges,
N is the number of flow graph nodes,
P is the number of predicate nodes.
Determine the basis of set of linearly independent paths.

3. CONDITIONAL TESTING
In this part of the testing each of the conditions were tested to both true and false aspects. And all the
resulting paths were tested. So that each path that may be generate on particular condition is traced
to uncover any possible errors.

4. DATA FLOW TESTING

This type of testing selects the path of the program according to the location of definition and use of
variables. This kind of testing was used only when some local variable were declared. The
definition-use chain method was used in this type of testing. These were particularly useful in nested
statements.

5. LOOP TESTING
In this type of testing all the loops are tested to all the limits possible. The following exercise was
adopted for all loops:
• All the loops were tested at their limits, just above them and just below them.
• All the loops were skipped at least once.
• For nested loops test the inner most loop first and then work outwards.
• For concatenated loops the values of dependent loops were set with the help of connected loop.
• Unstructured loops were resolved into nested loops or concatenated loops and tested as above.
8.OUTPUT SCREEN SHOTS
60
61
Home Page:
This is a home page of “Digital Imaging and Communications in Medicine” ,toolbar represents a
field called “Select a Task”.

Selecting a task:
This is a screen shot which shows the available options in the toolbar “Select a Task” they are Register
Patient, Write a File, Read a File, Start Receiver, Start Transmitter, user can select the required option
62
by clicking on the toolbar “Select a Task”

Registration Form:
This is a patient registration form with required fields “name, dob, gender, address, and
contact number” that will b e enough for further requirements
63
 .

Result of an patient registration :

Submit the button after entering the specified fields in the registration form, and then the result is
displayed in a dialog box.

64
 The following screen shot represents the success message of registering a patient

Write a file:
This is an DICOM Image Writer screen shot where the patient details entered in the registration form is
retrieved by relevant patient ID and at the same time the study details along with an x-ray which is in
65
jpeg format is submitted, an “ .dcm “ format file is generated .

Reading a “.dcm” file format:

After writing a file, browse a ‘.dcm” file which is stored in the location Dicom files then press
“read” button in the window, then the complete information of that patient is displayed.
66
67
Transmitting a “.dcm” file:

Select a file which is to transmit, to transmit the file need to know the Host IP Address and a port
number.

68
Screen shot represents that an “.dcm” file is transmitted to an Host IP Address 127.0.0.1 and a port
number 104.

69
Receiving a “.dcm” file:

The complete details of the patient are received on the receiver side.

70
 8.CONCLUSION

In this project titled “DIGITAL IMAGING AND COMMUNICATION IN MEDICINE”

which includes a file format definition and a network communication protocol. The communication
protocol is an application protocol that uses TCP/IP to communicate between systems. DICOM files can
be exchanged between two entities that are capable of receiving image and patient data in DICOM
(.dcm) format.
DICOM differs from other data formats in that it groups information into data sets. That means
that a file of a chest X-Ray image, for example, actually contains the patient ID within the file, so that
the image can never be separated from this information by mistake.
Thus it can be concluded that DICOM is a product for handling, storing, and transmitting
information in medical imaging.

71
 9.FUTURE ENHANCEMENTS

• Privileges can be assigned to the users of DICOM.

• Editing the image can be done which is very useful to view the specific parts in an image.
• Along with the patient details the doctor details can also be updated into the database.
• On the receiver side, security can be provided so that only authenticated users can view the
image.
• Encryption and Decryption algorithms can be used to provide

72
 10.BIBLIOGRAPHY

http://medical.nema.org/dicom.html
http://www.rsna.org/IHE
http://www.websamba.com/dicom4india
http://imaging.apteryx.fr/dicom/
http://www.dclunie.com/

73
11. APPENDIX

History

DICOM is the third version of a standard developed by American College of Radiology (ACR)
and National Electrical Manufacturers Association (NEMA).In the beginning of the 1980s it was almost
impossible for anyone other than manufacturers of computed tomography or magnetic resonance
imaging devices to decode the images that the machines generated. Radiologists wanted to use the
images for dose-planning for radiation therapy. ACR and NEMA joined forces and formed a standard
committee in 1983. Their first standard, ACR/NEMA 300, was released in 1985. Very soon after its
release, it became clear that improvements were needed. The text was vague and had internal
contradictions.

In 1988 the second version was released. This version gained more acceptances among vendors.
The image transmission was specified as over a dedicated 25 differential (EIA-485) pair cable. The first
demonstration of ACR/NEMA V2.0 interconnectivity technology was held at Georgetown University,
May 21-23, 1990. Six companies participated in this event, DeJarnette Research Systems, General
Electric Medical Systems, Merge Technologies, Siemens Medical Systems, Vortech (acquired by Kodak
that same year) and 3M. Commercial equipment supporting ACR/NEMA 2.0 was presented at the
annual meeting of the Radiological Society of North America (RSNA) in 1990 by these same vendors.
Many soon realized that the second version also needed improvement. Several extensions to
ACR/NEMA 2.0 were created, like Papyrus (developed by the University Hospital of Geneva,
Switzerland) and SPI, (Standard Product Interconnect, driven by Siemens Medical Systems and Philips
Medical Systems).

The first large scale deployment of ACR/NEMA technology was made in 1992 by the US Army
and Air Force as part of the MDIS (Medical Diagnostic Imaging Support)program run out of Ft. Detrick,
Maryland. Loral Aerospace and Siemens Medical Systems led a consortium of companies in deploying

74
the first US military PACS (Picture Archiving and Communications System) at all major Army and Air
Force medical treatment facilities and teleradiology nodes at a large number of US military clinics.
DeJarnette Research Systems and Merge Technologies provided the modality gateway interfaces from
third party imaging modalities to the Siemens SPI network. The Veterans Administration and the Navy
also purchased systems off this contract. In 1993 the third version of the standard was released. Its name
was then changed to DICOM so as to improve the possibility of international acceptance as a standard.
New service classes were defined, network support added and the Conformance Statement was
introduced. Officially, the latest version of the standard is still 3.0; however, it has been constantly
updated and extended since 1993. Instead of using the version number the standard is often version-
numbered using the release year, like "the 2007 version of DICOM".

While the DICOM standard has achieved a near universal level of acceptance amongst medical
imaging equipment vendors and healthcare IT organizations, the standard has its limitations. DICOM is
a standard directed at addressing technical interoperability issues in medical imaging. It is not a
framework or architecture for achieving a useful clinical workflow. RSNA's Integrating the Healthcare
Enterprise (IHE) initiative layered on top of DICOM (and HL-7) provides this final piece of the medical
imaging interoperability puzzle.

8.2 DICOM File format

DICOM differs from other data formats in that it groups information into data sets. That means
that a file of a chest X-Ray image, for example, actually contains the patient ID within the file, so that
the image can never be separated from this information by mistake.

A DICOM data object consists of a number of attributes, including items such as name, ID, etc.,
and also one special attribute containing the image pixel data (i.e. logically, the main object has no
"header" as such - merely a list of attributes, including the pixel data). A single DICOM object can only
contain one attribute containing pixel data. For many modalities, this corresponds to a single image. But
note that the attribute may contain multiple "frames", allowing storage of cine loops or other multi-
frame data. Another example is NM data, where an NM image by definition is a multi-dimensional
multi-frame image. In these cases three- or four-dimensional data can be encapsulated in a single
DICOM object. Pixel data can be compressed using a variety of standards, including JPEG, JPEG
Lossless, JPEG 2000, and Run-length encoding (RLE). LZW (zip) compression can be used for the
whole data set (not just the pixel data) but this is rarely implemented.

75
 DICOM uses three different Data Element encoding schemes. With Explicit VR Data Elements,
for VRs that are not OB, OW, OF, SQ, UT, or UN, the format for each Data Element is: GROUP (2
bytes) ELEMENT (2 bytes) VR (2 bytes) LengthInByte (2 bytes) Data (variable length). For the other
Explicit Data Elements or Implicit Data Elements, see section 7.1 of Part 5 of the DICOM Standard.

The same basic format is used for all applications, including network and file usage, but when
written to a file, usually a true "header" (containing copies of a few key attributes and
details of the application which wrote it) is added.

76