Sixty-Two Volunteers on a Spreadsheet: Why a Hospital's No One Dies Alone Program Needs a Relational Database, and What It Must Hold
[Student Name]
University of Phoenix
NSG/543: Database Management
Week 1 Assignment
[Instructor Name]
[Date]
The hospital, the program and all data are a composite written for a model paper.
Our 350-bed hospital began a No One Dies Alone program two years ago. When a patient is expected to die within hours or days and has no family or friends able to be present, trained volunteers take turns sitting with the patient so that no one dies alone. Programs of this kind have spread to many hospitals, and those who have implemented them describe the coordination work as considerable, from recruiting and training volunteers to filling vigil shifts at short notice (Bradas et al., 2014). The program now has 62 active volunteers and receives about 14 vigil requests a month. Its data live in one spreadsheet. This paper explains why that is no longer enough and what a better database must hold.
How the Program Works
A nurse who identifies a patient eligible for a vigil calls the chaplaincy office or, after hours, the house supervisor. The volunteer coordinator, a chaplain, then calls or texts volunteers to fill two-hour shifts around the clock until the patient dies or family arrives. After each shift, the volunteer writes a short note in a paper log kept in a comfort cart, and the coordinator later enters dates and hours into the spreadsheet. The program's steering committee reports to nursing leadership each quarter.
The Problems With the Spreadsheet
The spreadsheet has one row per vigil shift, with columns for date, time, unit, room, patient initials, volunteer name, volunteer phone number, training date and notes. Over two years it has grown to about 2,300 rows, and its problems are typical of flat files. Volunteer phone numbers and training dates are repeated on every row a volunteer works, so when a volunteer changes phone numbers, old rows keep the old number, and the coordinator has twice called a disconnected line. There is no reliable way to know which volunteers are due for annual refresher training. Uncovered hours, the most important outcome, are not recorded at all, because the spreadsheet records only shifts that were filled. And patient initials are not unique, so vigils for two patients with the same initials on the same unit have been confused. A spreadsheet can list what happened, but it cannot easily show what did not happen, and uncovered hours at a dying patient's bedside are exactly what the program most needs to see.
Three Database Models
A flat-file model stores data in a single table, like the current spreadsheet. It is simple but repeats data, which leads to the update errors described above.
A hierarchical model organizes data as a tree of parent and child records, such as a vigil with its shifts below it. It works well for data with one natural hierarchy but poorly when relationships cross, as they do here: a volunteer works many vigils, and a vigil has many volunteers.
A relational model stores data in separate tables, one for each kind of thing, linked by keys. Codd (1970) proposed the relational model to protect users from the details of how data are stored and to allow data to be combined flexibly through relationships between tables. Each fact is stored once, so a volunteer's phone number lives in one row of one table and every vigil refers to that row.
Why the Relational Model Fits
The program's data have many-to-many relationships: volunteers serve many vigils, vigils involve many volunteers and each shift links one volunteer to one vigil at one time. A relational database represents this with a table for volunteers, a table for vigils and a table for shifts connecting them. It also allows the program to record requested hours as well as filled hours, which makes uncovered hours calculable. McGonigle and Mastrian (2022) describe relational databases as the most common model in health care information systems because of this flexibility and their support for queries.
Entities and Attributes
Five entities emerge from the program's work.
Volunteer: name, phone, email, availability preferences, start date, status and training records.
Training: course, date completed and expiration date, linked to the volunteer.
Patient vigil: the patient, unit, room, date and time requested, requesting nurse, expected duration and end reason, such as death, family arrived or transfer.
Shift: the vigil, the volunteer, scheduled start and end, actual start and end and whether it was filled.
Unit: name, floor and nursing contact.
Patients will be identified by the hospital's medical record number, stored only where needed, with the patient's name displayed to coordinators through the record rather than duplicated in the database.
Relationships
A volunteer has many training records. A vigil has many shifts. A volunteer works many shifts. A unit hosts many vigils. Each shift belongs to exactly one vigil and, once filled, to exactly one volunteer; unfilled shifts have no volunteer, which is how uncovered hours become visible.
Who Will Use the Database
Four groups will use the database in different ways. The volunteer coordinator will use it daily to schedule shifts and track training. Chaplains who cover evenings and weekends will use it to fill urgent shifts. The steering committee will use its reports each quarter. And nurse managers will receive summaries about their units. Each group's needs will shape forms and reports later in the course, but all depend on the same well-designed tables.
Why Not a Commercial Volunteer System
The hospital's volunteer office uses a commercial system for general volunteers, and the coordinator asked whether it could be used instead. It tracks hours and training well, but it cannot link shifts to patient vigils, record unfilled requested shifts or connect to patient information in the record. Adapting it would cost more than building a small database on the hospital's existing platform, and the program's core outcome, uncovered hours, would still be missing.
Privacy From the Start
The database will hold protected health information, the patient's identity and the fact that the patient was dying, so it must be built on the hospital's secure platform, with access limited to the coordinator, chaplains and designated staff. Volunteers will not have access to the database itself.
Success Criteria for the Database
The database will be judged by three tests: the coordinator can see every unfilled shift for the next 72 hours at a glance, the committee receives covered and uncovered hours without anyone counting by hand and no volunteer serves with lapsed training.
What the Rest of the Course Will Build
Week 2 will design the tables, keys and relationships; Week 3 will design entry forms; Week 4 will write queries; Week 5 will build reports; and Week 6 will explore what data mining could reveal about vigil requests.
Conclusion
The program's spreadsheet repeats data, cannot show uncovered hours and cannot track training, problems that follow from its flat-file design. A relational database, with separate tables for volunteers, training, vigils, shifts and units linked by keys, fits the program's many-to-many work and makes its most important outcome measurable.
References
Bradas, C. M., Bowden, V., Moldaver, B., & Mion, L. C. (2014). Implementing the "No One Dies Alone" program: Process and lessons learned. Geriatric Nursing, 35(6), 471-473. https://doi.org/10.1016/j.gerinurse.2014.10.005
Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377-387. https://doi.org/10.1145/362384.362685
McGonigle, D., & Mastrian, K. G. (2022). Nursing informatics and the foundation of knowledge (5th ed.). Jones & Bartlett Learning.
How this NSG 543 Week 1 example is structured
The NSG/543 description introduces database models, forms, tables, reports, queries and data mining. This paper opens the course by describing a real kind of nursing data problem, comparing database models against it and defining the entities and relationships a database for it must represent, so that the design work in later weeks has a clear purpose. Students search this week as NSG 543 Week 1, NSG543 Wk 1 or NSG/543 Wk 1; all three are the same assignment.
NSG/543 Week 1 questions, answered
What does NSG/543 Week 1 usually ask for?
The course description introduces database models and the management of databases. Many sections begin by comparing database models and describing a nursing use case for a database.
What is a relational database?
A database that stores data in tables of rows and columns, with relationships between tables expressed through shared key values, so each fact is stored once and combined as needed.
What is an entity in database design?
A thing about which the database stores data, such as a volunteer, a patient vigil or a shift, each with its own attributes.
Write yours, or have the desk draft it
This paper is an original model document written by our desk, not a submitted student paper and not an official University of Phoenix document. Read it for the moves, then write your own to the instructions in your classroom. If you want one built to your exact prompt and rubric, the first custom sample is free and arrives in 24 to 48 hours.