Phase 5 - Team 32

8/2/2019 Phase 5 - Team 32

1/58

Phase 5: Final Report

Team 32: Innovation in MotionIan Busko, Andy Deasey, Grayson Dinsmore, Sam Evans, Michael Humiston

4/12/12

8/2/2019 Phase 5 - Team 32

2/58

2

Table of Contents

PREFACE................................................................................................................................................... 4

Document Identification........................................................................................................................ ...4

Privacy Information.................................................................................................................................. 4

INTRODUCTION....................................................................................................................................... 4

Purpose of Plan.........................................................................................................................................4

Background Information About the Project..............................................................................................4

Statement of Problem being Solved..........................................................................................................5

Project Approach......................................................................................................................................6

Project Goals and Business Objectives..................................................................................................6

Project Goals..........................................................................................................................................6

Business Objectives...............................................................................................................................7

Project Scope............................................................................................................................................7

Deliverables........................................................................................................................................... 7

REQUIREMENTS DEFINITION...............................................................................................................8

Requirements Gathering Process.......................................................................................................... ....8

Literature Search.......................................................................................................................................8

Requirements............................................................................................................................................ 9

Functional Requirements........................................................................................................................ 9

Mandatory Requirements........................................................................................................................9

Non-Functional Requirements..............................................................................................................11

Technical Requirements........................................................................................................................13

FUNCTIONAL DESIGN..........................................................................................................................19

Activity Diagrams...................................................................................................................................20

Use Cases................................................................................................................................................22

Use Case Narratives................................................................................................................................22

Use Case Glossary.................................................................................................................................. 27

TECHNICAL DESIGN.............................................................................................................................28

Technical / Application Architecture .....................................................................................................28

UML Diagrams.......................................................................................................................................29

Structural....................................................................................................................................... .......29

Behavioral.............................................................................................................................................31

QUALITY MANAGEMENT....................................................................................................................33

Activity Reviews/Walkthroughs.............................................................................................................33

Tools and Techniques............................................................................................................................. 34User Acceptance and Verification.......................................................................................................... 34

Project and Industry Standards............................................................................................................ ...35

PROJECT MANAGEMENT.....................................................................................................................36

Project Assumptions...............................................................................................................................36

Project Constraints..................................................................................................................................36

Work Breakdown Structure (WBS)........................................................................................................ 36

Gantt Chart............................................................................................................................................. 37

8/2/2019 Phase 5 - Team 32

3/58

3

Roles and Responsibilities...................................................................................................................... 37

Change Management........................................................................................................................ ......37

Issue Management.................................................................................................................................. 37

Issue Log................................................................................................................................................ 38Communications and Control................................................................................................................. 38

PROJECT DEMONSTRATION............................................................................................................... 38

PROJECT SUMMARY STATEMENT.....................................................................................................39

APPENDICES...........................................................................................................................................40

Appendix 1: WEEKLY STATUS REPORTS.........................................................................................40

Appendix 2: EXTERNAL COMMUNICATIONS.................................................................................50

Appendix 3: GLOSSARY.......................................................................................................................51

Appendix 4: TEAM CONTRACT..........................................................................................................52

Appendix 5: DATA DICTIONARY.......................................................................................................55

8/2/2019 Phase 5 - Team 32

4/58

4

PREFACE

Document Identification

Project Name MediCloud

Document Owner Innovation In Motion

The primary contact for questions regarding this document is: Michael Humiston

Project Team Members:

Name Email Phone

Ian Busko [email protected] 814-386-1537

Andy Deasey [email protected] 724-866-0291

Grayson Dinsmore [email protected] 814-404-0673

Michael Humiston [email protected] 330-730-0497

Sam Evans [email protected] 814-421-6030

Privacy InformationThis document may contain information of a sensitive nature. This information should

not be given to persons other than those who are involved in the MediCloud project or who will

become involved during the life-cycle.

INTRODUCTIONPurpose of Plan

This section of the document will introduce the problem to be solved by the MediCloud

project. The contents include the background and inspiration of the project, an explanation of

what problems have been identified, what problems will be solved, the business goals and

objectives for the project, and how we will approach the project.

Background Information About the ProjectThe idea for the MediCloud arose because of the increasing number of medical records

and contacts that are circulating. Data exchange is becoming increasingly complex, so something

must be done to simplify the amount of data and make it easier to access. Currently, there is very

8/2/2019 Phase 5 - Team 32

5/58

5

little being done on a grand scale, only small cloud-based solutions that help individuals to keep

track of their own medical records.

Despite its simplicity, there are oppositions to using a cloud-based system. The first is

that the records could become insecure. The second is that a poor connection would makeaccessing the records difficult. Another concern is that the allowing one central company to

control all of the data could be bad for business.

Still, pursuing the use of the MediCloud is worthwhile because it will be effective,

regardless of possible consequences. A centralized database will not be taking business away

from anyone, but simply be adding an additional service. This service will then simplify the

structure of the medical world, allowing patients to be more effectively served.

Statement of Problem being SolvedThe problem that MediCloud solves is the amount of redundant information being passed

around to hospitals and medical care clinics. Every time a person visits a different clinic, an

additional record of his or her information is created that may or may not be identical to another

hospitals record. Because of this, the same set of background questions are asked at every new

health care provider. Additionally, it takes time to transfer the records between two clinics,

requiring extra communication between the providers themselves. Furthermore, a patient may

not know all of his or her allergies or other conditions, so crucial mistakes could be made

without proper access to the most current records.

To restate this, medical records are important, but there is no simplified, centralized way

to manage them. The result is an excess of scattered records and too much communication

between various medical providers and specialists.

PatientsPatients will be affected in more than one way with the development of MediCloud.

With the technology that we plan to implement, patients will receive a better quality of care in

any facility that they visit as practitioners will have direct access to previous medical records

concerning the patients. With this access, the practitioners can then develop and implement a

solution to the illness of the patient in more cost effective and time efficient manner . If the

technology is implemented into health care facilities on a large scale, overall patient care will

increase in quality across the board.

Insurance CompaniesHealth Insurance Providers will indirectly benefit from the MediCloud. Using the cloud

will save the health care providers both money and time. Transfer of data will be faster, so less

money will be spent on the physical documents and their movement. This decrease in cost will

lead to lower costs for the hospital overall, which will result in lower costs for patients. Because

patients will be paying less, insurance companies will have to pay out less money, so their

services will be cheaper.

8/2/2019 Phase 5 - Team 32

6/58

6

Health care PractitionersHealth care practitioners will be directly affected by the adoption of a cloud service to

transfer electronic records. Documents ranging from x-ray scans to patients records cost the

practices money and time to deliver. The current systems in place are not compatible throughoutthe country and do not provide quick access to documents not stored on their servers. With the

implementation of the MediCloud system providers will see an increase of profit and less

downtime. The MediCloud system will provide quick, reliable data for the providers greatly

improving the existing system.

Project ApproachThe team consists of five members, one of whom is the team leader. The leader is

responsible for organizing and running the meetings as well as compiling the deliverables. The

team leader may delegate any responsibilities.

To complete the given tasks, the team will hold meetings. In these meetings, the team

will first define the problem at hand. Once the problem is determined, the team will decide the

best method to complete the solution. Decisions will be made by group consensus during the

meeting. Then, the work will be divided up based on members preferences and skill sets, then

by necessity. Deadlines will be set to ensure that the group is able to complete its work on time.

The actual project work will be to design a solution to a real-world problem. That

solution may change as the project commences based on the growing needs of the project or in

order to deal with additional issues.

Actual work during this process will be done by the iterative model. While an initial

solution to the given problem has been given, the actual solution and methodologies for

accomplishing the task will change based on needs. The end result will not be restricted by the

initial design of the solution.

Project Goals and Business ObjectivesThis section identifies the project's goals and business objectives that the project addresses.

Project Goals

The goals of this project are:

To design an innovative solution to the problem of the sharing of medical information

To design a cloud-based storage and sharing system that is interconnected throughout the

United States

To decrease the amount of spending of health care providers and insurance companies

To alleviate the issues of the slow speed of the sharing of physical information

8/2/2019 Phase 5 - Team 32

7/58

7

Business Objectives

The objectives for this group are:

To design an interconnected Cloud network within the United States Allow health care providers to add and edit file entries in the Cloud

Ensure the integrity and security of the information

Adhere to the laws surrounding confidential patient records

Decrease the cost associated with the transferring of the medical records via electronic

means

Project ScopeMediCloud is a simple, cloud-based central medical database that aims to help hospitals

better coordinate patient records within the United States. This system will allow all health care

providers who are part of the network to transfer any applicable electronic or digitized physicalmedical records.This project aims to create a feasible functioning design of the MediCloud that

will outline its purpose and uses. It aims to convince hospitals that the MediCloud would be

useful and feasible, as well. The limit of the application for now is that it links records over time

by using a cloud; it has no other uses. This project will not actually produce the application or

work out every potential issue with it, but simply to present the problem and an idea for a

solution. Technically, it should be scalable so that additional functionality could be added over

time based on user needs. For instance, an add-on could be provided that would verify pills given

to an individual.

DeliverablesItem # Deliverable Description Estimated Completion Date

1. Phase 1: Functional Design Report 2/2/12

2. Phase 2: Functional Design Review 2/9/12

3. Phase 3: Technical Design Report 3/1/12

4. Phase 4: Technical Design Review 3/12/12

5. Phase 5: Final Report 4/12/12

6. Phase 6: Demonstration 3/30/12

8/2/2019 Phase 5 - Team 32

8/58

8

REQUIREMENTS DEFINITION

This section describes how the project team identified properties of the functional andtechnical designs, as well as the requirements of the application.

Requirements Gathering ProcessTo determine the features and functions of our project our team evaluated many different

options and opinions. Information was collected through the use of health care journals and

online articles, as well as many other sources. Since this project deals with health care privacy

laws we will also consult these guidelines to apply to our project. Along with consulting health

care documents, we will also gain insight on requirements by evaluating existing cloud projects.

By examining how different cloud services operate we can determine which parts of an existing

system we could use for our project.

Library journal and articles about health care and online records

Laws pertaining to health care privacy and electronic records

Evaluation of different cloud services

Survey questions to medical business owner and practicing doctor

Literature SearchAshish K. Jha, M.D., M.P.H. "Use of Electronic Health Records in U.S. Hospitals." New

England Journal of Medicine. Web. 2 Feb. 2012.

.This article explains the use of electronic health care records in hospitals throughout the

United States. The document presented statistics that showed the use, or lack of, electronic health

care records. Also, the article justifies the use of online health care systems.

Catherine M. DesRoches, Dr.P.H. "Electronic Health Records in Ambulatory Care A National

Survey of Physicians." Nejm.org. New England Journal of Medicine. Web. 2 Feb. 2012.

.

This journal entry is about the response and treatments of patients in ambulatory care.

The article demonstrates the use of electronic records in expedient care. The writer determines

that online access to records is necessary in the quick treatment of a patient in the ambulence.

Carol Coots, CPC, CPC-H. "Enterprise Content and Record Management for

Healthcare."Ahima. Web. 02 Feb. 2012.

.

8/2/2019 Phase 5 - Team 32

9/58

9

This article shows the breakdown of the overall electronic system used by health care

professionals today. It breaks down the different categories of their content system, going in

depth into patient records.

Richard Hillestad. "Can Electronic Medical Record Systems Transform Health Care? Potential

Health Benefits, Savings, And Costs." Health Affairs. Web. 02 Feb. 2012.

.

This document determines the benefits of an electronic system and how it can not only

expedite patient care, but also save a health care company's capital. It showed the extreme

growth in other industries after the adoption of an electronic system.

Gauld, Robing. "The Impact of Health Sector Restructuring on Information and Communications

Technology-The New Zealand Case."Asian Journal of Public Administration 25.2 (2003): 209-

33. Print.This journal article looks at a similar system that had been attempted to be implemented

in New Zealand. There, the health care industry is much more government controlled and the

project ran into many problems when the government changed and its policies along with it.

Since our system is by a private enterprise, it will not run into these same problems as its

adoption will be organic and free instead of dictated by government mandate.

RequirementsOur MediCloud project, which seeks to fix the difficult storage and transfer of medical

records through the use of a Cloud network, requires a great deal of different functions to be

executed quickly and flawlessly. In order for the network to run continuously without any

problems, key functional and design features must be implemented to ensure its quality and

connectivity. The Cloud must also deal with the complex legal concerns pertaining to the

handling of patient medical records and their security within the network.

Functional Requirements

The following is a list of all the functional requirements for our project, both mandatory

and optional. Each of them pertaining to a different task within the network in order to achieve

success with the sharing and storing of patient medical information.

Mandatory Requirements

Multiple Connections The network must be capable of thousands of different connections; not

just from the individual nodes to the Cloud, but also to one another. The network must be able to

handle the sending and receiving of a large amount of data at any given time in order to meet the

8/2/2019 Phase 5 - Team 32

10/58

10

demands of hospitals and private practitioners. This ensures that data will remain updated and

shared with every node on the network to provide the best quality care possible.

Storage There are two separate requirements for the storage capabilities of MediCloud. Thefirst is the large amount of central storage that the Cloud will have to have in order to handle the

millions of patient records from the numerous nodes. Files will generally be made up of text

however complementing images and videos may also be associated with a patient, therefore

adequate storage space is a must have. Each individual health care center will also have their

own centralized database therefore the size of it must be taken into account with regard to the

size of the hospital and surrounding towns and cities.

Creation and Editing of Files One of the most key features the system must have is the ability

to create and edit patient records. Doctors and nurses will be able to create a record for each

patient that is stored on their own server for use. When they connect to the Cloud this file willbe transferred to it for sharing and updating with other nodes. Health care providers must also be

able to edit the files as the conditions and specifics of a patient change over time. This edit must

be reflected in not only the nodes storage but also the Cloud as a whole.

Search Functionality Not only does the MediCloud system need to be able to create and edit

files, it must also be able to search for them. A medical care provider must be able to search for

records by a patients name, address or any other kind of identifiable information. This allows

patient records to be transferred quickly and easily throughout the many nodes on the system.

Syncing Capabilities The updating and syncing of files is a core function of the MediCloudsystem as it allows for constantly updated information. Whenever a file is created, edited or

searched for on a nodes central database it will sync up with the Cloud to compare the two

databases. If they do not match, the system will either update the files stored on the Cloud or the

ones on the nodes own central database. This constant pinging of the Cloud will ensure that all

files, regardless of location will stay up to date with new information.

Secure Authorization Since the information contained within the servers is highly

confidential it is of the utmost importance to keep it secure. For this to be possible both the

Cloud and node databases must only be accessible from the designated locations and by

authorized personnel only. Only employees who should be looking at patient records should bethe ones who can create, edit and search for them. Making the databases themselves secure, both

electronically and physically is another important aspect that must be addressed.

Backups All the data contained in the databases must be backed up in a separate location in

order to maintain their integrity. If the Cloud network was to crash or somehow the files were all

8/2/2019 Phase 5 - Team 32

11/58

11

deleted, this would be a critical problem and could possibly lead to the shutdown of several

health care locations.

Disaster Recovery In the event of something happening to the system it is of great importanceto respond effectively and efficiently in order to mitigate and fix problems. If the central Cloud

server were to go down it is very important that the system remains operational at some level.

The node databases must still be operational in the event of the Cloud going down. This ensures

that even though data cannot be shared, it is still intact and accessible at the given location. This

should be more than enough to keep hospitals and private practitioners running until the Cloud

can be assessed and fixed.

Legal Adherence An important aspect that must be dealt with is adherence to the laws

surrounding patient record viewing and sharing. There are many steps and procedures that must

be followed in order for a record to be passed to another practitioner, even if it is in the samedepartment. Dealing with the transferring of files in between locations will require even more

consideration to keep the informations confidentiality and integrity in check.

Non-Functional Requirements

Performance The constant and reliable performance of MediCloud is a crucial requirement

because without it, the sharing and accessibility of medial records will be greatly hindered. Due

to the operating hours of hospitals and other healthcare centers, the MediCloud system would

need to match this tolerability, being able to function at any hour of the day. Having a fast and

reliable response time within the system would be a essential to handle the amount of queries tothe network as well as provide information quickly in an emergency situation. Having each

healthcare center have their own internal database would also greatly reduce the amount of stress

on the Cloud allowing to be queried more often and faster. The amount of volume required in

order to contain all of the relevant data would need to be extremely large, being able to hold

several hundred petabytes worth of data while also still being able to provide search results in a

timely manner.

Security Since the information contained within the servers is highly confidential it is of the

utmost importance to keep it secure. For this to be possible both the Cloud and node databases

must only be accessible from the designated locations and by authorized personnel only. Onlyemployees who have been authorized to view specific patient records should be the ones who

can create, edit and search for them. Making the databases themselves secure, both

electronically and physically is another important aspect that must be addressed. All data being

sent through the network will have to been encrypted to ensure its integrity while the physical

servers must be kept in locked areas with 24/7 surveillance. Each node database will only be

8/2/2019 Phase 5 - Team 32

12/58

12

accessible from within the healthcare centers network and the cloud, providing security from

external intrusions.

Back-up and Disaster Recovery In the event of something happening to the system it is ofgreat importance to respond effectively and efficiently in order to mitigate and fix problems. If

the central Cloud server were to go down it is very important that the system remains operational

at some level while allowing the node databases to function without any kind of interruption.

This ensures that even though data cannot be shared, it is still intact and accessible at the given

location. This should be more than enough to keep hospitals and private practitioners running

until the Cloud can be assessed and fixed. All the data contained in the databases must be

backed up in a separate location in order to maintain their integrity. If the Cloud network was to

crash or somehow the files were all deleted, this would be a critical problem and could possibly

lead to the shutdown of several healthcare locations.

Portability Due to the MediCloud network being a fixed system that others will connect to.

There will not be much need for it to have portability. Once we develop the Cloud network we

will not be transferring it to a different type of software or hardware. Over time the hardware

and software will need to be updated to maintain efficiency however this is not the same as

completely changing it over to a different system. At its core, MediCloud is nothing more than a

large database and so the software itself will not be very complicated. If the system ever needed

to be transferred, it would primarily come down to moving pieces of data from one network to

another and therefore portability is not that much of an issue.

Scalability Scalability is an important aspect of our network as each node that it will connectto, such as hospitals or private practitioner offices, will have very different infrastructures and

different volumes of information. Being able to scale the system to work as efficiently as

possible for different sized nodes is an important aspect of our network that will affect the

overall performance. Overtime the network will become connected to more nodes and receive

more queries on a daily basis. In order for it to be able to handle this increasing amount of

connectivity, regular assessment of the network will need to be performed in order to manage the

servers size and speed.

Interchangeability An aspect of interchangeability that will need to be addressed is the

replacing of healthcare providers current internal databases with MediClouds. Medical recordsneed to be accessible at any given time; therefore the transition of a current network to the

MediClouds will need to be instantaneous without any sort of loss in integrity and accessibility.

This same principle would apply to software as well, as any kind of upgrade or patch concerning

the cloud would need to be applied flawlessly.

8/2/2019 Phase 5 - Team 32

13/58

13

Sustainability Sustainability is an issue that will need to be dealt with as the requirements for

both the MediCloud and healthcare community will change overtime. Computing hardware and

software is a constantly changing and growing area of technology that sees many new iterations

of content. The amount of growth in technology over the years would have a definitive impacton MediCloud as it would require numerous changes while still being able to function. If an

upgrade or change in hardware were to occur it would need to be implemented without

disrupting the networks use or functionality. This principle also applies to the healthcare

community as the MediCloud system will need to be able to accommodate new forms of medical

information and the policies and laws surrounding them. Any change to the system, regardless

of its source, will need to be dealt with without compromising its functionality.

Interoperability Interoperability is an important aspect for MediCloud as the types of both

hardware and software change within different healthcare centers. Each node in the network will

have the same type of hardware in terms of their internal servers; however the way that theserver interacts with the healthcare centers various software and hardware will be quite different.

Our network will have to be able to handle not only multiple operating systems but different

kinds of text, image and video editing software. The exchanging of this information with other

nodes is also a prime concern as those healthcare centers will need to be able to view and edit

this existing data without any change to its integrity. It will be important to make sure images

and videos do not lose unacceptable amounts of data and quality when being compressed and

transferred throughout the cloud.

Usability Usability may be one of the primary technical concerns within MediCloud. The

systems purpose is to be used and provides nothing if its not used properly. Many of theindividuals who will be accessing and editing data may not have much experience with technical

systems and therefore will have a harder time understanding one once given to them. It is

important that the MediCloud interface be as clear as possible while also providing the precision

and breadth required for the creation and viewing of medical records. The interface will initially

have only a couple commands for the creation of or search for a record; however once the record

has been found or created, a healthcare employee can begin adding or editing data within it.

Each form created will be comprised of simple text boxes in order to avoid confusion and

provide a clear way of inputting data.

Technical Requirements

Input and Output Requirements

MediCloud is all about the exchange and storage of information, so it is important to

specify what these inputs and outputs exactly are. For our initial design, there will not be any

automated streams of data into or from the application; everything will be contained within it.

Data will flow between the databases and the web browser all within the application. At some

8/2/2019 Phase 5 - Team 32

14/58

14

stage, it would great to have MediCloud integrate with applications that are used within medical

facilities for creating, storing, and displaying data, but that his just not feasible for the initial

design.

However, that does not mean that data cannot be entered into the system or retrievedfrom it. For the initial design, it will have manual record entry where new patient records can be

created through a web interface. Records can then be retrieved through this same web interface.

Records can also be exported from the web interface and imported back in for redundancy

purposes.

Platform Requirements

Because our database will be web based software, all data exchange and and activity will

be through a web browser, thus eliminating the need for a specified operating system or

platform. As long as the hosting computers web browser has the basic capabilities of industry

standard web browsers, our software will be compatible with virtually any platform on themarket.

Hardware

Hardware Functionality

In order for this system to work efficiently, it must possess state of the art hardware. This

includes the most powerful processing units and the largest digital storage drives. Simply put,

our hardware will have the capability to handle very large amounts of data at a very fast rate.

According to the AHA, there are nearly 6,000 hospitals in the the United States. According to

our hospital of focus, Mount Nittany Medical Center, their storage space alone approaches 50

terabytes. When these numbers are multiplied together, the necessary storage for the currenthospitals in the country approaches 300 petabytes. When accounting for potential growth of

hospitals, expansion of health care systems, and necessary backup and recovery storage, it is

reasonable to expect a necessary storage amount of one exabyte over the entire cloud system.

Processing power requirements are slightly more difficult to calculate. On this system,

demand for data would be high and constant. Every practitioner in every hospital and health care

facility would be requesting data on a daily basis for a multitude of patients. Because of the

demand and large amounts of data being processed, processing requirements would be well into

the hundreds of terahertz of clock speed.

Hardware CharacteristicsHardware on this system will be housed in several data centers spread across the United

States. Each data center will have its own unique characteristics based on local climate,

functionality, geographical location, and usage. Every data center will be directly accessible for

technicians to diagnose hardware issues on site, and the majority of the data centers will have

staff on site at all times for routine hardware maintenance.

8/2/2019 Phase 5 - Team 32

15/58

15

Off site diagnosis will also be possible through network access of the hardware data

center hardware. A time consuming and costly on site diagnosis would only be necessary if a

network failure should occur, or if the problem is not diagnosable through virtual access.

Software

Software Functionality

There are a number of different software functions that need to be in place for this system

to work. It needs to run on multiple operating systems, have access to local and centralized

databases, a data connection, and some form of security system.

MediCloud software should be able to run on at least the Windows, Macintosh, and

Linux operating systems for maximum benefit. This allows hospitals to work with whatever

infrastructure or systems that have in place. Making the software run on multiple Operating

Systems also allows for redundancy in case one set of systems faces a security breach.

There are two types of databases that need to exist. A hospital using the software needs alocal database with all of the patient information that is relevant to its doctors. This also helps in

case the network connections go down. There also needs to be a centralized database that will

hold all of the information and serve as the cloud that hospitals will sync to and from. Both

databases would preferably be run on the same DBMS and use the same software.

In addition, the MediCloud will operate as both a client and server. The central database

will be run from a server and dispatch information from the database. Hospitals will purchase a

client that will have access to their own databases and the servers databases. The client will

check for changes in either database and seek to reconcile the differences.

To have any real impact, the MediCloud needs to be able to communicate with the

network. This is a basic functionality, but the software itself needs to be built to communicatewith the server, compare differences, and reconcile those differences.

Security is highly important in this software because of the importance of its contents.

There needs to be encryption in the data, databases, and communications. There also needs to be

some form of protection or backup in case a malicious user does change records. This could be

an automated system that would report any unusual changes or automatically restore corrupted

records. Protection against corrupted data is a key component, as corruption severely impacts a

system. Other precautions need to be taken as well, such as verification of who is using the

system or making sure that registration or records are current.

Software CharacteristicsSoftware used for the MediCloud should be separated into at least two packages, one package for

the server and one for the client. From there, the client and server both need to be able to be

upgraded quickly and efficiently, so the software should be modular, if possible. It could run

either as a web application or as an installed application.

8/2/2019 Phase 5 - Team 32

16/58

16

Data Requirements

At the most basic level, data will be grouped into a patient file. This will include personal

information and identifying information such as name, age, Social Security Number, date ofbirth, etc. This main file will then contain a collection of data for the medical record. This will

include a general record file, then a series of appointment files.

Each appointment will be broken down by its elements: the date, time, location, a field

for notes, and a section for any images or other similar records to be attached. Essentially,

everything piece of data currently handled by a health care provider in current records will be

digitized.

Whenever a patient is treated or seen by a health care provider, the general information

listed in the patient file will be updated and then an appointment record will be added. Then, this

will sync with the cloud, updating the general information and adding the new appointment to

the database.

A data model for the database is as follows:

Patients Vaccinations Appointments FamilyHistory Locations CurrProblems

Last Name

First Name

Middle

Name

Sex

Date of BirthStreet

City

Zip Code

Blood type

Organ

Donor

Patient

Appointment

Description

Patient

Location

When

Notes

Images

Video

Patient

Cancer

Diabetes

Heart

Birth Defect

KidneyMuscle

Neurological

Seizure

Name

Street

City

Zip Code

Description

Patient

Problem

Diagnosed

Appointment

Treatment

Allergies CurrMeds PastMeds CurrDrugs PastDrugs PastProblems

Patient

AllergyTreatment

Patient

TypeFrequency

Dosage

Reason

Patient

TypeFrequency

Dosage

Reason

Patient

TypeAmount

Patient

TypeAmount

Patient

ProblemDiagnosed

Appointment

Treatment

8/2/2019 Phase 5 - Team 32

17/58

17

8/2/2019 Phase 5 - Team 32

18/58

18

Communication Requirements

On the most basic level, the MediCloud needs a data connection with some redundancy.

It must be able to connect over a wired network using Ethernet connections. It must also be able

to use wireless communications, preferably a wireless router. These modes of communicationshould be handled by the OS. An additional level of redundancy would be the inclusion of a

telephone connection so that in the event of a network failure, the client end of the MediCloud

would be able to dial in to the server to update or retrieve data.

Development Requirements

For development, the required systems are:

Computers running Windows OS to write and test code

Computers running Macintosh OS to write and test code

Computers running Linux OS to write and test code

Windows Server Windows-based DBMS

Windows-based database

This system needs to be developed in the form of a web application so that it is platform

independent. Testing needs to be done on all platforms to be sure that there are no errors, but

there will be no locally run executable file. The server will likely be built on a Windows server

or a Linux server running a DBMS. Coding could be done in Java, since the application will take

on the form of an on-demand web service.

To test this application, a sizeable group of Windows, Macintosh, and Linux computers

must attempt to connect to the server and access and change records simultaneously. Errors inthe final system output should be examined in this way. The size of the test group should be

gradually increased so that the bugs can be worked out in a manageable fashion.

Technical Requirements Mapping

The MediCloud has two functional requirements: health care providers must be able to

store information in the cloud and other facilities must be able to retrieve that information about

patients. These are broken down into a handful of more specific functional design requirements

the have been previously discussed: multiple connections, storage, creation and editing of files,

search functionality, syncing capabilities, secure authorization, backups, disaster recovery, and

legal adherence.In addition, it has several non-functional requirements. It needs to be available as much

as possible. It needs to perform well and to be secure. It needs to be able to be backed up and

data must be recoverable. The system must be portable and scalable, and it must interact with

other applications. Finally, it must be sustainable and its functions must be inter-operable.

Finally, it has many technical requirements. It needs to be able to run on multiple

operating systems, have access to centralized and local databases, a redundant data connection,

8/2/2019 Phase 5 - Team 32

19/58

19

and many security features. It also must run on multiple operating systems, have a client-and-

server type operation, and a robust data design model. Furthermore, it needs to run on hardware

that can support its online capabilities.

All of the functional requirements are met by the technical requirements. The hardwareand software both support the connections for redundancy and safety of data. Servers will store

the data, and a server-side application will create and edit files. The DBMS on the server will

allow users to search through data. Network connections and software support on the client and

server sync the records between the local and remote databases. Security features included in the

technical design require secure authorization and encrypt the data. Software on the server end

backs up the data and the physical server provides disaster recovery.

The non-functional requirements are also met by the technical requirements. For

availability, the system runs over the redundant data connection. Performance and security are

available on the server. Data is backed up and maintained by the robust data model stored on the

server. In order to make the system portable and accessible, it runs as a web application, whichallows security updates and system maintenance to be done quickly. Finally, the software is

designed to work as a set of packages, so it will be inter-operable.

Design Constraints

This project is subject to many design restrictions. First, it will be impossible to test the

systems maximum effectiveness simply because there several million people in the United

States alone and it would be difficult to create that many tests. Second, the design would be

limited to two operating systems for the sake of time and interest. Third, even if the application

were to launch, it would only have access to the files of the subscribing hospitals, so the

effectiveness of the software would be limited to interest.

FUNCTIONAL DESIGN

MediCloud will have two main functions: the ability for health care practitioners to store

information in the cloud for other facilities to retrieve and the ability for health care practitioners

to easily retrieve information about unknown patients who have visited an health care facility

before.

8/2/2019 Phase 5 - Team 32

20/58

20

Activity DiagramsThe two activity diagrams show the two main functions that MediCloud will support. In

the first diagram, the health care practitioner will search for a patient to see if the patient exists

either in the local database or within MediCloud. If they do not exist, a local entry will be made

and any available information will be retrieved if possible. In the second diagram, information

about a current patient will be added to the local database and then synced to MediCloud for use

in the future.

8/2/2019 Phase 5 - Team 32

21/58

21

8/2/2019 Phase 5 - Team 32

22/58

22

Use CasesThe following Use Case Diagram shows the use cases that are part of the two major

functions of MediCloud. The Use Case Narratives and the Use Case Glossary explain each use

case, its function, and how it fits into the overall system.

Use Case Narratives

Use Case Name: Gives Information

Primary Actor(s): Patient, Entering Practitioner

Stakeholders and Interests:

Patient: The patient will be giving the information

Entering Practitioner: The entering practitioner will be receiving the information from the

patient.

Receiving Practitioner: The receiving practitioner will receive the information about a patient

when they come in for medical treatment.

Description: The patient gives their information to the entering practitioner

Trigger: Whenever the patient goes to a medical care facility

Type: External

Relationships:

8/2/2019 Phase 5 - Team 32

23/58

23

Association: Entering Practitioner and Patient

Flow of Events:

1. The patient gives their information to the entering practitioner

Subflows: None

Use Case Name: Enters Information

Primary Actor(s): Entering Practitioner



Entering Practitioner: The entering practitioner will be entering the information that the

patient gave.

Receiving Practitioner: The receiving practitioner will receive the information about a

patient when they come in for medical treatment.

Description: The entering practitioner will be entering the information that the patient gave.

Trigger: After the patient has given their information.

Type: External

Relationships:

Association: Entering PractitionerIncludes: Stored Locally

Flow of Events:

1. The entering practitioner receives the information from the patient

2. The entering practitioner inputs the information

Use Case Name: Stored Locally


Stakeholders and Interests:Patient: The patient will be giving the information

Entering Practitioner: The entering practitioner will be entering the information that the patient

gave.



8/2/2019 Phase 5 - Team 32

24/58

24

Description: The information that was entered will be stored at the facility in a local database.

Trigger: After the entering practitioner has entered the information

Type: Internal

Relationships:

Includes: Enters Information, Stored In Cloud

Flow of Events:

1. The information is entered.

2. The information is stored in the local database.

Subflows: None

Use Case Name: Stored In Cloud





gave.



Description: The information that was entered into the local database will be synced and stored

in the cloud.

Trigger: After the entering practitioner has entered the information into the local database, it is

synced with the cloud.

Type: Internal

Relationships:

Includes: Stored Locally

Flow of Events:1. The information is entered into the local database.

2. The information is synced with the cloud

Subflows:

1. If there is no network connection, the system waits before checking again.

2. Once connectivity is restored, the information is synced.

8/2/2019 Phase 5 - Team 32

25/58

25

Use Case Name: Searches Information

Primary Actor(s): Receiving Practitioner




gave.



Description: The receiving practitioner enters information from the patient to find their

records.

Trigger: The receiving practitioner receives information from the patient

Type: External

Relationships:

Association: Receiving Practitioner

Includes: Checks Locally

Flow of Events:

1. Receiving practitioner is given information about the patient

2. Information is entered to pull records

Subflows: None

Use Case Name: Checks Locally





gave.Receiving Practitioner: The receiving practitioner will receive the information about a patient


Description: After entering the information to search, the system first checks to see if the

patient is in the local database.

Trigger: The receiving practitioner enters the information to be searched.

8/2/2019 Phase 5 - Team 32

26/58

26

Type: Internal

Relationships:

Includes: Checks LocallyExtends: Pull From Cloud

Flow of Events:

1. Receiving practitioner enters the information from the patient.

2. The local database is queried for results

Subflows: None

Use Case Name: Pulled from Cloud





gave.



Description: The system checks the cloud for any new information about the patient that it

does not have stored locally.

Trigger: The local database is queried for results and the system then queries the cloud

Type: Internal

Relationships:

Extends: Checks Locally

Flow of Events:

1.The local database is queried for results.

2. The cloud is queried to determine if there is any new information.

Subflows:

1. If there is no network connection, the system waits before checking again.

2. Once connectivity is restored, the information is then pulled down.

8/2/2019 Phase 5 - Team 32

27/58

27

Use Case Glossary

Use Case Name Use Case Description Participating Actors and Roles

Gives Information The patient gives their information to the entering

practitioner

Patient (External data giver)Entering Practitioner (External

data receiver)

Enters Information The entering practitioner

will be entering the

information that the patient

gave.

Patient (External data giver)

Entering Practitioner (External

data inputer)

Stored Locally The information that was

entered will be stored at

the facility in a local

database


data inputer)

Stored in Cloud After the entering

practitioner has entered the

information into the local

database, it is synced with

the cloud.


data inputer)

Searches Information The receiving practitioner

enters information from

the patient to find their

records.

Receiving Practitioner (External

data receiver)

Checks Locally After entering the

information to search, the

system first checks to see

if the patient is in the local

database.


data receiver)

Pulled From Cloud The system checks the

cloud for any newinformation about the

patient that it does not

have stored locally.


data receiver)

8/2/2019 Phase 5 - Team 32

28/58

28

TECHNICAL DESIGN

Technical / Application ArchitectureThe two main pieces of software that will be used for the application is MySQL for the

databases and nginx for the web server. The website will be coded in HTML and PHP to take

advantage of the databases and easy exchanging of information. The central server will only

have a MySQL that clients pull data from and push data to. On the client side, they will also have

a server running MySQL that will house the local information. This client server will have the

web server that the client will access to interact with the MediCloud system.

In developing this system, we used many UML diagrams to direct how we wanted the

system to operate. Through using these diagrams, we were able to establish our overall technical

design, what data we needed to store, how to store the data, and how information would flow

through the system. We had an initial rough idea of how we wanted things to operate, but

diagramming how the system would work showed some things we had overlooked in our initial

design.

8/2/2019 Phase 5 - Team 32

29/58

29

We developed our initial application to be web-based so it could serve as a proof of

concept. This also has the advantage of being operating system independent and can run on

anything that has a web browser and network connectivity. Because of this, there is little risk of

the application itself failing or having problems unless network connectivity it lost. Thesetechnologies were chosen because of their speed, robustness, and cost.

UML Diagrams

Structural

Class

8/2/2019 Phase 5 - Team 32

30/58

30

Component

Deployment

8/2/2019 Phase 5 - Team 32

31/58

31

Behavioral

Activity

8/2/2019 Phase 5 - Team 32

32/58

32

Use Case

State Machine

8/2/2019 Phase 5 - Team 32

33/58

33

Sequence

QUALITY MANAGEMENT

Activity Reviews/WalkthroughsIn order to keep the stakeholders involved in the project we will hold monthly meetings

in which everyone will have the chance to participate and include their questions, comments, and

concerns with the life of the project. The meetings will begin with the significant changes for the

project from the last meeting presented by the project team. For the stakeholders to understand

what is going on in the meetings the deliverables for the next stage will be posted on a website

for the stakeholders to look at 48 hours before the meeting proposed time.

A project review is critical to maintaining control and monitoring the life of the project.

A facilitator will be designated for each project review in which the project manager and project

team will all attend. The facilitator will be in charge of keeping the meeting running smoothly by

keeping the discussion from drifting off. These reviews will take place during the completion of

each major phase to go over all the activities and tasks that were completed in the phase, as well

as prepare the team for the next phase and what is expected of them.

The project team will conduct code walkthroughs nearing the end of the project to show

the requirements are being met. The two people in charge of the walkthrough are the developer

and the reviewer. These walkthroughs will be done in an informal manner with the reviewer does

8/2/2019 Phase 5 - Team 32

34/58

34

on the spot corrections to the code. At the later stages of the project these will be conducted in a

more formal manner in which the reviewer will examine the codes algorithms, techniques and

style.

To test the code there will be manual testing in which randomly generated user profileswill be run on the MediCloud. Examples of these are then used for the deliverables to show the

stakeholders. These test scripts are run after every formal walkthrough noting any changes in the

code. These will also be compared to the current system in place at the hospitals.

Tools and TechniquesWe will be using the GANNT chart tool as a way to track our progress throughout the

course of the project. This is the easiest way to display visually the scheduled time of a task or

activity. It also provides a clear communication channel for the team to understand what is

expected of them as well as keep the stakeholders informed on the projects progress. It is also

easier for the project manager to keep control of the project knowing what each person is

working on and at what point they should be at in their individualized task. Every time an

important activity is completed within the GANNT chart it is appropriate to report that it is

completed. At each of the monthly meetings the GANNT chart would be a good visual tool for

stakeholders to judge the level of completion for the project.

User Acceptance and VerificationIn the medical field it is very important that you gain the acceptance from the patient

before any medical practice takes place. That is very important to the project team in relationship

to the MediCloud. Users are not going to want their very important medical information floatingaround in space to be accessed by anyone. In order for the MediCloud to really kickoff the

project team would have to gain a dedicated following of patients that would believe that the

MediCloud is really progress and a way of the future. To get patients to accept the practice we

would have to educate them first on the benefits of MediCloud, not to be overshadowed by the

very scary negative aspects. With those negative aspects we have to gain the trust of the patients

by explaining how we are going to control the risks.

To gain user acceptance education plays a key role. There will be conferences in which

any patient interested in the new project can attend to learn more about how this will affect them.

Healthcare practitioners will inform their patients of MediCloud and offer their records be placed

on the new system. After a brief introduction of MediCloud by the practitioner the patient will beable to sign off on the new system or given information on how they can find out more on the

system. Media will also play a role in such a large project informing a larger audience the

changes in the healthcare industry.

The project will be able to successfully transfer the information from the patients past

history onto the cloud. Using the past system the project team will be able to identify the

requirements for the new system as well as make improvements. If information from the past

8/2/2019 Phase 5 - Team 32

35/58

35

system isnt making it onto the new one then the project requirements are coming up short. To

have a successful system all information from the old system must have a place in the new

system.

To test the system there will be generated profiles of non-existent patients that willprovide the necessary testing techniques required. Test subjects will be used with their consent to

provide better feedback before the implementation of the final project. Once the project is

completed and actual patients are using MediCloud a performance and risk reports will be

generated quarterly to ensure the highest standards are being used and no information is being

leaked outside of the system.

Project and Industry StandardsThe database is SQL for use on Windows, Linux, and Macintosh operating systems. The

project team will be using the object-oriented structure with the java programming language.

This will allow the medical staff to work with graphics, text, and voice better than other type of

system. Microsoft Access will be used for the creation of the database. The user can access their

individual information from the database. The practitioner only accesses the patients information

under the circumstances in which they are working with the patient. The user can only edit their

profile in updating personal information not medical information. The practitioner can access the

profile only to edit the users medical records.

Status reports will be prepared to inform the project manager of the progress. The

manager will have to run through several of these to keep him informed. These will be relatively

short but contain the most important information to the status of the project. These will be one-

page in length well-written and have an intended audience and purpose for the report. The most

important information is up front and the least important is near the bottom. Color coded is also

another requirement to put the tasks that are behind schedule or running into trouble in red and

the tasks that are running correctly in green everything else that is unsure is in yellow. Each

report will contain risks and issues that could hurt the stakeholders, milestones three at a

minimum but no more than seven, and a status report a few sentences in length.

Staff meeting will be scheduled at the beginning of the project for up to six months ahead

of time. Each staff member is required to bring a notebook with them that will hold all meeting

notes. A week prior to all staff meetings there will be a specified agenda sent out to all the

participating members. General rules within the meetings are only one person speaking at a time,

sticking to the agenda, and maintaining respect among members. A master agenda will be sent

out 48 hours before the meeting. Everyone is to prepare for the meeting beforehand. Everyone is

to contribute and brainstorming will take place to help define solutions to the problem.

In order to achieve a successful project performance and quality standards have to be

met. It is the responsibility of each staff member to obtain the highest quality of work. Each

member that is assigned a specified task or assignment will be responsible for the completion of

that assignment. If the standards are not met we will replace the member with a new member.

For approval of this project the MediCloud must be a secure place where patients can safely

8/2/2019 Phase 5 - Team 32

36/58

36

protect all their personal records for use by only the practitioner that is working with the patient.

All risks must be reduced to the bare minimum upon completion of the project in order for these

standards to be met.

PROJECT MANAGEMENT

Project AssumptionsFor this project, we can assume that we have ample funding and resources. We have

been given sufficient technology to gather data on our chosen topic, and provided with team

members that have experience in the field of IT integration. Each team member has specific

talents that add to the structural integrity of the overall team, and we are confident that we will

be able to complete the project and all requirements in a timely manner.

Project ConstraintsFor this project so far, we appear to have ample funding and resources to meet our goals.

Our concerns currently include time constraints for completing the project and providing an

ample presentation to explain our accomplishments. We are also concerned with gathering

enough data to accurately convey what we wish to demonstrate in our project .

Work Breakdown Structure (WBS)

8/2/2019 Phase 5 - Team 32

37/58

37

Gantt Chart

Roles and ResponsibilitiesSo far, each team member has assumed the following roles:

Michael - Team Leader and Diagrams

Ian System Architect and Requirements

Sam Quality Management

Grayson Technology and Security

Andy - Project Management

Change ManagementOur team is prepared to deal with any changes that may occur. Combined with our team

member experience and wide availability of resources, change in the project can be easily

handled. The team leader is highly experienced with project changes and major alterations in

original project plans. We do not plan to have single points of failure in our project phases.

Thus, each phase will be highly flexible to any possible alterations.

Issue ManagementIf issues arise during the project, our team will evaluate each of them on an individual

basis. The purpose of this evaluation will be to determine if the issue at hand is an immediate

threat or if it is something that will work itself out over time. If the issue is an immediate threat

to the success of the project, the full effort of the team will be implemented to correct the issue as

quickly and efficiently as possible.

8/2/2019 Phase 5 - Team 32

38/58

38

Issue LogSo far, we have had no issues with the project. Everything has gone according to plan

and without incident. If such issues should arise, they will be logged accordingly.

Communications and ControlProject stakeholders will be communicated with via email for the majority of the project.

If something unexpected arises during the project and a meeting becomes necessary, that will be

handled at the appropriate time. The project team will use a variety of digital communication

techniques. These include collaborative online documents and meetings The team will also

meet in person on a regular basis to discuss project progression and complete tasks that are best

performed in a physical environment. If an unexpected issue arises during the project, an

emergency meeting can be called for the team to discuss possible resolutions.

PROJECT DEMONSTRATION

For our project demonstration, we participated in an expo for incoming students to Penn

State. The demonstration took place in the foyer of the IST building where each group was

given an area to demo their semester project to potential incoming students and their parents.

Our table consisted of two laptop computers and a trifold outlining some of the major points of

our project. These points included Cloud Computing, everyday applications of Cloud

Computing, a network outline, and a summary of the project. The two laptops representedseparate hospitals and participants were given the opportunity to either view the demonstration

of data transfer between the two laptops or participate in a hands on activity where they entered

their own information and watched as it moved between the two computers. This demonstration

showed that our developed application could be used in a real world scenario.

When participants approached our table, we first assessed their current knowledge of

Cloud Computing in order to avoid explaining a concept that they were already familiar with. If

necessary, we explained the fundamentals of Cloud Computing and how it could be applicable in

a healthcare field. Following this explanation, we allowed the participants to view our live

demonstration. We took questions and responded to comments, and promoted discussion about

our topic. Many of the participants were interested in our major and what we had learned in thepast four years. We responded to these curiosities as well, and answered all questions to the best

of our ability.

8/2/2019 Phase 5 - Team 32

39/58

39

PROJECT SUMMARY STATEMENT

Developing the idea of the MediCloud through creating a prototype for presentation wasan interesting venture. The MediCloud had several unexpected achievements. The working

prototype worked very smoothly, and while it was incomplete, it demonstrated all of the key

components. It was simple yet elegant, and the web interface made it easy to operate. There were

several problems with it, though. First, the database design was far too complex to create in any

reasonable amount of time. There was more information on the medical industry that needed to

be collected before real progress could be made in the databases and system. Finally, creating a

system of this magnitude and implementing would be a huge undertaking that would require a

large client base to be effective. Currently, no single organization owns more than 40% of

medical software, so there is also competition from other software providers to be contended

with.Additional problems included the legal implications of running a large-scale cloud

application like the MediCloud. First of all, finding a way to continually secure the system would

be a nightmare, as well as trying to develop user-customized versions, since all information

would be available to all subscribers. The legal end would be a hassle to deal with in addition to

actually securing the system. Second, hospitals are businesses, not services, so asking them to

use this software would be difficult since they own their own records and customers. Storing data

in a centralized server could be seen as infringement of information rights, among other things.

The future of the MediCloud seems somewhat dim based on the number of problems

associated with its use. While the software itself could definitely be created and secured, getting

support and traction in the market would require a large amount of capital. If it were given achance, it could revolutionize the way that medical computing and software operated. Still, if the

MediCloud were to further develop, it could find its niche in the market easily as the only cloud-

operated and most convenient software available to hospitals and medical service providers.

During this project, the team learned several important lessons. First, we learned how to

work together in creating a vision and following through on it. There was conflict in deciding

what direction to take, but we worked together once that direction was chosen. We also learned

the importance of doing research ahead of time. As the project developed, we learned that most

of the opposition to its execution would not be to the implementation of the software, but on the

legal and social end. Finally, it seems that most innovation is resisted by an unnecessary number

of social limiting factors. Revolutionary ideas are easy to generate, but they are limited by theenvironment, laws, and fears associated with the idea.

8/2/2019 Phase 5 - Team 32

40/58

40

APPENDICES

Appendix 1: WEEKLY STATUS REPORTSWEEKLY STATUS REPORT

To: Professor Hill

From: Team 32

Subject: Status

Week Of: 1/23

ACTIVITIES COMPLETED THIS WEEK

Completed Deliverables: NoneFirst team meeting

Problem and project idea decided upon

Delegation of tasks for Functional Design Document

ACTIVITIES IN PROCESS

Completing Functional Design Document

ACTIVITIES TO BE STARTED NEXT WEEK

Second meeting to finalize Functional Design DocumentPreparation of Functional Design Review

ISSUES FOR IMMEDIATE ATTENTION

None

8/2/2019 Phase 5 - Team 32

41/58

WEEKLY STATUS REPORT

To: Professor Hill

From: Team 32

Subject: Status

Week Of: 1/30


Completed Deliverables: Functional Design

Second team meeting

Created content for deliverable

Met to finalize and compile final document


Preparing for Functional Design Review


Preparation of Functional Design Review


Evaluate feedback from Functional Design document to determine if actions need to be taken

8/2/2019 Phase 5 - Team 32

42/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 2/06


Completed Deliverables: Functional Design Review

Third team meeting

Met with professor for functional design review

Met to review Functional Design document and make changes for resubmission


Preparing Functional Design Document resubmission


Starting gathering resources for Technical Design Document


Create Functional Design Document resubmission for Wednesday 2/15

8/2/2019 Phase 5 - Team 32

43/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 2/13


Completed Deliverables: Functional Design Document Resubmission

Completed and resubmitted the Functional Design Document


Preparing Technical Design Document


Compiling pieces of Technical Design Document


None

8/2/2019 Phase 5 - Team 32

44/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 2/20


Completed Deliverables: None

None: were unable to meet


Preparing Technical Design Document


Finalizing Technical Design Document


Need to have team meeting for Technical Design Document

8/2/2019 Phase 5 - Team 32

45/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 2/27


Completed Deliverables: Technical Design Document

Two team meetings to organize Technical Design Document work and finalize work


Preparing Technical Design Review


Spring Break!

Prepare for Technical Design Review after Break


None

8/2/2019 Phase 5 - Team 32

46/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 3/12


Completed Deliverables: Technical Design Review

Team meeting to discuss Demonstration


Creating the pieces of the demonstration


None


None

8/2/2019 Phase 5 - Team 32

47/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 3/19



Team meeting to work on poster


Creating website and database system

Creating poster

ACTIVITIES TO BE STARTED NEXT WEEK None


None

8/2/2019 Phase 5 - Team 32

48/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 3/26


Completed Deliverables: Phase 6: Demonstration

Met to finalize demonstration

Completed demonstration website

Completed demonstration poster




Begin preliminary work on Phase 5.


None

8/2/2019 Phase 5 - Team 32

49/58


To: Professor Hill

From: Team 32

Subject: Status

Week Of: 4/2



Began discussing the Phase 5: Final Report.




Finish Phase 5.


None

8/2/2019 Phase 5 - Team 32

50/58

50

Appendix 2: EXTERNAL COMMUNICATIONSNone

8/2/2019 Phase 5 - Team 32

51/58

51

Appendix 3: GLOSSARYNone

8/2/2019 Phase 5 - Team 32

52/58

52

Appendix 4: TEAM CONTRACTTeam Contract

Team Name: Innovation in Motion

Course/ Section: IST 440W - 003

Project Team Members Names and Sign-off

Note: Each team is required to have one Team Leader.

The team leader is: Michael Humiston

Responsible for managing the group project, beginning with a work plan that includes a

topic selection and responsibility matrix. Creating a communication plan may be as

simple as coordinating email or an Angel group. The leader also may schedule meetings

(live or virtual) and mediate member performance.

Primary liaison with instructors, including posting milestones to Angel dropboxes. Notethat each team member is free to meet with the instructor.

Member Name (Print) Contact Information Member Signature

Michael Humiston [email protected]

330-730-0497

Ian Busko [email protected]

814-386-1537

Sam Evans [email protected]

814-421-6030

Grayson Dinsmore [email protected]

814-404-0673

Andy Deasey [email protected]

724-866-0291Code of Conduct - Three Strike Policy

The Code of Conduct should help your team understand the degree of professionalism that is

expected throughout the project length. This also includes a warning system that can be used

with members not complying with contract.

We agree to:

Communicate at a minimum frequency of a weekly basis through email and/or telephone

to keep all team members up to date with project work, and

Participate actively in weekly meetings, and

Make sufficient effort to complete the project, on time, and on scope, and

Allocate work equally among team members, and

Confront each other to resolve any conflicts within our team, and

Authorize our team leader to inform our instructor in the case any conflict escalates out

of control, and

Notify all team members, in advance, if a team member cannot:
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]

8/2/2019 Phase 5 - Team 32

53/58

53

participate in a meeting, or

complete an assigned task on time.

Honor and respect all university rules and regulations.

Any infractions of these will result in a strike. After three strikes the rest of the group members

will speak with the TA and professor to see if the problem can be recitifed.

Participation

Equal participation should be expected by all team members.

We agree to:

Check emails daily and in order to not miss important emails regarding the group project

coming from other team members.

Respond each time an email is received from a team member, so that there is no doubt

whether the email was received.

Allocate the work equally among the team members.

Allow the team leader to set due dates with agreement from the other team members.

Monitor, at each meeting, the work that was due from each team member at that meeting.

Exchanged and review the work dome by all other team members.

Discuss work that is not up to group expectations.

It is the contributors responsibility to revise his/her work to be satisfactory by the next

night, and he/she will then distribute the improved work to all team members at that time.

Division of Work

Deadlines and standards should be created by each team so ensure an equal workload foreveryone involved.

We agree to:

Allocate work roughly equally between all members. NO one person should complete an

entire assignment.

Set and meet deadlines that allow review and edit of all documents by all team members.

Monitor all project activities to assure that each member works on for every assignment

to ensure that no one is doing more or less than others.

Communication

Each team must agree to the methods by which they will communicate with one another whether

it be through email, aim, Skype, or face-to-face. The team may also want to discuss documentsharing sites and other services that may make the team's collaboration more effective and

efficient.

We agree to:

Use Email for our daily communication skills, however for more serious issues we will

schedule face to face meeting times.

8/2/2019 Phase 5 - Team 32

54/58

54

Use ANGEL discussion boards for discussing group deliverables as well as online

messaging.

Assure the exchange of all documents to all team members so the entire team is fully

informed.

Meeting Guidelines

Your team may want to determine a location and time for weekly or bi-weekly meetings.

We agree to:

Create and fill out a doodle document to establish a meeting time that is acceptable for

all.

Work together to make sure we accomplish all that need to be done at our meetings.

Record the agreements reached concerning important dates and assignments agreed during team

meetings.

8/2/2019 Phase 5 - Team 32

55/58

55

Appendix 5: DATA DICTIONARY

Table Name Column Name Description Key Type Data Type Null?

Patients PatientID Unique ID number for thepatient

Primary char N

Patients LName Patient last name text N

Patients FName Patient first name text N

Patients MName Patient middle name text Y

Patients Sex Patient sex text N

Patients DOB Patient date of birth datetime N

Patients Street Patient home streetaddress

text N

Patients City Patient home city text N

Patients Zip Patient home zip code text N

Vaccinations VaccinationID Unique ID number foreach vaccination record

Primary char N

Vaccinations PatientID ID of patient that receivedvaccination

Foreign char N

Vaccinations AppID ID of appointment thatpatient receivedvac

Phase 5 - Team 32

Documents

Transcript of Phase 5 - Team 32