Citation
Design and analysis of user interface for radiology teaching file (RTF)

Material Information

Title:
Design and analysis of user interface for radiology teaching file (RTF)
Creator:
Balakrishnan, Aarathi
Place of Publication:
[Gainesville, Fla.]
Publisher:
University of Florida
Publication Date:
Language:
English

Subjects

Subjects / Keywords:
Database design ( jstor )
Databases ( jstor )
Design analysis ( jstor )
Image files ( jstor )
Radiology ( jstor )
Search engines ( jstor )
Software ( jstor )
SQL ( jstor )
Systems design ( jstor )
Usability ( jstor )
Computer and Information Science and Engineering thesis,M.S ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF ( lcsh )
Medical radiology -- Data processing ( lcsh )
User interfaces (Computer systems) ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent) ( marcgt )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Summary:
ABSTRACT: A Radiology Teaching File (RTF) is a collection of documentation on relevant medical cases consisting of radiological images. The use of an RTF for computer-based learning is becoming very common. An important characteristic of an RTF is ease of navigation, since the focus of these systems is the acquisition of knowledge by the user. Maintenance of the RTF is also an important task since the RTF typically contains a large number of cases with many images associated with each case. It, therefore, becomes very important and necessary to provide a simple and easy-to-use interface so that RTFs can be used to its full potential. Many software systems have a poorly designed user interface, which severely limits their use. It is important to realize that users view the interface as the system. Poorly designed interfaces prove difficult to learn and cause an increase in user errors. The acceptance rate of many software systems often drops because of a badly designed user interface. Hence the need to design improved user interfaces is emerging. This thesis examines the designing of a user interface for an RTF. The goal was to design a user-friendly system that could ease the cumbersome tasks of authoring and reviewing cases easy without causing the user much stress and anxiety.
Thesis:
Thesis (M.S.)--University of Florida, 2003.
Bibliography:
Includes bibliographical references.
System Details:
System requirements: World Wide Web browser and PDF reader.
System Details:
Mode of access: World Wide Web.
General Note:
Title from title page of source document.
General Note:
Includes vita.
Statement of Responsibility:
by Aarathi Balakrishnan.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Balakrishnan, Aarathi. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
5/1/2013
Resource Identifier:
029897539 ( ALEPH )
81808997 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

DESIGN AND ANALYSIS OF USER INTERFACE FOR RADIOLOGY TEACHING FILE (RTF) By AARATHI BALAKRISHNAN A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Aarathi Balakrishnan

PAGE 3

To My Family and Friends

PAGE 4

ACKNOWLEDGMENTS I thank Dr. Doug Dankel for his excellent support and guidance with this thesis. His direction and advice is greatly appreciated. I would also like to thank Dr. Sistrom who gave me the opportunity to work on this project. I appreciate his timely guidance and suggestions throughout the course of the thesis. I would also like to thank Dr. Beverly Sanders for serving on my committee. I thank the people of the Department of Radiology for providing me with the necessary resources and materials to complete this thesis. I thank Mr. Shriram Lakshmi for his valuable suggestions on my work. I thank all of my friends who have continuously encouraged and supported me through my graduate studies. Finally, I would like to express my gratitude to my parents and family for all things large and small that were never acknowledged. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS..................................................................................................iv LIST OF FIGURES...........................................................................................................vii ABSTRACT.......................................................................................................................ix CHAPTER 1 INTRODUCTION..........................................................................................................1 1.1 Problem Domain.....................................................................................................2 1.2 System Design.........................................................................................................2 1.3 Document Structure.................................................................................................5 2 BACKGROUND AND TECHNOLOGY OVERVIEW...............................................6 2.1 Existing Radiology Teaching File (RTF) System...................................................6 2.2 Design Principles Used...........................................................................................8 2.2.1 Usability........................................................................................................8 2.2.2 System-Centered Design...............................................................................9 2.2.3 User-Centered Design.................................................................................10 2.2.3.1 User and task analysis.......................................................................11 2.2.3.2 Prototyping and testing......................................................................12 2.3 Software Technology Used...................................................................................13 2.3.1 Active Server Pages.....................................................................................13 2.3.2 Microsoft Visual Basic Scripting Edition (VBScript).................................14 2.3.3 Open Data Base Connectivity (ODBC).......................................................15 2.3.4 Structured Query Language.........................................................................16 2.4 Summary...............................................................................................................17 3 RTF USER INTERFACE WALKTHROUGH............................................................18 3.1 Interface Design Principles...................................................................................18 3.1.1 Simplicity....................................................................................................18 3.1.2 Consistency.................................................................................................19 3.1.3 Visibility......................................................................................................19 3.1.4 Memory Load..............................................................................................19 3.1.5 Error Handling.............................................................................................19 3.1.6 Prompts, Labels, Messages and Feedback..................................................20 v

PAGE 6

3.1.7 Screen Layout..............................................................................................20 3.1.8 Shortcuts......................................................................................................21 3.2 RTF Walkthrough.................................................................................................21 3.2.1 Contributor Functions..................................................................................22 3.2.1.1 Moving cases to TF...........................................................................25 3.2.1.2 Edit cases...........................................................................................29 3.2.1.3 View my cases...................................................................................33 3.2.2 Administrator Functions..............................................................................36 3.2.3 General User Functions...............................................................................40 3.2.3.1 Free text search..................................................................................41 3.2.3.2 Advanced complex search.................................................................44 3.3 Summary...............................................................................................................45 4 INSIDE RTF................................................................................................................47 4.1 Main Database Design..........................................................................................47 4.1.1 Incoming_Images Table..............................................................................47 4.1.2 Teaching File (TF) Table.............................................................................49 4.1.3 Images Table...............................................................................................51 4.1.4 Other Tables................................................................................................52 4.1.4.1 Contributors.......................................................................................52 4.1.4.2 Patient_Info.......................................................................................52 4.1.4.3 Date_Info...........................................................................................52 4.1.4.4 Modalities..........................................................................................52 4.1.4.5 Hospital_Info.....................................................................................53 4.1.4.6 Profile................................................................................................53 4.2 Contributor Functions...........................................................................................53 4.2.1 Moving Cases to TF....................................................................................54 4.2.2 Adding Cases to TF.....................................................................................55 4.2.3 View Cases..................................................................................................55 4.3 Administrator Functions........................................................................................56 4.4 Summary and What Is Next..................................................................................57 5 FUTURE WORK AND CONCLUSIONS..................................................................58 5.1 Overview of RTF..................................................................................................58 5.2 Extensions of RTF.................................................................................................59 5.3 Summary...............................................................................................................60 LIST OF REFERENCES..................................................................................................61 BIOGRAPHICAL SKETCH.............................................................................................63 vi

PAGE 7

LIST OF FIGURES Figure page 2-1. User centered design lifecycle...............................................................................11 3-1. Login screen...........................................................................................................22 3-2. Contributor can select his role in the system.........................................................23 3-3. Contributor’s options screen..................................................................................24 3-4. First step in moving a case to the Teaching File....................................................25 3-5. Images associated with the case to be moved to the Teaching File.......................27 3-6. Patient and case details screen while moving the case to the Teaching File.........28 3-7. The user is presented with a list of cases to select from for editing......................30 3-8. Edit Case screen.....................................................................................................31 3-9. Edit Images screen.................................................................................................32 3-10. View Cases screen 1..............................................................................................33 3-11. Text mode of viewing cases...................................................................................34 3-12. Viewing the images associated with the case........................................................35 3-13. Detailed display mode............................................................................................36 3-14. Administrator options screen.................................................................................37 3-15. Screen to delete excess PACS images...................................................................38 3-16. Select images to be deleted....................................................................................39 3-17. This screen shows successful completion of the delete operation.........................40 3-18. Basic search screen................................................................................................41 3-19. Screen showing search results...............................................................................42 vii

PAGE 8

3-20. Detailed Case view................................................................................................43 3-21. Screen displaying the images associated with the case.........................................44 3-22. Advanced Search screen........................................................................................45 4-1. Main tables in the database....................................................................................48 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science DESIGN AND ANALYSIS OF USER INTERFACE FOR RADIOLOGY TEACHING FILE (RTF) By Aarathi Balakrishnan May 2003 Chair: Dr. Douglas D. Dankel II Department: Computer and Information Science and Engineering A Radiology Teaching File (RTF) is a collection of documentation on relevant medical cases consisting of radiological images. The use of an RTF for computer-based learning is becoming very common. An important characteristic of an RTF is ease of navigation, since the focus of these systems is the acquisition of knowledge by the user. Maintenance of the RTF is also an important task since the RTF typically contains a large number of cases with many images associated with each case. It, therefore, becomes very important and necessary to provide a simple and easy-to-use interface so that RTFs can be used to its full potential. Many software systems have a poorly designed user interface, which severely limits their use. It is important to realize that users view the interface as the system. Poorly designed interfaces prove difficult to learn and cause an increase in user errors and hence decrease the productivity of the software. The acceptance rate of many software ix

PAGE 10

systems often drops because of a badly designed user interface. Hence the need to design improved user interfaces is emerging. This thesis examines the designing of a user interface for an RTF. The goal was to design a user-friendly system that could ease the cumbersome tasks of authoring and reviewing cases easy without causing the user much stress and anxiety. x

PAGE 11

CHAPTER 1 INTRODUCTION Computer technology is growing rapidly and almost every profession has some interaction with different software systems. A key component of all systems is user interface. User interface is the part of the system that allows the user to interact with the computer. But many of these systems are not known to be user friendly – they are not easy to use or to learn. As a result, they are not used to their full potential and they cause significant frustration and anxiety [1]. Many myths associated with user interface design can result in low usability of the finished product. One such myth is “User interface design is a veneer added to the product. It is cosmetic – fit and finish” [2]. Often the software developer builds the interface during the last stage of software development and tends to overlook many important aspects from the user’s perspective. While creating the interface, the developer often omits details that seem obvious to him but are not obvious to the user. Good design arises when developers understand the people and not just the technology. Developers count on the fact that humans are flexible and adaptable, and that humans can adapt to the machine, rather than vice versa [3]. This attitude results in the user’s requirements being neglected and the final product not being constructed to the user’s satisfaction. Some interfaces are very difficult to learn, to adapt to, and to use. This results in increased user-training time and costs, decreased productivity, and higher error rates. There is an increased need to attach more importance to the whole interface design process, understanding and applying it while creating a final good user interface. 1

PAGE 12

2 1.1 Problem Domain A teaching file is a collection of patient cases with images that is created by physicians. Whenever a physician finds a case that is a good illustration of a particular disease, he adds it to the database of such cases with the patient demographic information, descriptions of findings, codes, and other appropriate content including the images. One such teaching file is the RTF at Shands Hospital at the University of Florida. The main purpose of the RTF is to allow radiologists to store and organize images with interesting findings for teaching, research, and reference during clinical work. The RTF is a growing database consisting of numerous cases, where each case has an associated set of images. The RTF at the University of Florida contains approximately twenty thousand patient cases and, on an average, each case has six associated images. The teaching file database is a valuable asset to academic radiology departments and private practice groups in teaching individuals about the characteristics of particular diseases. To allow this image collection to serve as a good educational and research tool over the Internet, it becomes necessary to design a good user interface for the system. Maintaining this database and navigating through it is a cumbersome task and should be made easier for the physician through a well-designed user interface. The focus of this thesis is the design of such an interface that causes minimal errors and stress to the users. The aim is to provide a good user interface for the web based RTF that allows the doctors to perform all their tasks with ease. 1.2 System Design The main functions of the RTF can be classified into two broad categories: Case authoring and maintenance Criterion-based case search engine

PAGE 13

3 The teaching file is a huge database of important information. Maintaining so much information is a cumbersome task. Many operations are involved before cases can actually be moved into the teaching file. Case authoring and maintenance allow these operations to be performed before these data are stored in an easily retrievable format. Most of the functionalities are involved with modifying the cases and the database. The functionalities and their corresponding design and implementation are explained later. The criterion-based case search engine allows different users to query the RTF to view interesting cases contained in the database. This engine provides various searches that may be useful to different users. For example it provides a search as simple as a Google search that queries the database on the basis of free text, and an advanced complex search that considers different criteria. This thesis also examines the design of the user interface for the search engine. While designing a user interface, the most important factor to remember is the user. One of the first steps in the development of the user interface is to define the users and state their requirements [4]. The RTF has 3 types of users: Contributors Administrators General users The contributors are general physicians who have permission to modify the back end databases. They can add, edit, or delete cases from the RTF. They can also use it to perform different types of searches. Administrators are users who have permission to modify the settings of the system and to make various bookkeeping changes to the system. The general user can only use the system for case viewing. He can query the

PAGE 14

4 system in various ways to view cases and does not have permission to modify internal databases. Figure 1-1 shows the main components of the system and the flow of control through the system. Data Request placed Requested data returned in a recordset Corresponding Raw data ASP script is is converted to HTML invoked and sent to the user through the IIS Dynamically generated HTML is sent to to the user through WWW User request User request picked up by IIS ASP Scripts Users World Wide Web SQL S erver d atabase Teaching File server Figure 1-1. Overall design of the system The user interface is designed with the aim of giving the user easy access to all features and not overwhelm the user with too many features. The design allows for a robust interaction without overcrowding the interface with unnecessary features. Components are used and positioned so as to reduce the chance of error. Care is taken to make forms with similar tasks to look as much alike as possible.

PAGE 15

5 1.3 Document Structure The following chapters of this thesis discuss the software and its user interface. Chapter 2 examines the existing teaching file system at the University of Florida. Principles behind user interface design are also discussed here. Chapters 3 and 4 examine the RTF’s interface and discuss its design details. Chapter 5 presents conclusions and examines future work related to this thesis.

PAGE 16

CHAPTER 2 BACKGROUND AND TECHNOLOGY OVERVIEW The current implementation of the teaching file consists of an Access database with patient demographic information and other case related information. The database contains pointers to the GIF images on the same server machine. This chapter examines how the current design of the teaching file system and its underlying software greatly reduces its usage. It shows how the new system is designed to overcome the shortcomings of the old system. A detailed description of the design principles behind the user interface for this system is also discussed. 2.1 Existing RTF System The older version of the teaching file was implemented with Microsoft Access. The forms and other elements of the user interface were also built using the MS Access Forms. As the teaching file server is important to the Department of Radiology, it needs to be shared by many individuals. To provide this sharing, the concept of linking, available with MS Access, was used. Microsoft Access allows one database to be linked to another, which builds an architecture similar to a one server database being accessed by several clients. The main database tables are stored on the server, while the client has its own set of tables, queries, forms, and other components. This architecture allows reading and editing data in the external source without having to import them. The external source can continue to be used, and its data can be accessed and modified with the help of MS Access. The main advantage of this feature is that the important tables containing the data can be stored separately at one place and the forms, reports, and 6

PAGE 17

7 queries that use this data in different ways can be stored in individual, different databases. Only the main database had the teaching file related tables while the forms and queries were stored in the individual client databases. This allowed different clients to manipulate the data in different ways with these changes become visible to all the clients. Some of the advantages of this architecture are Since there is one central database the data duplication problem is eliminated. All clients see the same copy of data. Any change made by a client will be reflected in the central database, which will be visible to all the other clients. In this manner the important information can be shared among many users of the teaching file and all the clients will be seeing the most recent copy of the data. Though this architecture seems to have many advantages, it has its own set of disadvantages: One of the biggest limitations of this architecture is that it is platform dependent. To access the teaching file database the client must have MS Access installed on his individual system. MS Access also has a limitation on the number of concurrent users at a given point of time. This restricts the number of users using the teaching file. It also becomes difficult to manage huge databases with Microsoft Access. As the teaching file is an ever-growing database, this feature of Access proves to be a serious problem, which greatly reduces its performance. Because of the importance of the teaching file in the teaching community, a need existed for developing a new platform-independent system capable of supporting many concurrent users. The new system needed to provide good and easy-to-use user interface. “Improved interface design may increase user’s successful experiences and positive attitudes” [1, p. 5]. Hence it becomes very important to design the RTF user interface with care so that it could be used easily for learning purposes.

PAGE 18

8 2.2 Design Principles Used To users, the interface is the system [5]. A user communicates with the system only through the user interface and has no knowledge about the internal functionalities of the system, thus making it imperative to develop a good interface. A well designed user interface results when designers understand the people as well as technology. Before designing the interface it is important to know the people, understand their capabilities, the tasks they perform, and the environment in which they operate. 2.2.1 Usability The main purpose of the user interface is to make the system “usable” to the user [4]. “Usability” is an important feature of the user interface that determines its acceptability, and it is very important to understand and include this feature while designing the system. Hix and Hartson [5] defined usability as a combination of the following user-oriented characteristics: Ease of learning, High speed of user task performance Low user error rate Subjective user satisfaction User retention over time While designing usable systems there is often a trade off in the usability requirements. For example, designing a system with low error rates can be achieved by keeping a small amount of data presented on the screen at any given time, but this results in low performance. Usability is important for any system but it is especially important for graphical user interfaces, as their complexity may sometimes be very confusing to the

PAGE 19

9 user. Hence there is a need to carefully determine the most important usability requirements early in the lifecycle of the system development. 2.2.2 System Centered Design Many software systems are designed with most of the focus on the system and its functionality with very little attention given to the interface and the end user. Such systems use a “System Centered Design” approach [4] where the “System” is the most important aspect. The design sequence in such systems typically involves the following steps: Creating a requirement specification. Developing a system analysis and design of the core of the system. Providing the implementation for the functions. Placing the user interface on top of the system, so that the user can interact with the functions. Testing the system. In such systems testing is kept for the last stage of development and as a result the user gets a feel of the system only after it is fully developed. In many situations the end product does not live up to the user’s expectations. By only thinking of the functionality when designing a system, designers, designers often tend to overlook many aspects that may be of great importance to the user but which may seem very trivial to the designer. Such a design approach is very useful for non-interactive systems where the importance is on the function, whereas it has a few disadvantages for interactive systems [3]. Some of them are System centered design develops from the heart of the system and toward the user interface in the end. The finished product may not be what the user actually expected.

PAGE 20

10 End user’s needs often tend to be neglected in such a design approach. The requirements are normally collected from people who are not going to be the end users of the system. Hence there is a possibility that some of the requirements may be missed, ignored, or misinterpreted. The requirements are restricted to the functional ones and do not take into account the manner in which the functions must be provided, such as ease of use, ease of learning, etc. A major concern with this approach is that the testing phase is ignored until the end of the development cycle and that testing is limited to functional testing. It, therefore, becomes very difficult to address usability issues after the whole product has been developed and functionally tested. To create usable systems, it is necessary to modify the normally used software life cycle to address usability issues. “User-centered design” is an approach to interactive system development, which focuses specifically on making systems usable and safe for their users [6]. 2.2.3 User-Centered Design A user-centered design process leads to more usable systems and products. It helps in designing a system that is intuitive and convenient for the user to use (i.e., adapting the system to the user), rather than developing what is convenient to the developer and the system and then asking the user to adapt to the developed system. Some important factors must be kept in mind when using this design approach: The designer focuses on the users, their tasks, and the environment. He needs to understand who the end users are, what tasks they perform, and what their capabilities are. Once the designer has a thorough knowledge of these factors, he can develop the interface around the users. End users play an important role throughout the analysis and design process. Their feedback must be included in the system. In this way, apart from providing functionality, care can be taken to make the services easy to use. An initial prototype of the system must be developed, and the user and the designer must jointly evaluate the usability issues. The design can then be modified to include

PAGE 21

11 changes suggested by the user. The design process is iterative in a user-centered approach (Figure 2-1). Requirement specification User analysis Task analysis User interface specification Architectural design Prototyping and testing Coding and testing Release and maintenance Integration and testing Detailed design Prototyping and testing Figure 2-1. User-centered design lifecycle 2.2.3.1 User and task analysis These are very important stages for this design approach. User analysis helps the designer understand the end users and their relevant characteristics. The best way to collect this information is by visiting users at their workplace and observing the way they perform their tasks. By talking to the users, the designer can obtain input specifications at

PAGE 22

12 all design stages and also give the users an idea of what can be done. Task analysis helps the developers understand the functionalities of the system. It allows the hierarchical breakdown of bigger tasks into smaller ones and provides specifications of the inputs and the desired outputs. A scenario, that is a sequence of steps describing an interaction between a user and the system, may help in understanding the design of a suitable interface. Normally there may be more than one way in which a particular task may be performed. A user-centered perspective makes the designer see what the user may need and prefer and hence choose the appropriate task. An important benefit resulting from performing the task analysis before the design is that it provides an understanding of what activities are “natural” to the user’s task domain. It thus prevents the user from performing “unnatural” acts [7]. 2.2.3.2 Prototyping and testing In the user-centered design, the phases of architectural design and detailed design should include the design of the user interface, since this is no longer deferred to the end of the system development. There are several important factors to consider when we are planning prototyping for user testing. We need to make careful choices about the fidelity, the level of interactivity, and the medium of the prototype [8]. The degree of fidelity is the closeness to the “depth, breadth and finish of the intended product” [8]. There are different opinions on how much the prototype should resemble the final version of the system. Prototypes can have a low, medium, or high degree of fidelity. A high fidelity prototype resembles the final design very closely. It can be represented as a set of HTML pages with simple links showing the flow through the system. This thesis used the high fidelity prototype as a basis for the design of the entire

PAGE 23

13 system. A technique called “Storyboarding” was used to walk through the prototype of the whole system and incorporate the changes and feedback from the user in this prototype before actual development began. By prototyping the system, the designer obtains a user’s point of view of the system early in the development cycle. The user-centered design methodology stresses the iteration of the design-implementation-evaluation cycle. To summarise, user-centered design focusses on the users and their tasks, incorporates user-derived feedback into the system design, and uses an iterative design approach whereby a prototype is designed, tested, and modified. 2.3 Software Technology Used This section describes the various technologies used in RTF. In RTF, the main data resides on a Microsoft SQL Server, also known as the “Sequel Server.” The SQL Server is an industrial strength database management system, which can support a large number of concurrent users. At the same time it can also support a huge databases. The server runs Microsoft “Internet Information Services 5.0,” which is a web server from Microsoft. This web server supports ASP or active server pages. Here VBScript is used as the scripting language. We examine the technologies used in the web server below. 2.3.1 Active Server Pages The Web server component of RTF supports Active Server Pages (ASP). The server-side scripts are written in VBScript [9]. A more detailed description of server side scripts and ASP follows. Microsoft Active Server Pages (ASP) is a server-side scripting environment used to create interactive Web pages and build powerful Web applications [10]. When the server

PAGE 24

14 receives a request for an ASP file, it processes server-side scripts contained in the file to build the Web page that is sent to the browser. In addition to server-side scripts, ASP files can contain HTML (including related client-side scripts) as well as calls to COM components that perform a variety of tasks, such as connecting to a database or processing business logic. A server-side script starts execution when a browser requests a .asp file from the Web server. The Web server then calls ASP, which processes the requested file from top to bottom, executes any script commands, and sends a Web page to the browser. Because the scripts executes on the server rather than on the client, the Web server performs all the work involved in generating the HTML pages sent to the browser. Server-side scripts cannot be readily copied because only the result of the script is returned to the browser. Users cannot view the script commands that created the page they are viewing. ASP supports various scripting languages including VBScript, which is used by RTF. 2.3.2 Microsoft Visual Basic Scripting Edition (VBScript) Microsoft Visual Basic Scripting Edition, the newest member of the Visual Basic family of programming languages [9], brings active scripting to a wide variety of environments, including Web client scripting in Microsoft Internet Explorer and Web server scripting in Microsoft Internet Information Server. It has all the good features of Visual Basic making it easy to use and learn. At the same time, it blends very well with all the other components of RTF. VBScript talks to host applications using ActiveX Scripting. With ActiveX Scripting, browsers and other host applications do not require special integration code for each scripting component. ActiveX Scripting enables a host to compile scripts, obtain and call entry points, and

PAGE 25

15 manage the namespace available to the developer. ActiveX Scripting is used in Internet Explorer and in IIS. VBScript and ActiveX Scripting can also be used as a general scripting language in other applications. 2.3.3 Open Data Base Connectivity (ODBC) The scripts interact with the Data Server over an ODBC connection. ODBC is a standard definition of an application-programming interface (API) used to access data in a relational or indexed sequential access method (ISAM) database. SQL Server supports ODBC as one of the native APIs for writing C, C++, and Visual Basic applications that communicate with the SQL Server. ODBC enables a database to become an integral part of an application. SQL statements can be incorporated into the application, allowing the application to retrieve and update values from a database. Values from the database can be placed in program variables for manipulation by the application. Conversely, values in program variables can be written to the database. ODBC enables applications to access a variety of data sources, including a wide range of relational databases and local ISAM data. The ODBC driver for SQL Server is included with SQL Server. ODBC defines a call-level interface, or CLI. A CLI is a set of function calls and their associated parameters, which uses a native programming language to call functions; therefore, a CLI requires no extensions to the underlying programming language. This contrasts with an embedded API, such as Embedded SQL, where the API is defined as an extension of the source code for a programming language, and applications using the API must be precompiled in a separate step.

PAGE 26

16 ODBC aligns with the following specification and standard for relational SQL database CLI definitions: The X/Open CAE specification Data Management: SQL Call-Level Interface (CLI) [11] and ISO/IEC 9075-3:1995 (E) Call-Level Interface (SQL/CLI) [11]. SQL Server programs that are written using the ODBC API communicate with SQL Server through C function calls. The SQL Server-specific versions of the ODBC functions are implemented in a SQL Server ODBC driver. The driver passes SQL statements to the SQL Server and returns the results of the statements to the application. ODBC applications are also interoperable with drivers for heterogeneous data sources. 2.3.4 Structured Query Language To work with data in a database, you must use a set of commands and statements (language) defined by the DBMS software. Several different languages can be used with relational databases; the most common is SQL (Structured Query Language). The American National Standards Institute (ANSI) and the International Standards Organization (ISO) define software standards, including standards for the SQL language [12]. SQL Server 2000, used for RTF, supports the Entry Level of SQL-92, the SQL standard published by ANSI and ISO in 1992 [12]. The dialect of SQL supported by Microsoft SQL Server is called Transact-SQL (T-SQL) [12]. Note that “SQL Server” is the name of the database system sold by Microsoft and is very different from “SQL,” which is a database access language standard. The two terms should not be confused with each other.

PAGE 27

17 2.4 Summary This chapter first examined the underlying defects of the existing Teaching File system developed in MS Access. We then discussed the advantages of building the system with SQL Server. We also discussed the design principles to be followed for developing a usable and interactive system. In the next chapter we describe the interface of the RTF by performing a walk through the system.

PAGE 28

CHAPTER 3 RTF USER INTERFACE WALKTHROUGH The preceding chapter discussed the design lifecycle followed to make the application more usable. This chapter discusses the principles to be followed for the presentation of the visual interface and then performs a walk through the system, explaining the concepts used. 3.1 Interface Design Principles There has been much research on the design of user interfaces to make them more useable. The following provides a brief description of some of the principles followed in the development of this user interface. This thesis tries to keep the interface design of the RTF consistent with the specifications given in the User-Centered Requirements Handbook. Some of the main principles followed are detailed in the following subsections. 3.1.1 Simplicity It is necessary to keep the basic interface as simple as possible and offer services that are clear to the user, so that he can use them with little or no help. One common myth associated with designing the interface is “Innovative design is better design. Users prefer software that has creative new methods of presentation” [2]. Users prefer simple interfaces rather than innovative ones. While designing the interface a principle that should be kept in mind is “Don’t complicate the users task” [7]. Common tasks should be made easy to perform, and the users should, through the specification of very little, be able to perform a significant amount of work 18

PAGE 29

19 3.1.2 Consistency The user should feel that he is in control of the system and the system is not dictating his moves. Sequences of actions should generate expected responses, identical terminology and abbreviations should be used throughout the system and prompts should always appear in the same place. Care should be taken to achieve maximum consistency. 3.1.3 Visibility Important elements such as navigational aids should be highly visible. Also elements that perform similar operations should be grouped together and separated from other elements that perform different operations. 3.1.4 Memory Load Making screen elements meaningful and consistent throughout the system reduces the memory load on the user. When the user sees a screen element he should quickly learn what it is supposed to do and should not have to remember it’s meaning from one screen to another. Recognition rather than recall [4] is a principle that identifies humans are better at recognizing items of information presented to them than recalling the same items from memory. This is an important factor to keep in mind when designing the interface. 3.1.5 Error Handling Humans make mistakes and room for handling errors must be provided in the design. Destructive commands such as deleting records should be designed so the user is prompted for confirmation before he performs the operation. We should also try to minimize errors by designing the interface so it avoids situations where the user is likely to make mistakes. Rather than condemning users for what they have done wrong, messages should indicate what needs to be done to set the mistake right. The use of

PAGE 30

20 positive error messages also helps the user in becoming more comfortable with the user interface and thus the system. 3.1.6 Prompts, Labels, Messages, and Feedback The user should always be prompted with sensible messages. The wording of messages is especially important for new inexperienced users. The designer should employ user-centered or task-centered rather than system-centered messages. It is better to communicate to the users in terms of their tasks. Using user-centered messages also suggests that the user is in control of the system initiating more than responding. The user should always be given feedback when he performs an action. He should not be kept in the dark when the processing is being performed on the back end he should always have control over the system. Hence, there should be some useful message or change in the screen indicating what is happening. Also, sequence of actions should be organized into groups with a beginning, middle, and end. Informative feedback given to the user at the completion of an event gives him the satisfaction of accomplishment, a sense of relief, and the confidence to continue to use the system for other operations. 3.1.7 Screen Layout The screen belongs to the user. Densely packed screens overwhelm even experienced users, let alone the novice users. The screen’s layout should give an appearance of clarity with sufficient space separating items. Items on the screen should be grouped together in a logical and consistent order. Groups can be surrounded by boxes or can be separated by spaces. Displays should be kept as simple as possible and the user should not be required to “carry-over” information from one screen to another. Also when the user changes some information on the screen, care must be taken to keep most of the other items unchanged. This feature is called “display inertia”[7].

PAGE 31

21 3.1.8 Shortcuts Shortcuts should be provided wherever possible. They increase the interaction process. As the frequency of use grows, so does the desire to reduce the number of interactions. Thus shortcuts are especially useful for experienced users, since they are familiar with the sequence of steps for the operation. However, care should be taken that the shortcuts do not confuse the inexperienced users. 3.2 RTF Walkthrough We now perform a screen-by-screen walkthrough and explain the features of the RTF through the process. As mentioned in the earlier chapters, RTF has three types of users (Contributors, Administrators, and a General Browser) with each user having a different set of operations available. Hence, the visual interface is developed taking into account the user’s role in the system. The first screen that the user encounters is the login screen shown in Figure 3-1. This screen is simple, thus immediately putting the user at ease when he first accesses the system. The login page is a page common to all the users and its default setting is for a first time user or a guest who may just want to browse through the system. A guest does not need a login name or password to enter the system, hence the login name is already filled in for the user. If the user is indeed a guest he can just hit the enter key which directs him to the search options page. In this manner a simple task is made simple for the user. A friendly message is also displayed on the screen to let the first time users know what they are supposed to do to access the system. If the user is a contributor or an administrator he enters his corresponding login name and password to enter the system.

PAGE 32

22 Figure 3-1. Login screen 3.2.1 Contributor Functions In this system a user may have more than one role ( i.e., he may be a contributor and an administrator). When a contributor who is also an administrator enters his login name and password on the login screen, he sees the screen shown in Figure 3-2. The various roles for a user are stored in the database. The system intelligently identifies the various roles of the user and lists them on the screen. The user can then select the mode he wishes to use for this login. In this way the user has flexibility in his use of the system. After deciding his role the user can access the screen associated with the role by following the hyperlink. The user can always come back later to switch his role to a different one thus giving him the flexibility of operation.

PAGE 33

23 Figure 3-2. Contributor can select his role in the system On choosing the contributor’s role, he sees the screen as shown in Figure 3-3. Most pages are divided into two sections: the head and the body. The head has buttons that are common to all pages such as Home, Logout, and the Quit. The positions of these buttons are fixed on all pages. This provides consistency throughout the design and helps the user become familiar and comfortable with the system and its functionalities. The body consists of details regarding the particular page. In Figure 3-3 the contributor is given a menu of operations that he may wish to perform on the system. Menu-selection systems are attractive since they eliminate the need for user training and memorization of complex command sequences [13]. This simplified interaction style reduces the possibility of keying errors. It also structures the task to guide the users.

PAGE 34

24 Figure 3-3. Contributor’s options screen The main functions of the web based RTF as discussed earlier are classified into two broad categories: Case authoring and maintenance Criterion-based case search engine The teaching file is a huge database of important information and maintaining this information is an important task. There are many operations involved before the cases can actually be moved into the teaching file and made available for viewing. Case authoring and maintenance allow the contributor to perform these various operations on the cases before they are stored in an easily retrievable format. The most important operations are discussed below with their corresponding screen views.

PAGE 35

25 3.2.1.1 Moving cases to a TF Many operations are performed on the images and case details before they are actually moved to the teaching file where they become permanent references. The images and related patient information come from the clinical PACS system in a form called the “consult function,” which is then processed and manipulated to extract the images and the patient information. The patient information comes in as a header file that needs to be parsed to extract the important information. The extracted information is then stored in a temporary location. Contributors can log on to the teaching file system to see their cases from the PACS system and select cases to be moved to the RTF. When the case is selected and moved to the TF, it gets deleted from this temporary location. When the user selects the Move cases option, he encounters the screen shown in Figure 3-4. Figure 3-4. First step in moving a case to the Teaching File

PAGE 36

26 Notice that the header of this page is similar to what the user encountered in Figure 3-3 with a few additional options. The buttons common to all the pages retain their position through all pages to maintain consistency [6]. Also the heading “Move Cases Step 1 of 4” gives the user a clear sense of progress or position within the sequence of operations. This informs him about how many more steps are required to complete the operation and helps him decide if he wants to go ahead with the operation or quit. Means for going backwards to earlier choices and possibly to terminate or restart the sequence of operations are also provided through the buttons “Back” and “Quit.” The data is displayed in a tabular form so that it is more readable and simple. Dense or cluttered displays can provoke anger and inconsistent formats can inhibit performance. By presenting too much information on the screen the error rate may increase. This may in turn decrease the productivity of the system. A case normally has significant, associated information, but only the information that is useful to the contributor is displayed on this screen, thus not overwhelming the user by presenting an over crowded screen. A tabular display is used throughout the system thus helping the user feel more in control of the system. A contributor may refer to a case through the patient’s name or the date the diagnosis was performed, making these fields important case identifying attributes. The comment that the contributor entered about the case is also displayed. Another user-centered feature provided by this interface is the facility to allow the contributor to sort the data on the basis of a particular column. The user can sort the data by just clicking on the column name. The user is prompted with a message indicating that he can move to the next step by clicking on a case’s ID. When a particular ID is selected, the user sees the screen shown in Figure 3-5.

PAGE 37

27 Figure 3-5. Images associated with the case to be moved to the Teaching File This page shown in Figure 3-5 follows the consistent division of the header and body format. A case may have several images associated with it. This page displays the images related to the case that the contributor can chose to move to the teaching file. The user is presented with a message at the top “Images for the patient, Patient Name.” This reduces the memory load for the user and he need not remember the patients name from the previous screen. Check boxes are provided for the user to select cases. Shortcuts in the form of buttons “Select All” and “De-Select All” are provided to make the task of selection easy. Each button is labeled to make its use clear to the user. We often see in many web sites, that the counterpart of the “Select All” button is the “Inverse All.” However “Inverse All” has its own meaning in the Radiology world. Hence, the button is labeled “De-Select All” making the labeling consistent with the users perception. Removing any confusion from the available buttons makes the software more usable and

PAGE 38

28 enjoyable. The placement of these buttons is also important in that they should be visible to the user from any part of the screen. Hence they are provided at the top and bottom of the page. Buttons that affect the entire dialog box should be distinguished from those that control specific data or settings in it [7]. Hence the “Select-All” and “De-SelectAll” buttons are separated from the “Submit” button. The user can quit from this application at any time by clicking on the “Quit” button. A “CancelOperation” button is also provided for the user so that he can quit the operation without going any further. He can also go back to the previous screen and select a different a case by clicking on the “Back” button. Once the user selects the required images for the particular case, he clicks on the “submit” button and is then taken to the screen shown in Figure 3-6. Figure 3-6. Patient and case details page while moving the case to the Teaching File

PAGE 39

29 The screen in Figure 3-6 has most of the information obtained from the case. The screen is organized with much thought and careful understanding of the various components to be displayed. The data is grouped into three groups: the left upper section displays the user’s personal information such as name, age, sex, etc.; the right upper section displays the contributor information related to the case; and the lower section displays information related to the case including Diagnosis, Chief Complaint, General comments, etc. The consult function provides some of this information when the case comes from the PACS system, with the contributor enters the rest of the information. The contributor also has the option of making his case private (i.e., visible only to him). This layout of the screen is maintained in all the other pages where the case related information needs to be displayed, thus keeping the view consistent. Finally after furnishing the required information, the user is ready to submit the information. With the user’s confirmation, the case and its corresponding images are moved to the teaching file and a successful message is displayed to the user. A “CancelOperation” button is also provided at the bottom of the screen, which allows the user to quit the operation. 3.2.1.2 Edit cases A contributor may at any point of time edit any of the cases that he added. When he selects the edit case option, he is presented with the screen shown in Figure 3-7. This screen is similar to the first screen encountered in the “Move Cases to TF” option. This tabular view as mentioned earlier is maintained throughout the system for the sake of consistency. The user can select the case for editing by clicking on the corresponding case’s ID. By maintaining the same way a case is selected, the memory load on the user is reduced.

PAGE 40

30 Figure 3-7. The user is presented with a list of cases to select from for editing. Frequent users are able to move through the system much faster while inexperienced users find this feature helpful in obtaining familiarity with the system. When the user selects a case he encounters the screen shown in Figure 3-8. In this page all the fields of the patient and his related case are displayed. Note that this page has used text boxes for selected fields rather than all fields, thus preventing its overuse. Text fields are primarily used for data that are unstructured, free form text. The ACR code field, instead of using a single unstructured text field, uses multiple text fields corresponding to the parts of the code. This eliminates the need for users to include special separating characters thus reducing syntax errors.

PAGE 41

31 Figure 3-8. Edit Case screen The ACR code is a code developed by the American College of Radiology, which is assigned to every case. It consists of two parts: the Anatomic code, which represents the anatomical location of the image, and the Pathologic code, representing the pathology. An example of such a code is 123.12, which describe the skull and contents, and in particular the base of the skull. The display separates the anatomic code from the pathologic code with a period. The user can view and edit the images associated with the case through the edit images option provided on the screen. The user is presented with a screen shown in Figure 3-9 when he wants to edit images.

PAGE 42

32 Figure 3-9. Edit Images screen This page is divided into two sections: one that displays the image and the other displays the corresponding textual information associated with the image. There is a set of navigational buttons displayed below the image. The application also displays the current image number and the total number of images associated with the case. This gives the user an idea about where he is in the application and gives an impression of responsiveness. While viewing the first image of the case, the first and previous buttons are deactivated and when the user views the last image the next button is deactivated, thus preventing any errors. Graying out choices when they are not available is a way to prevent errors from occurring in the system, reducing loss of productivity and making the system more useable [5]. The user can perform various modifications on the images. He can replace them, delete them, or add more images to the case. He can also change the

PAGE 43

33 annotations associated with the image. At any point of time the user can go back to the textual report associated with the case by clicking on the Back button. 3.2.1.3 View my cases When the user selects this option he sees the screen shown in Figure 3-10. The system provides the user with two viewing modes: a simple textual view mode and a detailed display mode. The user can set his preferred mode of viewing, which is stored in his profile. The next time the user logs on the system he views the cases in his preferred mode. Figure 3-10. View Cases screen 1 The user is also provided with the option of changing his preferences. When the user selects a case for viewing, the system first checks his settings and accordingly displays the screen shown in Figure 3-11 or Figure 3-13.

PAGE 44

34 Figure 3-11. Text mode of viewing cases Figure 3-11 shows the simple text mode of display, which is a read only display, just presenting all the information. Many applications abuse the text fields by using them for read-only data. Here the various fields are non editable and are present only for display purposes. They are non-editable and hence are not enclosed in a black box and look similar to a label [7]. The images associated with the case are presented to the user as shown in Figure 3-12, when he follows the link for displaying the images.

PAGE 45

35 Figure 3-12. Viewing the images associated with the case This display is kept very simple and is similar to the image display screen encountered earlier. The right side of the display contains the case number and the number of images while the left side contains an image. The navigational framework is provided below the images. The user can always go back to the text/detailed display of the case by clicking on the Back button. The user is provided with the option of changing his viewing mode at the bottom of the report screen. This provides the feature of customizability in the system, allowing the user to view the interface of his choice. The screen presented to the user when he changes his view preference is shown in Figure 3-13.

PAGE 46

36 Figure 3-13. Detailed display mode. The simple textual mode of this display gives a precise summary of the case. This display has a more detailed description of the various fields. The user is provided with the option of finding another specific case for viewing. The interface screens discussed above are similar for most of the other operations of the contributor. 3.2.2 Administrator Functions The administrator has the responsibility of the overall maintenance of the RTF. He performs various bookkeeping operations on the database (e.g., deleting orphan files, deleting very old cases from the incoming database, etc.) to always maintain the Teaching File database in a simple and consistent form. The administrator logs in to the

PAGE 47

37 system through the login page as discussed earlier and the first page he encounters after logging on to the system is the screen shown in Figure 3-14. Figure 3-14. Administrator options screen 3.2.2.1 Deleting excess PACS images The number of submissions to the system is very high and the size of the incoming table where they are stored becomes very large. The size of the temporary directory where the incoming images are stored also increases. To keep the size of this incoming table under control, there is a necessity to sometimes run maintenance operations against the database that delete the oldest files, which have never been moved to the Teaching File. When the administrator selects this delete option, he is presented with the screen as shown in Figure 3-15.

PAGE 48

38 Figure 3-15. Screen to delete the excess PACS images The results are presented in a tabular form with the oldest files being displayed. The number of image files within each group is also displayed to identify to the user the number of images associated with the particular case. The user can either delete all the files at once or view the images associated with the case and then delete the necessary images. The administrator can delete the files, which are more than a month old. In this way he can delete the files that are very old and hence keep the size of the table under control. Each case is associated with a number of images. When the user decides to view the images before he actually deletes them, he sees the screen shown in Figure 3-16. He can either select all the images or just a few of them to be deleted.

PAGE 49

39 Figure 3-16. Select images to be deleted Earlier the contributor was provided with a similar screen while moving the cases to the Teaching File. In a system where a user can have multiple roles, presenting a similar screen for different operations, helps make the user feel comfortable and familiar with the interface. The user can select the required images to be deleted from the system and submit the operation. After confirming with the user, the corresponding images and records are deleted from the incoming table and the user is presented with the screen shown in Figure 3-17, indicating the operation was completed successfully. A “CancelOperation” button is also provided in case the administrator decides not to go ahead with the delete operation.

PAGE 50

40 Figure 3-17. This screen indicates the successful completion of the delete operation The other operations performed by the administrator are similar to those performed by the contributor and hence the interface is also similar. By providing an easy to understand and use interface, the overall job of the administrator is simplified. 3.2.3 General User Functions A web based search engine called WebSE has been built for the RTF that can process queries against the database and perform quick and efficient searches on the cases. Mr. Shriram Lakshmi as part of his Master’s Thesis built the search engine, while the interface was designed and developed as a part of the RTF on the whole. The search engine offers a wide range of search options to the user, right from a very simple “free-text search” to a more complex “advanced search [14]. When a normal browser logs onto the system, he is presented with a screen as shown in Figure 3-18.

PAGE 51

41 Figure 3-18. Basic search screen 3.2.3.1 Free text search The user is presented with an interface, which is very similar to that of the “Google” engine. Providing such a familiar interface makes the search engine easy to use and thus ideal for the medical community. The user just enters the search phrase in the textbox provided. Some of the important fields the user may want to query the database against are disease name, diagnosis, and chief complaint. The screen also provides the user with the option of performing the complex advanced search. There may be times when the user may want to hide the diagnosis in the results displayed. This option is also provided to the user. When the user enters his search string in the text box, he is presented with the search results as shown in Figure 3-19.

PAGE 52

42 Figure 3-19. Screen displaying the search results The results are displayed in a very concise and summarized manner, providing the most important information to the user in an easy to understand format. The user can also

PAGE 53

43 have a detailed view of the case by following the link “view case details” as shown in Figure 3-20. Figure 3-20. Detailed Case view This view provides a more detailed description of the case. This page is also similar to the detailed text view presented to the contributor in the earlier section, thus maintaining consistency throughout the system [15]. The user can always go back to the search page by following the link provided. A hyperlink to the images associated with the case is provided and the images are viewed as shown in Figure 3-21.

PAGE 54

44 Figure 3-21. Screen displaying the images associated with the case. The navigational buttons are provided at the bottom of the screen. The unnecessary buttons are grayed out in order to prevent any errors from occurring in the system. The user can either return to the entire case results page or the detailed text view by following the links “Back to Search Page” or “View Case Details” respectively. 3.2.3.2 Advanced complex search The user has the option of performing a more complex search on the RTF. In Figure 3-20, when the user selects the advanced search option, he sees the screen shown in Figure 3-22.

PAGE 55

45 Figure 3-22. Advanced Search screen Sometimes the user may want to build and run a more complex query against the database. He may wish to specify a more specific criterion in the search query. For example, he may wish to find all cases that represent a particular disorder found in infants, which were added by a particular contributor. In such cases a simple free text search would not be enough, hence the need for a more complex query. The interface provided is very simple and the results of the search are presented in the same manner discussed above. 3.3 Summary This interface has been designed keeping in mind many factors such as its users and the environment in which they function. The use of a simple and consistent interface throughout the system helps the contributor concentrate on the task at hand and not be

PAGE 56

46 overwhelmed by the interface. This interface has many positive features like ease of learning, lower error rate, and user satisfaction, which makes it useable. The next chapter discusses on the processing that occurs beneath the interface. It examines the database design and implementation of the various operations.

PAGE 57

CHAPTER 4 INSIDE RTF For the RTF to do its tasks and be useable from the physician’s point of view, it must be provided with the necessary data in the correct format. The case authoring and maintenance, as discussed in Chapter 2 and Chapter 3, allow operations to be performed on the data so that they can be stored in an easily retrievable format. This chapter provides a detailed explanation of the design and implementation of the various functionalities. 4.1 Main Database Design For any database driven project to be successful, the underlying database design needs to be sound. The RTF has a number of tables, of significant relevance within the database. Contributors select the images they wish to add to the RTF while reading a case. These images are automatically sent to a table called Incoming_Images with the patient information attached. The contributors then use the teaching file application to move the cases selected for permanent reference into the Teaching File. Figure 4-1 shows the essence of the database design. It shows the main database tables and the relationships existing between them. A brief description of the significance of the main tables and their fields is given below. 4.1.1 Incoming_Images Table A case selected by a contributor enters from the PACS system as a header text file and the corresponding image file, which are stored in a temporary header and images directory, respectively. 47

PAGE 58

48 Figure 4-1. Main tables in the database For example, the header file associated with a particular case is of the form 2.16.124.113531.4.6.1013118135.13740.txt and the corresponding image file is 2.16.124.113531.4.6.1013118135.13740.gif. More than one image may be associated with a case. The Profiles table stores the incoming header and images directory name. The header file contains details about the case such as patient name, date of birth, sex, hospital number where the case was processed, the date on which the case was processed, etc. The relevant information is extracted from this header file and is stored in the table. Apart from the personal information, the other details extracted from the header file are discussed below. Group_ID: A case may have many associated images. This group_id, which is a unique number to each case, identifies the case to which the images belong.

PAGE 59

49 Image_ID: Every image is identified uniquely through its image_id. This is a function of the group_id, hospital_number, and image_number. Incoming_header_name: This field stores the name of the header file. Image_number: Since a case can consist of more than one image, this field identifies the ordering among the images. The Incoming_Images table does not store the images that come from the PACS system, instead it contains pointers to the locations where these images are stored. The header file and the images file have the same name and only vary in their extension. Since the Profile table stores the incoming images directory name and Incoming_Images table stores the incoming header name, these two pieces of information can be used to access the actual image file. 4.1.2 Teaching File (TF) Table When the case arrives from the PACS system, it initially is stored in the Incoming_Images table. Later, when a contributor logs on to the Teaching File application, he can move the required cases of importance from the Incoming_Images table into the Teaching File table, where they become permanent references. The cases in the Incoming_Images table are referenced with their Group_Id and when they get moved to the TF, they are assigned a unique case_number with which they are identified thereafter. The Incoming_Images table is thus just a temporary table holding the cases, and the corresponding case entry is deleted from this table when it is moved to the TF table. The TF table is an important table of the database, holding the data related to the cases. The information such as the chief complaint, diagnosis, ACR code for the case etc is stored in this table. The image information and other details about the patient and

PAGE 60

50 hospital etc. are stored in separate tables. There exists one tuple in this table for each case. Case_Number: This is a unique number assigned to every case in the teaching file. This is the primary key for the table. All cases are referenced internally using the case number. Patient_id: Every patient is assigned a unique identification code called the patient_id. The patient related information is stored in the Patient_Info table. This key connects the two tables, TF and Patient_Info. Age: This is the age of the patient in days. Since patients can include infants, whose age can only be expressed in days, all ages are stored in days. This value is divided by 365 to determine an approximate age for all other patients. Sex_Male: This field stores the gender of the patient by identifying whether the patient is male. Anatomic_Code: Every case is assigned a unique ACR code, which was developed by the American College of Radiology. The ACR code consists of two parts where the first part is the Anatomic_code, which represents the anatomy. Pathologic_Code: This is the second part of the ACR code, which represents the pathology of the case. Diagnosis: This field represents the final diagnosis of the case. Chief_Complaint: This represents the main complaint or symptoms associated with the case. The contributor is allowed to enter all the symptoms associated with this case in this field. Comment: A contributor can add specific comments about the case and its associated images. Contributor: Contributors add cases to the teaching file collection. The system contains a list of valid contributors where this field represents the id of the contributor who added the case to the collection. Imag_Anon: This field holds the image-anonymous status, which indicates if the image has any patient information associated with it. Sometime when the images come from the PACS system, the name of the patient may be embedded within the image. When displaying images in the public domain it is very important to protect the privacy of patient data and this field is used to protect the same. Hxno: This is an id code for the hospital in which this case occurred. The actual hospital details are stored in another table.

PAGE 61

51 Private: Whenever a contributor adds a case to the teaching file, he has the option of making the case private or public by setting this field. If the case is public all contributors can view it, while if it is private only the contributor who added it can view it. 4.1.3 Images Table Every case has one or more associated images. This table stores information related to the images for all the cases. The fields of this table are: Case_Number: This is the unique id of the case. This key has a foreign key constraint and references the Teaching File table’s case_number field. Modality: Every medical image has an associated modality. Examples of image modality are X-ray, MRI (Magnetic resonance imaging), MAM (Mammography), etc. Image_Annot: A contributor may annotate the image when adding/editing them. This field represents the annotation associated with the image. Orig_Image_Loc: This is the full network path of the image before it was added to the teaching file. Image_Dir: Whenever a case is added to the teaching file, the images associated with the case are stored in separate directories. The database just holds pointers to these locations and not the images themselves. This field represents the physical directory location where the image is stored. Image_File_Name: The current name of the image file. Image _Number: Each case can consist of more than one image. This field identifies the order of the images by specifying this image’s position in the case’s set of images. The Teaching File table and the Images table are the most important tables related to the case and corresponding image information. They are manipulated and searched most frequently. Additional information is stored in the other associated tables. A brief description of these tables follows.

PAGE 62

52 4.1.4 Other Tables 4.1.4.1 Contributors This table holds information about all of the contributors. The contributors are physicians who have permission to add, delete, and modify cases in the RTF. This table contains information regarding their login, password, name, and their type of permissions for accessing the teaching file. It also stores the profile settings for a particular contributor. The profile indicates the contributors mode of preference for viewing cases that will be used in the display of cases. 4.1.4.2 Patient_Info This table holds the patient’s personal information like Last name, First name, etc. This table is not publicly accessible due to physician-patient confidentiality. The contributors within the hospital may, however, access to this information. 4.1.4.3 Date_Info This table stores the date related information including the date when the case was entered, information about how the diagnosis was confirmed, etc. A case diagnosis can be confirmed through surgical findings, autopsy, etc. 4.1.4.4 Modalities Every image has an associated modality. Medical images can be of different types and the type is called its modality. Image modalities include X-Ray, MRI, etc. This lookup table has two fields, the modality abbreviation and its description and lists the available and commonly known modalities. The administrator can add new values to this table.

PAGE 63

53 4.1.4.5 Hospital_Info This table holds hospital information. Currently, only the hospital name is present in this table, since only that was thought necessary, but it can be extended to hold any additional information about the hospitals. 4.1.4.6 Profile This table holds information identifying the locations where the case images are stored. In this current implementation the images are not stored within the database but rather in a set of directories. The database holds pointers to the physical locations of these directories. There is a limit on the number of images that are stored in the directory. When the number of images exceeds the threshold, the new images are stored in a new directory. It holds the name of the current directory where the images need to be stored and the count of the images in the directory. When cases are moved from the Incoming_Images table to the Teaching File table, the images are moved from the incoming images temporary directory to the permanent directory, whose location is obtained from this table. This table also holds the name of the incoming header directory and the incoming image directory. This table is a stand-alone table and is not linked to any other table. However the information stored in this table is used for accessing and manipulating the directory where the images finally get stored. 4.2 Contributor Functions The contributor is the most important user of the RTF, since he is involved with authoring and maintaining the different cases that compose the teaching file. He is presented with many options to perform various operations on the database as seen in the

PAGE 64

54 previous chapter. A brief description of the design and implementation of his most important tasks is provided below. 4.2.1 Moving Cases to a TF Cases that come from the PACS system consists of the header file and the images file. The header files are stored in a temporary incoming header directory and the images are stored in the incoming images directory. The header file contains information about the case, which must be parsed to place it in a readable format. A large number of header files are submitted on a normal day, so they need to be parsed frequently to retrieve the important case related information. A script, written using Windows Scripting Host, parses the header file, stores the related information in the Incoming_Images table, and then deletes the header file from the temporary directory. The frequency with which this script executes is set based on the number of incoming files. Once the data are in the Incoming_images table, the contributor can log on to the application and move any of their cases to the permanent RTF. While moving a case to the teaching file, the contributor can either select all the images or specific images to be moved. The images are moved from their temporary location to their new permanent directories whose location is obtained from the Profiles table. Whenever an image directory’s size reaches its threshold, a new directory is created and new images are stored there. As mentioned earlier the database does not hold the images themselves but instead holds pointers to their physical location. The contributor can also add specific comments about the case before moving it into the RTF. Most of the information is obtained from the Incoming_Images table and is presented to the user through a series of forms. Through these forms, the users can provide additional information about the case, which is stored as variables in the ASP file. When the user finally submits the form, the script (present in

PAGE 65

55 the ASP file) establishes a connection with the Teaching File database using an ODBC connection. An SQL query is constructed with the variables to insert records into the TF and other tables. This query is sent over the ODBC bridge to the SQL Server. The SQL Server executes the query and returns the results over the ODBC connection to the asp file. The tables affected in this process are the TF, Images, Patient_Info, Date_Info Profile, and the Incoming_Images. The results are wrapped in HTML and returned to the user’s browser indicating that the file was successfully moved from the incoming database to the RTF. When the case is finally moved to the TF table, the corresponding case in the Incoming_Images table is deleted. 4.2.2 Adding Cases to a TF Adding cases is very similar to moving cases except this allows the contributor to add a case from an external source (i.e., the case with a unique finding from a non-PACS system at some other hospital or university). The user enters most of the information on the form (discussed in the previous chapter) since this case is from an outside source and the information cannot be entered automatically. Once the user submits the case, the query string is built as mentioned earlier and the ASP file sends it across the ODBC bridge to the SQL Server for execution. The results are sent back, wrapped in HTML and displayed to the user. 4.2.3 View Cases A contributor, at any given time, may want to view the cases that he added to the Teaching File. The contributor has the choice of viewing his cases in a normal text mode or in a detailed display mode. He can set his preferences so that the next time he logs on to the system he views the cases in his preferred mode. When the contributor selects the view cases option, a query string is built using the contributor’s id and his profile setting.

PAGE 66

56 This query is sent over the ODBC bridge to the SQL Server, which executes the query and returns the results as a set of records to the ASP file. The results are wrapped in HTML and sent back to the user’s browser for display in a tabular form. The user can then select the particular case for viewing. The contributor can perform many other operations like deleting cases, viewing others cases, etc. The design and implementation for these functionalities is almost identical to the options discussed above. 4.3 Administrator Functions The administrator has the responsibility of overseeing all maintenance of the RTF. Several scripts have been written for performing administrative functions. Very old cases in the Incoming_Images table, may not have been moved to the TF. Because of their age, these cases are unlikely to be moved into the TF in the future. A script is provided for the administrator to run, to delete these old files from the incoming database. Cases arriving from the PACS system normally consist of a pair of files, the header and the image files. If, through some error, only one of these files arrives at the system, orphans will exist that can never be moved to the TF. If the corresponding image file is not found when parsing the header file, the header file is moved to a separate directory of bad header that can be deleted later. The administrator also runs a script to check for orphan images (image files without headers) that are deleted if found. The administrator also has permission to add new contributors to the system, modify internal profiles tables according to the search criterion, and so on. In the search engine of the RTF, the search results view is customizable by the administrator. A few parameters can be set or unset by the administrator, thus changing the default behavior of the search results view.

PAGE 67

57 4.4 Summary and What Is Next We first looked at the database structure of RTF and then examined how the data is processed to provide a useable interface to the user. The next chapter presents conclusions about this research. It also discusses future improvements to make the RTF more robust and useable for the Radiology community.

PAGE 68

CHAPTER 5 FUTURE WORK AND CONCLUSIONS This thesis examined the user interface design for the Radiology Teaching File. The aim was to create a useable interface so that it could provide academic help to the medical community. Chapter 1 discusses the problem domain and introduces the RTF. Chapter 2 discusses the existing system and its drawbacks. It also discusses the design principles to be followed in developing a useable interface. Chapter 3 then discusses the visual interface principles followed in the design of the interface and looks at the interface of RTF by performing a walkthrough of the application. Chapter 4 discusses the RTF’s inner workings. The rest of this chapter summarizes the RTF as a whole and examines future extensions that are possible. 5.1 Overview of RTF In this thesis RTF was described in terms of its interface considerations and its system functionality. It is very important that the interface be closely linked with the system functionalities. When more importance is given to the system and the interface is built on top of the system, as is done in a system centered design approach, the interface will most probably not conform to the needs of the user. Such interfaces require significant effort from the users, and many users often experience much anxiety and frustration. To overcome the drawbacks associated with this approach, the development of the RTF followed a user-centered design, where the design is collaboration between the designers and the users. The design evolves and adapts to the users changing concerns and the user and designer are in constant communication. 58

PAGE 69

59 The main purpose the RTF is to allow radiologists to store and organize images with interesting findings for later use in teaching, research, and reference during clinical work. The important tasks associated with the RTF include the case authoring and maintenance and the criterion based search engine. By providing a uniform interface that has a same look-and-feel for most of the functionalities, the RTF interface helps the user achieve these tasks with ease and success. Making the case based search engine’s interface similar to the “Google” interface, helps the user feel familiar and comfortable with the system and, hence, use it to its full potential. 5.2 Extensions of RTF The RTF has a few aspects that could be extended to make it a more effective application. A good user interface is both uniform and customizable. The RTF has been designed to be a uniform and consistent application, providing the same look in most of its functionalities. A customizable interface allows the user to change the manner in which he or she interacts with the application [16]. Customizability is an important feature in the usefulness of the application, since it helps the user to teach the application the manner in which the user wants to use it. A customizable interface adapts to the needs of a user. For a system to be adaptive, simple memorization of the user’s interaction does not suffice. The previous experiences of the user should be generalized and these should then be applied to the new user interactions. This is a vast area of research in the field of human computer interaction. A few customizable features were built into the RTF. The mode of viewing the cases is a customizable feature in this application, where the user can set his default view to a simple text mode or a detailed mode of viewing. Customizability is a relatively tougher feature to achieve and it can be further studied and applied to the RTF to make it truly uniform and customizable.

PAGE 70

60 5.3 Summary The design of software is increasingly important in all professions including the medical community. Improved interface design increases the users successful experiences and positive attitudes. A good design arises when the designer understands the people as well as the technology. The quality of the software must be evaluated from the users point of view, by taking into account the people who will be using it. Usability is an important factor in judging the quality of the interface and the user centered design methodology aims at making the software more useable. The interface for the RTF was designed and developed keeping these factors in mind. The aim was to develop an easy to use interface that could serve its purpose in the medical community.

PAGE 71

LIST OF REFERENCES 1. Shniederman B. Designing information-abundant web sites: issues and recommendations. International Journal of Human-Computer Studies, vol. 47, pages 5-29, 1997. 2. Smith P. Debunking the myths of UI design. 2001. IBM. http://www106.ibm.com/developerworks/library/us-myth.html . Visited May 2002. 3. Chang SK. Handbook of Software Engineering and Knowledge Engineering. River Edge, New Jersey: World Scientific Publishing; 2001. 4. Redmond-Pyle D, Moore A. Graphical User Interface Design and Evaluation— A Practical Process. Hertfordshire, UK: Prentice Hall; 1995. 5. Hix D, Hartson HR. Developing User Interfaces: Ensuring Usability Through Product and Processes. Portland, Oregon: John Wiley and Sons; 1993. 6. Maguire CM. User-Centered Requirements Handbook. Version 3.2, 29 June 1998. European Journal of Engineering for Information Society Applications. http://www/eieisa.com/nectar/respect/5.3/a.htm . Visited April 2002 7 Johnson J. GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers. San Francisco, California: Morgan Kaufmann Publishers; 2000. 8. Farnum C. What an ia should know about prototypes for user testing. 2002. Boxes and Arrows. http://www.boxesandarrows.com/archives/what_an_ia_should_know_about_protot ypes_for_user_testing.php . Visited July 2002 9. Lomax P, Childs M, Petrusha R. VbScript in a Nutshell: A Desktop Quick Reference. Roseville, California: O’Reilly and Associates; 2000. 10. Mitchell S. Designing Active Server Pages. California: O’Reilly and Associates; 2000. 11. Microsoft ODBC, Universal Data Access Website. Microsoft. http://www.microsoft.com/data/odbc/default.htm . Visited November 2001. 12. Vieira R. Professional SQL Server 2000 Programming. Edison, New Jersey: Wrox Press; 2000. 61

PAGE 72

62 13. Shneiderman B. Designing the User Interface: Strategies for Effective Human-Computer Interaction. Portland, Oregon: Addison-Wesley; 1987. 14. Lakshmi S. Web-Based Search Engine For Radiology Teaching File. Master’s thesis, December 2002. University of Florida, Gainesville; 2002. 15. Truchard A, Katz-Haas R. Ten guidelines for user-centered web design. July 1998. Society for Technical Communication. http://www.stcsig.org/usability/newsletter/9807-webguide.html . Visited Aug 2002. 16. Kuhn MB, Binkley WD. In search of a customizable user interface. 1994. ACM Crossroads, Student Magazine. http://www.acm.org/crossroads/xrds1-2/ecl.html . Visited September 2002.

PAGE 73

BIOGRAPHICAL SKETCH Aarathi Balakrishnan was born in Wellington Island, Tamil Nadu, India on May 8 th 1978. She has lived in Chennai, Tamil Nadu for most of her life. She graduated from the University of Madras in 2000 and received her bachelor’s degree in computer science and engineering. She earned her master’s degree in computer and information science and engineering at the University of Florida in May 2003. Aarathi was a graduate teaching assistant at the University of Florida, for four semesters for the two courses “Data Structures and Algorithms in Java” and “Programming in C”. She currently works as a programmer for the University of Florida McTrans Center, where she is involved in developing a new module within the Highway Capacity Software. 63