Operational Concept Description Version 2.0.1
Operational Concept Description (OCD)
OCD_FCP_F17a_T06_V2.0.1
DIABETES HEALTH PLATFORM
(DHP)
Team: 06
VEERAV NAIDU – PROJECT MANAGER
MUKAI - ARCHITECT
STEVE SOUTH - IV & V
VIJAYA PRABHAKARA – QUALITY FOCAL POINT
SUDEEP SURESHAN – OPERATIONAL CONCEPT ENGINEER
AASHIHA PRIYADARSHNI LAKSHMI KUMAR - PROTOTYPER
VISHALI SOMASKANTHAN – REQUIREMENTS ENGINEER
VANDHANA SOMASKANTHAN – IMPLEMENTER/TESTER
SURABHI GOYAL – ARCHITECT
28 NOVEMBER 2017
v
Version Date: 28 November 2017
Operational Concept Description Version 2.0.1
Version History
28 November 2017
Version History
Date / Author / Version / Changes made / Rationale /10/8/17 / SS / 1.0 / Sections 1.1,1.2, 2.2, 3.2 ,3.4 / · Initial Draft, Preparation for FCR ARB /
10/8/17 / APL / 1.0 / Sections 2.3 , 3.1, 3.3 / · Initial Draft, Preparation for FCR ARB /
14/8/17 / SS / 1.1 / Sections 1.1, 3.2 / · Report based on FCR Review /
14/8/17 / APL / 1.1 / Sections 2.3 , 3.1, 3.3 / · Report based on FCR Review /
11/25/17 / SS / 2.0 / Sections 1.1,1.2, 2.2, 3.2 ,3.4 / · Initial Preparation for TRR Review /
11/25/17 / APL / 2.0 / Sections 2.3 , 3.1, 3.3 / · Initial Preparation for TRR Review /
11/28/17 / SS / 2.0.1 / Sections 1.1,1.2, 2.2, 3.2 ,3.4 / · Preparation for TRR Review /
11/28/17 / APL / 2.0.1 / Sections 2.3 , 3.1, 3.3 / · Preparation for TRR Review /
Table of Contents
Operational Concept Description (OCD) i
Version History ii
Table of Contents iii
Table of Tables iv
Table of Figures v
1. Introduction 1
1.1 Purpose of the OCD 1
1.2 Status of the OCD 1
2. Shared Vision 2
2.1 Benefits Chain 3
2.2 System Capability Description 3
2.3 System Boundary and Environment 4
3. System Transformation 6
3.1 Information on Current System 6
3.2 System Objectives, Constraints and Priorities 6
3.3 Proposed New Operational Concept 8
3.4 Organizational and Operational Implications 10
v
Version Date: 28 November 2017
Operational Concept Description (OCD) Version no 2.0
Table of Tables
Table 1: The Program Model 2
Table 2: Level of Service Goals 7
Table of Figures
Figure 1: Benefits Chain Diagram……………………………………………………………………………...... 3
Figure 2: System Boundary and Environment Diagram………………………………………………………………………5
Figure 3: Element Relationship Diagram………………………………………………………………………………………8
Figure 4: Business Workflows Diagram……………………………………………………………………………...... 9
v
Version Date: 28 November 2017
Operational Concept Description (OCD) Version 2.0.1
1. Introduction
1.1 Purpose of the OCD
This document of Operational Concept Description(OCD) has the following objectives:
1. Describe the proposed Android App, in terms of the patients needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used by patients.
2. It will be used to obtain consensus among the acquirer (Client), developer, support on the operational concept of a proposed system (Android App)
This document provides, in detail, the shared visions and goals of the stakeholders of the Keck School of Medicine doctor.
The success critical stakeholders of this project are as follows:
1. Diabetic Patients – focus is on Type-2 Diabetic patients.
2. Doctor - who would be supervising the patient’s health
3. USDA Food DB – the food input provider for the app.
4. CGM – the one which will give the glucose level, as the input
5. Developers – students of CSCI 577A, who would be building the system.
6. Maintainers- currently developers are playing this role too.
1.2 Status of the OCD
The status of the OCD is completely done and it. There are no previous versions to this project. The scope of the Diabetes Health Platform project has been directed to the Application development primarily. Since, the website portion of it, is of less importance and this has been reevaluated based on the client’s requirements.
2. Shared Vision
Table 1: The Program Model
Assumptions:· User is Type-2 Diabetic
· User Inputs the Data
· CGM is same across all products
· User responds to doctor’s suggestion
Stakeholders
/ Initiatives
/ Value Propositions
/ Beneficiaries
· Type-2 Diabetic Patients
· Doctors
· Developers
· Client/Maintainer
· API Provider Organization / · Patients use the app correctly and input all the relevant data.
· Doctors give feedback to patient
· Developers develop the Android app and website
· Maintainers maintain the Android app and website. / · Personalized Diagnosis
· Rea-Time Feedback
· Doctor is kept informed.
· Increased life quality.
· Less cost on medicines. / · Patients
· Doctors
Cost (Cost factors)
● Personnel costs – Client time on evaluating win conditions, weekly meetings.
● Software costs – Google Cloud Platform
● Hardware costs - CGM / Benefits
● Increases the remote monitoring of patients by doctor
● Patients tracking their sugar levels and keep a control over it.
● Decreased cost of patients travelling to and fro for small blood measurements.
2.1 Benefits Chain
Figure 1: Benefits Chain Diagram
2.2 System Capability Description
1. The project involves building:
i) Website for the Diabetic Heath, in general
ii) An Android App, which is the main focus.
2. The targeted customer(s) are:
i) Primarily, Type-2 Diabetic patients
ii) Doctors – to monitor patient's health in real time.
3. The need that will be satisfied by the App is that the patients can better monitor their health by getting real-time feedback and reduce medical costs too.
4. A compelling reason for the patients to use the App is for health benefits. Also, for monetary benefits in the long run.
5. No such App in the market as of now.
2.3 System Boundary and Environment
Figure 2: System Boundary and Environment Diagram
3. System Transformation
3.1 Information on Current System
3.1.1 Infrastructure
Currently, there is no such Android Application or Website in place at the Client’s Organization. So, this is the first initiative. No Software/Hardware is already in use.
However, currently the Client is performing this task manually though once is three months.
3.1.2 Artifacts
The following artifacts are used in dealing with the system:
1) Continuous Glucose Monitor (CGM)
2) Android Phone (Lollipop Version or Higher)
3.1.3 Current Business Workflow
Figure 3: Current Business Workflow Diagram
3.2 System Objectives, Constraints and Priorities
3.2.1 Capability Goals
Capability Goals / Priority LevelOC–1 Diabetic Website: A Website which will give information on diabetes and also have a link to download the Android app / Nice to have
OC-2 User Registration: The app allows patients to register when they try to use the app for the first time. / Must have
OC-3 FireBase Login: The app will let users have an option to login via Gmail or other authenticated signing in. / Must have
OC-4 User Input: The app lets the patient enter the required inputs based on the his/her case. / Must have
OC-5 Automated Report Generation: The app should generate patients health related reports based on doctor’s feedback. / Must have
OC-6 Notification Alert: The app should notify patients of input glucose level crosses threshold and also based on his/her input and feedback from doctor / Must have
3.2.2 Level of Service Goals
Level of Service Goals / Desired Level / AcceptableLevel / Referred WinWin Agreements
LOS1: Supported Android Versions / Oreo(API 26)
(2.15) / HoneyComb
(API 14)
(2.8) / WC_4464
LOS2: Supported CGM
devices / Various CGMs Support / Dexcom Device / WC_4389
LOS3:
Database Supported Versions/Types / NoSQL,
SQL,
Cloud Based / FireBase DB / WC_4612
Table 2: Level of Service Goals
3.2.3 Organizational Goals
· OG-1: Increased Personalized Diagnosis of Patient’s Health
· OG-2: Reduced monetary expenses, due to decrease in medicinal cost in the long run.
· OG-3: Increased life quality of patients.
3.2.4 Constraints
CO-1: Android as an Operating System: The new app must be able to run on Android platform.
CO-2: CGM Dependency: The app is dependent on the Dexcom team/company to open us the API to access their database. Also, there is a dependency with the CGM product owner to enable access to user information.
CO-3: Monetary Constraint: The selected Android App will be available only to a selected users, who have access code for the application.
CO-4: Java as Application Development Language: Java based (Android) will be used as a development language.
3.3 Proposed New Operational Concept
3.3.1 Element Relationship Diagram
Figure 3: Element Relationship Diagram
3.3.2 Business Workflows
Figure 4: Business Workflows Diagram
3.4 Organizational and Operational Implications
3.4.1 Organizational Transformations
The following organizational transformations will result from transitioning to the new system.
A. The need of a dedicated server to host/store the Backend capabilities and other Application related information
B. The need to hire a new system maintainer to take care of the Android Application, the server and website.
3.4.2 Operational Transformations
The following organizational transformations will result from transitioning to the new system.:
A. Having the feedback from doctor much faster, almost in real-time. This is aimed to decrease response time to the patient, subject to the fact that the patient provides all the required input.
B. The option for patients to sign in through registration or also via Google sign-in.
C. Immediate notifications, in case of abnormal conditions of health, specific to the patient.
6
Version Date: 28 November 2017