Electronic renal dialysis patient management network - vision document

Georgia State University

Electronic Renal Dialysis Patient Management Network

Vision

Version 3.0

Electronic Renal Dialysis Patient Management Network Version: 3.0Vision Date: <02/Mar/13><document identifier>

Revision HistoryDate Version Description Author

<28/Jan/13> <1.0> Creating a new electronic Renal Dialysis Patient Management Network

Sruthi Sagili, Douglas Cain, Nabeel Ahmed

<20/Feb/13> <2.0> Creating a new electronic Renal Dialysis Patient Management Network


<2/Mar/13> <3.0> Creating a new electronic Renal Dialysis Patient Management Network


Confidential Georgia State University, 2023


Table of Contents

1. Introduction 7

1.1 Purpose 71.2 Scope 71.3 Definitions, Acronyms, and Abbreviations 71.4 References 71.5 Analyst Certifications 71.6 Overview 7

2. Positioning 8

2.1 Business Opportunity 82.2 Problem Statement 82.3 Product Position Statement 8

3. Stakeholder and User Descriptions 9

3.1 Stakeholder Summary 93.2 User Summary 93.3 User Environment 10

4. Product Overview 11

4.1 Assumptions and Dependencies 114.2 Licensing and Installation 11

5. Goal Model 11

6. Constraints 12

7. Precedence and Priority 12

8. Overall Diagrams 13

8.1 StoryBoard - Staff dashboard 138.2 Business Process Modeling 17

9. Use-case Models 18

9.1 Use-case Diagram 189.2 Goal Use-case Traceability 199.3 UseCase_1_Create Virtual Chart 199.4 UseCase_2_Enter pre-assessment data 209.5 UseCase_3_Verify e-flowsheet 209.6 UseCase_4_Administer Dialysis 219.7 UseCase_5_Enter post-assessment data 229.8 UseCase_6_Prescribe drugs 229.9 UseCase_7_Triage Patient 239.10 UseCase_8_Discharge patient 239.11 UseCase_9_Bill Patient 24

10. Class Model 25

11. Context Model 26



12. Story Board using iRise 27

Vision1. IntroductionThe purpose of this document is to collect, define, and analyze high-level needs and features of the electronic Renal Dialysis Patient Management System. It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the electronic Renal Dialysis Patient Management System fulfills these needs are detailed in the use-case and supplementary specifications.

1.1 Purpose

The purpose of this document is to accurately document goals and requirements for the electronic Renal Dialysis Patient Management network as expressed by various stakeholders for creation of a virtual chart. Relationships and expectations will be drawn from these goals and requirements and used as the foundation for creating the electronic Renal Dialysis Patient Management network. Stakeholders, users and use cases will define exactly how the system is used.

1.2 Scope

This document will outline in detail how a virtual chart will be created, its primary uses and how the stakeholders and users will interface with the system.

1.3 Definitions, Acronyms, and Abbreviations

HIPAA - The Health Insurance Portability and Accountability Act protect the privacy of an individual health information and also governs how the health care providers collect, use, maintain and misuse the protected health informationHIS- Hospital Information System are designed to manage all the medical, financial, administrative and legal aspects of health providers DU- Dialysis Unit which includes the dialysis ward and its staffCMS- The Centers for Medicare & Medicaid Services is an agency within the US Department of Health & Human Services who are responsible for administration of federal health care programs.ARRA- American Recovery & Reinvestment Act provides investments needed to increase economic efficiency by technological advances in science and health HITECH - The Health Information Technology for Economic and Clinical Health Act was created to stimulate the adoption of electronic health records and supporting technology in the US GUI - Graphical user Interface is a type of user interface that allows users to interact with electronic images using icons and images rather than text commands HIN - Hospital Identification Number, which is a unique number given to the each patient by the hospital.

1.4 References

http://en.wikipedia.org/wiki/Graphical_user_interfacehttp://hipaa.stanford.edu/http://whatis.techtarget.com/definition/ARRA-American-Recovery-and-Reinvestment-Act-of-2009http://searchhealthit.techtarget.com/definition/HITECH-Acthttp://en.wikipedia.org/wiki/Hospital_information_systemhttp://searchhealthit.techtarget.com/definition/Centers-for-Medicare-Medicaid-Services-CMS

1.5 Analyst Certifications

We, Douglas Cain, Sruthi Sagili and Nabeel Ahmed analyzed these documents and believe that they: Comply with current UML syntax and best practices Are internally consistent Meet the stakeholder needs as we understand them


http://searchhealthit.techtarget.com/definition/Centers-for-Medicare-Medicaid-Services-CMS

http://en.wikipedia.org/wiki/Hospital_information_system

http://searchhealthit.techtarget.com/definition/HITECH-Act

http://whatis.techtarget.com/definition/ARRA-American-Recovery-and-Reinvestment-Act-of-2009

http://hipaa.stanford.edu/

http://en.wikipedia.org/wiki/Graphical_user_interface


1.6 Overview

The remaining sections of this document will outline the positioning statement, product positioning, stakeholder and user descriptions, user summary, user environment, key stakeholder and user needs, product overview, the goal model, constraints, precedence and priority, the use case and design model and stakeholder requests in increasing order of specificity.

2. Positioning

2.1 Business Opportunity

The opportunity to move outpatient dialysis centers onto a competing and complementary platform as the core HIS. The system will significantly bridge logistical divides between auxiliary systems. Safety and privacy are the main concerns of the health organization. Physicians, nurses, nutritionists and technicians will only be allowed to see patient data in relation to assigned roles. This virtual chart addresses lack of redundancy and immediately provides a comprehensive solution for erroneous flow sheets.

2.2 Problem Statement

The problem of A single non-redundant paper chart updated by all caregivers

Affects Hospitals, physicians, nurses, technicians, patients

the impact of which is The loss of patient records due to theft or destruction. Medical Codes and medicines entered erroneously and a lack of security of the patient data between physicians, nurses, nutritionists and technicians

a successful solution would be Provide online access to all caregivers. Facilitation of patient care, safety and privacy. The new system interfaces with main hospital HIS and various auxiliary systems

2.3 Product Position Statement

For Outpatient Dialysis Unit

Who Need an online virtual chart for caregiver staff for the patient's safety and privacy

The Renal Dialysis Patient Management Network

Uses a virtual chart over the enterprise intranet

That Maintains a virtual chart for vitals, pre- and post-assessments, labs, orders and results

Unlike The current paper based system that lacks privacy, security and back-up

Our product Provide online access to a comprehensive virtual chart for inserts and updates of patient data real time. Our product alleviates the data entry mistakes, unreadable manuscript and auto corrects common codes, procedures and medicines entered. Caregivers are assigned to groups to enforce HIPPA regulations and company policies. It interfaces with the Billing system and HIS.



3. Stakeholder and User Descriptions

3.1 Stakeholder Summary

Name Description Responsibilities

Care-A-Lot The company overseeing the entire DU

They will ensure that the new system meets the main goals of the DU and complies with its requirements

Hospital Management

The management of the hospital overseeing the entire facility

Will ensure that the new system complies with hospital standards and requirements

Other providers Health care providers Healthcare providers responsible for the patients care, such as hospitals, clinics, pharmacies etc who compete with the current DU.

Federal Regulators The government bodies/individuals responsible for enforcing standards, such as HIPPA

They will be keen to make sure that the new system complies with regulatory practices, such as HIPPAA regulations, ARRA & HITECH federal standards of patient safety, care, and confidentiality

Patients The individuals receiving treatment in the DU

They are a main beneficiary, as the system will allow providers to deliver optimal and confidential patient care

CMS(Center for Medicaid services)

Government entity for uninsured and the elderly patients

The companies reimburse care providers for uninsured services

3.2 User Summary

Name Description Responsibilities Stakeholder

Physicians They are the primary users, who manage and update the patient's records in the system

Enter the patient information like diagnosis, drug administration, etc. into the new system

Update any new additions or changes to the patient's records.

Check for any discrepancies in the patient records

Operational Stakeholder

Nurses They are the primary users, who administer the drugs to the patient based on physician's instruction updated in the system

Access the system to monitor the drug administration and test results. Update any new additions or changes to the patient's records.

Check for any discrepancies in the patient records

Operational Stakeholders



Administrators They are the primary users, who manage all the technical problems in the system

Manage the technical problems in the new system

Set and manage the access privileges to the system

Manage the security and maintenance of the system

Interfacing Stakeholder

Nutritionists They are the primary users, who recommend the diet plans based on the current health conditions of the patient

Update the recommended diet plan of the patient into the new system

Operational stakeholders

Technicians They are the secondary users, who manage the maintenance of the dialysis machines and handle the lab equipment.

Update the lab results into the new system

Send an alert to the assigned Physician or Nurse in case of any discrepancies in the lab results

Check the proper working of the lab equipment and the dialysis machines

Operational stakeholders

Developers They perform the coding for the application software

Understand the Functional Requirements in the System design and build the application software based on it

Testing the application software to check the proper working of the system

Surrogate stakeholders

Project Managers They manage the resources, schedule, cost and scope of the project

Manage the schedule, cost & scope of the project

Allocate the resources

Track all the change requests and approvals

Surrogates stakeholders

Business Analysts

They convert the High level Business needs to the Product or Functional Requirements

Understand the requirements of the DU and convert them into the functional requirements that can be understood and converted into working software by the developers.

Track any high level changes to the system

Surrogate stakeholders

3.3 User Environment

The current system follows paper-based patient records. It is handled by lot of staff and there is a probability of the patient chart getting lost or misplaced or misused. Since all the charts are placed in the open cart, there is no security for these charts and any one can access them. There is also a frequent problem of patient records being



stolen by the staff or by an intruder. To overcome all these problems, the new Electronic Renal Dialysis Patient Management system keeps track of the patient records by maintaining a virtual copy of the records rather than a paper based copy. The system maintains a standard format for the records that comply with the HIPAA standards and regulations. This system allows access to the authorized personnel to update or make any changes to the patient records. The new system interfaces with the current billing system and the HIS so that changes made to any patient records will be reflected in billing system and HIS.

4. Product OverviewElectronic Renal Dialysis Patient Management system keeps track of all the patient records in the DU. This system allows the physicians , nurses, Nutritionists, lab technicians to record and update the health records of the patient. Following are some of the important functions performed by the system: The system allows the assigned physician to update or make changes to the patient information The system has a user-friendly GUI, which is self-descriptive enough to be understood by the non-technical

staff The patient records will contain all the information of the patient like medical history, drug administration, lab

tests and their results and other basic information like allergies, blood group, weight, height etc The Physician can track the progress of the patient The system interfaces with the billing system and the HIS. Any changes to the patient's records will be reflected in the system that are interfaced with it The access privileges for the system are set for the DU staff so that only assigned physician can access and

modify a patient's information The new system replaces all the existing paper based patient records The emergency alerts or lab results alert can be sent by any nurse or the lab technician to the patient's assigned

physician

4.1 Assumptions and Dependencies

N/A

4.2 Licensing and Installation

N/A

5. Goal Model

5.1 The system shall ensure optimal patient care

5.2 Maintain: The system features and functions shall always comply with the most current federal HIPPA regulations

5.3 The system shall have a user-friendly GUI

5.4 Maintain: The system shall always maintain back-ups of all patient records

5.5 Convert all the existing paper-based patient charts to patient virtual charts5.5.1 Avoid: The system shall never require paper-based records

5.6 The system shall ensure patient confidentiality5.6.1 Avoid: The system shall never allow access to an unauthorized individual5.6.2 Cease: If the system is inactive for a certain period of time on any machine, it should automatically

log off the user account

5.7 The system should be able to accept access privilege changes



5.7.1 Maintain: They system shall allow the administrators to change access privileges for staff/users even after initial initiation and launch.

5.8 The system shall allow authorized users to create and update virtual charts.

5.8.1 Achieve: WHEN the patient is a reoccurring patient, THEN the system shall update the virtual chart for the patient

5.8.2 Achieve: WHEN the patient is a new incoming patient, THEN the system shall create a virtual chart for the patient

5.8.3 Achieve: WHEN a new or reoccurring patient arrives, THEN the system shall create a e-flowsheet within the virtual chart of the patient

5.9 Each e-flowsheet should contain the visit information of a patient5.9.1 Achieve: WHEN an pre-assessment has been conducted, THEN a nurse can update the pre-

assessment section of the e-flowsheet5.9.2 Achieve: WHEN an post-assessment has been conducted, THEN a nurse can update the post-

assessment section of the e-flowsheet

5.10 The system shall allow authorized users to have online access to patient information 5.10.1 Achieve: WHEN the e-flowsheet verification has been completed, THEN a physician can

accept/reject patient dialysis treatment5.10.2 Achieve: WHEN the post-assessment of the patient has been completed, THEN a physician can

prescribe drugs for the patient 5.10.3 Achieve: WHEN the dialysis treatment has been started, THEN a technician can update the

dialysis status in the e-flowsheet of the patient

5.11 The system shall maintain an up-to-date list of dischargeable patients5.11.1 Maintain: The system shall always allow immediate discharge of patients by clinical staff.

5.12 The system shall interface with the current Hospital Information Systems (HIS) 5.12.1 Achieve: When a patient is transferred to the main hospital, THEN the system shall transfer

the virtual chart of the patient to the main hospital 5.12.2 Achieve: When a patient is transferred from the main hospital, THEN the system shall receive

the virtual chart of the patient from the main hospital

5.13 The system shall interface with the hospital Billing system 5.13.1 Achieve: WHEN changes are made to diagnosis or services of the patient, THEN the system shall

update the changes in the Billing system

6. Constraints

N/A

7. Precedence and Priority N/A



8. Overall Diagrams

8.1 StoryBoard - Staff dashboard



8.2 Business Process Modeling



9. Use-case Models

9.1 Use-case Diagram



9.2 Goal Use-case Traceability

Use Case Goal

5.8 5.9.1 5.9.2 5.10.1 5.10.3 5.11.1 5.12 5.13 5.10.2

Create Virtual Chart

Enter pre-assessment data

Verify e-flowsheet

Enter post-assessment data

Prescribe Drugs

Triage Patient

Discharge patient

Bill patient

Administer Dialysis

9.3 UseCase_1_Create Virtual Chart

Goal: The system shall allow authorized users to create and update virtual charts.Actors: Clinical StaffBrief Description: This use-case describes creating a virtual chart for a new patientType: User-goalPre-conditions:The referred patient is a new patient and clinical staff is logged into the system. Post-conditions:An online virtual chart is created for new patients to record longitudinal and visit-specific data. Basic Flow of Events:

Clinical Staff System Response

1. Authenticated staff member clicks on virtual chart tab

2. System displays empty virtual chart containing new patient fields

3. Staff records patient longitudinal data in the fields 4. Staff clicks on “Save” button

3. System saves virtual chart in the database4. System displays message "virtual chart successfully

created"

Alternatives:a) System recognizes erroneous data format

5. System re-displays form along with an error message and appropriate field format (back to step 3 in main flow)



9.4 UseCase_2_Enter pre-assessment data

Goal: WHEN an pre-assessment has been conducted, THEN a nurse can update the pre-assessment section of the e-flowsheet

Actors: NurseBrief Description: This use-case describes patient pre-assessment data being recorded in the e-flowsheetType: User-goalPre-conditions:Authorized nurse is logged into the system and virtual chart has been created for the patient Post-conditions:Pre-assessment data is recorded in the electronic flowsheet Basic Flow of Events:

Nurse System Response

1. Nurse clicks on “create e-flowsheet” tab 2. System creates a new e-flowsheet form within virtual chart3. System displays the pre-assessment form having fields such as blood pressure, blood type, height and weight

4. Nurse records pre-assessment data in the pre assessment form within the e-flowsheet5. Nurse clicks on “Save” button

6. System saves e-flowsheet in the database7. System displays message "patient data saved" and displays the patient data for confirmation

8. Nurse verifies patient data and clicks "submit" 9. System displays message "e-flowsheet successfully created"


6. System re-displays the form along with an error message and appropriate field format (back to step 4 in main flow)

9.5 UseCase_3_Verify e-flowsheet

Goal: WHEN the e-flowsheet verification has been completed, THEN a physician can accept/reject patient dialysis treatmentActors: PhysicianBrief Description: This use-case describes the patient e-flowsheet verification process by the physicianType: User-goalPre-conditions:Authorized physician is logged into the system and pre-assessment data in the e-flow sheet has been entered for the patientPost-conditions:Physician has given approval or rejection of the dialysis process for the current patientBasic Flow of Events:

Physician System Response

1. Physician selects the "verify e-flowsheet" tab 2. System displays the pending patient e-flow sheets for approval

3. User selects the current patient's e-flow sheet 4. System displays the content of the selected e-flow sheet



5. Physician reviews the e-flow sheet data for any medical issues6. Physician clicks on the "Approve" button

7. System updates the approval status of the e-flow sheet in the database8. System displays the message " Patient is approved for Dialysis"

Alternatives:a) When medical issues are found in the patient e-flow sheet6. Physician selects the "Reject" button 7. System updates the approval status in the e-flow

sheet into the database8. System displays the message " Patient is rejected for Dialysis"

9.6 UseCase_4_Administer Dialysis

Goal: WHEN the dialysis treatment has been started, THEN a technician can update the dialysis status in the e-flowsheet of the patient

Actors: TechnicianBrief Description: This use-case describes the dialysis administration and status update processType: User-goalPre-conditions:Authorized technician is logged into the system, and e-flow sheet is verified and approved by the physicianPost-conditions:Technician has completed the dialysis administration and status update process for the current patientBasic Flow of Events:

Technician System Response

1. Technician clicks on the "Pending Patients" tab 2. System displays the list of patients waiting for the dialysis administration

3. User selects the current patient e-flow sheet from the list 4. Technician clicks on "Administer Dialysis" button

5. System updates the patient dialysis status as" in progress" in the e-flowsheet6. System displays a message " Dialysis Status updated to in progress"

7. When dialysis administration is complete, Technician clicks on "End Dialysis" button

8. System updates the patient dialysis status as" complete" in the e-flowsheet9. System displays a message " Dialysis Status updated to complete"

Alternatives:a) When dialysis administration is cancelled7. Technician clicks on the "Cancel" button 8. System updates the patient dialysis status as

"cancelled" in the e-flowsheet9. System displays a message "Dialysis Status updated to cancelled"

9.7 UseCase_5_Enter post-assessment data

Goal: WHEN an post-assessment has been conducted, THEN a nurse can update the post-assessment section of the e-flowsheetActors: Nurse



Brief Description: This use-case describes the recording of post-assessment data in the e-flowsheetType: User-goalPre-conditions:Authorized Nurse is logged into the system, and dialysis administration is complete for the current patientPost-conditions:Nurse has completed the post-assessment form within the e-flowsheet for the current patientBasic Flow of Events:

Nurse System Response

1. .Nurse clicks on "Post-assessment data" option 2. System displays the pending post-assessment list

3. Nurse selects the current patient e-flowsheet from the post-assessment list

4. System displays the post assessment form with blank fields to fill the patient data

5. Nurse records the post assessment data into the respective fields of the post assessment form within the e-flowsheet. 6. Nurse selects the " Submit" button

7. System updates the e-flowsheet in the database8. System displays the message "post assessment data updated successfully into the e-flowsheet"


7. System re-displays form along with an error message and appropriate field format (back to step 5 in main flow)

9.8 UseCase_6_Prescribe drugs

Goal: The system shall always allow immediate discharge of patients by clinical staff.Actors: PhysicianBrief Description: This use-case describes the patient drug prescription processType: User-goalPre-conditions:Authorized Physician is logged into the system and post-assessment process has been completed.Post-conditions:The drug prescription for the current patient is updated in the e-flowsheetBasic Flow of Events:

Physician System Response

1. Physician selects the "Formulary" tab 2. System displays a list of patients awaiting drug prescription 3. Physician checks the post assessment form 4. Physician clicks on " Assign Formulary" button

5. Physician selects the current patient from the list 6. The system displays the post assessment form for the current patient

7. Physician checks the post assessment form 8. Physician clicks on " Assign Formulary" button

9. The system provides a list of recommended drugs

10. Physician selects the necessary drugs from the list11. Physician selects "Confirm" button

12. The system updates the e-flowsheet in the database13. The system displays a message "e-flowsheet updated successfully"

Alternatives:



a) When the necessary drugs are not listed in the recommended list 10. The Physician selects the "Other" option at the end of the recommended list

13. The system displays a search window, which allows to search based on name, brand and class

11. The Physician inputs the values into the search fields12. The Physician clicks on the " Search" button

14. The system searches for the drug 15. The system displays the matching entries satisfying the search criteria

16. The Physicians selects the valid drug from the matched entries17. The Physician clicks on the "Add" button

18. The system adds the selected drug to the recommended list

9.9 UseCase_7_Triage Patient

Goal: The system shall interface with the current Hospital Information Systems (HIS)Actors: Clinical staffBrief Description: This use-case describes the triage process for the patients who have been rejected for dialysis by the physicianType: User-goalPre-conditions:Authorized clinical staff member is logged into the system, and dialysis administration has been rejected for the current patient by the physicianPost-conditions:The current patient has been transferred to the main hospital based on the physician recommendationsBasic Flow of Events:

Clinical staff System Response

1. Staff member selects the “Transfer patient” tab 2. System displays a transfer form to be completed

3. Staff member enters important information, including patient identifying information and reason(s) for transfer 4. Staff member clicks on “Transfer” button to confirm the transfer

5. System displays message “patient information transferred successfully.”

Alternatives: Transfer action fails6. System displays message “transfer failed – please attempt transfer again” (back to step 5)

9.10 UseCase_8_Discharge patient

Goal: The system shall always allow immediate discharge of patients by clinical staff.Actors: Clinical staffBrief Description: This use-case describes the discharge of the patient from the Dialysis unitType: User-goalPre-conditions:Authorized Clinical staff is logged into the system, and the patient treatment and check-up has endedPost-conditions:The current patient is checked out of the Dialysis unit



Basic Flow of Events:Clinical staff System Response

1. The staff selects the "Discharge" tab 2. System displays a list of patients awaiting discharge

3. The staff selects the current patient to be discharged from the list 4. The staff clicks on "Discharge" to confirm the discharge of the patient

5. The system updates the time of discharge into the e-flowsheet in the database6. The system displays the message "Patient discharged from the clinic"

Alternatives:a) When the current patient is not present in the Dischargeable patient's list3. The Staff clicks on the "Add" button below the dischargeable patient's list to manually add the patient into the list

4. The system displays an “add” dialog box with fields to enter the patient information

5. The staff enters the current patient information in the respective fields 6. The staff selects the "Confirm" button

7. The System adds the patient to the “dischargeable patients” list(back to step 5 in main flow)

9.11 UseCase_9_Bill Patient

Goal: The system shall interface with the hospital Billing system Actors: CoderBrief Description: This use-case describes billing the patient for diagnosis and services undergoneType: User-goalPre-conditions:Authorized coder should be logged into the system and the patient should be discharged from the dialysis unitPost-conditions:The invoice is created for the current patientBasic Flow of Events:

Coder System Response

1. The coder selects the "Billing" tab 2. System displays the list of patients waiting for their invoice

3. The coder selects the current patient e-flowsheet from the list 4. The coder clicks on " OK" button

5. The system displays the services and diagnosis of the patient along with the recommended list of codes for each service

6. The coder selects the appropriate code for the services 7. The coder clicks on the "Confirm" button

7. The system generates an invoice for the services8. The system stores the invoice into the database9. The system displays the message "invoice generated and saved into the database successfully"

Alternatives:a) When the necessary codes are not listed in the



recommended list 6. The Coder selects the "Add" button, which is next to the recommended list

7. The system displays the “add” dialog box and the respective fields to add the code.

8. The Coder inputs the values into the respective fields9. The Coder clicks on the "Confirm" button

10. The system adds the code into the recommended list 11. The system displays the message " Code is added to the list successfully" (back to step 7 in main flow)

10. Class Model

11. Context Model



12. Story Board using iRise


Electronic renal dialysis patient management network - vision document

Technology

Transcript of Electronic renal dialysis patient management network - vision document