With the increase in the population and growing health diseases, and increase in treatment costs, the use of telemedicine/telehealth and patient self-monitoring systems are becoming evident.
All the patients, physicians, hospitals benefit from the vigilant, time saving and cost effective telehealth systems. One of the most life threatening problem for living being are the Cardiovascular diseases, heart attacks, heart arrests, sudden fall in their blood pressure, inconsistent breath rate, glucose levels, etc., which occur all of a sudden in regular life cycle and are difficult to detect unless they visit nearby hospital or a Cardiologist or a Physician. It is economically unrealistic for patients with conditions such as diabetes to see their doctors frequently enough to properly monitor their blood glucose levels. Therefore, most diabetic patients use portable testing devices to monitor their own glucose levels. Many conditions, such as heart palpitations, can only be fully observed and diagnosed if they are frequent enough to occur during a clinical evaluation, or by using expensive at-home or portable event monitors (e.g. Holter vests). Patient self-monitoring can provide an inexpensive alternative, where the patient collects their own data, flagging the data sets corresponding to symptom events, and presenting the data to their physician for analysis.
Thus the under described content in the document provides insights on a solution to these problems through introduction of a Cardiac Telehealth System with Cloud Storage and Real time analysis.
1.2 Existing System
Portable ECG1 devices have been used in a variety of applications. The most common device used for extensive mobile-ECG recording is the Holter monitor (named for the inventor, Norman Holter) which uses a conventional tape recorder or solid-state storage system to store ECG data to be viewed and processed later by a physician. However, Holter systems are typically very expensive to use, even for only a 24-48 hour period.
Jeon et al. improved on the standard Holter system by integrating real-time analysis into their device design. The system consists of a single-lead data collection device with a built-in display and data processor. Analog data is amplified and filtered in a pre-processing circuit, then an ARM2 processor digitizes the data and applies an additional digital filter before the data is analyzed. Analysis results are then viewed directly on the device display. While this provides real-time analysis, a physician is unable to know the status of the patient or to verify the accuracy of the device’s analysis, and the computational capabilities are limited to the power of the small on-board processor.
Fang et al. integrated ECG data collection with mobile-phone communications to allow physicians to receive SMS3 alerts regarding the patient’s status. They used a portable ECG device connected via Bluetooth to a standard mobile phone (Nokia 91) to analyze the data and transmit results to a similar device used by the physician. All data analyses and transmissions are handled using algorithms and software installed on the device itself, and data retrieval or report generation is handled by software installed on the physician’s device.
Wen et al. took the standard Holter design, and integrated an on-board, real-time data analysis system, which could transmit abnormal findings to a remote server via GSM4 service providers. The Holter is used to collect and store the ECG data, and a software program is used to classify the data into several beat types. If the beat type is of concern, the Holter transmits the data and analysis results to a remote server, where a monitoring service employee is able to review it to determine if an alert should be issued.
1.3 Need for new System
The prior existing systems put a large strain on the device’s processor and battery if data was to be collected and analyzed continuously throughout the day, and limits computational power to the capabilities of the mobile device’s small processor.
The holter system comprised of purchasing of the expensive holter unit with the added cost of an on-board processor, transmission capabilities, GSM service plans, and subscription to a central monitoring service.
They also do not allow for real-time data analysis or monitoring, since the data is simply stored until the device is returned for data retrieval.
Thus there exists the need of the new system where the data is continuously collected , monitored and analyzed in the Cloud Server and then broadcasted to Patients and Cardiac Physicians and also has continuous monitoring of heart rate and patient and their connected physician are alerted/notified in case of any abnormality.
1.4 Objectives of New System
• To provide an inexpensive alternative, where the patient collects their own data, flagging the data sets corresponding to symptom events, and presenting the data to their physician for analysis.
• To provide patient care outside of a clinical setting, giving both patients and physicians drastically increased mobility. This is meant to cut down the need for clinical visits and hospital stays, and allow for earlier detection and diagnosis of various conditions.
1.5 Problem Definition
Development of a portable, smart-phone connected system for continuous cardiac monitoring. The system is capable of continuously monitoring the conditions of the heart, automated detection of cardiac arrhythmias, and real-time notifying patients and physicians of the detected abnormalities.
1.6 Software Process Model
A software process model is a simplified description of a software process which is presented from a particular perspective. Models, by their very nature, are simplifications so a software process model is an abstraction of the actual process which is being described. Process models may include activities which are part of the software process, software products and the roles of people involved in software engineering. A process model is a development strategy that is used to achieve a goal that satisfies the requirements abiding by the constraints. The software process model for the development RAD4 of our project is Waterfall Model.
• At home continuous heart rate monitoring
• Self-monitoring system which is cost and time efficient
• Instant alerts in case of heart abnormalities to both the user of the chest strap and cardiac physicians connected to them.
• The ECG graph is updated every quarter second providing for detailed analysis and capture of minute details too.
• All the diagnosed data is sent from Google Cloud to the intended devices and also the data is stored in the cloud.
• User can at any time access the database show casing their Health History.
1.9.2 Disadvantages
• The user has to continuously wear the Chest Strap for continuous monitoring if interested in every quarter second analysis of his ECG Graph.
• Have to spend certain amount for the blue tooth enabled chest strap ECG.
2. Requirement Determination and Analysis
2.1 Requirements Determination
Requirements analysis in system engineering and software engineering encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of various analyzing, documenting, validating and managing software or system requirements.
2.1.1 Functional Requirements
• The device should be Bluetooth enabled to take the data produced by Chest Strap ECG and store it securely in the database.
• The data collected should efficiently be transferred to cloud storage for the analysis and diagnosis of the heart abnormalities.
• The system must properly send the data from cloud to the patient and physician in data packets.
• The system should generate alerts at right time in case of abnormality detection to both patients and Physicians connected.
2.1.2 Non Functional Requirements
• Security:
The website has the primary requirement to login into the system to do the next task. Hence this username and password of the user should be maintained properly and should not allow any unauthorized user to enter into the system.
Also the Physicians License no is acquired during the registration process for the users assurance of qualified doctor.
• Compatibility:
The system should run on all android enabled devices properly. Not only the mobile devices but also tablets.
• Application should have a good user interface, so it will be quite easy to use for the users of the system in order to communicate with each other.
• The system must keep the ability to with stand the faults and errors that will occur.
2.1.3 Hardware Requirements
• Android Device
• Bluetooth enabled Chest Strap ECG
2.1.4 Software Requirements
• Android Studio 3.1
• Java Development Kit
• Firebase
• Google Cloud Server
2.2 Targeted Users
The intended users to whom this system is designed are as follows:
• Elderly Patients
• Heart Patients
• Standalone Personal Users
• Diabetic Patients
• High Blood Pressure Patients
• Physician
• Cardiologists
3. Feasibility Study
3.1 Technical Study
• The system requires connection with the chest strap ECG and also both should be Bluetooth enabled.
• The system can be used at any location like at home, workplace, hospitals.
• It is made using android studio and cloud space is rented or purchased to store data.
• Java Programming skills and android programming skills are mandatory to make the system and also algorithm making ability is also required.
• Good user Interface should be provided to view patients’ history.
• System risk tolerant.