Software Requirements Specification (SRS)
Data Collection – EMR
Authors:
Meghan McNeil, Rob Victoria, Vu Bui, Michael Cybulski
Customer:
Brian Berenbach, Siemens Corporate Research, Princeton, NJ
Instructor:
Dr. Betty Cheng
1 Introduction
This is the Software Requirements Specification for Cura (a Data Collection
Electronic Medical Record). This document contains a product overview of Cura, going
over the expectations, requirements, user capabilities, and system capabilities. This
document also includes a list of requirements, diagrams of the system, diagrams of the
user capabilities, and a prototype user manual.
1.1
Purpose
The purpose of this document is to demonstrate how Cura will be designed, the
hardware requirements, and software requirements so that it can be implemented to its
full ability. Also, this document provides an outline of different capabilities of each user.
Section two, three, and five are intended for the users. Section two, three, and four are
intended for developers.
1.2
Scope
The objective of Cura is to collect patient personal and medical information
digitally and store the data in one place. Medical personal can easily view patient medical
history on demand. Cura will have the capability for users to add patient information,
edit patient information, upload patient artifacts, and prescribe medication. Cura will not
recommend diagnosis, recommend treatment, nor distribute medical information.
1.3
Definitions, acronyms, and abbreviations
Advanced expertise – Being able to all actions of intermediate expertise. Also shall
know how to add medical staff as users to the system, install software updates, install
hardware updates, and manage the server that Cura runs on.
Artifacts – These include patient profile picture, test results, image of injury, scans, or
any other document that is important to medical history.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
EMR – Electronic Medical Record
HL-7 Standards – Standards for electronic data exchange
Intermediate expertise – Being able to turn computer on, type, use stylus, open a browser
and navigate to the Cura homepage.
Modern browers – Internet Explorer, Mozilla Firefox, and Safari.
1.4
2
3
4
5
6
7
Organization
Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
2.6 Approportioning of Requirements
Specific Requirements
Modeling Requirements
4.1 Class Diagrams
4.2 Use Case Diagrams
4.4 Scenarios
Prototype
5.2 How to Run Prototype
5.3 Sample Scenarios
References
Point of Contact
2
2
3
4
5
6
7
7
8
8
10
15
18
18
18
22
22
2 Overall Description
Cura is a product is a user-friendly system designed for collecting data in an EMR
system. This section includes the expectations of Cura, its functionalities, and
constraints.
2.1
Product Perspective
Cura is specifically designed for data entry of patient information into an EMR
system by hospital staff and patients in an emergency room. Because Cura is intended
solely for the purposes of data collection, this does not include the functionality of data
analysis or data distribution of the system. The role of Cura is shown in Figure 2.1
below.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 2.1 Data Flow Diagram for Cura
2.1.1 Hardware Constraints
Cura is intended to be installed and functional on a hospital tablet PC.
2.1.2 Software Constraints
Cura can be accessed by patients though a web application using a web browser
with Internet connection.
2.2
Product Functions
2.2.1 Entry of Basic Patient Data
The system shall allow for the patient to enter basic profile information. Basic
information includes name, address, birth date, insurance information, and emergency
contact information.
2.2.2 Wirelessly Collect Vitals
The system shall allow for patient vitals to be collected and stored in an online
database where they can be accessed. Vitals include respiratory rate, pulse, blood
pressure, IV drip, and brain waves.
2.2.3 Access Resources for Lab Results
The system shall allow for patient artifacts to be stored in the database and
retrieved upon request. Artifacts are organized accordingly to each hospital visit.
2.2.4 Store/Access Patient Medical Records
The system shall allow users to store and access patient medical information. If a
patient is already in the system, then previous medical records shall be obtained from the
database.
2.2.5 Record Medical Conditions
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
The system shall store medical conditions such as symptoms and observations
inputted by the user through textboxes.
2.2.6 Verify Medical Information
The system shall verify that the medical information inputted by the patient is the
same as the patient’s past medical information.
2.2.7 Prescribing Medication
The system shall provide a way for an attending physician to write prescriptions
for both inpatients and outpatients.
2.2.8 Allergies Information
The system shall store allergy information inputted by the user and verify that the
information is the same as the patient’s past allergy information.
2.2.9 Record of Patient Interface
The system shall keep a log for each of the patients’ visits and stays. The logs
shall automatically include the staff member’s name and identification (ID) number of
who saw the patient, time of the visit or stay, date of the visit or stay, and medical
information from the visit or stay.
2.2.10 Record Preliminary Diagnosis
The system shall provide templates for the medical staff. These templates will
include text input boxes for recording information and diagnosis for the patient’s visit.
Each template will have a commentary area where the medical staff will input text to
specify any clarifications for the information and diagnosis, and record that staff
members name and ID number, time, and date of comment.
2.2.11 Information Traceability
The system shall provide traceable information by displaying histories of all tests
ordered, medications prescribed, treatment plans, and chain of command for medical
staff.
2.2.12 Risk Analysis
The system shall compare the patient’s information (medicine, allergies etc.) with
previous information to ensure data integrity. If certain fields do not match, then the
users will be notified and the information will not be submitted.
2.2.13 Web Application
The system shall allow for patients to view their personal profile information
through the Internet.
2.3
User Characteristics
The users of Cura are patients, attending physicians, nurses, technicians,
physician assistants, residents, receptionists, and administrators. All of these users have
certain expectations on their experiences with computer knowledge.
2.3.1 Patient
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
The hospital patient is expected to have little to no experience with computers or
using tablet PCs. The electronic forms filled out by the patient are similar to the physical
forms filled out in traditional hospitals. The patient is expected to know how to either
write using a tablet PC or know how to type on a keyboard.
2.3.2 Attending Physician
The attending physician will need intermediate expertise with computer usage.
The doctor will need to be well trained with Cura, especially with the tasks of data entry
and accessing/uploading forms and files, as well as submitting prescriptions to a selected
pharmacy.
2.3.3 Nurse
The nurse will need intermediate expertise with computer usage. The nurse will
need to be well trained with Cura, especially with the tasks of inputting patient
information into the system.
2.3.4 Technician
The technician will need to have the ability to upload artifacts to the system.
2.3.5 Physician Assistant
The physician assistant will need intermediate expertise with computer usage.
The nurse will need to be well trained with Cura, especially with the tasks of data entry
and collecting vitals from the patient.
2.3.6 Resident
The resident physician will need intermediate expertise with computer usage. The
doctor will need to be well trained with Cura, especially with the tasks of data entry and
accessing/uploading forms and files, as well as submitting prescriptions to a selected
pharmacy.
2.3.7 Receptionist
The receptionist will need intermediate expertise with computer usage. The
receptionist will need to be well trained with Cura, especially with the tasks of searching
and verifying patient information, as well as adding new patients to the database. They
should also be familiar with entering patient information so they can assist patients where
needed.
2.3.8 Administrator
The administrator will need expert level knowledge with computer usage. The
administrator will need to be well trained with Cura, especially with the tasks of
assigning roles and permissions to staff.
2.4
Constraints
2.4.1 Patient Verification
Each time a patient checks into the hospital, a staff member must verify that the
staff member pulled up the correct medical information. If the wrong information is
given to the patient, then there can be safety-critical consequences, such as prescribing a
medication to a patient that is allergic to it.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
2.4.2 User Verification
If the user is logged in under a different name (i.e. nurse trying to enter in patient
data and is logged in as a receptionist), then the user will not be able to access all of the
pages to enter in the information that they need to.
2.5
Assumptions and Dependencies
2.5.1 Hardware Assumptions
In order to have full functionality of the system, the Cura software must be
installed on a tablet and desktop PC. However, a user can view profile information
outside the hospital by accessing the web application through the Internet.
2.5.2 Software Assumptions
Cura is intended to be viewed and interfaced using a web browser.
2.5.3 User Interactions
2.5.3.1
Administrator Interaction
The administrator will interact with Cura by defining and setting roles and
permissions for users of the system.
2.5.3.2
Receptionist Interaction
The receptionist will interact with Cura, primarily with the functionality of
searching for patients and verifying their information. Also, the receptionist will
need to add new patients to the database and take the patient’s profile picture
appropriately. They should be able to view the wait room queue as well as triage
the patient accordingly.
2.5.3.3
Patient Interaction
The patient will interact with Cura by filling out forms indicating their
personal profile, insurance information, previous medication, emergency contact
information, and allergy histories.
2.5.3.4
Nurse Interaction
The nurse will interact with Cura by viewing a list of checked-in patients
and confirming patient information. The nurse should also be able to enter in
visit-specific information such as height, weight, blood pressure, etc.
2.5.3.5
Attending Physician Interaction
The attending physician will interact with Cura by confirming patient
information, filling out forms for patient diagnosis, accessing lab results, and
writing prescriptions.
2.5.3.6
Technician Interaction
The technician will interact with Cura to upload artifacts to the system.
2.5.3.7
Resident Interaction
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Residents will interact with Cura by filling out forms for patient diagnosis,
accessing lab results, and writing prescriptions.
2.5.3.8
Physician Assistant Interaction
The physician assistant will interact with Cura by being able to enter visitspecific information such as height, weight, blood pressure, etc.
2.6
Approportioning of Requirements
2.6.1 Biometric Security
Based on discussions with the customer, it was determined that adding biometric
security to determine patients and staff would be beyond the scope of the current project.
However, as technology advances, a retina scan, fingerprint reader, and other technology
may be considered as a requirement in the future.
2.6.2 Voice-to-Text Capabilities
Based on the requirements given by the customer, Cura should be able to
recognize speech from the user, write out what they are saying, and insert them into text
box. However, we can not implement this in the time frame that we have, so this may be
considered as a future requirement
2.6.3 RFID Support
Based on interactions with the customer, the ability to see the location of patients
on a digital map may be a future requirement for this system. Radio-frequency
identification can be used for monitoring patients within hospital walls. RFIDs can be
used to confirm and identify patients and determine their location.
3 Specific Requirements
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.1.9
3.1.10
3.1.11
3.1.12
3.1.13
3.1.14
3.1.15
3.1.16
3.1.17
Cura shall run locally on a tablet PC based
Patient data shall be batched and sent to the database on submit
If there is no connection to the database, changes shall be saved locally
Changes should be submitted as soon as connection is remade
Data storage shall comply with HL-7 standards
Cura shall have a Web page for patients
Patients shall be able to log in with their email address and password
Patients shall be able to view their medical records
Patients shall be able to edit their personal information
Personal information includes address, contact information, emergency contact
information, and insurance information.
Medical staff shall verify these changes next time the patient is at the hospital
Medical staff shall have to log in to use Cura with username and password that
the administrator assigned to them
Medical staff shall be able to add new patient medical data
Medical data includes symptoms described by patient, symptoms observed by
medical staff, and diagnosis
Medical staff shall be able to upload artifacts of medical conditions
Medical staff shall be able to view patient medical record
Medical staff shall be able to upload artifacts to patient medical record
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
3.1.18 Cura shall provide risk analysis to ensure data input, accessed, and generated
3.1.19 Two people shall not be able to edit the same patient medical data at the same
time
3.1.20 Patient data shall be locked while changes are being made
3.1.21 Patient data shall be unlocked when changes have been submitted
3.1.22 Administrator shall be able to release locks from patient data
3.1.23 Cura shall store all medical staff who entered medical data for a patient
4 Modeling Requirements
4.1
Class Diagrams
4.1.1 Static structures class diagram
The class diagram in Figure 4.1 shows the static structures that make up Cura. A
brief description of the classes is provided followed by an illustrated class diagram. The
class diagram uses polymorphism to extract commonalities between system entities. For
example, patient and staff are generalized into a Person class which shares the common
attributes “Name” and “SSN” (Social Security Number). The Patient entity contains
information about the patient that is currently on file and can be updated by the Patient
and verified/updated by the Staff member. Patient is a base class for Adult or Child
because of different required information for minors in the system. Patients and Staff can
be associated with the DoctorVisit class which contains information specific to the
current visit. Staff members are assigned to specific DoctorVisits to track who treats a
particular Patient. A Medication entity represents medication information entered by the
patient from previous visits to other doctors as well as medication information assigned
as a result of medication prescribed during the DoctorVisit. The Insurance entity
represents all insurance related data used for billing. The Artifact entity is any document,
picture, X-Ray, audio recording, video recording that can be associated with a Patient or
DoctorVisit. An example of an Artifact associated with a Patient would be a profile
photo. An example of an Artifact associated with a DoctorVisit would be an X-Ray taken
during a visit. The Account entity holds all information related to a person’s account
information for logging in. These attributes include UserName, Password, Email, Role,
Permissions, etc. The Queue entity holds a list of Patients to keep track of the order at
which they arrive.
4.1.2 User Interface Class Diagram
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Account
Queue
-UserName : string
-Email : string
-Password : string
-Role : string
-SecretQuestion : string
-SecretAnswer : string
-Permissions : int
+setUserName()
+getUserName() : string
+setEmail()
+getEmail() : string
+setPassword()
+getPassword() : string
+getRole() : string
+setRole()
+setQuestion()
+setAnswer()
+getQuestion() : string
+setAnswer() : string
+setPermissions() : int
+getPermissions() : int
+addPatient()
+removePatient()
1
Person
0..*
-Name : string
+getName() : string
+setName()
Patient
1
1
-PatientID : string
-InsuranceID : string
-Age : uint
-Weight : uint
-Sex : string
-Height : string
-Allergy : string
-Address : string
-Phone : string
-SSN : string
+getInsurance() : Insurance
+getAge()
+getWeight()
+getSex()
+getHeight()
+getAllergy()
+setAge()
+setWeight()
+setSex()
+setHeight()
+setAllergy()
+setAddress()
+setPhone()
+getAddress()
+getPhone()
+getSSN()
+setSSN()
1
1
Staff
-EmployeeID : string
0..*
1
0..*
Previous
Medications
PerformedTreament
0..*
0..*
Adult
Child
-DriversLicense : string
-Guardian : Person
+getDriversLicense()
+setDriversLicense()
+getGuardian()
+setGuardian()
DoctorVisit
1..*
-Date : string
-Time : string
-BloodPressure : int
-Height : string
-Weight : uint
-DiscrepDesc : string
-DiscrepCrit : string
+getDate()
+getTime()
+getBloodPressure()
+getVisitHeight()
+getVisitWeight()
+setBloodPressure()
+setVisitHeight()
+setViistWeight()
+setDiscrepDesc()
+setDiscrepCrit()
1
HasGuardian
Medication
Medication Prescribed
During Visit
1
0..*
-MedID : int
-Name : string
-Type : string
-Dosage : string
+getName()
+getType()
+getDosage()
+setDosage()
+setName()
+setDosage()
0..*
1
1
Insurance
Artifact
VisitHasArtifact
0..*
-DocID : int
-Type : string
-FileLocation : string
+getFileLocation()
+setFileLocation()
-InsuranceID : string
-CoverageProvider : string
-PlanID : string
+getCoverageProvider()
+setCoverageProvider()
+getPlanID()
+setPlanID()
0..1
Figure 4.1 Static Structure Class Diagram
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Scanner Triggers ScanManager to Validate Card
Scanned Card Information
SessionManager
AutoCompleteManager
ScanManager
+validateLicense()
+validateInsurance()
+login()
+logout()
+changeview()
+SearchPatients()
+SelectPatients()
+CreateAccount()
+SearchStaff()
+SelectStaff()
+focusInputBox()
+findLikeOptions()
+insertSelected()
PatientManager
TextBox
+AddDoctorVisit()
+AddArtifact()
+ViewPatientInfo()
+SearchPatientInfo()
+EditPatientInfo()
+VerifyToSave()
+StoreData()
Button
Window
Figure 4.2 User Interface Class Diagram
4.2
State Diagram
4.2.1 Session Manager State Diagram
Users need to log in to use Cura. Users have the option to search for patients, add
an account, search for staff, or release patient locks depending on the permissions the
user has. The State Diagram for adding accounts, viewing patient data, editing patient
data, and adding patient data is shown in Figure 4.3. All of the actions of the user are
handled by the SessionManager. When a patient is selected, then the PatientManager
handles the actions for editing and viewing that specific patients data. Everytime that
patient data is being edited, a lock will be applied to the patient. This ensures that two
people can not edit the same patient concurrently. The administrator has the ability to
view current locks and release locks.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 4.3 Cura State Diagram
4.2.2 Edit Patient Information State Diagram
4.3
Use Case Diagrams
The use case diagram section explains the system functionality graphically. Each use case
diagram explains what action a particular role can perform. The five roles represented in
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
the system are: Nurse, Receptionist, Doctor, Administrator and Patient. The use case
diagrams are shown below.
NOTE: These use case diagrams illustrate default role permissions. These permissions
can be changed by the administrator on a role or per person basis.
4.2.1 Patient
A patient only has the ability to modify his/her own data. The patient may create
their own account online and log on. Once logged on, the patient can view/update their
profile information. The patient may also view hospital contact information and view
information related to a previous visit. For instance a patient may want to check the
prescriptions they received during a particular visit. The patient use case diagram is
shown below in Figure 4.4.
EMR Home
Access
Data Collection
Pages
View Instructions
<inclu
Log On
<include>
Enter Contact
Information
Enter Insurance
Information
Enter Physicians
Information
Enter Allergies
Enter Medical
Conditions
Enter
Medications and
Pharmacies
Enter
Immunization
Record
Enter Medical
Equipments
Enter Family
History
de>
View/Update
Information
Patient
Enter Personal
Information
View Contacts
Update Account
Information
Create Account
View Visit
Information
<include>
<in
c
lud
View
Medications
e>
Sign Permission
Form
Figure 4.4 Patient Use Case Diagram
4.2.2 Receptionist
A receptionist is primarily responsible for checking patient in and out of the
emergency room. The receptionist’s check in is a two step process. First, a receptionist
verifies a patient’s identity by swiping a driver’s license or insurance card. Second, the
receptionist allows the patient to check over their information and make changes. If
applicable, the receptionist then views information discrepancies. The patient use case
diagram is shown below. The receptionist can also view patient information and check a
patient out. During the check in/out process permission forms may need to be signed by
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
patient or guardian. The receptionist is able to administer permission forms. Below a
receptionist use case diagram in Figure 4.5 illustrates the receptionist’s available actions
in the system.
EMR Hospital
Access
<
c
<in
>
de
e>
lud
e>
View Patient
Information Entry
Discrepancies
lud
<in
c
>
< in
<in
c
Scan Driver’s
License
de
Search
Patients
>
de
Scan Insurance
Card
d>
View
Patient
Information
Log On
Receptionist
ten
cl u
View Patient
Queue
cl u
<e
x
e>
< in
n
<i
Check In
Patient
lud
Verify Patient
Identity
lu
inc
cl u
de
n
<i
>
Check Out
Patient
cl u
>
de
<include>
Administer
Permission
Form
Process
Insurance
Figure 4.5 Receptionist Use Case Diagram
4.2.3 Nurse
The nurse has the same permissions as the receptionist with some added abilities
to enter visit specific information. The nurse is able to collect vitals such as blood
pressure, pulse, and respiratory rate. The nurse can attach an artifact (see definition
section for examples of artifacts) to a patients current visit record. The nurse is also able
to verify patient prescription information to avoid typos in dosage. The nurse use case
diagram is shown below in Figure 4.6.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
EMR Hospital
Access
lu
inc
n
<i
Check In
Patient
Nurse
Search
Patients
< in
cl u
View/Update
Patient
Information
nc
lu
de
nc
lu
>
View Patient
Information Entry
Discrepancies
>
<include>
<i
nd
de >
<i
Log On
xte
cl
<in
ude
<include>
<i n
cl u
>
de
Check Out
Patient
e>
<include>
Scan
Insurance
Card
Assign
Criticality
>
Enter Visit
Information
de
>
<
<inclu
d
Scan Driver’s
License
Attach Artifact
(X-ray, photo,
audio, video)
lu
<inc
View Patient
Queue
<e
>
de
>
de
de
>
n
<i
cl u
cl u
Verify Patient
Identity
de>
Enter Patient
Vitals
Administer
Permission
Form
<include>
<in
cl
Process
Insurance
ude
>
Verify
Prescriptions
Figure 4.6 Nurse Use Case Diagram
4.2.4 Doctor
The doctor has the same permissions as the nurse with added ability to write
prescriptions and to order surgery. The doctor use case diagram is shown below in Figure
4.7.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
EMR Hospital
Access
n
<i
Check In
Patient
Log On
cl u
nc
lu
<include>
cl
<in
ude
< in
cl u d
<in
c
de
>
<i
u
n cl
< in
Process
Payment/
Insurance
>
de
cl u
de
>
<include>
Enter Visit
Information
Check Out
Patient
Assign
Criticality
Order
Surgery
de >
<include>
Search
Patients
<i
d>
View/Update
Patient
Information
lud
< in
Doctor
<e
xte
n
Scan Driver’s
License
Scan Insurance
Card
View Patient
Information Entry
Discrepancies
<in
c
View Patient
Queue
Verify Patient
Identity
>
de
>
de
e>
<
lu
inc
cl u
de>
cl u
< in
<in
cl u d
e>
Write
Prescriptions
e>
lud
e>
Attach Artifact
Enter Patient
Vitals
>
Verify
Prescriptions
Figure 4.7 Doctor Use Case Diagram
4.2.5 Administrator
The administrator has the ability to grant/revoke permissions to do the various
operations for any role or person. For example, the administrator can revoke the write
prescriptions permission for all doctors. The administrator can also grant write
prescription permission to just one nurse. The use case diagram for the administrator is
shown in Figure 4.8.
EMR Hospital
Access
Admin Log
On
<include>
Add/Remove
Functionality
e>
cl u d
<in
< in
cl u
de>
Edit By Role
Edit By
Person
Administrator
Figure 4.8 Administrator Use Case Diagram
4.3 Scenarios
4.2.6 Scenario 1 – Create an Account and Enter Required Information
Patient navigates to patient information website from home computer or patient
reception tablet. The patient creates a new account be entering desired user account name
and password for account. The patient is automatically logged in to begin entering
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
information. The patient enters their name, birth date, driver’s license and social security
number into the input boxes of the user interface. This is shown in a sequence diagram in
Figure 4.9.
New Patient creates account
1) Patient creates an account
Patient <<actor>>
UI Element
Create Account
:Account
:Adult
Account( UserName, Password, Role)
Adult():
Account
Name
2) Patient enters Name
setName(Name):
3) Patient enters Birthdate
Birthdate
setAge(Birthdate):
4) Patient enters Driver’s License
Driver's License
setDriversLicense()
5) Patient enters Social Security
Number
Social Security Number
setSSN()
NOTE: Window, Button and TextBox are generalized into UI element for simplicity of this diagram
Figure 4.9 Scenario 1 Sequence Diagram
4.2.7 Scenario 2 – Check In to Health Clinic
The patient approaches the reception desk and the nurse asks for driver’s license
or insurance card. The patient presents a driver’s license and the nurse scans the ID. After
scanning, the nurse sees that the patient has already entered information into their system.
The nurse hands the patient a tablet pc and asks the patient to verify the information. The
patient clicks through the wizard and finds that the system does not show his allergy to
penicillin. The patient enters the additional allergy and returns the tablet back to the
nurse. The nurse notices that there has been a change in the information and assigns an
information discrepancy rating of “Medium”. This is shown in Figure 4.10.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Existing Patient Checks In
Nurse <actor>
Scanner <actor>
UI Element
:ScanManager
:SessionManager
:Adult
Swipes Driver's License
validateLicense()
1) Nurse Validates Drivers License
Validated
UserName, Password
login(UserName, Password):
2) Patient Logs In
Validated
Patient <actor>
Allergy
3) Patient adds allergy
setAllergy(Allergy):
Incorrect Allergy:
4) Nurse Sets Discrepancy
Description and Criticality
setDiscrepDesc()
Medium:
setDiscrepCrit()
NOTE: Window, Button and TextBox are generalized into UI element for simplicity of this diagram
Figure 4.10 Sequence Diagram for Scenario 2
4.2.8 Scenario 3 – Administrator Removes Driver’s License Scan Functionality for
Nurse
An administrator logs into the system. The administrator notices that a particular
nurse should not have prescription writing permission. The administrator searches for the
system for that nurse. Once found, the administrator changes the permissions. This is
shown in figure 4.11.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
:DoctorVisit
Admin Changes Permission for Nurse
Admin <actor>
:SessionManager
UI Element
Nurse:Account
UserName, Password
login(UserName, Password):
1) Admin Logs In
Validated
Nurse:
SearchStaff(Nurse):
2) Admin searches for nurse
Nurse
Check Permissions:
3) Admin View Permissions
getPermissions():
Nurse Permissions
Change Permissions:
4) Admin Changes Permissions
setPermissions(newPermissions):
NOTE: Window, Button and TextBox are generalized into UI element for simplicity of this diagram
Figure 4.11 Sequence Diagram for Scenario 3
5
Prototype
Our prototype will demonstrate user interfaces that are used by patients, receptionists,
nurses, and doctors to conveniently and accurately access patient information and
medical data. It will also demonstrate the ability to add, modify and verify the patient’s
information.
5.2
How to Run Prototype
The prototype can be accessed using modern web browsers at www.cse.msu.edu/~buivu/.
The following are the specific system requirements:
 CPU: 233 MHz processor or higher
 Memory: 64 MB or higher
 Display: Super VGA (800x600) or higher
 Peripherals: Internet connection
5.3
Sample Scenarios
A patient named Michael John Cybulski visited his doctor first time at a healthcare
facility where a new EMR program just got implemented. He was handed a tablet which
displayed a webpage that he could use to fill out his information (Figure 5.1).
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 5.1: Patient's information and health record
Firstly he had to fill out his personal information which includes name, birthdate,
social security number, drivers license number and other personal information using
textboxes and drop-down list boxes (Figure 5.2)
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 5.2: Patient's personal information
Then he moved on to fill out his contact information as well as an emergency contact.
(Figure 5.3)
Figure 5.3: Patient's contact information
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
He then moved on to fill out the rest of the information including his insurance
information and gave the tablet back to the receptionist along with his driver license and
insurance card so the patient information could be verified.
After checking the patient's information, the receptionist proceeded to let the patient see a
nurse who then logged into the EMR program that had been populated with the patient's
information. The nurse then measured and filled out patient's vital signs before started to
ask the patient about Nature of Present Illness (NPI) (Figure 5.4)
Figure 5.4: Nature of Present Illness interface (support scanned documents and voice
recording)
The nurse then saved the information entered, logged out, and let the patient see the
doctor. The doctor logged into the same EMR program. He clicked on the "Profile"
button to double check the patient's current medication and other medical related
information. He then clicked on "NPI" to read what the nurse has entered earlier, then
clicked on the "Diagnosis" button to enter his diagnosis. He also could enter prescriptions
and/or procedures information through clicking on the menu options.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)
Figure 5.5: Diagnosis interface (support scanned documents and voice recording)
The doctor could also enter prescriptions and/or procedures information through clicking
on the menu options.
6
References
[1]
D. Thakore and S. Biswas, “Routing with Persistent Link Modeling in Intermittently
Connected Wireless Networks,” Proceedings of IEEE Military Communication, Atlantic
City, October 2005.
[2]
Brian Berenbach
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.
Template based on IEEE Std 830-1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.edu)