Comprehensive Analysis and Design of Headspace Health Record System

This report provides a comprehensive analysis and design of a health record system for Headspace, a mental health organization. It begins by outlining the system's non-functional requirements, including usability, reliability, performance, and supportability. The report then details system interfaces, encompassing user interfaces and external system/device interfaces, along with system constraints. A review of applicable cloud-based solutions, particularly the Platform as a Service (PaaS) model and hybrid cloud deployment, is presented. The Software Development Life Cycle (SDLC) approach is discussed, comparing predictive and adaptive methodologies, with a recommendation for an adaptive approach such as Agile. The report concludes with recommendations for project management, specifically the Project Management Body of Knowledge (PMBOK) methodology, and references relevant sources.

System Analysis and Design
Headspace
5/20/2017
1

My Health Record
Table of Contents
Introduction.................................................................................................................................................3
System Qualities (Non-Functional Requirements)......................................................................................3
Usability of Health Record System..........................................................................................................3
Reliability of Health Record System.......................................................................................................3
Performance of Health Record System....................................................................................................4
Supportability of Health Record System.................................................................................................4
System Interfaces........................................................................................................................................4
User Interfaces of Health Record System................................................................................................4
External Systems/Devices Interfaces for Health Record System.............................................................5
System Constraints of Health Record System.............................................................................................6
Review of the Applicable Cloud Based Solutions.......................................................................................6
SDLC Approach for Health Record System................................................................................................7
Predictive SDLC Approaches..................................................................................................................7
Adaptive SDLC Approaches...................................................................................................................7
Recommendations & Conclusions...........................................................................................................7
References...............................................................................................................................................9
2

My Health Record
Introduction
Technology is being used and applied in many of the business sectors with healthcare being a
prime user and applicant of technology. There are several technological tools and applications
that healthcare industries make use of for a variety of operations. Headspace is an organization
that has decided to adapt the same by using an automated health record system. Headspace
provides treatment and assistance to the patients suffering from any form of mental illness. The
use of the health record system will enhance the quality of service provided by the organization.
System Qualities (Non-Functional Requirements)
The health record system that will be developed for Headspace will have the prime objective of
easy management of the patient details and information along with ease of services for the
patients. In order to achieve these aims, there will be many specifications and requirements that
will be incorporated. One of the most significant set would be the non-functional requirements
covering the qualities of the system that will be covered.
Usability of Health Record System
The system qualities of a particular system determine the alignment of the system with the
specifications that are provided and the level of user experience that is earned by the system. For
the health record system for Headspace, it would be essential that the expectations and
necessities of the users are met through the functionalities included in the system. System
Usability would be the non-functional requirement that would make it possible (Lauesen &
Younessi, 2016). The users must be provided with the ability to login, access information,
control privacy setting of information etc. and the system shall be easy to navigate and the layout
of the system must be simple.
Reliability of Health Record System
Health information is extremely sensitive information category and the sensitivity further
intensifies with the involvement of mental health information. In cases of incorrect or invalid
display of information by the system, the consequences can be extremely adverse (Chung, 2016).
The system shall, therefore, always provide the users with reliable information and output.
3

My Health Record
Performance of Health Record System
The main aim of automation is to enhance the service speed and accuracy (Malan & Bredemeyer,
2010). In case of delays by the system in terms of the time taken to respond to the user queries or
the throughput time, the user experience will drop. Therefore, the system must be high-
performing in nature at all times irrespective of the network connections or the number of users
accessing the system.
Supportability of Health Record System
The health record system that is designed and implemented for Headspace must have the scope
to be changed and modified as per the changing technology and user expectations. It must
support the operating systems and other technical components for the purpose of strong
integration (Shaikh & Misbahuddin, 2016).
System Interfaces
User Interfaces of Health Record System
 Interaction and connectivity will be the two major parameters of the system and it would
be essential that the maximum interactivity is maintained. Responsive web design shall
be used as the design methodology for achieving this objective.
 The color scheme for the system shall be kept in accordance with the theme and the
nature of the application. There shall not be use of extremely bright or extremely dull
colors and a moderate color scheme shall be used and implemented.
 The users must be able to see the system behavior in terms of its recognition and response
to the user action. For instance, when a user click on a button then it shall be highlighted
with a different color and likewise.
 The choice of colors and the themes may vary from one user to the other. There shall be
an option of customization and personalization that must be available for this purpose
(Fosse & Delp, 2016).
 The system shall also have consistency in terms of the layout of the UI elements and their
placement, color scheme and themes. The layout of the system shall be simple and the
4

My Health Record
patients as well as the medical team must be able to easily understand it. It is because of
the reason that none of these users will have a very strong technical background to deal
with the complexities of the technical concepts.
 The flow and navigation that would be implemented in the system must be simple and
smooth. The users must be able to understand the flow of the system on their own
without any external help.
 The text that would be present on the system must have a uniform style on all the system
screens. There shall be use of a uniform color for all the headings and a uniform color
shall be used for the text in the body section as well.
 The extraction of reports by the users shall be customized by allowing them to download
or view the report in the desired format.
External Systems/Devices Interfaces for Health Record System
 Patients shall be allowed to communicate with the medical professional using Simple
Mail Transfer Protocol (SMTP).
 The sharing of the files shall be allowed on the system between the patient, medical
professionals and among the medical team. The File Transfer Protocol (FTP) shall be set
up for this purpose.
 The network connections shall be functional and their functionality shall be determined
by the protocols as Transmission Control Protocol (TCP) along with the User Datagram
Protocol (UDP).
 Real Time Protocol (RTP) shall be set up to allow the users to communicate with each
other in real-time using options like instant messaging or tele-conferencing.
 There shall also be integration of the system with the basic health equipment for
recording of the health signs by the patients (Conde et al., 2010).
 There shall be use of HTTPS and SSL for securing the information on the system from
any of the security risks and attacks (Wheatcraft, 2010).
5

My Health Record
System Constraints of Health Record System
 The front end of the system shall be developed using a programming language that is
flexible and secure in nature. PHP shall be used as the language for creating the source
code.
 Cloud databases and NoSQL databases shall be used for information storage, processing
and management.
 TestLink shall be used for the creation and execution of the testing activities for the
system (Dettmer, 2016). The defects shall be reported and managed by using the tool
called Bugzilla.
Review of the Applicable Cloud Based Solutions
Cloud computing will have a great role to play in this case as the system will be deployed on
cloud for making sure that remote access to the patients and medical team is possible. There will
also be cloud databases that will be used for the information management.
The deployment of the system can be done using any of the cloud models that are available on
the basis of service, platform or infrastructure.
The most suitable delivery model for health record system for Headspace would be Platform as a
Service (PaaS) model of cloud. Health information is very sensitive in nature and the most
important parameter behind the selection of the cloud model would be security. PaaS model
would provide advanced security to the information and will also allow the updates to be easily
installed. The maintenance will also be smooth and less complex and there will also be no issues
around the ownership of the data and information in this model.
The cloud services will be usable once they are deployed on the cloud using any of the cloud
deployment models. There are three such models available which can be used viz. public, hybrid
or private cloud models. The model most applicable in this case would be the hybrid cloud
deployment model. This is because there will be sensitive, private, public and internal data sets
that will be involved with specific cloud services around each. The deployment model would be
required to handle all of these information types which would be best possible with a hybrid
model.
6

My Health Record
SDLC Approach for Health Record System
SDLC stands for Software Development Life Cycle and it a process that involves all the
activities that are involved in the development of particular software.
There are many methodologies and mechanisms through which software such as health record
system for Headspace can be developed.
Predictive SDLC Approaches
One of the SDLC approaches for health record system is the predictive approach in which the set
of phases and activities to be applied are determined beforehand. These estimations and
decisions are taken on the basis of the specifications and requirements along with the information
collected from different sources. This approach will provide the management and leadership with
the guidelines and framework that they must follow. However, it does not have the ability to
handle the frequent changes in the project and the risk management is also weak in this case. One
of the examples of this approach is the Waterfall model.
Adaptive SDLC Approaches
The second approach for the development of health record system is the adaptive approach that
is value based. It is ad-hoc approach that carries out the set of tasks and activities on the basis of
the situations in the project. It is extremely flexible in nature and can manage the changes with
utmost ease. However, there may be certain hidden costs involved in this case. One of the
examples of the adaptive SDLC methodology is the agile methodology for software
development.
Recommendations & Conclusions
The two different sets of approaches have been analyzed as per the requirements of the health
record system for Headspace and the one that has been recommended is the adaptive approach.
This is because in case of this system, the requirements are already determined but there can be a
few modifications in terms of the number of patients to be handled by the system, new healthcare
concepts to be integrated and likewise. Such requirements would be difficult to incorporate with
the predictive SDLC approach. The adaptive SDLC methodology such as agile methodology
would allow a flexible approach to be followed in all of the developmental tasks.
7

My Health Record
Another recommendation that is provided to the project team is the use of an applicable project
management methodology in the project life cycle. These methodologies will provide the project
leadership and managers with the ability to manage the project risks, conflicts and problems and
will also allow easy planning and estimation activities to be carried out. The methodology
recommended for this project is Project Management Body of Knowledge (PMBOK). It will
include five stages for the management of the project as initiation, planning, execution, control
and closure.
8

My Health Record
References
Agilemodeling,. (2016). UML 2 Use Case Diagramming Guidelines. Agilemodeling.com.
Retrieved 27 September 2017, from http://agilemodeling.com/style/useCaseDiagram.htm
Bourne, L. (2016). Stakeholder Relationship Management. Retrieved 27 September 2017, from
http://www.mosaicprojects.com.au/PDF_Papers/P128b_Stakeholder_Relationship_Manage
ment.pdf
Chung, L. (2016). Non-Functional Requirements. Retrieved 27 September 2017, from
https://www.utdallas.edu/~chung/SYSM6309/NFR-18-4-on-1.pdf
Conde, J., De, S., Hall, R., Johansen, E., Meglan, D., & Peng, G. (2010). Telehealth Innovations
in Health Education and Training. Telemedicine And E-Health, 16(1), 103-106.
http://dx.doi.org/10.1089/tmj.2009.0152
Dettmer, H. (2016). Systems and Constraints: The Concept of Leverage. Retrieved 27 September
2017, from http://goalsys.com/systemsthinking/documents/Part-6-
SystemsandConstraints.pdf
Fakhroutdinov, K. (2016). UML actor is a role played by a human user of the designed system,
some other system or hardware that interacts with the subject by using services of the
subject.. Uml-diagrams.org. Retrieved 27 September 2017, from http://www.uml-
diagrams.org/use-case-actor.html
Fosse, E. & Delp, C. (2016). Systems Engineering Interfaces: A Model Based Approach.
Retrieved 27 September 2017, from
http://www.omgsysml.org/System_Engineering_Interfaces-IEEE_2013.pdf
Lauesen, S. & Younessi, H. (2016). Six Styles for Usability Requirements. Retrieved 27
September 2017, from http://www.itu.dk/~slauesen/Papers/SixStyles.pdf
Malan, R. & Bredemeyer, D. (2010). Defining Non-Functional Requirements. Retrieved 27
September 2017, from http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF
McAtee, M. (2016). A good compliance system takes the administrating out of managing.
Qualitydigest.com. Retrieved 27 September 2017, from
9

My Health Record
http://www.qualitydigest.com/nov01/html/paperless.html
Rhyous,. (2011). The 8 Types of Technical Documentation and Why Each Is Important. Rhyous.
Retrieved 27 September 2017, from https://www.rhyous.com/2011/07/21/the-different-
types-of-technical-documentation-for-software-and-why-each-is-important/
Shaikh, A. & Misbahuddin, M. (2016). A system design for a telemedicine health care system.
Retrieved 27 September 2017, from
https://gupea.ub.gu.se/bitstream/2077/10498/1/gupea_2077_10498_1.pdf
Walker, D. (2016). Influence, Stakeholder Mapping and Visualisation. Retrieved 27 September
2017, from
https://mosaicprojects.com.au/PDF_Papers/P062_Influence_Stakeholder_Mapping_and_Vi
sualisation.pdf
Watt, A. (2016). 5. Stakeholder Management | Project Management. Opentextbc.ca. Retrieved
27 September 2017, from https://opentextbc.ca/projectmanagement/chapter/chapter-5-
project-stakeholders-project-management/
Wheatcraft, L. (2010). Everything you wanted to know about interfaces, but were afraid to ask.
Retrieved 27 September 2017, from
http://spacese.spacegrant.org/uploads/images/UserContributedFiles/
WheatcraftInterfaces110909.pdf
Wick, S. (2016). User Stories and Use Cases - Don’t Use Both!. Batimes.com. Retrieved 27
September 2017, from https://www.batimes.com/articles/user-stories-and-use-cases-dont-
use-both.html
10