CS421: Fall 2008 Project

Vision Statement

RHIMS provides a modular interface for healthcare providers to view health care information of remote patients. RHIMS collects vital sign information such as blood pressure, oxidation levels, and pulse. Using a standard representation of this data makes the data accessible in a standard format on a database. This standard format of healthcare data allows RHIMS to provide an interface for accessing healthcare data through a web interface in the forms of graphs and patient alert color schemes. RHIMS also allows healthcare providers to monitor multiple patients at a single time as well as forward necessary information to patient family members.

Requirements and Features

Must have 3 components of design
- Hardware interface
- Database/server backend
- Web interface for viewing patient information
Graphs that contain data trends for each patient
Alert system if data received is outside of medically accepted range
Possible calibration of data for each patient
Should be able to log trends of each client and a group of clients into a database
Define or use existing medical standard for data representation
Modular design allowing for easy addition or removing of health information gathering devices
Data and web interface should be password protected
Display heart and temperature as the base modules
Multiple Client/Patient view
Easy to use and Simple GUI

Key Features

Add patients and clinicians to the system and create cases and guidelines for them
Collect data from (simulated) monitoring devices and store it in database
View collected patient data real time for both single and multiple patient views
Generate alerts using guideline based analysis of monitored patient data

GUI Sketches

Domain Model

Patient, Monitoring Device, Receiver
The patient has a medical monitoring device attached to them that continuously acquires physiological vital signs and transmits this data to a receiver. The receiver sends patient data to the server.

Doctor/Nurse
The doctor, nurse, or other medical professional that are responsible for health of their patients use the software to view the medical data collected by the monitoring device and receive alerts from the server when a patient enters a critical range. Doctors and Nurses also are responsible for creating patient groups if they desire to monitor patient group trends.

Healthcare Provider
The healthcare provider is responsible for assigning patients to doctors/nurses and managing users of the software system. They are also responsible for setting up the monitoring device and configuring the software system to accept and monitor the patients.

Actors

Patient - the patient is the individual whose vital signs are being monitored and analyzed
Monitoring Device - the physical medical device that monitors and transmits the patient's vital signs
Database - stores physiological data for all patients that is gathered by the monitoring device(s)
Web Server - the server handles interaction between the monitoring devices, the user interface, and the database, in addition to managing users and patients
Web Interface - the web based GUI that allows users to view and manage patients, along with displaying graphs and patient status
Nurse/Doctor - the medical professionals who are responsible for taking care of the patients
Health Care Provider - the management organization for the nurses, doctors, and patients

Use-cases

Administrator Login
Primary Actors: Health Care Provider
Secondary Actors: Web Interface, Server
Goal: Login with Administrator rights
Main Path:

Enter administrator login information
Validate login information
If correct, display list of administrator options

User Creation
Primary Actors: Health Care Provider
Secondary Actors: Web Interface, Serer
Goal: Create a new Nurse/Doctor user
Pre-condition: Administrator Login
Main Path:

Select create new user option
Enter new user information
Check if user does not already exist
If user does no already exist, create user and add to user list
If need be, restrict or expand user options

Adding Patient
Primary Actor: Health Care Provider
Secondary Actors: Web Interface, Server
Goal: Add a patient to the system
Pre-condition: Administrator Login
Main Path:

Select create a new patient option
Enter new patient information
Check if user does not already exist
If patient does not already exist, create patient and add to patient list
Assign patient to a user (doctor/nurse) by creating a Case

Removing Patient
Primary Actor: Health Care Provider
Secondary Actors: Web Interface, Server
Goal: Remove patient from the system
Pre-condition: Administrator Login
Main Path:

Select remove patient option
Enter patient information
Check if the user already exists
If patient does exist, delete any Cases they are part of
Remove patient from patient list

User Login
Primary Actor: Doctor/Nurse
Secondary Actors: Web Interface, Server
Goal: Login as a Doctor or Nurse
Pre-condition: Doctor or Nurse user has already been created
Main Path:

Enter user login infromation
Validate login information
If correct, display list of user options

Single Patient Overview
Primary Actor: Doctor/Nurse
Secondary Actors: Web Interface, Server, and Patient
Goal: View Patient Data
Pre-conditions: User Login, patient assigned to user
Main Path:

Select view patient list option
Select patient
Receive most current patient data and trends

Create Patient Group
Primary Actor: Doctor/Nurse
Secondary Actors: Web Interface, Server
Goal: Add a patient group to the system
Pre-condition: User Login
Main Path:

Select create new patient group option
Enter new group information
Check if patient group does not already exist
If patient group does not already exist, create patient group and add to system

Add Patient to a Patient Group
Primary Actor: Nurse/Doctor
Secondary Actors: Web Interface, Server
Goal: Add a patient to a patient group
Pre-condition: User Login, Patient Group Created, Patient in User Patient List
Main Path:

Select patient group
Select add patient to patient group
Select patient from list to add to group
Add patient to group

Multiple Patient Overview
Primary Actor: Doctor/Nurse
Secondary Actors: Web Interface, Server, and Patient
Goal: View patient group
Pre-conditions: User Login, Patient group existed
Main Path:

Select view patient groups option
Select patient group from list
Receive most current patient group data and trends

Single Patient Calibration
Primary Actor: Doctor/Nurse
Secondary Actors: Web Interface, Server, and Patient
Goal: Calibrate Data for a patient
Pre-conditions: User Login, Patient assigned to user
Main Path:

Select view patient list option
Select patient
Receive most current patient group data and trends
Give new parameters for accepted range based on old group trends

Patient Physiological Data Received
Primary Actor: Patient
Secondary Actors: Web Interface, Server
Goal: Place patient data in database
Pre-conditions: Patient is assigned to user
Main Path:

Patient device gathers data
Device formats data for transmission to server
Server receives data and gets what patient it is for
Server checks if data is within acceptable range
If it is in acceptable range, log it in the database

Alternate Path

If data is not in acceptable range, send alert to assigned doctor or nurse via email
Log deviation and the alert in the database

Activity Diagram

Use Case: Patient Physiological Data Received Activity

Sequence Diagram

Use Case: Patient Physiological Data Received Sequence

Class Diagrams

Class Diagram of the entity classes in the system.

Class Diagram of the patient monitoring and alert classes in the system. These classes will most likely be EJBs.

Class Diagram of the different managers in the system. These classes will most likely be message driven beans.

Class Design Proposal - JavaDoc

Entity, Manager, and Monitoring classes on the Application Server

Device Simulator Classes

Architecture

This project is going to be a web based application using the J2EE platform that follows the three-tier architecture.

Monitoring Device and Device Interface
- The Device Interface communicates with the actual medical devices that record the physiological data. It sends this data to the server in an asynchronous manner (data is sent to the server as soon as it is received from the device). The device itself may actually be simulated for this project to facilitate rapid development and testing.
Application Server
- The major componenets of the Application Server will be responsible for:
  - receiving medical data from the device interface and entering it into the database
  - processing and analyzing medical data to determine trends and patient status (whether their vitals indicate they are healthy or whether they are not)
  - retrieving data from the database when requested by the user interface
  - storing user accounts and performing user validation
  - sending email or text message alerts to the appropriate users when a patient enters a critical condition
Web Server
- The Web Server will contain components to:
  - Manage user accounts, such as creation and login/logout
  - Display single patient profiles and graphs of physiological data, including timeline of triggered alerts
  - Display multiple patient overview
  - Manage patients associated with user
Database and Persistence
- A database is used to record all of the acquired medical data, along with patient accounts, user accounts, cases, etc. This is actually going to be a part of the Application Server. There are components responsible for interacting with this database, such as a Patient Manager, a Clinician Manager, and a Case Manager.

Deployment Diagram

Resources

We will use several resourses to assist in our development. Java ServerFaces (JSF) will be used to help develop the web based user interface. We will also be using multiple JBoss products throughout our development. We will use EJB3 to help support application logic, Seam to integrate JSF and the EJB3 components, and the JBoss Application Server. We will also be using Hibernate to manage our medical data. More information about these technologies can be found below.