Upload
grayson-dinsmore
View
216
Download
0
Embed Size (px)
Citation preview
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
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.
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
Primary Actor(s): Entering Practitioner
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.
Receiving Practitioner: The receiving practitioner will receive the information about a patient
when they come in for medical treatment.
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
Primary Actor(s): Entering Practitioner
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.
Receiving Practitioner: The receiving practitioner will receive the information about a patient
when they come in for medical treatment.
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
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.
Receiving Practitioner: The receiving practitioner will receive the information about a patient
when they come in for medical treatment.
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
Primary Actor(s): Receiving Practitioner
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.Receiving Practitioner: The receiving practitioner will receive the information about a patient
when they come in for medical treatment.
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
Primary Actor(s): Receiving Practitioner
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.
Receiving Practitioner: The receiving practitioner will receive the information about a patient
when they come in for medical treatment.
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
Entering Practitioner (External
data inputer)
Stored in Cloud After the entering
practitioner has entered the
information into the local
database, it is synced with
the cloud.
Entering Practitioner (External
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.
Receiving Practitioner (External
data receiver)
Pulled From Cloud The system checks the
cloud for any newinformation about the
patient that it does not
have stored locally.
Receiving Practitioner (External
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
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: Functional Design
Second team meeting
Created content for deliverable
Met to finalize and compile final document
ACTIVITIES IN PROCESS
Preparing for Functional Design Review
ACTIVITIES TO BE STARTED NEXT WEEK
Preparation of Functional Design Review
ISSUES FOR IMMEDIATE ATTENTION
Evaluate feedback from Functional Design document to determine if actions need to be taken
8/2/2019 Phase 5 - Team 32
42/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 2/06
ACTIVITIES COMPLETED THIS WEEK
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
ACTIVITIES IN PROCESS
Preparing Functional Design Document resubmission
ACTIVITIES TO BE STARTED NEXT WEEK
Starting gathering resources for Technical Design Document
ISSUES FOR IMMEDIATE ATTENTION
Create Functional Design Document resubmission for Wednesday 2/15
8/2/2019 Phase 5 - Team 32
43/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 2/13
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: Functional Design Document Resubmission
Completed and resubmitted the Functional Design Document
ACTIVITIES IN PROCESS
Preparing Technical Design Document
ACTIVITIES TO BE STARTED NEXT WEEK
Compiling pieces of Technical Design Document
ISSUES FOR IMMEDIATE ATTENTION
None
8/2/2019 Phase 5 - Team 32
44/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 2/20
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: None
None: were unable to meet
ACTIVITIES IN PROCESS
Preparing Technical Design Document
ACTIVITIES TO BE STARTED NEXT WEEK
Finalizing Technical Design Document
ISSUES FOR IMMEDIATE ATTENTION
Need to have team meeting for Technical Design Document
8/2/2019 Phase 5 - Team 32
45/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 2/27
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: Technical Design Document
Two team meetings to organize Technical Design Document work and finalize work
ACTIVITIES IN PROCESS
Preparing Technical Design Review
ACTIVITIES TO BE STARTED NEXT WEEK
Spring Break!
Prepare for Technical Design Review after Break
ISSUES FOR IMMEDIATE ATTENTION
None
8/2/2019 Phase 5 - Team 32
46/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 3/12
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: Technical Design Review
Team meeting to discuss Demonstration
ACTIVITIES IN PROCESS
Creating the pieces of the demonstration
ACTIVITIES TO BE STARTED NEXT WEEK
None
ISSUES FOR IMMEDIATE ATTENTION
None
8/2/2019 Phase 5 - Team 32
47/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 3/19
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: None
Team meeting to work on poster
ACTIVITIES IN PROCESS
Creating website and database system
Creating poster
ACTIVITIES TO BE STARTED NEXT WEEK None
ISSUES FOR IMMEDIATE ATTENTION
None
8/2/2019 Phase 5 - Team 32
48/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 3/26
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: Phase 6: Demonstration
Met to finalize demonstration
Completed demonstration website
Completed demonstration poster
ACTIVITIES IN PROCESS
Phase 5: Final Report
ACTIVITIES TO BE STARTED NEXT WEEK
Begin preliminary work on Phase 5.
ISSUES FOR IMMEDIATE ATTENTION
None
8/2/2019 Phase 5 - Team 32
49/58
WEEKLY STATUS REPORT
To: Professor Hill
From: Team 32
Subject: Status
Week Of: 4/2
ACTIVITIES COMPLETED THIS WEEK
Completed Deliverables: None
Began discussing the Phase 5: Final Report.
ACTIVITIES IN PROCESS
Phase 5: Final Report
ACTIVITIES TO BE STARTED NEXT WEEK
Finish Phase 5.
ISSUES FOR IMMEDIATE ATTENTION
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