Download Personal Medical Record - MSU CSE

Software Requirements Specification (SRS)
Personal Medical Record
Authors: Christopher Dasbach, Sammy Djap, John Furcean, Steven Garske, Michael Kerwin,
Haohan Lin, Wayne Stiles, William Zajac
Customer: Dr. Raza Haque
Instructor: Dr. Betty H.C. Cheng
1 Introduction
This document first introduces the product specified within, then gives an overall
description of the system and specific, modeled requirements thereof, and afterwards describes a
prototype of the software. The references used and a point of contact for further information are
listed at the conclusion of the document. This software requirements specification should
provide a high-level perspective of the product’s purpose, requirements, and design. This
document should serve as a basis for implementation of the product described.
1.1 Purpose
The purpose of this document is to describe the Personal Medical Record (PMR)
application for the iPhone and Android smartphone platforms in a manner clearly understood by
both the developers and the customer of the system for validation of the high-level design. The
final version of this document will be recommended as the basis of low-level design of the
software and its implementation.
The intended audience for this document is the students of CSE 435 at Michigan State
University, Dr. Betty Cheng, and Dr. Raza Haque.
1.2 Scope
The software product to be produced is the Personal Medical Record application. This
application, for the iPhone and Android platforms, provides a user access to a portable copy of
their medical records on the device. The medical information will be stored on a secure server to
1
which the application is linked. The user can view their medical history and list of medications,
view and modify their general contact and diagnosis information, and authorize persons they
specify as having access to their information via remote connection to the online server
(constrained to those for which the user states as having signed a HIPAA agreement, or Health
Insurance Portability and Accountability Act agreement). The user can authorize persons as
having read-only or editorial access to their medical information. The user can backup
information to either the secure server or to a personal laptop, and can restore information to the
portable platform from either.
The user can also add comments and personal notes to their medical records, which will
be delineated as user-entered information. Comments added by authorized caretakers or family
members would also be noted as unofficial. Any medical professionals who the user authorizes
to access their medical information would be able to add information (medication prescriptions,
laboratory results, and other medical events) marked as physician-entered information. Medical
professionals can add information manually or from the electronic medical record system. All
modifications to the user’s medical record stored on the secure server will be included when the
device next synchronizes to the server to update information. Physician-entered information
may not be modified except by a medical professional.
The server that will be used for this project will only accept data from two points. The
server will update itself from the ARMOR collection server for the medical records and also
receive updates for personal records from the phone as well as notes associated with both the
medical and personal records. Constricting the application to accept data from these two sources
in a specified format, will minimize any security issues associated with this system.
The user interface on each platform will be designed with user-friendliness in mind and
with the understanding that users of the personal medical record application will primarily be
geriatric patients taking several medications.
1.3 Definitions, acronyms, and abbreviations
The purpose of this section is to explain and define any acronyms or abbreviations used
in this document for clarification.
2
ARMOR – “Assess, Review, Minimize, Optimize, Reassess”. An electronic medical
record system designed for use by medical professionals. It collects medical information and
analyzes it for possible drug interactions and issues related to patient quality of life for geriatric
patients taking several medications. This system is being designed in parallel with the PMR
software.
CCR – Continuity of Care Record. A documentation format for storing medical records,
built as a subset of the XML format described below.
EMR – Electronic Medical Record. A copy of a patient’s medical records stored on a
computer or online for security, efficiency, convenience, and portability. May be intended for
use by medical professionals, patients, or both.
HIPAA – Health Insurance Portability and Accountability Act. A law which mandates
that a patient sign an agreement whenever they want to authorize any person to view their
medical information. A statement that the user has signed a HIPAA agreement is required for
the user to authorize any person to view their medical records through the PMR software.
HW – Hardware. The physical electronic machine(s) on which software is run.
PDM – Personal Drug Management. An electronic system for tracking, maintaining, and
managing a user’s medications, including descriptions of each drug and notifications for when
medication needs to be taken. This system is being designed in parallel with the PMR software,
but does not directly interact with it.
PMR – Personal Medical Record. An electronic copy of one’s medical records intended
to be user-portable, such that the user always has their medical records with them in case they are
needed. Image files in their record are only accessible with an internet connection, as they are
not saved on the smartphone.
3
SRS – Software Requirements Specification. A document outlining a high-level design
of a software system, the requirements it should meet and the constraints by which it should be
limited.
SW – Software. The applications, both user-run and system-run, which perform
numerous functions for the user.
UML – Unified Modeling Language. A widely-used notation for describing a software
system in a series of diagrams, helpful in designing how to build the system.
XML – Extensible Markup Language. A highly-flexible and easy to use documentation
format for storing information, which can be adapted to almost any software input specifications.
ZIP – (not an acronym) A widely-used file format that allows one to compress a folder of
files into a single file for purposes of easy portability.
1.4 Organization
The remainder of this document consists of an overall description of the product
(including the product perspective and functions, user characteristics, constraints, assumptions
and dependencies, and apportioning of requirements), followed by the specific and modeled
requirements of the system. Then, this document describes a functional prototype, how to use
the prototype, and example scenarios of the prototype in use. Finally, this document includes all
references used and a point of contact for further information.
2 Overall Description
This section is intended to give an overview of the purpose of our application and what
functions it will include. It will also explain who will benefit from the product, and how we plan
to design the application to meet the needs of our target demographic.
4
2.1 Product Perspective
The main purpose of the Personal Medical Record system is to allow the user to observe
their medical records with their smartphone wherever and whenever they want. This ability
empowers the patient and encourages them to take a more proactive role in their health. It allows
physicians and healthcare workers to promptly review vital information in a timely fashion (an
otherwise time-consuming process) essential to making more meaningful clinical judgments.
Our goal is to create a simple product geared towards geriatric patients which will allow them to
confidently participate in their healthcare using this new medium.
The types of medical records that can be provided are confidential documents such as CT
and X-ray scans, and lists of medications, consultation or emergency room reports from other
physicians, and prescriptions. However, there are also some secondary level personal records
such as blood type, age, health condition, organ donation instructions, etc.
The Personal Medical Record is a part of a bigger system (see Figure 2.1). The back-end
system is the database of information from the ARMOR system (Data Collection, Data Analysis,
and Optimization), which provides medical documents to both the PDM and PMR software
applications on all platforms (iPhone and Android for the PMR software; iPhone, iPad, and
Android for the PDM software). The format of documents in the database to be used as input to
the PMR system is expected to be CCR, a subset of the XML format.
5
Figure 2.1: Entire system, of which the Personal Medical Record application is a part.
The Personal Medical Record software must be built to follow several constraints. Both
the iPhone and Android platforms should have the same functionality, and the same basic
features, including a touchscreen, on-screen keyboard, camera, and microphone. Beyond this
extra platform-specific features may be implemented, such as use of the Android’s slide-out
keyboard functionality. The application should have a touch-based user interface on both
platforms, and should have functionality to output medical records to a laptop or server. This
may be implemented wirelessly or through a smartphone – computer connection.
In addition to system constraints, there should be limitations to the user interface. Given
the small screen of a smartphone platform, the functionalities of the application should be
divided into separate pages in a manner that does not confuse the user. Menus or lists that have
too many options or events for the screen to display at once should implement scrolling
capability.
6
The application should be able to process information obtained from the server or laptop
backup efficiently using the smartphone hardware. The application should account for the rare
situation where the smartphone runs out of memory and cannot process the entire medical
record. Any solution for this problem should not write over information that would be important
in an emergency, including the user’s list of medications, allergies, blood type, external devices
used, and pacemaker information (if any).
The application should include a high level security system to protect the confidentiality
of the user’s private medical information. This security should extend to both communication
with the server and authorization to view the actual application. Despite this, the personal
medical record should implement an override that medical professionals can use in the event of
an emergency, allowing them to view emergency information (listed above).
2.2 Product Functions
The most significant feature of the software is letting the user conveniently observe their
personal medical record wherever they go. Their record is downloaded periodically from the
secure server, and includes the user’s entire medical history of documents, list of medications,
and physician information. Images are downloaded from the server as they are accessed. Each
category will be presented in a list, with the ability to select individual records to view their
details. These details include all results and summary of medical events, dosage information of
medications, and contact information for physicians and the user. Information will be clearly
delineated as user-entered or physician-entered, and official records may not be modified, though
the user may add their own user-entered comments if they desire.
The application allows for backups to be made to the secure server or to an external
storage device, including all user-entered and physician-entered information and comments. The
application and server will be secure; security of information stored on a laptop is the user’s
prerogative. The user, as well as anyone the user authorizes, can access their medical record on
the server remotely through an internet browser, allowing other authorized persons to add
comments and the user to have access to their information even if their smartphone breaks.
The user will have ultimate control concerning who is authorized to view their medical
information through the personal medical record system, either on the smartphone or through the
server remotely. The user must assert that they have signed a HIPAA agreement concerning
7
each person before that person can be authorized, though no electronic copy of the agreement is
stored on the smartphone. A subset of medical information critical in an emergency may be
viewable by any medical professional using the system.
2.3 User Characteristics
Our target demographic is geriatric patients who are, as a whole, unlikely to be
technically savvy. Many seniors who have limited experience with handheld devices might be
intimidated by them. Therefore it is important that they trust our system and are never required
to perform any complex tasks. Furthermore, due to memory loss, some users may need frequent
notifications of important information and it may not be enough to merely display information
once.
Other users of the system would be persons the patient authorizes, some of whom may be
medical professionals. These people will have different levels of access to the personal medical
record application – authorized medical professionals will be able to add physician-entered
information to the record, while authorized relatives or friends may view the system but may not
add comments unless authorized by the user. Medical professionals should be informed of how
to retrieve emergency information from the system even if unauthorized to view the patient’s full
medical record.
2.4 Constraints
There are three main constraints of the PMR system, to ensure the safety and security of
the medical record. First, logging in is always required when the user tries to access the medical
file. If there are too many failed login attempts, the program will try to help with id and password
recovery with registered email, phone number, and security question. If there are still too many
failed attempts to login, the login will lock up for one hour.
Second, when the user logs in, a timer will start and the user will be automatically logged
out within 5 minutes if they do not take any action. This timer will reset every time the user
takes an action.
Third, the user should know that their iPhone or Android is using its legal and proper OS
to protect both the local and back up medical file. Any modifications, disassembly, or cracking
8
operations may lead to safety issues and/or application faults. The application cannot be held
liable for any problems that arise from running it on a modified smartphone.
2.5 Assumptions and Dependencies
We are assuming that the device will only be available to the patient whose medical
records are stored on the device. Additionally the patient using the smartphone device will have
internet access frequently, allowing the system to communicate with the server. We expect the
user to have at minimum a very basic understanding of digital interfaces, and be able to grasp
concepts like saving, loading, and basic data input, and that the user will be able to operate and
view the smartphone regardless of any disabilities. The system will be made as accessible as
possible, but some patients may still have difficulties using it. We also assume the patient will
know and remember enough about their own medical history and situation that the information
displayed will be relevant and useful to them.
Regarding the smartphone itself, we assume the iPhone or Android includes a
touchscreen, camera, and microphone (the camera and microphone will be used in a later
implementation). The PMR software assumes that the user understands the significance of a
HIPAA agreement, and uses the application responsibly and in its proper environment.
2.6 Apportioning of Requirements
Some features originally intended will not be included in the initial version of the
application. Voice commands, HIPAA verification, email notifications of appointments,
interaction with the smartphone’s camera function, and automated data sharing will not be
included, but will be valuable to the user in a future version of the software.
3 Specific Requirements
Next to each requirement below is a letter denoting whether the requirement is common
to all platforms, or is a variation for either the iPhone or Android platform only. A ‘C’
represents a common requirement, whereas a ‘V’ represents a variant requirement.
9
1. External interface requirements
1.1 User interfaces
1.1.1 C Convenient, easy to use
1.1.2 C Scalable windows
1.1.3 C “Main menu” button
1.2 Hardware interfaces
1.2.1 V Apple iPhone operating system
1.2.2 V Google Android operating system
1.2.3 C Web server
1.3 Software interfaces
1.3.1 C CCR file format
1.3.1 C Server must link to ARMOR database
2. System Features
2.1 Login
2.1.1 C The login screen will allow returning users to specify username and
password to gain access to the application and verify those credentials. It
will also allow new users to set up an account.
2.1.2 C Stimulus/Response
2.1.2.1 C PMR Application Icon clicked in smartphone menu/Login
screen presented if application not already running
2.1.2.2 C User submitted and invalid credentials/Display phrase “Incorrect
username or password” and allow user to resubmit.
2.1.2.3 C User submitted and valid credentials/Advance screen to Main
Menu
2.1.2.4 C User clicks “Forgot Password?” link/Application asks for user's
username
2.1.2.4.1 C If username was previously registered, send password
to associated email address
2.1.2.4.2 C If username not registered, advance user to Registration
Screen with message displayed “Unregistered Username”
10
2.1.2.4.3 C User clicks “Register” link/Application advances to
Registration Screen
2.1.3 C Functional Requirements
2.1.3.1 C The system shall mask the password field
2.1.3.2 C The system shall validate username and password match by
sending a request to the server
2.1.3.2.1 C The username and password shall be sent encrypted
2.1.3.3 C The username and password field will hold a max of 20
characters
2.1.3.4 C The username and password field will only contain
alphanumeric characters
2.1.3.5 C When clicked, the username and password field will use the
smartphone's onscreen keyboard functionality
2.1.3.6 V The Android platform may alternately use its slide-out keyboard
functionality.
2.1.3.7 C After a failed login attempt, the password field shall be cleared
2.1.3.8 C The system shall take less than 10 seconds to validate user
credentials
2.1.3.8.1 C If server is inaccessible, output message “Can't connect
to server”
2.2 Main Menu Screen
2.2.1 C The main menu screen will be a full view, scrollable screen containing
large buttons linking to the User Information, Medical History, Backup,
and User Permissions screen. Also, a box on the bottom which will be
displayed at all times on this screen allows for quick user recording of
notes.
2.2.2 C Stimulus/Response
2.2.2.1 C User clicks “User Information” button / Application advances to
User Information Screen
2.2.2.2 C User clicks “Medical History” button / Application advances to
Medical History Screen
11
2.2.2.3 C User clicks “Backup” button / Application advances to Backup
Screen
2.2.2.4 C User clicks “User Permissions” button / Application advances to
User Permissions Screen
2.2.2.5 C User clicks “Edit” link on note box / On screen keyboard
displayed allowing user to type in current condition
2.2.2.6 C User clicks “Add a picture?” link on note box / smartphone
Camera application is launched, picture captured is displayed in
thumbnail near bottom
2.2.2.7 C User clicks Picture Thumbnail / Picture displayed in full screen
with close option
2.2.2.8 C User scrolls window / If information is too large to fit into one
view, view will scroll to reveal extra information not displayed
2.2.3 C Functional Requirements
2.2.3.1 C The system shall always display the note box even when the user
scrolls
2.2.3.2 C If the user makes a change in the note box, the system shall
record the note information and save the information daily on the
server for retrieval later
2.3 User Information Options
2.3.1 C The user’s personal information record will be a full screen, scrollable
view containing information about the user including name, age, blood
type, current known medical condition, primary and specialist physician
contact information, and a link to current medication list.
2.3.2 C Stimulus/Response
2.3.2.1 C User clicks “List of Medication” button / Application advances
to drug list on Medical History screen
2.3.2.2 C User clicks “Back” button / Application advances to Main Menu
screen
2.3.2.3 C User scrolls window / If information is too large to fit into one
view, view will scroll to reveal extra information not displayed
12
2.3.3 C Functional Requirements
2.3.3.1 C Information displayed on this screen will be stored locally on the
phone's storage system
2.4 Medical History Options
2.4.1 C The medical history will be displayed in a full screen, scrollable view
with information including what, who, where, and when the record is
for/from, and a comment field with edit and submit buttons. A next button
will advance to the next most recent record. A list of the user’s
medications may be viewed as part of the history or separately.
2.4.2 C Stimulus/Response
2.4.2.1 C User clicks “View Comment” button / On-screen keyboard is
displayed allowing user to edit comment
2.4.2.1.1 C On return, comment box displays typed comment
2.4.2.1.2 V On the Android platform the slide-out keyboard may
be used instead
2.4.2.2 C User clicks “Submit Comment” button / Comment is sent to
server and attached to record but delineated as a user addition and
not part of the official record
2.4.2.2.1 C If user has already associated a comment with the
particular record, the new comment is appended to the list
of comments with new timestamp
2.4.2.3 C User clicks “Next” button / Application pulls down the next
most recent history record from the server
2.4.2.4 C User clicks “Previous” button / Application pulls down the last
most recent history record from the server
2.4.2.5 C User clicks “Back” button / Application advances to Main Menu
screen
2.4.2.6 C User scrolls window / If information is too large to fit into one
view, view will scroll to reveal extra information not displayed
2.4.3 C Functional Requirements
13
2.4.3.1 C Comment field with have a maximum character limit of 160
alphanumeric characters and punctuation.
2.4.3.2 C On initial load of screen, the user will get most recent record
from server and display it
2.4.3.2.1 C Subsequent loads of screen will display latest viewed
record
2.4.3.3 C If the most recent record is displayed, then a “Previous” button
will be grayed out and inoperable in the bottom-left hand corner
2.4.3.4 C If the oldest record is displayed, then the “Next” button will be
greyed out and inoperable.
2.4.3.5 C Comment box will display all comments associated with the
record
2.4.3.6 C User comments will be in a different color than that used for
official medical record comments
2.4.3.7 C Comment box shall be scrollable separately from the main
screen
2.5 Backup Data
2.5.1 C The backup screen will display two options as buttons to either restore
data to last backup by syncing with the server or backup current data to an
external device.
2.5.2 C Stimulus/Response
2.5.2.1 C User clicks “Restore to last backup” button / Application
initiates backup action overwriting current information with that of
backup
2.5.2.2 C User clicks “Backup Current Data” button / Application initiates
backup action writing current information to the external device
(or server). The data is stored as a zip file on the external device.
2.5.2.3 C User clicks “Back” button / Application advances to Main Menu
14
2.5.3 C Functional Requirements
2.5.3.1 C When a backup action is initiated, application will check for
external device connected to phone (usually through USB,
Bluetooth, or the server)
2.5.3.2 C Application will be locked while backup is in progress
(smartphone may still be used for other purposes such as calling)
2.5.3.3 C Application will ask for location to write data on external device
or where to read data from
2.5.3.4 C All data will be stored in a zip file and the zip file will include:
records, user information, and notes associated with the records.
2.5.4.5 C Backup utility will not be fully available in final prototype
release.
2.6 User Permissions
2.6.1 C The user permissions menu maintains a list of current people the user has
authorized to view their personal medical record.
2.6.2 C Stimulus/Response
2.6.2.1 C User clicks “Add new person” link / Application advances to
Authorized Person screen
2.6.2.2 C User selects an entry from the table / Application advances to
Authorized Person screen with that person's information displayed
in the fields
2.6.2.3 C User clicks the “Back” button / Application advances to the
Main Menu
2.6.2.4 C User scrolls table / If information is too large to fit into one
view, view will scroll to reveal extra information not displayed
2.6.3 C Functional Requirements
2.6.3.1 C User permissions data is stored locally and on the server
2.6.3.2 C The name and relationship columns each have a 25 character
limit
15
2.7 Authorized Person
2.7.1 C This screen displays information about a person a user has authorized or
allows a user to add a new person and includes name, address, relation,
and permissions: view, edit, and HIPAA.
2.7.2 C Stimulus / Response
2.7.2.1 C User clicks the Name field / On-screen keyboard opens allowing
user to update name field
2.7.2.1.1 V On the Android platform, the slide-out keyboard may
be used instead
2.7.2.2 C User clicks the Address field / On-screen keyboard opens
allowing user to update address field
2.7.2.2.1 C Same for each line of address
2.7.2.2.2 V On the Android platform, the slide-out keyboard may
be used instead
2.7.2.3 C User clicks the Relation field / On-screen keyboard opens
allowing user to update relation field
2.7.2.3.1 V On the Android platform, the slide-out keyboard may
be used instead
2.7.2.4 C User clicks the View checkbox / If checked, uncheck; else if
unchecked, check
2.7.2.5 C User clicks the Edit checkbox / If checked, uncheck; else if
unchecked, check
2.7.2.6 C User clicks the HIPAA checkbox / If checked, uncheck; else if
unchecked, check
2.7.2.6.1 C The application assumes the user has signed a HIPAA
agreement for the person if they click the checkbox. The
application does not have any way to verify this itself.
2.7.2.7 C User clicks the “Cancel” button / Application advances to User
Permissions screen and changes are not saved
16
2.7.2.8 C User clicks the “OK” button / Application advances to the User
Permissions screen, changes are saved, and new/updated entry is
displayed in the table
2.7.3 C Functional Requirements
2.7.3.1 C The name field and relation field have a 25 character limit
2.7.3.2 C Each address line has a 200 character limit
2.7.3.3 C If an entry has the view checkbox enabled and the HIPAA
checkbox is also enabled, the person is allowed to view the user's
records
2.7.3.4 C If an entry has the edit checkbox enabled and the HIPAA
checkbox is also enabled, the person is allowed to leave comments
on records
4 Modeling Requirements
It is useful to create models of software designs before implementing the program in
code, as these diagrams can make obvious possible errors early on in the design process. Below
are diagrams commonly used to model software: a use-case diagram, a domain model diagram,
sequence diagrams, and state diagrams.
4.1 Use-Case Diagram
Figure 4.1 is a use-case diagram, which details the actions that can be taken within the
system. The characters outside the box are called actors; they are the users outside the system
that interact with the system. The circles within the box, or system boundary, are the use cases.
They describe the functions each actor can take within the system. A use-case may be linked to
another use-case as an ‘include’. An included use-case has all the functionality of the use-case
including it, with additional features besides.
Use-case descriptions help explain the functionality and relationships which may not be
clear from the diagram below. The use-case descriptions for this diagram follow Figure 4.1.
17
Figure 4.1: Use-case diagram for the personal medical record system.
Add Image/Document
Use Case:
User
Actors:
Description: The user can add an image taken by the camera of their phone or a text document
they write with the smartphone’s keyboard to any medical record they have
personally created. These images or documents would be permanently attached
to the record and can be viewed at any time.
Primary and Essential
Type:
Create Record
Includes:
Extends:
Cross-refs: 2.2.2.5, 2.2.2.6, 2.2.3.2, 2.4.2.2
Create Record
Use cases:
Add Note
Use Case:
User
Actors:
Description: The user will have the option to add on notes regarding a certain medical record.
These notes will be attached to the record permanently and will be able to be
viewed at later times.
Secondary
Type:
View Record
Includes:
Extends:
Cross-refs: 2.4.2.2
View Record
Use cases:
18
Backup
Use Case:
User, Server, Laptop
Actors:
Description: The user has the opportunity to backup all of the medical records on to an
external storage device. The user must have an established connection with the
device, and data will be transferred to the device so that the device will have a
hard copy backup. The data will be directly downloaded from the server.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 2.5.3.2, 2.5.2.2, 2.5.3.1, 2.5.3.3
Use cases:
Create Record
Use Case:
User
Actors:
Description: The user has an option to create his/her own medical record to store information
about symptoms of ailments.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 2.4.2.2
Use cases:
Login
Use Case:
User, Server
Actors:
Description: The system will require the user to login to the system via a pre-established
username and password that is linked to the users account. The user cannot
access any data unless they are logged in. The server is used to verify the users
credentials.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 2.1.2.1, 2.1.2.3
Use cases:
Logout
Use Case:
User
Actors:
Description: The user may logout of the system at any time during use. A user must be logged
in, in order for a logout to be possible.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs:
Login
Use cases:
19
Manage Permissions
Use Case:
User
Actors:
Description: The user may edit the list of persons authorized to log in to the system. A person
who is not authorized may not log in or view information.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 2.2.2.4, 2.6.2.1, 2.7.2
Use cases:
Sync
Use Case:
User, Server
Actors:
Description: The PMR application will listen to the server and update any record that has a
newer version that was previously displayed on the phone.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 1.2.3, 1.3.1
Use cases:
Update User Information
Use Case:
User
Actors:
Description: The user can update their personal information such as name, primary doctor,
address, blood type, and any other information that would be medically relevant.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 2.3.1
Use cases:
View Records
Use Case:
User
Actors:
Description: The user can request a medical record that is either provided from the healthcare
provider or the user themselves. The record will contain all the information
associated with the visit or entry.
Primary and Essential
Type:
Includes:
Extends:
Cross-refs: 2.4.1, 2.4.2.3, 2.4.2.4, 2.4.2.6, 2.4.3.2
Use cases:
20
4.2 Domain Model Diagram
The following, Figure 4.2, is a domain model diagram, which details the objects within
the system. The boxes, or elements, represent different classes in an object-oriented
programming environment. The lines between boxes show the relationships between these
classes. A line with a white arrow indicates that the class pointing to the other ‘inherits’ from the
other class – it includes all the functionality of the base class, with additional features or
capabilities. A line with a black diamond indicates a composition association: the first class is a
part of the class with the diamond, and furthermore neither element can exist without the other.
The numbers at the ends of lines represent how many of a given class can be associated with the
other class, an ‘…’ represents a range of values, and an asterisk (*) indicates that any finite
number of the given class may be associated with the other class.
Domain models, or class diagrams, help show relationships between objects and reveal
possible contradictions or errors before software is implemented. Data dictionaries help explain
the attributes and functionalities of each element that may not be clear from the diagram below.
The data dictionary for this diagram follows Figure 4.2.
Although the attributes and operations of the class objects are included in both diagram
4.2 and the data dictionary, the stereotypes and constraints included in the data dictionary were
excluded from the diagram to make it easier to read.
21
Figure 4.2: Domain model diagram for the personal medical record system.
Element Name
CareGiver
Description
Class that contains the full information regarding
about each care giver.
Attributes
name:String
position:String
role:String
workplace:String
The care giver’s fullname
The care giver’s job position
The care giver’s role for the official record
The location where the care giver is working
Operations
Relationships
UML
Extensions
getCareGiverInfo () :
Function that returns the information regarding
String[]
about a care giver into an array of strings.
CareGiver class is fully owned by the official record. Mainly because, each
official record will be created by one or more care givers.
<<optionalLifeline>> The lifeline of CareGiver is fully dependent on the
OfficialRecord. If the OfficialRecord is destroyed, the CareGiver’s lifeline will
then end.
22
Element Name
Documents
Description
The documents class is abstract and used to
represent official documents on the patients
record either added manually or scanned in
Attributes
documentID:String
description:String
comments:String
timestamp:String
author:String
A unique identifier for each document.
A description of what the document contains
Any comments associated with the
document
Time the document was added to the record
Name of person who added document to
record
Operations
getDocumentInfo(String
documentID): Document
Relationships
UML
Extensions
Virtual function which takes document ID
and returns all information about that
document.
getDocumentData(String
Function to request the binary data for a
documentID) : File
particular document.
Documents is associated with one DocumentView which displays its info.
Records also contains a list of documents which make up the record.
Documents is abstract and has two sub-classes which inherit from it, Text and
Scanned.
Constraint of comments to stay within 160 characters.
Element Name
DocumentView
Attributes
Description
An interface for display a document.
File_name : string
Path : string
The name of the document.
The local path of document.
Operations
RecordView(string, string) :
void
show () : int
Relationships
UML
Extensions
Constructor for initialize File_name and
Path.
Virtual function for open and show
documents.
Accept by the interface object. Children Class of SingleView.
<<interface>>
<<variationPoint>>
23
Element Name
Drug
Description
Drug contains all the information related to a
particular medication including name, dosage,
frequency, duration, condition, and physician.
Attributes
name:String
dosage:Int
frequency:Float
duration:Int
condition:String
physician:String
The name of the drug
Amount of dosage of the drug, given in milligrams
(mg)
How often to take drug, given in times per day
How long to take drug, given in number of days
Name of condition(s) that the drug is used to treat
Name of physician who prescribed drug
Operations
getDrugInfo(String
property): String
Relationships
Function which takes a string which is the name of
the attribute you want to know. The result is
returned as a string of the attribute requested.
Drug is associated with DrugView in that a drug only has one view and Drug
View reads the data to display from Drug. Record contains a list of drugs
associated with the particular record and makes up part of the record.
UML
Extensions
Element Name
DrugView
Attributes
Description
Display a drug list.
File_name : string
Path : string
The name of the drug list.
The local path of drug list.
RecordView(string,
string) : void
show () : int
Constructor for initialize File_name and Path.
Operations
Relationships
UML
Extensions
Function for open and displays drug list. Any
failure will return -1; otherwise, return 1;
Accept by the interface object. Child Class of SingleView.
<<variation>>
24
Element Name
Image
Description
Image class simply contains the property of an
image associated with a record
Attributes
imageID:String
description:String
comments:String
picture:Object
timestamp:String
Unique identifier for the image.
A description of what the image contains
Any comments associated with the image
Actual image data (could be stored different on
different platforms)
Time the image was added to the record
Operations
getImageData(String
imageID) : File
getImageInfo(String
imageID): Image
Relationships
UML
Extensions
Function to return the binary image data from
the server for a particular image.
Function to return all data about a known
image with the exception of the actual image
data.
The image class is associated with an ImageView class which displays the
image properly. The Record class can also contain a list of images which
makes up the record.
<<variation>> on how the picture Object is actually stored on the platform.
Constraint on comments to stay within 160 characters.
Element Name
ImageView
Attributes
Description
Display an image.
File_name : string
Path : string
The name of the image.
The local path of image.
RecordView(string,
string) : void
show () : int
Constructor for initialize File_name and Path.
Operations
Relationships
UML
Extensions
Function for open and displays image. Any failure
will return -1; otherwise, return 1;
Accept by the interface object. Child Class of SingleView.
<<variation>>
25
Element Name
Interface
Description
The main class that is capable of calling the default
iOS User Interface API, in this case is the List/Grid
view window and single view window. Moreover,
it is the main menu for displaying documents.
Attributes
singleView:View
listView:View
viewType:String
The single view object
The list view object
The type of objects to show in the view (e.g. image,
document, drug, or record)
startListView (String
viewType, View
listView): void
startSingleView (String
viewType, View
singleView): void
RequestBackup()
Function to start and open the ListView for a given
type of objects.
Operations
Relationships
UML
Extensions
Function to start and open the SingleView for a
given type of objects.
Function to start the process of receiving a zip
backup of all of the data on the server.
Interface class is owned by the PMRSystem due to it starts the whole
application and user interface. Moreover, since Interface class controls how
object/s should be displayed, it has an association with the view objects.
Constraint in the user interface might be a small issue for the interface as it
represents as the main menu for all view. Therefore, limitation in showing all
possible view choices might occur.
Element Name
ListView
Attributes
Description
List all medical files and display.
File_name_ Vector:
vector<string>
Path_ Vector:
vector <string>
The vector of local files’ name.
The vector of local files’ path.
Operations
ListView( ) : void
Relationships
UML
Extensions
Constructor by search local storage to find the medical
file and recode the name and path by File_name_ Vector
and Path_Vector.
show ( ) : int
Show all medical files to user to choose in the vector.
Once the user chooses one file, open and display it until
the user closes it. Any failure will return -1; otherwise,
return 1.
Accept by the interface object. Inheritance form View.
<<variation>>
26
Element Name
OfficialRecord
Description
Official Record is a class derived from the
Record class. It holds the records, such as
notes, written by care giver (e.g. specialist,
physicians, nurse, etc.)
Attributes
summary:String
date:String
careGiver:CareGiver[]
category:String
note:String
The official record’s description
The date when the record is made
An array of care givers
The official record’s category (e.g. drug,
medical condition, etc.)
The user added note.
Operations
addCareGiver(CareGiver
careGiver) : boolean
Relationships
UML
Extensions
Function that adds new care giver into the
official records. The function returns true if
adding is successful, false otherwise.
deleteCareGiver(CareGiver
Function that deletes existing care giver. The
caregiver) : boolean
function returns true if deleting is successful,
false otherwise
addNote(String note)
Adds a comment to the official record
Official record is inherited from parent Record class. Official record also owns
the list of care givers who contribute to the record.
<<variant>> Official record is a variant of variation point. The variation is the
Record class. Moreover, Official record behavior is relying on the Record
interaction with other classes.
Element Name
PatientRecord
Description
PatientRecord is a class derived from the Record
class. It holds the records added unofficially by the
patient and delimited as such.
Attributes
summary:String
date:String
category:String
A description of what the record contains
The date when the record was made/added
The record's category (what it's for)
Operations
GetInfo():String[]
Relationships
UML
Extensions
Returns the information associated with the record as
an array of string
SendToServer(Record) Sends the record to the server to be stored
permanently.
Patient record inherits from the abstract class Record. It contains Records
attributes and Operations.
<<variant>> PatientRecord is a variant of variation point. The variation is the
Record class. Moreover, PatientRecord behavior is relying on the Record
interaction with other classes.
27
Element Name
PMRSystem
Description
Start the whole PMR program and controls the
connection with the application’s interface and
the web server. Moreover, it contains the user
log-in functionality.
Attributes
username:String
password:String
Interface:Interface
currentUser:User
The username of a particular user
The password of a particular username
The main interface object
The user information associated with the
application
Operations
tryLogIn (String username,
String password): boolean
Relationships
UML
Extensions
Function to validate the authentication by sending
username and password to the web server.
Function will return true if authentication
successful, false otherwise.
startMenu (Interface
Start the main interface and also the main menu
interface): void
for the application
Logout()
Will log the user out of the application
GetUpdate()
Will request an updated list of records from the
server.
GetBackup()
Will ask the server to return a zip file of all of the
user’s data.
PMRSystem is made up of the interface class that acts as the application’s
output (TouchScreen). Without interface, any user will not be able to access the
system. Moreover, PMRSystem also has association with Server due to the
whole system will be required to synchronize with the server in order to obtain
some data. With the log-in functionality, PMRSystem need to have an
association with user class because of the information gained from the loggingin will be feed into the user class.
Communication constraint between the application and server might be a big
issue. Security constraint in the communication will also affect the quality of
data transferring.
28
Element Name
Record
Description
Record is an abstract class and represents
an official Medical History record on the
patient's file. It can contain any number
documents, drugs, or images.
Attributes
recordID : String
documents:Vector<Documens>
drugs:Vector<Drugs>
images:Vector<Image>
comments:String
additionalInfo:String
title:String
updateDate:String
The unique ID associated with this record.
A list of documents associated with the
record
A list of drugs associated with the record
A list of images associated with the
record
Any comments associated with the record
Any additional info associated with the
record such as follow-up activities, sideeffects, or relationship to family history
The record’s title
Shows when the record was last updated
Operations
addDrug(Drug drug):boolean
Relationships
UML
Extensions
Adds a Drug to the record, returns true if
successful
deleteDrug(Drug drug):boolean
Deletes a Drug from the record, returns
true if successful
addImage(Image image):boolean
Adds a Image to the record, returns true if
successful
deleteImage(Image image):boolean Deletes a Image from the record, returns
true if successful
addDocument(Documents
Adds a Documents to the record, returns
doc):boolean
true if successful
deleteDocument( Documents
Deletes a Documents from the record,
doc):boolean
returns true if successful
getRecordInfo(String
Requests information about a single
recordID):Record
record from the server.
Record is an abstract class that has two subclass types, PatientRecord and
Official Record which actually do the implementation. Record contains a list of
documents, drugs, and images. Record also has an associated RecordView and
interacts with the User which each record is attached to.
Constraint on comments to 160 character limit.
29
Element Name
RecordView
Attributes
Description
Display a record.
File_name : string
Path : string
The name of the record.
The local path of record.
RecordView(string,
string) : void
show ( ) : int
Constructor for initialize File_name and Path.
Operations
Relationships
UML
Extensions
Function for open and displays record. Any
failure will return -1; otherwise, return 1;
back ( ) : void
Function to return to the record list view.
Accept by the interface object. Children Class of SingleView.
<<variation>>
Element Name
Scanned
Attributes
Operations
Relationships
UML
Extensions
Description
A sub-class of documents, represents a document
which was inputted scanned as an image. Inherits
attributes and operations from Documents.
(NOTE: implements
Documents attributes)
picture:Object
The scanned picture of the document
(NOTE: implements
Documents operations)
None
Inherits from and is a Documents and implements the virtual function
GetDocumentInfo().
<<variation>> Could be variation in how the document image is stored on
different platforms
Element Name
ScanView
Attributes
Description
Display a scanned document.
File_name : string
Path : string
The name of the scanned document.
The local path of scanned document.
RecordView(string,
string) : void
show () : int
Constructor for initialize File_name and Path.
Operations
Relationships
UML
Extensions
Function for open and show scanned document.
Any failure will return -1; otherwise, return 1;
Accept by the interface object. Children Class of DocumentView.
<<variant>>
30
Element Name
Server
Description
Responsible to execute HttpGet or HttpPost
method to the web server in order to obtain
records. This class will be called every time the
user initiates a functionality that requires a data
sent or received by the web server.
Attributes
url:String
parameter:String
entity:ResponseEntity
The complete url of the web server.
The parameter required to complete the URL
(Mainly used for HttpGet).
Save the Http response sent by the server.
Operations
tryConnect(url:String) :
ResponseEntity
trySearch (String url, String
parameter): ResponseEntity
Relationships
UML
Extensions
Function to connect to a web server given as the
URL parameter.
Function to connect and request data from the
web server. The request data will be returned by
this function
tryUpload (String url, String Function to connect and feed new data to the web
parameter): int
server. The Http status code will be returned by
this function
handleResponse (HttpEntity Function responsible for receiving the Http
response) : void
Response sent by the web server and pass it to the
appropriate class.
Server is mainly connected only with PMRSystem. It is important to limit the
vulnerability of server class from other classes in order to increase the security
Communication constraint between the application and server will still be an
issue and again Security constraint in the communication will also affect the
quality of data transferring.
<<optionalLifeline>> Server class is used only when data transferring or
feeding is required.
31
Element Name
SharedPermissions
Description
Class that holds the information regarding about
the shared permission users.
Attributes
fullname:String
age:int
gender:String
userID:String
sharedLevel:int
The user’s fullname
The user’s age
The user’s gender
The user’s ID
Indicate the level of access the shared
permission user has.
Operations
setSharedLevel(int lvl) : void
Relationships
UML
Extensions
Function to set the sharedLevel. This function
will be invoked by User class.
SharedPermissions class is controlled by the User only. Each user can have
multiple numbers of shared permissions users, but the main user is allowed to
limit the level of access.
<<optionalLifeline>> Each shared permissions user will have optional lifeline
and it is controlled by the user. <<optionalInteraction>> Each shared
permissions user will also have optional interaction with the main user, and only
the main user can control the amount of interaction.
Element Name
SingleView
Attributes
Description
An interface for display of a single object.
File_name : string
Path : string
The name of the file
The local path of file.
SingleView(string, string) :
void
show ( ) : int
Constructor for initialize File_name and Path.
Operations
Relationships
UML
Extensions
Virtual function for all view type class
displays different objects.
Accept by the interface object. Parent of RecordView, ImageView, DrugView,
and DocumentView. Inheritance from View.
<<interface>>
<<variationPoint>>
32
Element Name
Text
Attributes
Operations
Relationships
Description
A sub-class of documents, represents a document
which was input manually with user editable fields.
Inherits attributes and operations from Documents.
(NOTE: implements
Documents attributes)
contents:String
The text of the document
(NOTE: implements
Documents operations)
None
Inherits from and is a Documents and implements the virtual function
GetDocumentInfo().
UML
Extensions
Element Name
TextView
Attributes
Description
Display a text-based document.
File_name : string
Path : string
The name of the text-based document.
The local path of text-based document.
RecordView(string,
string) : void
show () : int
Constructor for initialize File_name and Path.
Operations
Relationships
UML
Extensions
Function for open and show text-based document.
Any failure will return -1; otherwise, return 1.
Accept by the interface object. Children Class of DocumentView.
<<variant>>
33
Element Name
User
Description
Class that holds the information regarding
a user. It also controls the amount of
shared permissions users.
Attributes
fullname:String
age:int
gender:String
userID:String
records:vector<Record>
The user’s fullname
The user’s age
The user’s gender
The user’s ID
Contains a vector of records associated
with the user.
Operations
getRecordList(String userID):
vector<Record>
Relationships
UML
Extensions
Function to request some data from the
web server. The function will return the
Records objects associated with the user
getDrugList(String userID) :
Function to request all drugs precribed to
vector<Drug>
a user.
getDocumentList(String userID) :
Function to request all documents
vector<Document>
associated with any of a users records.
getImageList(String userID) :
Function to request all images associated
vector<Image>
with a user.
setSharedPermissions (String user, Function that will set another shared
String ID): void
permission user.
deleteSharedPermissions (String
Function that will delete a shared
user, String ID) : void
permission user.
createRecord(String title, String
Function that will create a blank patient
summary, String Category)
record for the user to fill in.
getProfile(String user) : User
Fuction to call PMRSystem and return
information about a sigle user.
Each user has several records which mean there is an association between the
user and records. However, user does not own the records. User also has an
association with PMRSystem due to it is the log-in page for every user.
Communication constraint with the server might occur as a result of user does
not have direct connection with server. Hence, uploading or searching data
might have longer delay.
34
Element Name
View
Description
Pure virtual class (Protocol). Help the interface accept the unify
type View to display different objects like record, image, drug,
documents, etc.
Attributes
NONE
Operations
Relationships
UML
Extensions
View () : Virtual constructor
void
show () : Virtual function for displaying different object
int
Accept by the interface object. Parent of all view objects.
<<interface>>
<<variationPoint>>
4.3 Sequence Diagrams
The following diagrams are classified as “sequence diagrams”. The purpose of these
diagrams is to show how the different objects of a system interact with each other during a
specific instance of an execution. The objects are located along the top horizontal axis, and time
is depicted along the vertical axis. Time zero is located at the top of the vertical axis, and the
time increments positively downward.
The objects are defined by their object name followed by a “:” and the class name. The
defining of the object is done in rectangular boxes that are located above the timeline of the
object. The object name can be left blank, but the box must contain the class name. The
timeline of the object represents when the object is created in reference to the other objects
associated in the particular sequence diagram. The start of the object is shown by the top of the
vertical rectangle box, and the conclusion of the objects lifetime is associated with the bottom of
the rectangle box.
The creation of an object is due to a function call from another object. These function
calls are shown above the solid arrows which go from the object that is calling the function
(caller object) to the object that data or an action is being requested from (called object). Solid
arrows come in two types, synchronous, and asynchronous. Asynchronous arrows have both the
top and bottom part of the arrowhead and show that the called object must complete the
execution of the function in order for the caller object to continue. Synchronous calls are shown
by an arrowhead that is missing the bottom half of the arrowhead. The synchronous calls show
35
that both the caller object and called object can execute in parallel and both objects are not
waiting for any return values from the other in order to continue execution. The dashed arrows
represent return values from a called object and often state a piece of data on top of the dashed
arrow to show the actual data or variable returned to the called object.
4.3.1 Adding a Note
This sequence diagram (Figure 4.3) shows the execution of the user first logging in and
syncing the information to make sure the data is consistent between the server and the phone
application. Next, a particular record is requested from a user's list of records. When the record
is successfully obtained, the user is able to use the system and add a note to be associated with
that particular record. After the user is finished, they upload the new information to the server
and log out of the system.
Figure 4.3: Sequence Diagram showing the execution steps to view and add a note to a
record.
36
4.3.2 Creating a Record
In this sequence diagram, Figure 4.4, the user begins by logging in and syncing the data
between the server and the phone application. Then, the user uses the system to instantiate a new
empty record which is added to the user's list of records. When the record is successfully
created, the user is able to add an image and a document to be associated with that particular
record. After the user is finished, they upload the new information to the server and log out of
the system.
Figure 4.4: Sequence Diagram showing the execution steps to create a new record and
add an image and document
37
4.3.3 Setting Permissions
The following sequence diagram, Figure 4.5, displays the steps to edit user information
and set permissions for additional users. First, the user must log in and begins by syncing with
the server to make sure the information obtained is the most recent. Next, the user uses the
system to edit the information associated with the User class such as contact information,
emergency contacts, primary physicians, etc. Then, the user updates a permission (read, edit) for
an additional specified user by setting the shared permissions for that person. When finished, the
user uploads the new information to the server and logs out of the system.
Figure 4.5: Sequence Diagram showing the execution steps to edit user information and
set permissions
38
4.4 State Diagram
State diagrams show which state a single object can be in at any point of the program’s
execution. Whereas the sequence diagram showed multiple objects for a single execution, a state
diagram shows a single object over multiple executions.
The state diagram has a specific notation. The object being described is encompassed by
a large rectangle with the name of the object in the upper left hand corner of the rectangle. The
objects in the circle are called the “states” and an object must be in a state at any point of the
programs execution. The states are connected via arrows which represent functions or guards on
a state. The functions are functions as defined in the class diagram above for the specified
object. The guards are conditions that must be met in order for the object to transition to another
state. Guards are enclosed by “<<” and “>>” and functions just give the name of the function
along with any values needed where the values are in between “(“and “)”.
4.4.1: User
The following state diagram is used for the class object of user. User objects store what
records the user of the system is associated with. These records associated with a certain user are
referred to as profiles. Users can have the ability to access multiple profiles. This is done
through the first user associated with the profile setting up another user’s permission to view the
profile. A user can only view one profile at a time as to eliminate cross-profile confusion.
Figure 4.6: State diagram for the User object.
39
4.4.2: Interface
The following state diagram is for the interface class object. The interface object is the
controller for the actual screen of the application. The states of the interface object are therefore
the set of screens that the application could be in at any time. The functions and guards
connecting the states are the functions required to execute in order to change screens.
Figure 4.7: State diagram for the Interface object.
40
4.4.3: Server
The following state diagram is for the server class object. The server object is in charge
of sending and receiving data from the server. The states associated with the server are basic
states associated with a server. The functions and guards in this diagram are the functions
needed to retrieve and send data to the server, and the server guards needed for connection to
occur.
Figure 4.8: State diagram for the Server object.
41
4.4.4: Record
The following state diagram is for the record class object. The record class is a
combination of all data associated with an individual medical or personal entry into the profile.
The states of the record class are the states associated with each individual record. The functions
and guards are those required to accomplish tasks such as view or updating a record.
Figure 4.9: State diagram for the Record object.
42
5 Prototype
Next to each statement below is a letter denoted whether the statement is true for all
platforms, or is a variation that is true for either the iPhone or Android platform only. A ‘C’
represents a common statement, whereas a ‘V’ represents a variant statement.
C: The prototype will allow a user access to the medical records currently associated with
that user as determined by the server. The user will be able to view, create and add notes
to medical records.
C: The user can keep a current profile which includes relevant health information and this
profile can be edited at any time and does not need to interact with the server at all.
C: The user can back up all of the medical records and personal information onto an
external storage device via a backup button.
5.1 How to Run Prototype
C: The prototype can be run from any internet accessing computer or device.
V: For the iPhone Prototype: http://www.cse.msu.edu/~cse435/Projects/F2010/PMRiPhone/web/prototype.html
V: For the Android Prototype: http://www.cse.msu.edu/~cse435/Projects/F2010/PMRAndroid/Prototype/index.html
V: The iPhone Prototype (shown below) is a web-based text and picture mock-up of the
intended application.
V: The Android Prototype (shown below) is an application-based interactive model. The
user of the prototype can navigate through the design to determine the flow of one screen
to the next.
43
5.2 Sample Scenarios (Android Prototype)
5.2.1: Login
The login screen (Figure 5.1) is the first thing a user will see upon opening the
application. No data will be presented until they successfully log in.
Figure 5.1: Prototype screenshot for the Login screen.
44
5.2.2: Main Menu
The main menu (Figure 5.2) lists each type of record that the application keeps track of.
Additionally there is a button to back-up the data onto another device such as a laptop.
Figure 5.2: Prototype screenshot for the Main Menu screen.
45
5.2.3: Records List
The official records page (Figure 5.3) lists only records which were input by medical
professionals. These are not able to be edited by the user, or anyone else once entered. The
“Sync Records” button at the bottom of the page will communicate with the server to download
new records. The application synchronizes with the server automatically every month, but the
user can use this button to update information immediately. Additionally, every screen will have
the “Home” button at the bottom for easy navigation back to the home screen of the application.
Figure 5.3: Prototype screenshot for the Official Records List screen.
46
5.2.4: Single Record
This screen, Figure 5.4, is displayed when an individual record button is clicked. It
shows the details of that record including the date of the event, the practitioner involved, the
rationale for any actions the doctor took, and more.
Figure 5.4: Prototype screenshot for the Single Records screen.
47
5.2.5: Patient Records List
Patient records (Figure 5.5) are displayed separately from official medical records. All
patient entered information is shown in blue to easily distinguish it to the user. The user is
allowed to enter and delete his/her own records in this category as well.
Figure 5.5: Prototype screenshot for the Patient Records List screen.
48
5.2.6: Single Patient Record
This screen, Figure 5.6, shows an example of a patient record. The patient can describe
what symptoms they are having, and the context of the event. Additionally they can attach an
image to the record if applicable.
Figure 5.6: Prototype screenshot for the Single Patient Records screen.
49
5.2.7: Practitioners List
The practitioners list (Figure 5.7) displays both official practitioners gleaned from the
official records, and patient entered practitioners. Once again they are differentiated by color.
Figure 5.7: Prototype screenshot for the Practitioners screen.
50
5.2.8: Single Practitioner
All known contact information for a practitioner is available by selecting a practitioner
from the list (see Figure 5.8).
Figure 5.8: Prototype screenshot for the Single Practitioners screen.
.
51
5.2.9: Prescriptions List
The prescriptions page, Figure 5.9, shows all prescriptions that the patient is currently
taking. Medications can be entered by a practitioner, or by the user.
Figure 5.9: Prototype screenshot for the Prescriptions List screen.
52
5.2.10: Single Prescription
The details of a medication (see Figure 5.10) show all relevant information about the
medicine. This allows the user to make more informed decisions when taking new medications,
and helps them to remember which medications are supposed to be taken and when.
Figure 5.10: Prototype screenshot for the Single Prescription screen.
53
5.2.11: Images List
Images which have been used in medical records or added by the user for general use are
listed on the images page (Figure 5.11).
Figure 5.11: Prototype screenshot for the Images List screen.
54
5.2.12: Single Image
Images can be previewed individually, as in Figure 5.12.
Figure 5.12: Prototype screenshot for the Single Images screen.
55
5.3 Sample Scenarios (iPhone Prototype)
5.3.1: Login
The user must log in to the system (see Figure 5.13) before viewing their personal
medical record.
Figure 5.13: Login screen for the iPhone prototype.
56
5.3.2 Login Failure
A user who is not authorized will not be allowed to access the system, as shown in Figure
5.14.
Figure 5.14: Login failure for the iPhone prototype.
57
5.3.3 Main Menu
Figures 5.15, 5.16, and 5.17 display the main menu. The main menu of the personal
medical record shows all possible menu options - the user's health record, medical history, drug
list, calendar function (apportioned since making this prototype), backup, and permissions.
Figure 5.15: First page of the main menu for the iPhone prototype.
58
Figure 5.16: Second page of the main menu for the iPhone prototype.
59
Figure 5.17: Third page of the main menu for the iPhone prototype
60
5.3.4 User Record
The user record menu, Figure 5.18, includes the most recent information about the user's
health status, medical conditions, age, contact information, and so forth as a quick reference
page. It also links to the drug list menu.
Figure 5.18: User record for the iPhone prototype.
61
5.3.5 Medical History
Figures 5.19 and 5.20 show the medical history menu. The medical history menu
maintains a list of medical events the user has experienced, most recent first. The medical
history menu also includes for each event any and all details known, and delineates patiententered information from physician-entered information.
Figure 5.19: First page of the medical history menu for the iPhone prototype.
62
Figure 5.20: Second page of the medical history menu for the iPhone prototype.
63
5.3.6 Drug List
The drug list menu, Figure 5.21, shows the details of all the medications the user is
currently taking, including their dosage, frequency, duration, and purpose. Where possible, it will
also include the doctor who prescribed the medication and the pharmacy which filled it out, as
well as a picture of the medication.
Figure 5.21: Drug List menu for the iPhone prototype.
64
5.3.7 Backup Menu
Figure 5.22 shows the Backup menu. The backup menu allows the user to back-up the
current information on their iPhone to the server, or restore the information from a previous
backup on the server.
Figure 5.22: Backup menu for iPhone prototype.
65
5.3.8 User Permissions
The user permissions menu (Figure 5.23) maintains a list of current people the user has
authorized to view their personal medical record.
Figure 5.23: Permissions menu for iPhone prototype.
66
5.3.9 Add New Person
Figure 5.24 shows the Add New Person page. Adding a new person requires that the user
specify they have signed a HIPAA agreement for that person, though the personal medical record
does not maintain an electronic copy of any HIPAA agreements.
Figure 5.24: Add New Person for iPhone prototype.
67
6 References
[1]
Dr. Raza Haque, “ARMOR: A Tool to Evaluate Polypharmacy in Elderly Persons,”
Annals of Long-Term Care, June 2009.
[2]
Android SDK, http://developer.android.com/reference/packages.html, Google, November
2010.
[3]
iOS SDK, http://developer.apple.com/library/ios/navigation/, Apple Inc., 2010.
[4]
UML, http://www.uml.org/, Object Management Group, Inc., 2010.
[5]
Personal Medical Record - Android,
http://www.cse.msu.edu/~cse435/Projects/F2010/PMR-Droid/web/index.html, 2010.
7 Point of Contact
For further information regarding this document and project, please contact Prof. Betty
H.C. Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this
document have been sanitized for proprietary data. The students and the instructor gratefully
acknowledge the participation of our industrial collaborators.
68