Project Design Report

Automated Medical Patient’s Evaluation System

Project Design Report

dec01-03

April 17, 2001

Client:

Dr. David Carlyle

Faculty Advisors:

Dr. John Lamont

Dr. Ralph E. Patterson III

Team Members:

William Chan

Chau-Meng Gan

Lucas Fisher

Onome Ufomata

Table of Contents

List of Figures

List of Tables

Abstract

Definition of Terms

Acknowledgements

Introduction

General Background

Technical Problem

Operating Environment

Intended Users and Uses

Assumptions and Limitations

Design Requirements

Design Objectives

Functional Requirements

Authentication

User Interface Look and Feel

Recording a Patient Visit

Output

Illness Templates

Design Constraints

Measurable Milestones

End Product Description

Technical Approach and Design

Patient Evaluation Program

User Interface

Authentication

Output

Illness Templates

Administration Software

User Interface

User Management

Print Settings

Testing

General User Interface Tests

Navigation Bar Tests

Administration Program Tests

Risk and Risk Management

Recommendation for Continued Work

Financial Budget

Personal Effort Budget

Project Schedule

Project Team Information

Faculty Advisors

Client

Team Members

Summary

List of Figures

Figure 1 - Process of creating a visit record with the patient evaluation program......

Figure 2 - Login Screen......

Figure 3 - Patient Id screen......

Figure 4 - Illness List Screen......

Figure 5 - Edit Illness Screen......

Figure 6 - Done Screen......

Figure 7 - Sample patient visit record printout......

Figure 8 - Subjective section of template......

Figure 9 - Objective section of template......

Figure 10 - Objective section of template......

Figure 11 - Objective and Plan sections of template......

Figure 12 - Administration Program User Interface......

Figure 13 - Original Gantt Chart......

Figure 14 - Revised Gantt Chart......

List of Tables

Table 1 - Estimated Financial Costs......

Table 2 - Original Personnel EfforBudget......

Table 3 - Revised Personnel Effort Budget......

Abstract

A typical day in a clinic involves scheduling patient visits, admitting patients for doctor examinations, scheduling, recommending tests and medication, and recording these events for future reference. More often than not, the same illnesses are diagnosed over and over again for different patients, as many illnesses are seasonal in occurrence. Having to write the same descriptions of symptoms and illnesses time and time again becomes inefficient and time consuming. Often, the efficiency of a clinic is highly dependent on the efficiency of the patient visit and recording process.

The primary aim of the Automated Medical Evaluation System is to reduce the time between an examination and when the report gets filed in the patient’s folder. The Automated Medical Evaluation System also aims to make this process more efficient and reliable by using a computer to collect the patient’s health data, provide standard responses to various illnesses, provide a standard output format for the patient’s visit record, and make the recording process concurrent with the examination.

This system is currently suited to meet the requirements of the McFarland clinic in Ames, Iowa.

Definition of Terms

Database: Software that stores and organizes data for easy searching and retrieval.
Local area network: Links computers and printers in the same building or area.
Prototype: Initial product that exhibits the essential features of the final product.
Touchscreen: Computer monitor that also acts as an input device by positioning the cursor or mouse at the location of the user’s touch.
Visual Basic: Programming language developed by Microsoft that has extensive graphical capabilities necessary to develop a user interface for this project.

Acknowledgements

With our current schedules and deadlines, it would be a most challenging task for the project team to completely and accurately accomplish the requirements of this project. The following individuals are actively involved in ensuring that this project is a success.

Dr. David Carlyle, McFarland Clinic, Ames, IA -- Client and sponsor of the project.
Prof. Lamont and Prof. Patterson -- Project overview and guidance. Project team advisors.

Introduction

General Background

The Automated Medical Evaluation System involves developing software to record daily patient visits. Doctors will use it when examining patients to record their diagnosis of the patient’s situation and also prescribe any treatments necessary. The automated system developed is specifically suited to meet the requirements of the McFarland clinic in Ames, Iowa.

The current system used at McFarland clinic involves the doctor writing down his diagnosis of the patient during the examination. Later in the day, the doctor’s notes are voice recorded using a tape recorder. Recordings are later typed by a hired assistant, printed, and filed in the patient’s folder. This whole process (between the examination and filing the patient record) usually takes several days.

This project aims to improve the speed and reliability of the recording process by fully automating the patient visit record process. When a patient is admitted to the examination room, the nurse would enter the patient’s name, gender and birth date into the software. The doctor then examines the patient. During the examination, the doctor can select the diagnosed illness from the software and automatically, templates describing the illness will be displayed. The doctor completes these templates and automatically a description of the illness and prescribed treatments are generated. The output is previewed and sent electronically to the front desk where it is printed and filed in the patient’s folder. The software will be user-friendly to allow easy and flexible maneuvering by the clients. It will have a relatively simple user interface that intuitively guides the user through the software.

With the Automated Medical Evaluation System, a standard format for the patient visit record will be developed. With the current system, different doctors may have different ways of recording diagnoses so different doctors will produce different visit records. The automated system developed would standardize not only the recording process, but also the output format.

Technical Problem

The Automated Medical Evaluation System is required to work with the touch screen monitors in the examination rooms at McFarland clinic. The software will also have to work with other standard forms of input such as the keyboard and mouse, as it would also be installed on personal computers in Doctors’ offices.

This software will be developed for standard Microsoft Windows based PCs using Microsoft Visual Basic.

This system must have some form of authentication for entry due to the sensitive nature of medical records. This authentication will also serve to identify the doctor that created a particular patient record. With this, the software will have to manage users and user information such as passwords and electronic signatures used to validate the records.

The user interface must provide entry capability for all pertinent examination information for each illness. The software will also provide an interface for possible future expansion of illnesses handled by the system.

The software will electronically send patient visit records to the front desk or a printer for printing and filing. Records will be printed on labels that are later stuck to forms in the patient’s medical file. The output will have to be formatted to fit on the labels.

Operating Environment

The software will be installed on Microsoft Windows-based computers in examination rooms and doctors’ offices at McFarland clinic. Some of these systems will be equipped with touchscreen displays.

The software will have to take into consideration that patients might have access to the system while waiting in the examination room for a doctor. Patient access will have to be prevented.

Intended Users and Uses

The intended users will naturally be medical personnel, such as doctors and nurses that examine patients at the clinic. Currently, this software targets the requirements of the McFarland Clinic in Ames, Iowa. Dr. David Carlyle, a doctor at McFarland Clinic, is the main client of this project. Other doctors at McFarland Clinic may use the software to record patient visits, also.

Other staff at the clinic may use the software to enter patient names, update illness lists, and illness descriptions as required by clinic operations.

Assumptions and Limitations

The main assumptions made in this project are:

The clients of this software will supply a list of illnesses, and their descriptions and treatments.
All computers running this software will have Microsoft Windows-based operating systems.
A local area network connection to a central printer is available.
The touchscreen driver software emulates a mouse.
Users have some basic knowledge on the operation of computers and software use.
Touchscreens and all other required hardware are provided and maintained by the client.

Limitations to the development of this project include:

Project team members have no previous experience with Visual Basic programming.
Touchscreen input accuracy defines how user interface items such as buttons and scrollbars are designed.
Touchscreens in examination rooms at McFarland clinic have six by eight inches of viewable area. This size greatly restricts the user-interface features that can be included for user navigation.
Finding time to meet with the client. Communication with client is extremely limited due to conflicting schedules.
Client has little knowledge about software development and may not be able to provide a complete set of requirements at initial encounters. Prototyping may be required to assess the full requirements of the system.
Little or no testing time may be allowed on actual systems the software is going to run on.

Design Requirements

Design Objectives

Software to collect patient information during clinic visit. – The software needs to provide a clear and easy way to record the information the nurses and doctors gather during a patient’s visit to the clinic.

Create suitable patient visit record. – A means to output the visit record in physical form is needed. The output method must be suitable for placing in a patient’s health record.

Easy to use interface. - The user interface must be easy to use with a touchscreen, mouse, and keyboard. The user interface must help limit the number of errors made by the user. The interface will hide the complexities of whatever storage system is chosen for patient and illness lists.

Software runs on existing equipment. - The client already has computer equipment that he does not want to replace. The software must perform acceptably on this computer.

Functional Requirements

The following subsections define the required functions that the end product will perform. The Automated Medical Evaluation System will be used to generate patient records that may contain sensitive information. Records will be generated during the patient examination and printed on patient forms right after. The Automated Medical Evaluation System will have to address this process to make it as efficient and reliable as possible.

Authentication

The identity of the user who completed the patient visit record must be verified, because of the sensitive nature and legal requirements of medical records.

The user shall not electronically sign and print a patient visit record without authenticating his/her identity.
The user shall electronically sign the patient visit record to approve it.
At least one user shall always have the privileges to add, remove, and modify user information. User information shall consist of at least the user’s login name, password, real name, and electronic signature.
Only authorized users shall add, remove, and modify user information.

User Interface Look and Feel

Every part of the user interface shall have a common look and feel. This will help ensure a lower learning curve for the software.

The user shall be able to exclusively control the user interface with a touchscreen, mouse, keyboard, or a combination of these devices.
The current date and time shall be displayed on every screen.
At any time during the process of creating a patient visit record the user shall be able to return to previous screens to change previously entered information.
The user interface shall fit on a 6 by 8 inch screen.

Recording a Patient Visit

The user(s) will follow a series of steps to record a patient visit. These are the requirements for those steps.

The patient’s name, gender, and birth date shall be entered for every visit record.

The patient’s age shall be displayed on the same screen as the patient’s name, gender, and birth date. The age shall be calculated based on the entered birth date.

The user shall select the patient’s illness from a list of illnesses.

The user shall complete templates for the subjective, objective, and treatment analyses of the patient’s illness.

The templates shall be completed using the touchscreen to modify the template fields.

A template field shall present the user with a list of choices and allow the user to select one of the choices.

The user shall be able to complete analysis templates for multiple illnesses.

The user shall choose whether to include the “Past medical history is well documented.” statement in the patient visit record.

The user shall choose whether to include the “Review of systems is otherwise unremarkable.” statement in the patient visit record.

The user shall choose whether to include the “Refer to other dictation.” statement in the patient visit record.

The user shall review the patient visit record. The review shall look exactly like the printed patient visit record.
The user shall print the final patient’s visit record to a printer of his or her choice.
The user shall be able to start a new patient visit record at any time.
The user shall be able to quit the program at any time.

Output

The printed patient visit record has the following requirements:

The printed patient visit record shall include the:

patient’s name, gender, and birth date
current date and time
subjective statement
patient’s history
state of the patient’s other systems
analysis of each illness, which includes the:

subjective statement
objective statement
treatment plan

short description of the software used to create the visit record
doctor’s electronic signature

Every patient visit record shall be printed using the same format.
The patient visit record shall fit on an 8.5 by 11 inch adhesive label.

Illness Templates

Each illness shall have templates for the subjective, objective, and treatment plan parts of the SOAP analysis.
The users shall be able to add new templates to the software without intervention by the software developers.
The users shall be able to take templates used on one computer running the software and install them on another computer running the software.

Design Constraints

Touchscreen use. - The software must be usable with a touchscreen. A touchscreen is not as precise a pointing device as a mouse. Thus buttons, scroll bar, and other control features must be larger than an average fingertip.

Screen size. - Each screen must be readable on the touchscreen of the examination room (6x8 inches). Therefore, only so much information can be collected and displayed on each screen if it is to remain readable.

Computer experience of users. – The project team must always keep in mind the amount of experience the users have with computers. The design must be as clear and simple as possible so those with little computer experience will have little trouble learning to use the software.

Method of printing. - The quality and difficulty of outputting the patient visit record depends on the type of printer used. The software must be modified to print on preprinted forms (sticky labels) versus printing on a plain paper laser printer.

Method of data storage. – Data such as the illness lists must be stored somewhere and kept common on all computers. The method of storage determines the flexibility and easiness in which such data can be maintained.

Security. – Because of the sensitive nature of medical information, the software must be designed so that multiple users are able to login to different accounts. Security is needed so that a user is not able to use other user’s electronic signature because the patient visit record is valid only when the doctor puts his or her electronic signature on it.

Measurable Milestones

The following are major milestones in the completion of the project. These milestones may be used to judge the progress of the project. The levels of evaluation for each milestone are: meet expectations, beyond expectations, below expectations, and did not meet expectations. If a milestone has been completed, its level of evaluation is listed with the milestone. If a milestone has yet to be completed, the expected level of evaluation is listed.

Project description for Dr. Carlyle is completed.

Met expectations – Dr. Carlyle understands and clarifies the project description.

Project plan is completed.

Below expectations – The purpose of the project was not clear.

Revised project description based on Dr. Carlyle's feedback is completed.

Met expectations – Dr. Carlyle understands and agrees with the revised project description.

Project poster is completed.

Beyond expectations – Received good response from faculty advisors and received the blue ribbon.

Web site is made available through the senior design web.

Met expectations – The web site is being maintained and is up to date.

A prototype of the software is presented to Dr. Carlyle.

Did not meet expectations – Postponed to second semester due to inadequate resources.