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
Access to a physicia
n’s information by name, practice, specialty, gender location and
Easily able to put appointment information into a calendar.
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.
Easily able to note patient questions and answers.
Access to Microsoft Healthvault to keep current information about medications and other
Scanning Quick Response (QR) Codes to assist in the navigation tho
ught the hospital.
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
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
Figure 1: Mock Interface
Operating Environment (
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
seems essentially not changed
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
(JSON) will be used for communication between the mobile app and the server.
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).
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.
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
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
This option allows the user to search and access the information of a physician currently
employed by Saint Francis Hospital.
This option allows the user to put appointment information into a calendar.
My Healthcare Tea
This menu option allows the user to add, view, and remove physicians from his healthcare team.
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
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:
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
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
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.
Microsoft Healthvault Database:
This is a database that stores the information of all the patients of Saint Francis hospital. Each
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.
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
need to really think about how to display a “path” for the user to
follow from their location to destination.
This is a database managed by the St. Francis secretaries that stores appointments for the patient
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
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.
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.
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
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
Healthvault, and answer any questions they have submitted to them through the St. Francis
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
From a given location you need to find a path to a destination. Y
need to store
enough info to generate such a path (and regenerate if they rescan a QR code).
To allow for easy navigation through the hospital without internet
Perminantly built into the application. An original map will come
reloaded with the download, and then be updated daily through the internet.
so patients can find out how to get to their destination by using QR codes
Other components of the app can access the map layout to show the
ere his appointment will be
Anyone can access the map of the hospital by downloading the app
The location map will consist of a map of the hospital with rooms
which are touchable to get directions to them.
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
er without GPS.
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.
The graph will be on each user’s phone and accessed and
updated regularly to suit each client’s necessities.
User (Patients & Physicians)
To uniquely identify a user
Persistent until user
deletes his account
Used to authenticate a certain user, and present him with his medical records and
User IU do not need to interact with other components of the system
No other end user will be allowed
access to another’s username due to
A username represents a patient or physician of the hospital
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.
Users will consist of a unique User ID, unique Username along
with a password hash and their privileges
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
remind a user of an appointment
Available for 1 year af
Used to notify users that their appointments are coming up and to store
questions they should ask during the visit.
Appointments will be accessible by other components of the device to
remind the user of them.
Only verified users through MS Healthvault will be able to access
An appointment is a date, time, and physician a user meets with.
Appointments will be linked to a certain User ID and
Appointments will contain a date, a time, a user ID
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)
To be able to find a physician based on certain requirements.
Persistent until a physician is terminated or quits
To search for a certain physician
Physicians can be added to an appointment by their physician ID.
Every user will have access to the database of physicians.
A physician is a compilation of their gender, name, specialty,
location in th
e hospital, and languages spoken.
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.
A physician is a physicia
n ID, name, gender, specialty, location,
and languages spoken.
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
Questions & Answers
To be able to ask the physician a question about your health and him to give
you an answer savable on your device
Persistent for a year after an appointment
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
Questions and Answers will be available to the calendar application
to add them to a specific appointment
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.
Q&A are a compilation of one question along with the subsequent
er from the physician and the patient who asked the question and physician who was
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
A question will always have to have an answer, so there will be
a data structure containing both
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.
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
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
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
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
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
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
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
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
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
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,
navigation feature will be designed for minimal reliance on this database. Connections will be
infrequent, and not bandwidth
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.
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
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
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
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
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.
Integrate Figs with TEXT!
Figure 2. Patient Use Case Diagram
Figure 3. Staff Use Case Diagram
Figure 4. Unregistered Use Case Diagram
Figure 5. Admin Use Case Diagram