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.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- sub alert frontline
- lemon alert cars 2019
- blackboard connect alert system
- scam alert list
- lemon alert stay away from these cars
- options trading alert service
- high alert medication list
- narrator for web pages microsoft edge
- high alert medications 2019
- person to person alert device
- motley fool ultimate buy alert stock gumshoe
- lock alert equifax