Software Design Description - Drexel University - Computer Science

Software Design Description

Authors (in alphabetical order):Gregory Bajgier

Somil ParikhDhruv SalhotraBernard Wolff

Min Yaung

May 27, 2008

Contents

1 Document Information 4

1.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Definitions, Acronyms, and Abbreviations . . . . . . . . . . . . . . . . . . . 4

2 Design Overview 6

2.1 Description of Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Technologies Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Architecture 7

3.1 Application Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Shared Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1.1 Document Class . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1.1.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1.1.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1.2 Person Class . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1.2.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1.3 User Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1.3.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1.4 Patient Class . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1.4.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1.4.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1.5 Physician Class . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1.5.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1.6 Template Class . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1.6.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 14

1

3.1.1.7 Department Class . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1.7.1 Properties . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.2 OpenOffice Extension Classes . . . . . . . . . . . . . . . . . . . . . . 14

3.1.2.1 OODriver Class . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2.1.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.3 Administrator Interface Classes . . . . . . . . . . . . . . . . . . . . . 15

3.1.3.1 AdminDriver Class . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.3.1.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Database Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Design Features 18

4.1 User Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 Document Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.3 Patient Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.4 Physician Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.5 Save Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.6 Open Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.7 Find Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.8 Lock Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.9 Unlock document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.10 Lost Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.11 Lost Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Administrator Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Administrator Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2 User Account Creation . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.3 User Account Modification . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.4 User Finder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.5 Manage Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2

4.2.6 Manage Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3

1 Document Information

1.1 Properties

Title Healthcare Document Management System Requirements DocumentAuthors Somil Parikh, Min Yaung, Dhruv Salhotra, Gregory Bajgier, Bernard WolffReviewers Jeff Salvage, Somil Parikh, Min Yaung, Dhruv Salhotra, Gregory Bajgier, Bernard Wolff

1.2 Purpose

This document specifies the entire software architecture and design for the HCDocs doc-ument management system. These design decisions directly relate to the functionalities,performances, constraints, attributes, and interfaces of the system. HCDocs is a documentmanagement system which electronically stores, organizes and manages healthcare docu-ments and provides fast, security-controlled access to these documents. HCDocs providesthe look and feel of a standard word processor with capabilities for storing documents inan encrypted non-local repository-style database. All documents stored in the system areassociated with the patient’s identity and related fields such as patient’s care provider iden-tity, facility, author, or referring physicians, which can be used as keywords for documentsearching, retrieving and recordkeeping. HCDocs is designed to comply with HIPAA (HealthInsurance Portability and Accountability Act) and focus on identity management to preventunauthorized use and fraud. Our goals with the HCDocs system are to develop a user-friendlyand cost effective document management system while providing simplicity, flexibility, secu-rity, accessibility and reliability to its users. For further detail, refer to the HCDocs SoftwareRequirements Specification.

1.3 Scope

This document describes the software architecture and design for the initial release of HC-Docs, version 1.0. The intended audience of this document exclusively includes the designers,the developers, and the testers of the HCDocs software system.

1.4 Definitions, Acronyms, and Abbreviations

BLOB: Binary Large Object. Binary data stored in the database. Examples includeimages, audio, video, or other binary data.

Database: A database refers to a collection of related pieces of information stored elec-tronically. A database provides a way for other computer programs to quickly retrieve and

4

update desired pieces of data.

Document Service: A document service is a ”backend” engine which controls documentcreation and distribution.

Document Template: A document template is a super-structure of an otherwise normalword processor template which contains data regarding its distribution (who it was originallygiven to) and other document identifiers, including patient data and relevant physician data.

HCDocs: Title and project name referring to Healthcare Document Management System.

HIPAA: Acronym that stands for the Health Insurance Portability and AccountabilityAct, a US law designed to provide privacy standards to protect patients’ medical recordsand other health information provided to health plans, doctors, hospitals and other healthcare providers.

Network: A computer network is the interconnection of multiple computers using atelecommunications system, which allows for the communication and sharing of resources.

Privilege: The HCDocs system limits user accounts from performing certain actions oncertain documents; whether a user account can or cannot perform these actions is called theuser’s privileges. The defined privileges are: create, edit, delete and view; each action theuser can take upon the system must be classified as one of these categories. User privilegesare specific to different parts of the software system.

Patient: A patient is a person who receives medical attention, care, or treatment.

Repository: A repository is a collection of resources that can be accessed to retrieveinformation. Repositories often consist of several databases tied together by a commonsearch engine.

System Administrator: A system administrator is a special user whose user accounthas all the possible privileges available to any other user account as well as direct accessto the underlying HCDocs system processes and server(s). This person should be the onepermitted to access the physical machines running the HCDocs system. The role of thesystem administrator is to perform system maintenance and configuration. There may bemore than one System Administrator present in the system.

UNO: Universal Network Object. It is a component model that offers inter-operabilitybetween different programming languages, different objects models, different machine archi-tectures, and different processes; either in a LAN or via the Internet.

User: A user is a person who interacts with the HCDocs system.

User Account: A user account is an independent collection of user information that theHCDocs system uses to recognize individual users. Each user account is uniquely identifiedby a user name and is given a unique password which allows the software to track individualuser privileges.

5

2 Design Overview

2.1 Description of Problem

With the growth of technology, increased security threats, and HIPPA regulations, healthcare systems realized a need to be able to securely store, search, and manage patient records.The University of Pennsylvania Health System needed a way to keep organized patientrecords. Under their current system, a server on the network is used to store those recordswithout any control measures, which allows users to have open access to read, write, andmodify patient records. Also, these systems are unable to track a revision history of thedocuments. Currently, there are a multitude of document management systems within thehealthcare industry such as ClickON Document Management, DOCSVAULT and ITAZ do-Qument to name a few. However, these systems are generally expensive, inflexible, difficultto learn, and they are not customized specifically for the University of Pennsylvania HealthSystem needs. To fulfill this unique need, HCDocs provides a product that allows sim-ple, flexible, secure and reliable access to documents as a user-friendly and cost effectivedocument management system.

2.2 Technologies Used

HCDocs uses an amalgamation of various technologies to form a coherent approach to itsdesign. For the database, we use MySQL, a free and open source product by Sun Microsys-tems. MySQL was chosen for its relative ease of use, short learning curve, outstandingdocumentation and diverse user community. For the application and business logic layers,we use Java, a widely used object oriented programming language. Java was chosen becauseof the familiarity with it among members of the team, and also for its integration with theOpenOffice extension system. Bindings for other languages exist, but the Java bindings havebeen around the longest, and most of the OpenOffice API documentation is geared towardsJava. UNO, which stands for Universal Network Objects, is used for the development of theOpenOffice extension. UNO is a set of libraries for programmatically accessing most featuresof the OpenOffice suite.

2.3 Context Diagram

The context diagram in Figure 1 shows a high level overview of the main components ofHCDocs.

6

Database Server

Patient PickerPhysician Picker

OpenOffice Application(with HCDocs

extension installed)

Administrator Front-End

Help-Menu System

Figure 1: Context Diagram

3 Architecture

This section describes the architecture of HCDocs. There are two main components tothe architecture; the application architecture, described in section 3.1, and the databasearchitecture, described in section 3.2. The application architecture is itself composed oftwo components; the OpenOffice extension, and the Administrator Interface program. Theapplication architecture is object oriented, and describes a set of classes which make up theapplication. Classes are either used solely by one of the two components, or are sharedbetween the two.

7

3.1 Application Architecture

Figure 2: Class Diagram

This section describes the architecture of the application component of the system. Figure2 shows an overview of the classes making up the application. Each sub-section describes aparticular class. Properties and methods are listed along with some text describing them.Note that accessors and mutators (getters and setters) are not described, unless they dosomething other than simply getting or setting a property.

3.1.1 Shared Classes

These classes are shared between the two major components of HCDocs, namely, the OpenOf-fice Extension and the Administrator Interface.

8

9

3.1.1.1 Document Class Represents a document. Allows manipulation, saving, andsearching of documents.

10

3.1.1.1.1 Properties

Name Type Description

id int Database primary key.description String An optional string describing the document, helps to differenti-

ate between documents with the same properties.template Template The template that this document is based off of.department Department The hospital department associated with this document.locked boolean Indicates whether the document is locked; locked documents

cannot be edited.active boolean Indicates whether the document is active; inactive documents

are hidden from users.date Date The date field within the document.created Date The date this document was created.modified Date The date this document was modified.author User The user that created this document.patient Patient The patient associated with this document.data byte[] The raw data for this document as it is stored in the database.

3.1.1.1.2 Methods

static Document[] search(Document doc)Input A Document object with partially-filled in fields.Output An array of documents or null if none match.Description Searches the document repository for documents matching the given properties.

11

boolean save()Input None.Output A boolean value indicating whether the save was successful.Description Saves the document to the repository.

3.1.1.2 Person Class Abstract base class for person classes. The Patient, Physician,and User classes are derived from this class.



db id int Database primary key.first name String The person’s first name.last name String The person’s last name.

3.1.1.3 User Class Represents a user. Stores information related to a user account,including template access permissions.

12



username String Alphanumeric username.password hash String An irreversible password hash. Compared against

password hash in database during login.email String Email address of the user.admin boolean Indicates whether the user is an administrator.active boolean Indicates whether the user is active in the system.departments List<Department> A list of departments that the user is a part of.read only templates List<Template> The user has read only access to all documents

created with these templates.full access templates List<Template> The user has read/write access to all documents

created with these templates.

3.1.1.4 Patient Class Represents a patient.



patient id int A unique identifier assigned by the hospital.date of birth Date The patient’s date of birth.

3.1.1.4.2 Methods

static Patient getPatient()Input None.Output A Patient object.Description Displays the Patient Picker and returns the chosen patient.

3.1.1.5 Physician Class Represents a physician.

13



physician id int A unique identifier assigned by the hospital.

3.1.1.6 Template Class Represents a document template.



id int Database primary key.name String Descriptive name of the template.active boolean Indicates whether the template is active in the system. New

documents cannot be created from inactive templates.

3.1.1.7 Department Class Represents a department in the hospital.



id int Database primary key.name String Descriptive name of the department.

3.1.2 OpenOffice Extension Classes

The OpenOffice Extension is an installable UNO package that users can add to their existingOpenOffice installation. It provides all of the client-side user functionality of HCDocs.

14

3.1.2.1 OODriver Class The main driver class for the OpenOffice Extension.

3.1.2.1.1 Methods

static void main(String[] args)Input Arguments to the application.Output None.Description Main entry point to the application.

boolean login(User user, String entered password)Input user - The user desiring to login. entered password - The password

entered by the user at the login prompt.Output A boolean value indicating whether the login was successful.Description Allows the user to login. Hashes the entered password and compares it

the the hash in the database.

3.1.3 Administrator Interface Classes

The Administrator Interface is a stand-alone program that the HCDocs System Administra-tor uses the manage the system.

3.1.3.1 AdminDriver Class The main driver class for the Administrator Interface ap-plication.

3.1.3.1.1 Methods

static void main(String[] args)Input Arguments to the application.Output None.Description Main entry point to the application.

15

3.2 Database Architecture

This section describes the architecture of the database component of the system.

Table 1: Structure of table Bool

Field Type Null Default Comments

ID int(11) YesVALUE text Yes

Table 2: Structure of table Documents


ID int(11) YesAUTHOR int(11) YesREVISION int(11) YesDATA longblob YesLASTMODIFIED datetime YesMODIFIEDBY int(11) YesTEMPLATE int(11) YesDOCTOR int(11) YesPAITENT int(11) YesDELETED tinyint(4) YesFINALIZED tinyint(4) Yes

Table 3: Structure of table Paitents


ID int(11) YesFIRSTNAME text YesLASTNAME text YesPHONE text YesMIDDLENAME text YesADDRESS text YesCITYSTATEZIP text Yes

Table 4: Structure of table Physician


ID int(11) YesFIRSTNAME text Yes

16

Table 4: Structure of table Physician (continued)


LASTNAME text YesMIDDLENAME text YesDEPARTMENT text YesPHONE text Yes

Table 5: Structure of table Templates


ID int(11) YesUPLOADED TIME datetime YesDATA longblob YesACTIVE tinyint(4) Yes

Table 6: Structure of table Users


ID int(11) Yes NULLFIRST text YesLAST text YesEMAIL text YesPASSHASH text YesACTIVE tinyint(4) YesMUSTCHANGEPASS tinyint(4) YesCREATED datetime YesADMIN tinyint(4) Yes

17

4 Design Features

4.1 User Features

These features are applicable to all users, both administrators and regular users.

4.1.1 Login

The Login feature allows users to login to HCDocs system with a valid username and pass-word combination. Figure 3 shows a high level overview of the login process.

U s e r

O p e n o f f i c e . o r g

L o g i n S e r v i c e

U s e r A c c o u n t S e r v i c e

D a t a b a s e

A u t h e n t i c a t i o n S e r v i c e

Figure 3: Login - Vertical Slice

The Login process takes the username and password entered by the user and passes themto authentication service to verify the user against the HCDocs database. The result ispassed back to the Login service to inform whether the login is a success or failure. If theauthentication is successful, the Login service assigns the user to appropriate privileges andallows the user to have access to the HCDocs system. If the authentication is a failure, apopup error message will occur and will ask the user to enter their username and passwordagain. After three unsuccessful tries, the account will be locked out for twenty minutes.

18

User OpenOffice.org Login Service User Account ServiceAuthentication Service Database

click on HCDocs button

login(username,password)

login(username,password)al

t

[ authentication failed ]

get username and password Info

compare username and password

return username and password Info

deny login

[ else ]

approve login

get user privileges

get user Info

set user privilege

approve login

redirect to login window

redirect to main window

encrypt password

Figure 4: Login - Sequence Diagram

19

4.1.2 Document Creation

The Document Creation feature allows users to create new documents and save it intoHCDocs system. A wizard will guide users step by step to create new document based onthe selected templates. Figure 5 shows a high level overview of the document creationprocess.

U s e r


C r e a t e D o c u m e n t S e r v i c e

N e w D o c u m e n t

F i n d P a t i e n t S e r v i c e

F i n d P h y s i c i a n S e r v i c e

S e l e c t T e m p l a t e

. .

Figure 5: Document Creation - Vertical Slice

The Document Creation process provides users a window to select a template for the typeof document they are creating. Based on the selected template, users will be guided througha list of steps to select a patient and physician of the corresponding patient. After the usersfinish selecting the required fields to the document, a new document will be generated withthe previously selected information at the top of the document. Users can start writing atthe given text areas on the document as they desire.

20

User OpenOffice.org Select Template Find PhysicianFind Patient New Document

click on New button

select a template

enter patient Info

alt

[ physician not found ]

get search result

[ else ]create new document

get search resultclick on Find Patient

[ patient not found ]redirect to find patient window

[ else ] enter physician Info

click on Find Physician

alt

redirect to find physician window

Figure 6: Document Creation - Sequence Diagram

21

4.1.3 Patient Finder

The Patient Finder features allows service clients to find the patients in the HCDocs system’sdatabase. Figure 7 shows a high level overview of the Patient Finder process.

S e r v i c e C l i e n t


P a t i e n t M a n a g e m e n t S e r v i c e

D a t a b a s e

. .

Figure 7: Find Patient - Vertical Slice

The Patient Finder process takes the patient’s id, date of birth, patient’s first name and lastname as the search fields and passes those fields to the patient management service. PatientManagement service will check against the database with those fields and return the patientsmatch to those search criteria. The search result wills then pass to the service client.

22

Service Client Find Patient Service Patient Management Service Database

enter patient Info

findPatient(patientID,DOB,firstname,lastname)

get patient record

compare patient Info

click on Find Patient

return patient record

return search results

Figure 8: Patient Finder - Sequence Diagram

23

4.1.4 Physician Finder

The Physician Finder features allows service clients to find the physicians in the HCDocssystem’s database. Figure 9 shows a high level overview of the Physician Finder process.



P a t i e n t M a n a g e m e n t S e r v i c e

D a t a b a s e

. .

Figure 9: Physician Finder - Vertical Slice

The Physician Finder process takes the physician’s id, physician’s first name and last nameas the search fields and passes those fields to the physician management service. PhysicianManagement service will check against the database with those fields and return the physi-cians match to those search criteria. The search result wills then pass to the service client.======= The Physician Finder process takes the physician’s id, physician’s first nameand last name as the search fields and pass those fields to the physician management service.Physician Management service will check against the database with those fields and returnthe physicians match to those search criteria. The search result will then pass to the serviceclient.

24

Service Client Find Physician ServicePhysician Management

Service Database

enter physician Info

findPhysician(physicianID,firstname,lastname)

get physician record

compare physician Info

click on Find Physician

return physician record


Figure 10: Physician Finder - Sequence Diagram

25

4.1.5 Save Document

The Save Document features allows users to save documents to HCDocs system’s database.Figure 11 shows a high level overview of the save document process.


N e w D o c u m e n t

S a v e D o c u m e n t S e r v i c e

D a t a b a s e

F i n a l i z a t i o n S e r v i c e

Figure 11: Save Document - Vertical Slice

The Save Document process saves the document when users click on save button creating anew document or editing an opened document. As soon as users click on save a window willpop up and give user two options on saving the document. Users can select ”Save only” or”Finalize and Save” options. If the save only is select, the system will only save the documentto the system’s database, if the other option is chosen the system will finalize the documentbefore saving it to the system’s database. If the finalize and save option is selected, an audittrail will start keeping track of all revisions made to that particular document.

26

Service Client New Document Save Document Service Finalization Service

create new document

finalize document

validate privilege to save

click on save document

confirm saving and finalization

Database

alt

[ If finalize document ]

finalize and save document

alt

return error message[ invalid privilege ]

[ else ]

[ else ]

save documentalt

validate privilege to finalize

[ invalid privilege ]

[ else ]

return error message

confirm saving

Figure 12: Save Document - Sequence Diagram

27

4.1.6 Open Document

The Open Document features allows users to open documents from the HCDocs system’sdatabase. Figure 13 shows a high level overview of the document creation process.

U s e r


O p e n D o c u m e n t

D i s p l a y

F i n d D o c u m e n t

D a t a b a s e

M u l t i p l e D o c u m e n t s S e r v i c e

Figure 13: Open Document - Vertical Slice

The Open Document process takes patient’s id, date of birth, patient’s first name and lastname, physician’s id, physician first name and last name, document created date or documentmodified date as search fields. Users can enter any one or more than one of those fields toinitiate the search. Those information will pass to the find document service and the searchresult will return back from the find document service. If the documents with the givensearch criteria exist in the database, the results will return back to the open documentservice. If there are more than one patients’ documents are associate with the search results,a list of patients names and their information will display on the next window and userscan select the patient whose document that they are trying to open. If there are only onepatient’s document is associate with the search results, the document will be opened on thenext window.

28

User OpenOffice.org Open Document Multiple Documents ServiceFind Document

Click on HCDocs button

click on Open

enter document Info

alt

[ If document not found ]

[ else ]

get search result

Display Document

Search FieldsPatient ID, DOB, firstname, lastnamePhysicianID, firstname, lastnameCreatedDate, ModifiedDate

click on Search

list patients' name[ If more than one patient associate with the search result ]

redirect to search document windowal

t

select a document to open

[ else ]display the document

Figure 14: Open Document - Sequence Diagram

29

4.1.7 Find Document

The Find Document features allows service clients to find documents in the HCDocs system’sdatabase. Figure 15 shows a high level overview of the find document process.


F i n d D o c u m e n t S e r v i c e

D o c u m e n t M a n a g e m e n t S e r v i c e

D a t a b a s e

. .

Figure 15: Find Document - Vertical Slice

The Find Document process takes patient’s id, date of birth, patient’s first name and lastname, physician’s id, physician first name and last name, document created date or documentmodified date as search fields. Find document service will take those information passed fromservice clients and compare against the records in the database. If the match records arefound, the records are returned back to the service clients. If there were no matching records,an message will send back to the service clients.

30

Service Client Find Document Service Document Management Service Database

enter document Info

findDocument(Search Fields)

get document record

compare document Info

click on Search

return docuemnt record



Figure 16: Find Document - Sequence Diagram

31

4.1.8 Lock Document

The Lock Document feature allows a document to be locked while it is being edited by a userso that it will prevent other users from making changes to it simultaneously. The featurebegins automatically as soon as a document is opened for editing by the first user.

4.1.9 Unlock document

The Unlock Document feature allows the administrator to unlock a document in the eventof computer crash or other hardware/software failures in which a document remains lockedwhich otherwise should not be.

4.1.10 Lost Username

The Lost Username feature allows the Administrator to retrieve a users username upon theirrequest.

4.1.11 Lost Password

The Lost Password feature allows a the Administrator to auto generate a new password fora user upon their request. The user must request a new password and will receive the newpassword in their designated email address on file. The Administrator will never have accessto a users password.

32

4.2 Administrator Features

These features relate to users with administrator privilege only.

4.2.1 Administrator Login

The Admin Login features allows administrators to login to the HCDocs admin system withvalid username and password combination. Figure 17 shows a high level overview of theadministrator login process.

A d m i n i s t r a t o r

H C D o c s A d m i n I n t e r f a c e

L o g i n S e r v i c e

A d m i n A c c o u n t S e r v i c e

D a t a b a s e

A u t h e n t i c a t i o n S e r v i c e

Figure 17: Admin Login - Vertical Slice

The Admin Login process takes the username and password entered by admin and passthem to authentication service to verify the admin against HCDocs database. The result ispassed back to the Admin Login service to inform whether the login is a success or failure. Ifthe authentication is successful, the Admin Login service assigns the admin to appropriateprivileges and allows the admin to have access to the HCDocs admin system.

33

Administrator HCDocs Admin Login Service Admin Account ServiceAuthentication Service Database

click on HCDocs admin login

login(username,password)

login(username,password)al

t

[ authentication failed ]

get username and password Info

compare username and password

return username and password Info

deny login

[ else ]

approve login

get admin privileges

get admin Info

set Admin privilege

approve login

redirect to login window

redirect to admin main window

encrypt password

Figure 18: Admin Login - Sequence Diagram

34

4.2.2 User Account Creation

The User Account Creation features allows administrators to add new user accounts to theHCDocs system. Figure 19 shows a high level overview of the user account creation process.


A d d U s e r S e r v i c e

C r e a t e A c c o u n t S e r v i c e

D a t a b a s e

..

Figure 19: User Account Creation - Vertical Slice

The User Account Creation process takes the user id, date of birth, user first name, lastname, e-mail address and a list of templates assigned to that user. User Account Creationservice will first validate the input data for the correct format and missing fields. If thevalidation failed, an error message will popup showing what fields are erroneous and will askthe user to reenter those fields, otherwise a new user account will be created in the systemwith the given information.

35

Service Client Add User Service Create Account Service Database

enter new user Info

addUser(userID,DOB,firstname,lastname,email,templates)

click on Add User

validate input data

alt

[ validation failed ]error message for invalid input data

[ else ] add new user to database

confirm successfully added

Figure 20: User Account Creation - Sequence Diagram

36

4.2.3 User Account Modification

The User Account Modification features allows administrators to modify user accounts inthe HCDocs system. Figure 21 shows a high level overview of the user account modificationprocess.

F i n d U s e r

M o d i f y A c c o u n t

D a t a b a s e

M o d i f y U s e r C l i e n t

R e m o v e A c c o u n t


Figure 21: User Account Modification - Vertical Slice

The User Account Modification process takes user id, date of birth, user first name, lastname and e-mail address and passes the information to find user service. Find user servicewill search the users that match to the given fields against the database. The search resultswill return to the User Account Modification service. If the search failed, it will redirect theadmin to reenter different search keywords, otherwise it will display the search results. Ifthe admin wants to disable the user account, he/she can select a user from the search resultsand click on Remove User. The user account will be disable from the system. If the adminwants to modify the user account’s information, he/she can select a user from the searchresults and click on Modify User. The entire information related to the selected user accountwill display on the next window. Admin can then modify the desired fields and click on saveto save the updated user account information into the database. Admin can also reset theusers’ password by clicking on the Reset Password button. A password will be randomlygenerated and saved to the database and e-mail new password to the users’ correspondinge-mail address. A new password can only be generated upon users request.

37

Service Client Modify User Service Find User Modify Account Service

click on Modify User

get search resultsal

t

[ user not found ]redirect to find user window

[ else ]

select a user from search results

DatabaseRemove Account Service

click on Find User

alt

{ If modify user ]

click on Modify User

redirect to Modify User window

[ else ]select a user from search results

click on Remove User

confirm removal

disable the user account

redirect to modify user window

Modify Service Reset Password

modify(userID,firstname,lastname,email,templates)

validate input data

resetPassword(userID)

alt

{ Invalid input ]redirect to modify user window

[ else ] save modified user info to database

comfirm modification

save password to database

generate new password

e-mail new password to user

redirect to modify user window

findUser(userID,firstname,lastname,email)

Figure 22: User Account Modification - Sequence Diagram

38

4.2.4 User Finder

The User Finder features allows service clients to find the users in the HCDocs system.Figure 23 shows a high level overview of the User Finder process.


F i n d U s e r S e r v i c e

U s e r M a n a g e m e n t S e r v i c e

D a t a b a s e

. .

Figure 23: Find User - Vertical Slice

The User Finder process takes the user’s id, user’s first name and last name as the searchfields and pass those fields to the user management service. User Management service willcheck against the database with those fields and return the users match to those searchcriteria. The search result will then pass it to the service client.

39

Service Client Find User Service User Management Service Database

enter User Info

findUser(userID,firstname,lastname,email)

get user record

compare user Info

click on Find User

return user record


Figure 24: User Finder - Sequence Diagram

40

4.2.5 Manage Document

The Manage Document features allows administrators to manage documents in the HCDocssystem. Figure 25 shows a high level overview of the manage document process.


M a n a g e D o c u m e n t S e r v i c e

F i n d D o c u m e n t

D i s p l a y D o c u m e n t I n f o

M o d i f y D o c u m e n t I n f o

D a t a b a s e

M u l t i p l e D o c u m e n t s S e r v i c e

Figure 25: Manage Document - Vertical Slice

The Manage Document process takes patient’s id, date of birth, patient’s first name, lastname, physician’s id, physician first name, last name, document created date or documentmodified date as search fields. Users can enter one or more of those fields to initiate thesearch. That information will pass to the find document service and the search results willreturn back form the find document service. If the search failed, it will redirect the admin toreenter different search keywords, otherwise it will display the search results. If more thanone patients’ documents are associate with the search results, a list of patients names andtheir information will display on the next window and users can select the patient whosedocuments they are trying to manage. If there is only one patients document associated withthe search results, the document information will be displayed on the next window. Adminwill be able to modify the document information, lock or unlock the document, or removethe documents from the system. Once the admin clicks on the Apply button, the updateddocument information will be saved to the database.

41

Admin Manage Document Multiple Doc ServiceFind Document

Click on Manage Document button

enter document Info

alt

[ If document not found ]

[ else ]

get search result

Display Doc


click on Search

list patients' name[ If more than one patient associate with the search result ]

redirect to search document window

alt

select a document to get it's Info

[ else ]display the document Info

Modify Doc Info Database

modify the document Info

click on Applyvalidate input data

alt

[ Invalid input ]redirect to display document Info window

[ else ]update document info in database

confirm modification

redirect to modify document window

Figure 26: Manage Document - Sequence Diagram

42

4.2.6 Manage Template

The Manage Template features allows administrators to manage templates provide by theHCDocs system. Figure 27 shows a high level overview of the manage template process.


M a n a g e T e m p l a t e S e r v i c e

A d d T e m p l a t e

U p l o a d T e m p l a t e

D a t a b a s e

R e m o v e T e m p l a t e

Figure 27: Manage Template - Vertical Slice

The Manage Template process will display a list of template available in the HCDocs system’sdatabase and a list of template that are available to the users. Admin can either add theexisting templates in the database to available list for user to have access to or uploadtemplates from external system to the HCDocs system’s database. Admin can also disabletemplates currently available to users by removing the template form the available list.

43

Admin Manage Template Upload TemplateAdd Template

Click on Manage Template button

select a template to add

alt

[ add exiting template from database ]

[ else (template doesn’t exist in the database ]

Remove Template

click on Add

Database

get templates list

return a list of templates form database

enable the template to allow users to use

click on Upload template

select a template to upload

add the uploaded template to database

select a template to remove

click on Remove

disable the template from being use

confirm the removal

Figure 28: Manage Template - Sequence Diagram

44