Alert Framework - Web Pages



Alert Framework

Design Documentation Version 1.0

Sri Harsha Chevuru

Sudhir Navalapakam

Overview

The aim of the project is to create a framework that would facilitate the alerting of the attending medical staff in a hospital when medical emergencies occurs, as defined by a set of parameters for these monitored values – heart rate, temperature, blood pressure, etc. As the maximum or minimum values for these parameters (or combinations thereof) are met, medical personnel can be summoned via one of many mediums, and will be able to provide immediate care to the patient.

The benefits of this project will include:

• Increased resource efficiency

• Real-time monitoring of key medical indicators

• Ability to immediately engage the correct staff when needed

• The ability to fully configure medical indicators

• Increase to quality of service for all inpatients

Glossary

• Front-Desk Personnel: The user who would inform the system when the medical personnel on call responds to the message

• Admin-User: A user with administrative permissions which gives him/her the privileges to add/delete/modify rules/parameters/messaging modes. This user is the one who can either create more logins or delete dissolve existing ones

• Sensor: These are the various data sources from which we can get data about a particular patient. This might be anything even a database.

• Parameters: The medical data associated with any patient like Blood pressure, pulse rate etc.

• Rules: The association of various parameters based on arithmetic and logical rules.

• Messaging Modes: Various messaging modes like eMail, SMS etc.

• Messaging Subsystem: This component deals with sending messages to the appropriate user using the appropriate messaging mode and also ensuring the response to the message.

• Logic Subsystem: When some medical data associated with a patient changes, the logic sub system checks out if there is any abnormality associated with the condition and if yes alerts the messaging subsystem of it

• Configuration Sub System: This stores and lends information relating to logins, rules, parameters and messaing modes.

Requirements Specification

Functional and Non-Functional:

• Monitoring of source data

➢ Data from specified sources needs to be monitored at regular intervals of time.

➢ Data can be from varied sources. The framework shall be configurable to use various types of data sources

• Rules

➢ The rules associated with the different parameters shall be stored

➢ Rules defined shall incorporate binary and comparison logic

• Rule configuration

➢ A method shall be provided to add in new rules with relations between parameters

➢ A method shall be provided to edit existing rules

➢ A method to add in or delete the parameters to be monitored from time to time shall be provided

• Analysis of Data

➢ The source data will be analyzed based on the rules defined.

• Messaging

➢ Alert the concerned authority if the data matches the patterns specified.

• Support for multiple modes of communication

➢ The framework shall support communication of data via multiple modes (SMS, email, etc)

➢ It shall be configurable to choose more than one messaging mode for the system.

➢ Given more than one messaging mode it shall be possible to specify the preference between the messaging modes

➢ It shall be possible to page through all messaging modes available and configured by the system

• Tracking the response

➢ In case no response is obtained for a alert in a given time frame then an alternative resource is to be alerted

➢ It should be possible to alert the supervisor in case a particular authority doesn’t respond repeatedly

➢ What to do in case a response is not received shall be configurable

• Authentication procedures

➢ Authentication shall be provided to both the access of data and any attempts made to edit or add any new patterns to the system.

• Support for multiple DBMS

➢ As a framework, the system shall support interfacing with different types of databases. For example, given a new plugin the framework could interface with a mySQL database or a MSAccess database.

Business Domain & Stake Holders:

• All parties who server as primary caretakers of patients would be stake holders for this framework

• With its ability to reduce the time that a doctor or any medical personnel spends monitoring a patient, it effectively increases the throughput of the entire hospital workflow

• This sort of a framework can be used as a cue to develop frameworks in other domains where again continuous monitoring of data is the order of the day.

Framework Specification

The diagram below describes the framework of our system. As can be seen from the diagram, the Configuration Sub System forms the center of the system which coordinates the activities of all other components.

[pic]

Figure 1: System Framework

Assumptions and Principles:

• It is believed that the data that we get from the sensor is authentic

• We assume there is a front desk personnel who informs the system when a medical personnel responds to the call

• We implement data streams in a generic way but then we test it with only data coming through databases

• Though we provide support for adding more messaging modes in future we are implementing only the basic mode right now. More modes shall be implemented time pertaining

• It is being assumed that the resource allocated is independent of the abnormality of the patient

• The admin user is the sole responsible person to include the parameters or rules in the system

Methodologies:

Algorithm

• Sensor sends data to the data stream

• This data is received by the logic subsystem

• The logic subsystem retrieves all the rules relating the parameter it received from the configuration subsystem

• The unknown parameters to validate the rules are queried from Data Stream

• On receiving the required data, the rules are validated and if any of the rules match with the data in hand, the messaging subsystem is invoked.

• The messaging subsystem queries the resource handler for the available medical personnel at that time

• The messaging subsystem queries the configuration sub system for the messaging mode

• The medical personnel is paged

• The front desk personnel uses the response handler to alert the system when the medical personnel attends to his/her duty

• If the response is not received within a particular time interval, either another resource is called or the supervisor is informed about this based on the rules in the configuration sub system.

Data Structures:

• Effective use of linked lists to represent most of the data sets in the system

• Tree structure effectively used by the use of XML documents and schemas

Design Pattern:

• If the response is not received within a particular time interval, either another resource is called or the supervisor is informed about this based on the rules in the configuration sub system.

• The UML design pattern has been used

• The UML combines the best of the best from

➢ Data Modeling concepts (Entity Relationship Diagrams)

➢ Business Modeling (work flow)

➢ Object Modeling

➢ Component Modeling

• The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system

• It can be used with all processes, throughout the development life cycle, and across different implementation technologies.

System Specification

Use Case Diagram:

The diagram below specifies the basic functionality of the administrator. The administrator first logs into the system and then either add/delete logins or Edit various settings like messaging mode, parameters, rules etc.

[pic]

Figure 2: Administrator use-case

[pic]

Figure 3: Edit Settings use-case

The following use-case defines the messaging service in the system. The sensor feeding in the data acts as a trigger.

[pic]

Figure 4: Messaging use-case

Sequence Diagrams:

This sequence diagram describes how to change settings using admin login.

[pic]

Figure 5: Admin Login(Change Settings)

This sequence diagram describes how to edit logins using admin login.

[pic]

Figure 6: Admin Login(Login Management)

This sequence diagram describes as to how does the front desk personnel respond to the system.

[pic]

Figure 7: User Login(Respond to a call)

The following sequence diagram as to how is the medical personnel on receiving some medical data.

[pic]

Figure 8: Messaging

Operation Specification

PreConditions

• The administrator login and password should form part of the installation of the system. There is no way to add a administrator login once the system is installed

• The configuration file should be well populated with data if the system is to start working immediately after being installed

• The system assumes that the front desk informs the system whenever the medical personnel responds to a call from the system

• The administrator cannot delete a login of a person while that person is still logged in. Until the said person explicitly logs out, the administrator cannot delete his/her login.

Post Conditions

• The integrity of the entire of the entire system is to be maintained after every operation.

System UI

[pic]

Figure 9: Login

The UI in the above figure will be used to log into the system. It can be used either by the administrator or the front desk personnel.

[pic]

Figure 10: Admin functionality

The UI above lists the options available to the administrator after having logged into the system. The admin chooses one among the several options available (edit rules, edit

parameters etc.).

[pic]

Figure 11: Responder Functionality

The above UI is used by the front desk personnel to inform the system that some medical personnel responded to the call.

System Architecture Design

Architecture Diagram:

The following diagram describes the architecture diagram of our system.

[pic]

Figure 12: Architecture Diagram

Component Diagram:

This diagram represents the component diagram of our system.

[pic]

Figure 13: Component Diagram

Package Diagram:

The diagram below represents the package diagram of our system.

[pic]

Figure 14: Package Diagram

Protocol Design:

• We use XML to store the various configuration parameters

Database Design:

|PATIENT’S TABLE |ParameterID |BedID |Value |

|CONFIGURATION TABLE |Rule |List of parameters |Association |

|LOGIN TABLE |LoginID |Password |

Figure 15: Database Design

Class Diagram:

The following describes the class diagram of our system

[pic]

Figure 16: Class Diagram

Technology Selection

Feasibility Study:

• We propose to implement the system using Java. Java provides numerous APIs for messaging, accessing databases and processing XML documents. This would give us a lot of flexibility in looking at the high level elements of our system rather than building the lower level foundation first.

• We propose to use XML for transfer of information between the components in the framework.

• There are various GUI components to be built in the system. We propose to use web page technology for this. For instance to add in more rules into the configuration control, we list out the available parameters from which the user can choose the parameters of interest and define a association between them.

• To implement access of data from varied sources, we propose to implement DB plug-ins which can effectively be used to access different types of databases.

Project Timelines:

Week of Sept 26th: Determine configuration requirements, and create XML schema

Week of Oct 3rd: Individual component design

Week of Oct 10th: Interface design, UML documentation finalized

Milestone: Friday Oct 18– Design document submission

Week of Oct 17 th: Individual component implementation

Week of Oct 24th: Complete component implementation

Week of Oct 31st: Component integration implementation

Week of Nov 7th: Complete integration implementation

Milestone: Friday Nov 12th – Prototype I submission

Week of Nov 14th: Testing/Final Functionality Implementations

Week of Nov 21st: Testing

Week of Nov 28th: Documentation

Milestone: Mon Nov 29th – Prototype II submission

Week of Dec 5th: Presentation planning

Week of Dec 12th: Documentation finalization

Milestone: Mon Dec 13th – Final Project Documentation

Task Responsibility:

Configuration block – Sudhir and Harsha

Data plugin – Sudhir and Harsha

Admin GUI – Sudhir and Harsha

Fetching and Logic Handling Block – Sudhir and Harsha

Messaging Block – Sudhir and Harsha

Documentation – Sudhir and Harsha

Messaging dummy services – Sudhir and Harsha

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download