Dicom Srs(imp)

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 CT DD DG EC EM

Modality of type Computed Radiography Modality of type Computed Tomography Modality of type Duplex Doppler-Retired 2008 Modality of type Diaphangraphy Modality of type Echo cardiography – Retired 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 xray machine. Also called computerized tomography and computerized axial tomography (CAT) scan. MRI: Magnetic resonance imaging scan. A diagnostic technique that frequency radio waves and a computer to visualise the organs of the body.

uses high

X-RAYS: X-radiation (composed of X-rays) is a form of electromagnetic radiation. Xrays 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 import import import

java.sql.Connection; java.sql.DatabaseMetaData; java.sql.DriverManager; 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 nonproprietary 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 I/P’s

For Registrations. Patient Name, Patient ID, D.O.B, Gender, Address,

PROCESS OUTPUT

Blood Group. The Values Entered Are Stored In a Data Base. 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

PROCESS

Path. Compares The I/P’s Entered And Updates The Patient

OUTPUT

Record. 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 I/P’S PROCESS

Transmitting the patient’s data. DICOM Transmitter. The X-rays/MRI scans/CRI Scans Are Transmitted And No. Of. Patients With Common

OUTPUT

Symptoms Are Checked. 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

•

Design models give us a template that guides us in constructing a system.

•

Design models document the decision we have made.

system.

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 File Managemen t

1 Admin 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

Logout Message 1.5

1 Admin Services

1.4 Remo ve User

Logou t

1.3 Updat e User

1.1 Login

Result USER MASTER TABLE 40

1.2 Create New User

Update Result

Result USER MASTER TABLE

Update Result

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

Lab - Tech

Doctor

3 User (D/L)

3.4 Remo ve patient

3.3 Updat e Patien t Detail s

3.1 Login 3.2 Patien t Reg

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 Write details into .dcm file

2.1.1 Diognising Record

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 Read Patien t Detail s

Dicom file store

Lab Tech.

Patieny Details

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 Store

2.2.1 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 Store

Doctor

2.4.1 Display . dcm file

2.4.2 Retrieve Required HL7 Format

Lab Tech

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 dm inis trator

A s s igning id patient

Use Case Diagram2:

Patient

Consulting

Prescribing

doctor testing <> Examining Report <> 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 admin:admin Patient : Patient Doctor : Doctor

Form : Patient Registration

form : Doctor Registration

JDBC : Database

Database : Data base

update() enterData()

establishConnection( )

getDBConnection( )

executeUpdate() AssignId ()

enterData()

update successfully closeConnection()

establishConnection(getDBConnection( ) ) executeUpdate() update successfully assignId() closeConnection()

48

Patient : Patient

Doctor : Doctor

Prescription : Prescription

Test : Test

Report : Report

consults() generatePrescription( )

has

undergoes()

generates()

examineReport( ) updateReport( ) update successfully gives()

receives()

6.5 CLASS DIAGRAM: 49

Consultation : Consultation

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 nam e dob gender a d d re s s c o n ta c t n o r e g is t ra t io n () a s s ig n in g id ()

D a t a b a s e C o n n e c t ivit y d rive r c la s s c o n n e c t io n s ta te m e n t p re p a re d s t a t e m e n t g e t D B C o n n e c t io n () e x e c u t e Q u e ry ( ) e x e c u t e U p d a t e ()

D o c to r R e g is t ra t io n nam e a d d re s s s e c ia liz a t io n r e g is t ra t io n () a s s ig n in g id ()

C o n s u lt a t io n d ia g n o s in g ()

R e p o rt Te s t 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 r e p o rt d a t e 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 () g e n e ra t e p re s c rip t io n () e x a m in in g re p o r t() a s s ig n in g id () a s s ig n in g id () u p d a t in g re p o rt () P r e s c rip t io n p re s c rip t io n d a te

6.6 Activity Diagram 50

Start

Login Page

Enter User Id and Password

If Vali d

No

Yes Open Home Page

Select a task

Registration

Write

Read

Transmissio n

Stop 6.7 OOAD OVERVIEW 51

Reception

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 realworld 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 Blood Group

Reg no*

Fig: 6.8.1 Patient-registration: one-one

Doctor Registration

Name Specialization Address Email ID Contact No

Reg no*

Fig: 6.8.2 Doctor-Registration: one-one

55

Patient

Doctor

id Name Gender Address Date of Birth Blood Group

id Name Specialization Address Email ID Contact No

Study Study ID* Parts examined 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 wellplanned 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

Integration Testing

SYSTEM 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 versionnumbered 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 multiframe 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