Embed Size (px)
Citation preview
INFO 620: Information Systems Analysis and
Design Term Project Proposal Navarro Chamberlain, Jeffrey kellam and Saji Verghese
Navarro
ABSTRACT
Project Category: Analysis & Design
2
Table of Contents
1. Title: .................................................................................................................................. 2
2. The Problem Statement……………………………………..……………………………………………………………..2
3. Requirements .................................................................................................................... 3
4. Examples of system input/output, etc. ............................................................................... 6
5. Knowledge Acquisition ...................................................................................................... 7
6. Software and/or hardware involved .................................................................................. 7
7. Proposed Deliverables and work plans ............................................................................... 7
9. Use Case Diagram ......................................................................................................... 7
10. Use Case Descriptions ............................................................................................... 9
11. Class Diagram ........................................................................................................... 20
12. Actors and Goals ...................................................................................................... 21
1. Title: Analysis and Design of a Simplified Patient Care Clinic System (PCCS)
2. The Problem Statement
A small, local clinic would like to digitize their accounting system as it relates to their
patients. The have requested that we help them to begin phasing in their patients into
the new system immediately. To this end, we have begun gathering requirements and
developing use cases to conceptualize how this would come about. The solution will
need to address several different aspects of the system, as well as be versatile enough
that it can be used in the environment long term without having to have heavy redesign.
It needs to be able to handle the creation, modification, and deletion of records as well
as the resolution and pay out of accounts concerning both the patients directly and a
third party. It must be able to handle scheduling and invoicing duties as well.
The problem is limited to the Accounting system concerning the patients and
should not take into account interoperability with or dependency on any other system
with in the clinic. We will be assuming an infinite amount of time and funding until
3
otherwise noted, however have been given the guidance to err on the side of the most
cost efficient plan of action. The client will be provided with a white paper detailing the
actions taken to satisfy this request as well as all findings requested.
(a) Overall Goals of the System
The overall goals of the system are to keep track of patients, their appointments,
medical history, diagnosis, procedures, insurance information, and payment
transactions.
(b) Context and Importance of the System
It is important for the clinic to computerize their patient accounting system to track
information about their patient population. It is also important to keep these documents
in an electronic format to ensure quality control and better security of patients protected
health information. It also provides a better system to track and follow-up payment
transactions from patients and insurance companies.
(c) Scope of the Project
In-Scope:
(PCCS) will include patient information, invoices, payments, insurance information, and
appointments
(PCCS) can be used as a knowledge database for patient issues that both nurses and
doctors can refer to during patient visits.
E.G.
● Referral letters
● Previous visits
● Medications
● Diagnostic results
● Medical codes and descriptions
Out-of-Scope:
(PCCS) will not include office-related, inventory, or staffing activities.
3. Requirements 3.1 Functional Requirements (partial list)
The system will be password protected, utilize encrypted hard drives, and multi-
user logon. (PCCS) will perform the following functions:
4
(1) Add new patient
(1a) enter patient info
(1b) enter patient medical history
(1c) enter patient insurance information
(1d) assign account number
(2) Find patient (search by lastname, insurance number, or primary account
holder)
(3) Modify patient info
(3a) personal info
(3b) insurance info
(4) Find service (search by lastname, date, or insurance claim)
(5) Enter service
(5a) assign account number
(5b) select service
(5c) select payment method
(6) Modify service
(7) Enter appointment (patient info, doctor info, date, time)
(8) Modify appointment
(9) Generate schedule
(9a) individual doctors
(9b) all doctors
(10) Generate Invoices
(10a) individual patient
(10b) multi patient
(10c) patients overdue
(11) Generate Medical Records
(11a) individual patient
(11b) multi patient
(12) Generate Patient Inventory
(12a) individual doctor
(12b) all doctors
(13) Login
(14) Logout
(15) Delete patient
(16) Add/remove users
3.2 Data requirements (Partial List)
PCCS will keep track of patient’s account number, name, address, business
phone, home phone, cell phone, emergency contact, responsible party,
5
guarantor, and insurance information.
PCCS will keep track of patient’s medical history including medications, referral
letters, and diagnostic results.
PCCS will keep track of appointments, including time and date of service,
patient’s name, account number, doctor’s name, and type of visit.
PCCS will be used to record a snapshot of the patients’ current medical status
including:
●weight
●blood pressure
●temperature
●smoking status
●drinking status
For each visit, PCCS will keep track of account number, patient name, date of
service, description of service, diagnosis, procedures, copay, charges and
current balance.
For each patient/insurance payment, PCCS will keep track of transaction
number, payment date, description, amount, payment type, check number, and
bank name.
For invoices, PCCS will keep track of invoice number, invoice date, account
status, total billing amount, insurance paid amount, patient responsibility.
3.3 Business Rules and Logic (Partial List)
(1) All HIPAA Requirements should be observed and taken into consideration
(2) All SOX requirements should be taken into consideration and observed
(A) Special Consideration should be given to Audit, Configuration
Management and Procedures on tracking security
(3) Only required parties should have access to patient data
(A) Required partied must be defined based on business needs and
legal requirements
(4) Tracking of Login/Logout
(5) Development of policies concerning data retention
(6) Accounts in delinquency should be marked and forwarded to the proper
function as well as discerned from ongoing accounts
6
(7) Development of a unique identifier system that allows patients to be identified
and tracked individually
(8) Balances should always be kept up to date and all changes should be able to
be tracked and accounted for
(9) Invoices should be complete and detailed with information concerning all
charges and surcharges
3.4 Non-functional requirements
Security, privacy, integrity, redundancy, reliability requirements include the
following:
(1) Strong secure passwords (security)
(2) Stored data must be encrypted (security)
(3) Restrict external devices (security)
(4) Privacy training and certification required before access (privacy)
(5) automated backups (reliability)
(6) Non-users will not be able to view system (privacy)
(7) Operating system will be properly locked-down (security)
(8) Offsite storage of data (redundancy)
(9) Physical security (computers behind secured doors with security system in
use)
(10) Menu or tabbed design (usability)
3.5 Other Assumptions
(1) PCCS will be used by a small patient care clinic in a real-world setting.
(2) PCCS will run on a Windows based client/server environment.
(3) Back-end data will be stored in Microsoft Access
(4) Servers and client computers are maintained with latest security patches and
updates.
(5) Users have basic knowledge and skills in computer operations
4. Examples of system input/output, etc. Input:
● Patient calls to make an appointment
● Staff adds a new patient
● Staff updates insurance information
Output:
● System prints a daily list of appointments.
7
● System generates invoices for patients
● System calculates overdue accounts and generates letters to Patients.
5. Knowledge Acquisition Due to the nature of the project, Requirements must be defined and agreed upon by all
stakeholders. We will then reference available sources and dependencies to make sure
the project is compliant with all regulations. We will use all available resources to make
sure our results are as accurate and sound as possible
6. Software and/or hardware involved We will utilize Visio to provide our UML Diagrams. We will utilize Microsoft Access to
provide a Server-side database solution as well as a GUI Front-End
7. Proposed Deliverables and work plans Deliverables will include a working model of the PCCS System as well as a detailed
report concerning methodologies and what the processes behind the system. It will also
include a complete set of UML diagrams, supporting documentation and fully document
the Lessons Learned report including difficulties, outstanding questions, and future
expansion opportunities.
8. Known References (so far)
HIPAA
1. http://www.hhs.gov/ocr/privacy/
SOX
1. http://www.aicpa.org/InterestAreas/ForensicAndValuation/Resources/FraudPreve
ntionDetectionResponse/Pages/Summary%20of%20the%20Provisions%20of%2
0the%20Sarbanes-Oxley%20Act%20of%202002.aspx
2. http://www.sec.gov/news/studies/principlesbasedstand.htm
9. Use Case Diagram
(Needs to be updated based on prof's comments)
8
9
10. Use Case Descriptions
USE CASE #
1
USE CASE Name
Add New Patient
ACTOR
Receptionist/Data Entry Staff
Goal (1 phrase)
Create a new patient account
Overview and
scope
Subscriber enters personal and shipping data. After entering data the
subscriber will select a subscription length and proceed to pay for
subscription.
Level
Primary
Preconditions
Patient must have identification information, insurance information
and filled out patient information form.
Post conditions
in words
Receptionist created new account for patient based on patient
information provided on forms. Personal information data (name,
address, age, sex, phone number, and emergency contact) was
entered. Medical data (weight, height, past surgeries, medication, and
allergies) was entered. Insurance data (insurance number, primary
account name, and insurance company name) was entered. A new
Patient ID was created in the system and assigned to a primary
healthcare physician.
Trigger Receptionist selecting “add new patient” option within PCCS
Included Use Cases None
Extending Use Cases None
MAIN SUCCESSFUL Actor Action System Action
10
SCENARIO in numbered
sequence
1. Receptionist selects “Add
New Patient”
2. Opens new patient form page
3. Receptionist enters
personal information and the
selects “Create”
4. Receptionist enters medical history
for patient and then selects “Next”
5. Receptionist enters
Insurance information and
then selects “Finish”
OTHER SUCCESSFUL
SCENARIOS
EXTEND
Step Branching Action
4. No previous medical history
to enter or is not available.
Receptionist selects “Skip”.
5. Opens insurance information page.
UNSUCCESSFUL
SCENARIOS
Conditions Actions
Patient does not have
required personal information
such as name and address
Process is cancelled
11
Patient does not have all
insurance information.
Process is cancelled
Patient does not have
required ID
Process is cancelled
Priority in scheduling Primary
Frequency 10 or less a day
Business rules and data
logic
All or no insurance information is entered. Partial information is
useless.
New patient must of proof of identification before process can be
completed.
Doctor or nurse must approve the addition of a new patient before the
patient is entered into the system.
Rules for underage children must be applied…
Other non-functional
requirements
Superordinates None
Developer Jeffrey Kellam
Creation date and last
modified date
Other Comments none
12
USE CASE #
2
USE CASE Name
Generating Patient Medical Records
ACTOR
Receptionist, Care giver
Goal (1 phrase)
To create medical records
Overview and
scope
Medical records can be generated and printed to be sent to patient or
insurance companies.
Level
Primary
Preconditions
Patient must have identification and insurance information already within the system
Patient must have previous visit
There must be a need for record generation in order to comply with HIPAA
Postconditions
in words
Record regarding Patients Medical history is generated including physical history, medication history, injury history, chronic disease, prior major and minor procedure and any other pertinent information.
Trigger Caregiver, Receptionist or Administrator must select Medical Records
option from Patients profile within PCCS
Included Use Cases None
Extending Use Cases None
MAIN SUCCESSFUL
SCENARIO in numbered
sequence
Actor Action System Action
1. Caregiver, Receptionist or
Administrator must select
Medical Records option from
Patients profile
2. Opens patient medical records
authorization page
13
3. Requestor Gives Name,
Employee ID and reason for
request
4.Service generates patient full
medical history
5. Requestor selects print
record
6. System prints paper record of
transaction
7. Requestor selects Finish 8. System Closes patient record and
logs transaction
OTHER SUCCESSFUL
SCENARIOS
Step Branching Action
5. Requestor selects Finish 6. System Closes patient record and
logs transaction
UNSUCCESSFUL
SCENARIOS
Conditions Actions
Patient has no prior record in
system
Process is cancelled
Requestor does not have
proper credentials
Process is cancelled
Requestor is not Receptionist,
Caregiver, or Administrator
Process is cancelled
Priority in scheduling Primary
Frequency Daily
14
Business rules and data
logic
Other non-functional
requirements
N/A
Superordinates None
Developer Navarro Chamberlain
Creation date and last
modified date
Other Comments None
15
USE CASE #
3
USE CASE Name
Add Appointment
ACTOR
Receptionist
Goal (1 phrase)
To add an appointment for a patient
Overview and
scope
A patient wants to make an appointment to see a doctor
Level
Primary
Preconditions
Postconditions
in words
Appointment information was recorded. Appointment date and
doctor information was updated in the system.
Trigger Patient calls the receptionist to make an appointment
Included Use Cases Modify appointment
Extending Use Cases
MAIN SUCCESSFUL
SCENARIO in numbered
sequence
Actor Action System Action
1. Receptionist clicks button to
add an appointment
2. System shows a form to enter /
search patient by name, date of birth,
SSN, or account number
3. Receptionist fills the
appropriate fields and click to
find the correct patient
4. System displays the patient
16
5. Subscriber enters the
desired time, date and doctor
for the appointment
6. System updates the appointment
information in the patient record
OTHER SUCCESSFUL
SCENARIOS
EXTEND
Step Branching Action
1a. Receptionist clicks to
modify an appointment
INCLUDES Modify Appointment
3a. Receptionist enters wrong
information
System returns to the form for
reentry
UNSUCCESSFUL
SCENARIOS
Conditions Actions
Receptionist cannot find
patient
Cancel the activity
*a Cancel the activity
Priority in scheduling Primary
Frequency 20 a day
17
Business rules and data
logic
Doctors' schedule must be available to the receptionist
Other non-functional
requirements
Phones must be answered in a timely manner
Superordinates None
Developer Saji Varghese
Creation date and last
modified date
Created on: February 22, 2011
Modified on: February 22, 2011
Other Comments
18
USE CASE #
4
USE CASE Name
Modify Appointment
ACTOR
Goal (1 phrase)
To change or cancel appointment
Overview and
scope
Appointment information is updated or deleted upon patient's request
Level
Included
Preconditions
Patient must already have an appointment made in system
Postconditions
in words
The appointment was changed or deleted
Trigger Patient calls to modify appointment
Included Use Cases
Extending Use Cases
MAIN SUCCESSFUL
SCENARIO in numbered
sequence
Actor Action System Action
1. Receptionist clicks on a
button to modify appointment
2. System shows a form to enter /
search patient by name, date of birth,
SSN, or account number
3. Receptionist fills the
appropriate fields and click to
find the correct patient
4. System displays the patient
5. Receptionist selects the
patient
6. System displays appointments for
that patient
19
7. Receptionist selects the
appointment
8. System displays details of the
appointment
9. Receptionist makes
changes to the appointment
10. System displays confirmation on
the changes
OTHER SUCCESSFUL
SCENARIOS
Step Branching Action
3a. Receptionist enters wrong
information
System returns to the form for
reentry
7a. Unable to locate
appointment
System returns to home screen
where a new appointment can be
created
UNSUCCESSFUL
SCENARIOS
Conditions Actions
3a. Unable to find patient Abort the activity
*a Cancel the activity
Priority in scheduling Primary
Frequency 10 a day
Business rules and data
logic
Doctors' schedule must be available to the receptionist
Other non-functional
requirements
Phones must be answered in a timely manner
Superordinates None
Developer Saji Varghese
Creation date and last
modified date
Created on: February 25, 2011
20
Modified on: February 25, 2011
Other Comments
11. Class Diagram (Needs to be combined)
21
-PatientID-AppointmentDate -CavegiverName-ScheduledDate-userModified-Notes
Appointment
-PatientID-LastSeenOn-FirstVisit-Medications-ChronicDieseases-Conditions-InjuryHistory-CurrentTemperture-Lasttemperture-height-weight-BP-BMI-PrimaryCaregiver
Patient Medcal record
-PatientID-InvoiceID-TotalBilled-ProcedureCode-DueDate
Invoice
-PatientID-LastSeenOn-FirstVisit-PrimaryCaregiver-LastBill-LastPayment-AccountStatus
PatientBillingRecord
-PatientID-InvoiceID-PaymentMethod-PaymentDate-Paymentamount
Payment
-AmountTendered-ChangeDue
Cash
-CheckID-PatientID-BankID
Check-CCType-CCNumber-CVID-Experationdate-Amountpaid-Amountdue
CreditCard -PatientID-referralID-ReferralCaregiver-Justification-Notes
PatientReferral-patientID-prescriptionID-prescriptionDate-prescriptionDoctor-prescriptionNote-prescriptionRefills
Prescription
1
1
11
11
0
1
0
1
1
1
-StaffID-FirstName-LastName-Title
Staff
-StaffID-FirstName-LastName
Medical Professional
-StaffID-FirstName-LastName
Receptionist
12. Actors and Goals
Primary
Receptionist
o Receptionist will be responsible for producing the data to the patient and
initial processing of their information
Heath Care Provider
o Health Care Provider will be responsible for providing patient data to be
used in the process of generating invoices
Patient
o Will be responsible for the payment of the invoices as well as being the
recipient of service
22
Administrator
o Will be primary responsible for the modification of the patients records as
well as being the primary point of contact with the insurance company
Secondary
Insurance Company
o Is primarily responsible for paying the invoices as dictated by the
administrator and Health Care Provider
Credit Card Authorization System
o Responsible for processing payment made by credit card from the patient
