Thirty-Eight Requirements Before the First Demo: What a Bed Management System Must Do, Written From the Hospital's Own Workarounds
Student Name
American College of Education
HLTH5643: Information Systems Management for Healthcare Administrators
Module 2 Assignment
Instructor Name
September 11, 2028
Why Requirements Come First
A vendor demonstration is designed to show a product at its best, following a script the vendor has refined over many sales. A hospital that watches demonstrations before it knows what it needs tends to adopt the vendor's view of the problem, judging products on features that look impressive rather than on whether they solve the hospital's own problems. Kaplan and Harris-Salamone (2009), summarizing the literature and an expert workshop on health information technology success and failure, identified poor fit between systems and the work they are meant to support, and inadequate attention to the people and organizations using them, as recurring causes of failure. Requirements written after a demonstration describe the product just seen; requirements written before describe the hospital.
The previous module traced 46 admissions at the composite 318-bed hospital used in this course and found that bed information actually moves through a supervisor's private spreadsheet, personal texts between charge nurses and the supervisor, beds held back near shift change and cleaning done outside the dispatch record. Those findings are the primary source for the requirements here. The steering committee agreed that no vendor would be invited to demonstrate until the requirements were approved.
How the Requirements Were Gathered and Written
Two analysts held a 90-minute workshop with each of five groups: house supervisors, emergency department nurses and physicians, inpatient charge nurses, environmental services staff and dispatchers and patient transport. Each workshop began with the traced cases from that group's part of the process, and participants were asked what they would need in order to stop using the workaround they relied on. Information security, the interface team and the patient access department reviewed a draft for technical and regulatory needs.
Each requirement follows the same format: an identifier, a single testable statement of what the system must do, the source that justifies it, a priority and the method by which it will be verified. Priorities use three levels: must, meaning a product that cannot meet the requirement will be eliminated; should, meaning it will be scored; and could, meaning it is desirable but will carry little weight. The final list contains 38 requirements, of which 17 are must, 15 are should and 6 are could. Restricting must requirements to fewer than half keeps the list from eliminating every product on the market.
Functional Requirements
The functional requirements fall into five groups, each tied to a workaround. Bed status requirements replace the supervisor's spreadsheet. For example, BS-01 (must) requires that the system display the current status of every staffed bed, occupied, discharge pending, dirty, cleaning in progress, clean or blocked, to the house supervisor on one screen, updated within 60 seconds of any status change. BS-04 (must) requires that environmental services staff be able to change a bed's status from a hospital-issued mobile device at the bedside in no more than two taps, which removes the telephone relay that added a median of 24 minutes.
Communication requirements replace personal texting. CM-02 (must) requires secure messaging between the supervisor and charge nurses within the system or an integrated hospital messaging platform, with no patient information stored on unmanaged devices. Dispatch requirements address the cleaning delay: DS-01 (should) requires that a bed be queued for cleaning automatically when the patient's departure is recorded, and DS-05 (should) requires a way for a nurse to record that they cleaned a room. The admission pause requirement, AP-01 (should), responds to beds held back at shift change: it allows a charge nurse to place a visible, time-limited hold of up to 30 minutes on a clean bed, with a reason, released automatically, so that capacity is paused openly rather than hidden. Reporting requirements, such as RP-02 (must), require timestamps for each step from the admission decision to arrival on the unit, so the hospital can measure whether the system works.
Technical and Security Requirements
Technical requirements address integration, reliability and security. IN-01 (must) requires that the system receive admission, discharge and transfer events from the hospital's electronic record through its existing interface engine and reflect them within 60 seconds. IN-03 (should) requires that bed assignment in the new system be sent back to the electronic record, so that nobody has to enter the same assignment twice. AV-01 (must) requires availability of at least 99.9 percent outside scheduled maintenance, and AV-02 (must) requires a documented downtime procedure, including a printable bed status report, because the hospital cannot stop admitting patients when a server fails.
Security requirements include role-based access, so that environmental services staff can see bed status without seeing diagnoses, and a complete audit log of who viewed or changed each record. SC-03 (must) requires that the vendor sign a business associate agreement and describe where data are hosted. Usability requirements set limits on training: US-02 (should) requires that environmental services staff be able to use the mobile functions after no more than one hour of training, since they are the group whose participation the whole system depends on.
Checking Coverage Against a Sociotechnical Model
Requirements gathered from workarounds tend to focus on functions and can miss other dimensions of a system's success. The analysts checked the draft against the eight dimensions of the sociotechnical model proposed by Sittig and Singh (2010), which run from the technology itself, the equipment, programs and clinical content it holds, through the screens people use and the people themselves, to the flow of work and messages, the hospital's own rules and habits, requirements set by regulators, and continuing checks on how well the system works in daily use. The check found two gaps. No requirement addressed internal policy, and the hospital's bed placement policy, which assigns final authority to the house supervisor, would need to change if charge nurses could place holds. A policy requirement was added, along with a note that the policy must be revised before go-live. No requirement addressed ongoing monitoring of the system itself, so a requirement was added for a monthly report of interface failures and status updates made more than 15 minutes late.
A third check looked for ways the system itself could create new problems. Ash et al. (2004) described how patient care information systems can produce errors in two broad ways: in the process of entering and retrieving information, for example through screens that are hard to read under pressure or that demand overly structured input, and in communication and coordination, where a system can disrupt the informal conversations clinicians rely on. The second category matters here, because charge nurses and the supervisor currently talk several times a shift about expected discharges, and a system that replaced those conversations entirely with status icons could lose information that never fits a field. Requirement CM-04 (should) was added so that each bed can carry a short free-text note visible to the supervisor, and the implementation team will be asked to keep the midday bed huddle rather than assume the screen has made it unnecessary.
From Requirements to a Demonstration Script
The requirements become the script that each invited vendor must follow. Rather than a standard product tour, each vendor will be given four scenarios drawn from the traced admissions: a Tuesday afternoon with three discharges pending and four emergency admissions waiting; a night shift in which a housekeeper cleans a room while dispatch believes it is dirty; a shift change on a medical unit where the charge nurse needs a brief pause; and a two-hour interface outage. Vendors will have to show, in their product, how each must and should requirement is met in those scenarios, with an evaluation team of a supervisor, a charge nurse, an emergency nurse, a dispatcher and an interface analyst scoring each requirement as met, partly met or not met.
Vendors will also receive a written questionnaire covering requirements that cannot be demonstrated, such as availability history, hosting, security certifications and pricing structure, and reference calls will be conducted with at least two hospitals of similar size that have used the product for more than a year. Scoring the options against these requirements, and not against the features each vendor chooses to highlight, is the task of the next module. A scripted demonstration asks the vendor to solve the hospital's problem; an unscripted one lets the vendor choose the problem.
Conclusion
The 38 requirements describe what a bed management system must do for this hospital: show every bed's status in real time, let housekeepers update it at the bedside, replace personal texts with secure messaging, make admission pauses visible and limited, integrate with the electronic record and keep working during outages. Each requirement comes from an observed need, carries a priority and can be tested. Written before any demonstration, they give the hospital a way to judge products by its own problems rather than by the vendor's presentation.
References
Ash, J. S., Berg, M., & Coiera, E. (2004). Some unintended consequences of information technology in health care: The nature of patient care information system-related errors. Journal of the American Medical Informatics Association, 11(2), 104-112. https://doi.org/10.1197/jamia.M1471
Kaplan, B., & Harris-Salamone, K. D. (2009). Health IT success and failure: Recommendations from literature and an AMIA workshop. Journal of the American Medical Informatics Association, 16(3), 291-299. https://doi.org/10.1197/jamia.M2997
Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality and Safety in Health Care, 19(Suppl. 3), i68-i74. https://doi.org/10.1136/qshc.2010.042085
How this HLTH 5643 Module 2 example is structured
HLTH 5643 Module 2 typically writes requirements before anyone sits through a vendor demonstration; your classroom's instructions decide the format and how many requirements to include. This example explains why the order matters, describes how requirements were gathered and the format each one follows, then presents the functional and technical requirements in groups with representative examples. A coverage check against a named sociotechnical model shows what the list might have missed. The paper closes by converting the requirements into a demonstration script built from real cases.
HLTH5643 Module 2 questions, answered
What does HLTH5643 Module 2 usually ask for?
HLTH5643 Module 2 typically asks students to write system requirements for a health information technology purchase before vendors are evaluated. Many sections expect functional and technical requirements, priorities and a link to the needs identified earlier. Your classroom's instructions decide the format and the number of requirements.
How should a system requirement be written?
Write one testable statement per requirement, say what the system must do rather than how, and include a source, a priority such as must, should or could, and how it will be verified. Vague requirements such as user friendly cannot be tested; a limit on taps or training hours can.
Why write requirements before vendor demonstrations?
Demonstrations follow the vendor's script and highlight the product's strengths. Writing requirements first lets the organization define its own problems, then require vendors to demonstrate how they solve them, which makes comparisons fair and keeps the decision focused on fit.
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 American College of Education 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.