SD_TeamC_Rev_Spec

shrewdnessmodernMobile - Wireless

Dec 14, 2013 (3 years and 7 months ago)

88 views

Team C

(
-

_
-
) ┬─┬

Introduction

The St. Francis Patient App (SFPA) is a mobile application for Android and iPhone devices
designed to assist the patients in navigation throughout the hospital. The app will have the
following features:

1.

Access to a physicia
n’s information by name, practice, specialty, gender location and
lanuage(s) spoken.

2.

Easily able to put appointment information into a calendar.

3.

Select photos and names of the physicians and others who are part of the patient’s
healthcare team, and assembl
e them in one section of the app.

4.

Easily able to note patient questions and answers.

5.

Access to Microsoft Healthvault to keep current information about medications and other
medical records.

6.

Scanning Quick Response (QR) Codes to assist in the navigation tho
ught the hospital.

7.

When a doctor logs into SFPA, the application will expose additional interfaces for
viewing patients and updating profile information.

A mock interface for the app can be seen in Figure 1.

You still need to explain Figure 1 and just
not
cite it.
Still missing: Motivate


discuss the app from the end user and system perspective.

Due to barriers to entry in iOS software developments, the iPhone version of the application will
be assigned a secondary priority to the Android version. Once

the Android application prototype
is complete, it will be ported to an iPhone version if an iOS development machine becomes
available.


Figure 1: Mock Interface

Operating Environment (
Team Member
)


I
highlighted material that I suggested be part of Intro
. I asked you
for a SWArchitecture
diagram. I asked you to move fig 2 in line with its citation


this
seems essentially not changed
too much.
The operating environment of the St. Francis Patient App will be the specific user’s
mobile phone. The phone w
ill either be a Smartphone running Android OS or it will be an
Apple iPhone running iOS. There are some existing software systems which are likely to be
needed for the use of our application. Microsoft’s Windows Communication Foundation (WCF)
is used to
pass complex data types from our server to the user’s mobile phone app. Microsoft’s
ASP.NET 4 will be used for our web application part of the server. JavaScript Object Notation
(JSON) will be used for communication between the mobile app and the server.

Microsoft’s
Model View Controller (MVC) will be used to assist in JSON calls with the server. The app will
also take advantage of an existing SQL server database which has been setup by St. Francis
Hospital and Medical Center. By utilizing these existi
ng technologies, our application will be
able to provide the user with many convenient features including making/editing appointments,
viewing their healthcare team, assistance navigating the hospital, and viewing HealthVault
information (see figure 2).
Ou
r St. Francis Patient App will put all of these features at the user’s
finger tips and allow them to have easy access to important medical information on the go. The
application will exist on the user’s mobile phone so the physical environment will change

depending on the specific user and we will not have control over the hardware, but the majority
of the app’s use will occur when the user is in the hospital itself. The server app will be running
off a server located in a server room which should be a st
able environment. The mobile app
itself needs to be designed with simplicity in mind since hospital patients are expected to
be“naïve” users. Many times the app will be used for the first time when the patient enters the
hospital so the app must be desig
ned in a way which is easy to use and requires a zero learning
curve. The mobile application will see almost all of its usage when the patient is within the
hospital itself but will see little to no usage when the patient is not visiting the hospital.

On

the
other hand the server application will have to be ready to run 24/7 since it should be anticipated
that there will always be patients in the hospital needing navigation and patients updating their
patient information through the mobile app. High data

traffic between the server and mobile
clients is anticipated to occur when St. Francis Hospital is having a busy day. The server
experiencing heavy usage is directly related to the number of patients in the hospital at a given
time.


Interfaces (
Team Mem
ber
)

The St. Francis Patient App (SFPA) is intended to allow users to interact with hospital services
in different ways: a mock up of the interface based on the discussion from the introduction is
shown in Figure 1.


The functions of the app are as follows
:

Search Physicians:

This option allows the user to search and access the information of a physician currently
employed by Saint Francis Hospital.


Appointments:

This option allows the user to put appointment information into a calendar.


My Healthcare Tea
m:

This menu option allows the user to add, view, and remove physicians from his healthcare team.

Questions:

This option allows the patient to write any questions they may have, so that they are available to
be used during their hospital visit, with the po
tential to send them to their designated physicians
for answers.

Microsoft Heathvault:

This option allows the patient to access their personal medical information that is stored in
Microsoft Healthvault, with an emphasis on medications.

Scan QR Code:

This
will open up a QR Code scanning program that will scan a QR Code. After scanning the
code, user will be required to select their destination for a list of rooms, hospital services, or
physicians. A map with a route leading to their destination will then ap
pear on the screen.

The interfaces for the Saint Francis Patient Application will require the following database
interfaces:

Physician Database:

This is a database of all employed physicians of Saint Francis Hospital which each smartphone
running the appl
ication will be able to access and read. Each entry in this database will contain a
physician’s name, practice, specialty, gender, location, and language spoken. This is the database
which the
Search Physicians

and
My Healthcare Team

options will access wh
en needing to
perform their functions. This will be a long
-
term database that will be accessed from a St.
Francis server.

Microsoft Healthvault Database:

This is a database that stores the information of all the patients of Saint Francis hospital. Each
ent
ry in this database will contain each patient’s medical status, history, and which medications
the patient is on. Access to the entirety of this database will be limited depending on the user of
the application. For example, a patient should only be able t
o access his particular medical
records in this database and not the records of anyone else.


Quick Response (QR) Code Database:

When a user scans a QR Code, their phone will receive information of the user’s current location
in the hospital. The user from

there will pick a location they want to go to. To show the user how
to get to this location, the application will access this database, which will have directions to get
to their destination.

Map Database:

This is a database that will contain maps of St.
Francis Hospital. Using the information collected
from the QR Code Database, the app will select a map from the map database with a drawn out
route for the patient to take.

You can’t store all possible maps from all possible locations to all
other possibl
e locations


you
need to really think about how to display a “path” for the user to
follow from their location to destination.

Appointment Database:

This is a database managed by the St. Francis secretaries that stores appointments for the patient
into
MS HealthVault. The user will be able to view all of his appointments in this database
through the Appointment option of the app.

Healthcare Team Database:

This is a database managed by the app to permenantly store the information of a patient’s
healthcare

team. Using the
My Healthcare Team

function, the user will be able to access the
physician database and add a selected physician to the healthcare team database. The user will be
able to remove physicians from the healthcare team database should his physi
cian is changed.

Questions Database:

This is a database managed by the app that will permanently store the questions of a patient. The
patient will be able to continuously type up and store questions into this database, remove
questions, or edit them. Thi
s database will be used to quickly access a question the user may
have instead of having to type it up again. The user will be able to select a question from this
database and send it to their designated physicians for answers. The user will also have the
ability to store the answers of their corresponding question into this database.









Information (
Team Member
)

Due to the fact that this application must store massive amounts of data there must be both data
structures and also database tables implemen
ted in the system to interact with the Graphical User
Interface. The first and biggest piece of information would have to be a Graph ADT to store in
the phone for navigation throughout the hospital without internet. This graph would be linked to
a map layo
ut of the whole building. Therefore if a user knows which room they want to go to,
they would select the room on the layout and scan the nearest QR code to navigate around the
hospital without getting lost. This map layout would be stored along with the gr
aph on each
user’s phone once the app is downloaded. Each graph node would correspond to a room of the
hospital, and each node would have a distance to the rest of the nodes, which would change
dynamically as a user scans a new QR code. This would generate

a new path on the map layout
for the users to follow. Each one of the nodes of the graph would correspond to a room on the
map layout and an interface would allow the user to touch the room they want to go to or look up
the room of a certain physician and

scan their nearest QR Code to get directions to the room they
are trying to reach.

Other information units that would need to be stored in a database and pertain to the user would
be a unique user for each client, their appointments, each physician a user

is linked to, questions
that they have, and answers to questions by physicians. The username and password of each
client will be stored in MS HealthVault. Appointments will be stored centrally by a St. Francis
database server. Physicians are stored via SQ
L on an already existing server, and questions and
answers by patients and physicians would need to be stored in MS Healthvault, due to their
privacy in the system.

There will initially be four types of users in the system, providers, secretaries, patients
, and
patient families.
As in the initial


some in intro, some in op environ,
-

too late to explain 6 page
sinto the spec.
Patients will be able to check in to the hospital by scanning QR codes located at
the entrance and exit of the hospital, while also

being able to obtain directions from the QR
codes located around the hospital for navigation purposes. Patients will also receive notifications
of appointments that are drawing near while also allowing the patient and his authorized family
members who hav
e an account to see their medical records through MS HealthVault. They can
also search through all physicians and filter them by name, gender, practice, specialty, location,
and languages spoken. Providers will be able to check a patient’s medical record t
hrough MS
Healthvault, and answer any questions they have submitted to them through the St. Francis
Physicians Application.

The secretaries using the system will have to input any appointments a
user has into MS Healthvault, this way patients, providers, a
nd patient families can be reminded
of their appointments.


You need to make sure your DB interfaces are consistent in name and intent to these info
units.

Information Units

Location Map

From a given location you need to find a path to a destination. Y
ou

need to store
enough info to generate such a path (and regenerate if they rescan a QR code).



Purpose


To allow for easy navigation through the hospital without internet



Lifetime


Semi
-
Perminantly built into the application. An original map will come
p
reloaded with the download, and then be updated daily through the internet.



Usage


Used

so patients can find out how to get to their destination by using QR codes




Availability



Other components of the app can access the map layout to show the

user wh
ere his appointment will be



Accessibility


Anyone can access the map of the hospital by downloading the app



Semantic Structure


The location map will consist of a map of the hospital with rooms
which are touchable to get directions to them.



Interactions



Rooms of a certain User’s Healthcare Team can be shown on the layout
with the physician's name about each node, so a user can easily select which room he
needs to go to, and will also need to interact with the QR Code interface in order to locate
the us
er without GPS.



Structural Relationship


The location map will consist of an overlay of graph nodes and
edges to represent QR Code locations and hospital rooms and an underlay of a map that
will be able to access the graph data structure to draw a route t
o the user of where to go.



Storage/Access


The graph will be on each user’s phone and accessed and

updated regularly to suit each client’s necessities.



User (Patients & Physicians)



Purpose


To uniquely identify a user



Lifetime


Persistent until user

deletes his account



Usage


Used to authenticate a certain user, and present him with his medical records and
appointments



Availability


User IU do not need to interact with other components of the system



Accessibility


No other end user will be allowed

access to another’s username due to
privacy concerns



Semantic Structure


A username represents a patient or physician of the hospital




Interactions


Users will be able to interact with Appointments. Scheduled Appointments
will be downloaded from the ser
ver and saved on the User’s device along with
information about the physician or patient the appointment is with.



Structural Relationship


Users will consist of a unique User ID, unique Username along
with a password hash and their privileges



Storage/Acce
ss


Usernames will be stored in a St. Francis MS HealthVault

database when a new user is created or a username is changed and accessed only
upon authentication.


Appointment



Purpose


To

remind a user of an appointment



Lifetime


Available for 1 year af
ter appointment



Usage


Used to notify users that their appointments are coming up and to store

questions they should ask during the visit.



Availability


Appointments will be accessible by other components of the device to

remind the user of them.



Acces
sibility


Only verified users through MS Healthvault will be able to access

appointment information.



Semantic Structure


An appointment is a date, time, and physician a user meets with.



Interactions


Appointments will be linked to a certain User ID and

physician.



Structural Relationship


Appointments will contain a date, a time, a user ID

and a
physician ID.



Storage/Access


Appointments will be stored by the client on the hospital side into the
MS Healthvault and accessed by the user who has the appo
intment from the St. Francis
central schedule database.


Physician (Data Type)



Purpose


To be able to find a physician based on certain requirements.



Lifetime


Persistent until a physician is terminated or quits




Usage


To search for a certain physician




Availability



Physicians can be added to an appointment by their physician ID.



Accessibility


Every user will have access to the database of physicians.



Semantic Structure


A physician is a compilation of their gender, name, specialty,
location in th
e hospital, and languages spoken.



Interactions


Physicians will be linked to users in their Healthcare Team section of the
app. Appointments will also access physicians to see who an appointment is with.



Structural Relationship


A physician is a physicia
n ID, name, gender, specialty, location,
and languages spoken.




Storage/Access


Physicians will be publicly accessed, so that users can pick which
physician they would like to see. They are already stored on

St. Francis http
servers.


Questions & Answers



Purpose


To be able to ask the physician a question about your health and him to give
you an answer savable on your device



Lifetime


Persistent for a year after an appointment



Usage


The user will input questions to his physician about his health that
he may forget
during the visit and the physician will write back to him after he sees him



Availability



Questions and Answers will be available to the calendar application

to add them to a specific appointment



Accessibility


Other users will not be all
owed to see Q&A from another user’s

account unless they are given permission to through MS HealthVault. Physicians
will be allowed to view questions and answer them.



Semantic Structure


Q&A are a compilation of one question along with the subsequent
answ
er from the physician and the patient who asked the question and physician who was
asked.



Interactions



Q&A will be linked to both a physician to which they are asked and the
patient who asked the question. This will allow for both to edit their respecti
ve questions
and answers.



Structural Relationship


A question will always have to have an answer, so there will be
a data structure containing both




Storage/Access


Questions will be stored in MS HealthVault once a question is asked by
a patient and retr
ieved by physicians once they sign in to their account. An answer will
also be stored in MS HealthVault once the physician answers the question and will be
accessed by the patient once he is logged in.



Performance (
Team Member
)

Good Revision

The applicat
ion will take advantage of the local storage capacity of modern smartphones by
caching data wherever feasible. Options will be provided to limit the size of the cache and to
clear the cached data to recover space. Storing data such as navigation nodes and
most recently
viewed doctor profiles will speed up the application and enable it to function in the absence of a
network connection. To mitigate the risk of maintaining stale data on the device, cached data can
be assigned an expiration timestamp depending

on the frequency at which the data is expected to
change.

The application must support corridor navigation without using GPS information. Inputs to the
navigation feature (QR codes and destinations) are independent of phone connectivity, so the
applicati
on will not make any assumptions about the availability of network data. Instead, it will
store a graph containing navigation nodes and perform its calculations locally. Since hospital
renovations and office location changes are not likely to occur durin
g the course of a patient’s
visit, the node cache can be semi
-
permanent and updated as necessary. The localization of
navigation data and processing helps to ensure a rapid response time. A route calculation should
not take longer than several seconds to

complete, as patients may be running late for an
appointment. A pathfinding algorithm such as A* with a carefully selected heuristic will help to
ensure that processing is finished quickly. If trials show that performance of these local
calculations is
slow on some devices, then a server may need to be implemented to handle the
processing. In either case, recently calculated navigation results may be cached with the same
shelf life as the node data.

Any patient is a potential user of the application, so

it must be designed for ease of use. All GUI
components must make efficient use of screen real estate and be responsive. Any user input
fields should be grouped logically and be easy to select or cycle between. Likewise, any
information displayed to th
e user must follow a logical grouping and be easy to browse.
Excessive lag between user inputs and feedback can cause confusion and frustration, and thus
should be eliminated wherever possible. The application should support a user’s expectations for
how

it will behave. For example, on a multi
-
touch device, placing two fingers on a map and
moving them about an anchor point should cause the map to rotate about that point.

The application should be written to support thousands of users, with scalability in

mind. The
bottleneck in this respect is likely to be the database
-
driven backend. Each database must make
use of best practice design principles to minimize duplication of data and ensure its integrity.
Such a database should take advantage of lookup t
ables to avoid storing a patient’s username in
more than one location, for example. It should also utilize foreign keys to make cascading
changes when a row of a table is altered, so that information that is no longer relevant is
removed, and data across
the application reflects the change to the current state.

The user database is one that will be accessed only momentarily when a user registers or logs
into the application. There will be relatively few concurrent connections to this database. The
appoin
tment database will receive updates by interfacing with the receptionists’ appointment
system, and the appointments will be synchronized with patients’ phones periodically.
Therefore, the appointment database will also not need to support a large number o
f concurrent
connections.

The physician data will be retrieved from St. Francis servers. To ensure that searches which
return a large number of physicians do not degrade the performance of the application, we will
retrieve only the information necessary t
o match search criteria. Full profile information
including any pictures will only be queried when the user selects a physician to view, and only if
the data is not already cached. Since many patients may be searching the physician database
simultaneousl
y, we hope that the St. Francis physician database supports at least as many
concurrent connections as there are application users.

The navigation database will store nodes as strings, each a relatively small number of bytes,
which are converted to JSON ob
jects. In addition to nodes, the navigation database will store a
graphical underlay for each floor of the hospital. Each underlay will only have to be downloaded
on the first use of the application, and upon subsequent changes. As discussed previously,

the
navigation feature will be designed for minimal reliance on this database. Connections will be
infrequent, and not bandwidth
-
intensive.

The majority of the workload is expected to consist of short, unpredictable requests for data by
the user. There w
ill be little, if any, data streaming or persistent connections. Data retrieved by
the user will probably contain only images and text. Without audio and video retrieval taking
place, bandwidth consumed by the application will be relatively small. Thus,
the backend will
be tuned in whatever manner possible for transactional processing.




Security (
Team Member
)

Good Revision

The security overview will be to ensure that the software in the application and the
communications between the mobile device and th
e servers are as secure as possible from
intrusion. Our goal is to allow users the access to the information they need without any possible
threat to their private information and follow all HIPPA guidelines.

There would be four different user roles all
owed in the SFPA and would include coverage of
unregistered users, registered patients, staff and sysadmin accounts. The unregistered users
would have the most limited parts of the SFPA and would be only allowed to navigate through
the hospital and do sear
ches on the staff. Unregistered users could consist of family
members/visitors to the hospital who would not have any access to any medical records or make
any changes to the SFPA or St. Francis servers. For the Navigation part of the SFPA the graph
tree

and appropriate algorithms would be stored on the SFPA local database on the phone, while
search and browsing doctors list would require read access on the St. Francis Server.
Communications to the Server would be through JSON and could easily be encrypt
ed with JSON
encryption to meet HIPAA regulations.

Registered users would be Patients in the hospital that have already registered with the SFPA and
St. Francis servers. Registered users would have many more capabilities then the unregistered
user and h
ave a higher level of security. Registered users would need to have a patient ID
number assigned to St. Francis and a password that they setup before they can login to access
their medical information. Password protected records are a necessity of HIPAA
and would be
satisfied by this. Registered Users would add upon the capabilities of the Unregistered Users and
would be able to View their personal HealthCare team, Make and Edit Appointments, View their
Health vault information and ask questions to their

doctors. All of these uses would require the
SFPA to be in contact with St. Francis servers to work with the data. The Health care team
would be selected by the Registered user locally on their phone by selected them based on
queries from the servers an
d the team would be stored locally, this would allow for write access
locally but no writing to the server. Similarly appointments would be accessed to the SFPA from
the server and stored locally to the users calender. Editing appointments would require
write
access to the server and only be completed with the approval of St.Francis. Health Vault
information would only be viewed but not allowed to be written by the Registered user and as
such they would only require read access to the server. Questions
to the doctor would be input
locally by the patient and then copied to the server, requiring write access to the sever at the
lowest level. Once again all communication between the phone and the server would use JSON
encryption for the messages and any lo
cal data would be encrypted in the local database as well.


Staff user roles would be different than the previous user roles altogether. Staff users would
require registration which would be authenticated with the SFPA. Staff users would be able to
up
date their own profile, view patient information and answer questions that have been presented
by the patient. Staff users would require local read and write access as well as read and write
access on the server. Staffers could update their own profile on

the server with write access and
could view it locally. Staff would be able to view the patient data and make changes to it, JSON
encryption once agian being used to protect patient privacy. Staff would also be able to answer
questions asked by patients

locally which would then perpetuate back to the server and
eventually back to the patient.

Admin user roles would be limited to sysadmins and similar accounts. Admins would have the
distinction of being able to add Staff members to the SFPA and be abl
e to get statistics about the
servers and system in general. Admins would have read and write access to the server which
would allow them to add Staff and review the server information. One of the differences of this
user role is that it would not have a
ny access to the patient data to comply with HIPAA and
instead only focus on the system and hardware itself.

In the event that a user has lost their device the chance of someone maliciously recovering any
data is very low. Patient data would on
ly be seen after a user has been registered and logged into
the app so unless a maliciously user has the patients ID and password it is unlikely they would be
to gain access to the data. Local data stored on the phone may be easier to compromise so any
lo
cal data would be encrypted or hashed depending on the data so it is unlikely any information
would be readable in this form. With these security implementations we should easily fit in as
acceptable HIPAA software.


Glossary


OMITTED


NO CHANGES










Integrate Figs with TEXT!

Appendix A
-

Diagrams


Figure 2. Patient Use Case Diagram


Figure 3. Staff Use Case Diagram




Figure 4. Unregistered Use Case Diagram


Figure 5. Admin Use Case Diagram








Team C

(

°□°
)╯


┻━┻