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 Level
OC–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 / Acceptable
Level / 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