Phase 5 - Team 32

Phase 5: Final Report
Team 32: Innovation in Motion

Ian Busko, Andy Deasey, Grayson Dinsmore, Sam Evans, Michael Humiston
4/12/12
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.............................................................................................................................34 User 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
3
Roles and Responsibilities......................................................................................................................37 Change Management..............................................................................................................................37 Issue Management..................................................................................................................................37 Issue Log................................................................................................................................................38 Communications 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
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 Ian Busko Andy Deasey Grayson Dinsmore Michael Humiston Sam Evans Email ijb109@psu.edu asd5127@psu.edu gvd5011@psu.edu mjh5305@psu.edu sse5021@psu.edu Phone 814-386-1537 724-866-0291 814-404-0673 330-730-0497 814-421-6030
Privacy Information
This 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.
INTRODUCTION
Purpose 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 Project

The 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
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 make accessing 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 Solved

The 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.
Patients
Patients 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 Companies
Health 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.
Health care Practitioners

Health 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 throughout the 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 Approach
The 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 Objectives

This 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
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 Scope
MediCloud 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 physical medical 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.
Deliverables
Item # 1. 2. 3. 4. 5. 6. Deliverable Description Phase 1: Functional Design Report Phase 2: Functional Design Review Phase 3: Technical Design Report Phase 4: Technical Design Review Phase 5: Final Report Phase 6: Demonstration Estimated Completion Date 2/2/12 2/9/12 3/1/12 3/12/12 4/12/12 3/30/12
REQUIREMENTS DEFINITION
This section describes how the project team identified properties of the functional and technical designs, as well as the requirements of the application.
Requirements Gathering Process

To 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 Search
Ashish 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. <http://www.nejm.org/doi/full/10.1056/NEJMsa0900592>. 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. <http://www.nejm.org/doi/full/10.1056/NEJMsa0802005>. 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. <http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_040405.hcsp? dDocName=bok1_040405>.
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. <http://content.healthaffairs.org/content/24/5/1103.full>. 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): 20933. 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.
Requirements
Our 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
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. The first 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 will be 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 MediCloud system 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 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. 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
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 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. 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 same department. 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 to the 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. Only employees 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
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 of great 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 connect to, 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 records need 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.
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 impact on 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 the server 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 the individuals 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
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 retrieved from 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 the market. 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 current hospitals 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 Characteristics Hardware 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.
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 a local 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 communicate with 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 Characteristics Software 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.
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 of birth, 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 Patient Location When Notes Images Video Patient Cancer Diabetes Heart Birth Defect Kidney Muscle Neurological Seizure Name Street City Zip Code Description CurrProblems Patient Problem Diagnosed Appointment Treatment
Last Name Patient First Name Appointment Middle Description Name Sex Date of Birth Street City Zip Code Blood type Organ Donor Allergies Patient Allergy Treatment CurrMeds Patient Type Frequency Dosage Reason
PastMeds Patient Type Frequency Dosage Reason
CurrDrugs Patient Type Amount
PastDrugs Patient Type Amount
PastProblems Patient Problem Diagnosed Appointment Treatment
17
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 communication should 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 in the 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,
19 and many security features. It also must run on multiple operating systems, have a client-andserver 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 hardware and 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, which allows 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.
20
Activity Diagrams
The 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.
21
22
Use Cases
The 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:
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 Practitioner Includes: 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.
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.
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.
26 Type: Internal Relationships: Includes: Checks Locally Extends: 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.
27
Use Case Glossary

Use Case Name Gives Information Use Case Description The patient gives their information to the entering practitioner Participating Actors and Roles Patient (External data giver) Entering Practitioner (External data receiver)
Enters Information
The entering practitioner Patient (External data giver) will be entering the Entering Practitioner (External information that the patient data inputer) gave. The information that was entered will be stored at the facility in a local database Entering Practitioner (External data inputer)
Stored Locally
Stored in Cloud
After the entering Entering Practitioner (External practitioner has entered the data inputer) information into the local database, it is synced with the cloud. The receiving practitioner enters information from the patient to find their records. After entering the information to search, the system first checks to see if the patient is in the local database. The system checks the cloud for any new information about the patient that it does not have stored locally. Receiving Practitioner (External data receiver)
Searches Information
Checks Locally
Receiving Practitioner (External data receiver)
Pulled From Cloud
Receiving Practitioner (External data receiver)
28
TECHNICAL DESIGN
Technical / Application Architecture
The 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.
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. These technologies were chosen because of their speed, robustness, and cost.
UML Diagrams
Structural
Class
30 Component
Deployment
31
Behavioral
Activity
32 Use Case
State Machine
33 Sequence
QUALITY MANAGEMENT
Activity Reviews/Walkthroughs
In 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
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 profiles will 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 Techniques

We 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 Verification

In 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 floating around 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 be able 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
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 will provide 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 Standards

The 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 onepage 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
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 Assumptions
For 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 Constraints
For 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)
37
Gantt Chart
Roles and Responsibilities

So 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 Management
Our 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 Management
If 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.
38
Issue Log
So 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 Control

Project 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 represented separate 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 the past four years. We responded to these curiosities as well, and answered all questions to the best of our ability.
39
PROJECT SUMMARY STATEMENT

Developing the idea of the MediCloud through creating a prototype for presentation was an 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 a chance, 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 cloudoperated 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 the environment, laws, and fears associated with the idea.
40
APPENDICES
Appendix 1: WEEKLY STATUS REPORTS
To: From: Subject: Week Of: WEEKLY STATUS REPORT Professor Hill Team 32 Status 1/23
ACTIVITIES COMPLETED THIS WEEK Completed Deliverables: None First 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 Document Preparation of Functional Design Review ISSUES FOR IMMEDIATE ATTENTION None
WEEKLY STATUS REPORT To: From: Subject: Week Of: Professor Hill Team 32 Status 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
WEEKLY STATUS REPORT

To: From: Subject: Week Of: Professor Hill Team 32 Status 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


Completed Deliverables: Functional Design Document Resubmission Completed and resubmitted the Functional Design Document
Preparing Technical Design Document

Compiling pieces of Technical Design Document

None


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


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


Completed Deliverables: Technical Design Review Team meeting to discuss Demonstration
Creating the pieces of the demonstration

None

None


Completed Deliverables: None Team meeting to work on poster

Creating website and database system Creating poster

None

None


Completed Deliverables: Phase 6: Demonstration Met to finalize demonstration Completed demonstration website Completed demonstration poster

Begin preliminary work on Phase 5.

None


Completed Deliverables: None Began discussing the Phase 5: Final Report.

Finish Phase 5.

None
50
Appendix 2: EXTERNAL COMMUNICATIONS

None
51
Appendix 3: GLOSSARY
None
52
Appendix 4: TEAM CONTRACT

Team 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. Note that each team member is free to meet with the instructor. Member Name (Print) Contact Information Member Signature Michael Humiston Mjh5305@psu.edu 330-730-0497 Ian Busko Ijb109@psu.edu 814-386-1537 Sam Evans Sse5021@psu.edu 814-421-6030 Grayson Dinsmore Gvd5011@psu.edu 814-404-0673 Andy Deasey Asd5127@psu.edu 724-866-0291 Code 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:
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 for everyone 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 document sharing 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.
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.
55
Appendix 5: DATA DICTIONARY

Table Name Patients Patients Patients Patients Patients Patients Patients Patients Patients Vaccinations Vaccinations Vaccinations Column Name PatientID LName FName MName Sex DOB Street City Zip VaccinationID PatientID AppID Description Unique ID number for the patient Patient last name Patient first name Patient middle name Patient sex Patient date of birth Patient home street address Patient home city Patient home zip code Unique ID number for each vaccination record Primary Key Type Data Type Null? Primary char text text text text datetime text text text char char char N N N Y N N N N N N N N
ID of patient that received Foreign vaccination ID of appointment that patient received vaccination Description of the vaccine Unique ID for each appointment ID of patient who attended the appointment ID of the location where the appointment occurred When the appointment occurred Primary Foreign Foreign Foreign
Vaccinations Appointments Appointments Appointments Appointments
Description AppID PatientID LocationID Time
text char char char datetime
N N N N N
56 Appointments Appointments Appointments Locations Locations Locations Locations Locations Locations Notes Images Videos LocationID Name Street City Zip Description Notes about what happened Any images that were taken Any videos taken Unique ID for each location Name of the location Street address Locations city Locations zip Description of the location Unique ID for each entry Patient ID If cancer, any info If diabetes, any info If heart disease, any info If birth defects, any info If kidney disease, any info If muscle disease, any info If neurological disease, any info If seizures or epilepsy, any info Unique ID for each entry Patient ID Primary Foreign Primary Foreign Primary longtext N
longbinary Y longbinary Y char text text text text text char char text text text text text text text text char char N N N N N N N N N N N N N N N N N N
FamiliyHistory HistoryID FamiliyHistory PatientID FamiliyHistory Cancer FamiliyHistory Diabetes FamiliyHistory Heart FamiliyHistory BirthDefect FamiliyHistory Kidney FamiliyHistory Muscle FamiliyHistory Neurological FamiliyHistory Seizure CurrMeds CurrMeds CurrMedsID PatientID
57 CurrMeds CurrMeds CurrMeds CurrMeds PastMeds PastMeds PastMeds PastMeds PastMeds PastMeds CurrDrugs CurrDrugs CurrDrugs CurrDrugs PastDrugs PastDrugs PastDrugs PastDrugs PastProblems PastProblems PastProblems PastProblems PastProblems PastProblems Type Frequency Dosage Reason PastMedsID PatientID Type Frequency Dosage Reason CurrDrugsID PatientID Type Amount PastDrugsID PatientID Type Amount Type of medication Frequency taken How much taken Reason for taking Unique ID for each entry Patient ID Type of medication Frequency taken How much taken Reason for taking Unique ID for each entry Patient ID Type of drug How much taken Unique ID for each entry Patient ID Type of drug How much taken Primary Foreign Primary Foreign Primary Foreign Primary Foreign text text text text char char text text text text char char text text char char text text char char text datetime Foreign char text N N N N N N N N N N N N N N N N N N N N N Y N N
PastProblemID Unique ID for each entry PatientID Problem Diagnosed AppID Treatment Patient ID What the problem is When diagnosed Appointment where problem was diagnosed Treatment for problem
58 CurrProblems CurrProblems CurrProblems CurrProblems CurrProblems CurrProblems PastProblemID Unique ID for each entry PatientID Problem Diagnosed AppID Treatment Patient ID What the problem is When diagnosed Appointment where problem was diagnosed Treatment for problem Foreign Primary Foreign char char text datetime char text N N N Y N N

Phase 5 - Team 32

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Phase 5 - Team 32

Enviado por

Direitos autorais:

Formatos disponíveis

Phase 5: Final Report

Team 32: Innovation in Motion

Background Information About the Project

Statement of Problem being Solved

Health care Practitioners

Project Goals and Business Objectives

Requirements Gathering Process

PastMeds Patient Type Frequency Dosage Reason

CurrDrugs Patient Type Amount

PastDrugs Patient Type Amount

PastProblems Patient Problem Diagnosed Appointment Treatment

Use Case Narratives

Use Case Glossary

Receiving Practitioner (External data receiver)

Pulled From Cloud

Receiving Practitioner (External data receiver)

Tools and Techniques

User Acceptance and Verification

Project and Industry Standards

Work Breakdown Structure (WBS)

Roles and Responsibilities

Communications and Control

PROJECT SUMMARY STATEMENT

ACTIVITIES COMPLETED THIS WEEK

Preparing for Functional Design Review

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Preparing Functional Design Document resubmission

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Preparing Technical Design Document

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Preparing Technical Design Document

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Preparing Technical Design Review

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Creating the pieces of the demonstration

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Creating website and database system Creating poster

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK

Phase 5: Final Report

ACTIVITIES TO BE STARTED NEXT WEEK

ISSUES FOR IMMEDIATE ATTENTION

WEEKLY STATUS REPORT

ACTIVITIES COMPLETED THIS WEEK