Your browser doesn't support JavaScript. Please upgrade to a modern browser or enable JavaScript in your existing browser.
Skip Navigation U.S. Department of Health and Human Services www.hhs.gov
Agency for Healthcare Research Quality www.ahrq.gov
www.ahrq.gov

National Hospital Available Beds for Emergencies and Disasters (HAvBED) System

Appendix D. Preliminary System Specification Document

HAvBED
Hospital Available Beds for Emergencies and Disasters

Preliminary Software Requirements Specifications
2004-2005

Version: January 21, 2005

Document Purpose

The purpose of the software requirements specifications (SRS) document is to detail the functional and nonfunctional requirements of the HAvBED system. This document will be used as a guideline for the development of the system

1. Introduction

1.1. Purpose

HavBED (Hospital Available Beds for Emergencies and Disasters) is an information technology proof-of-concept project funded by AHRQ (The Agency for Healthcare Research and Quality). The purpose of the HAvBED project is to demonstrate a standardized "real-time" hospital bed and resource availability information system that can be used by decision makers, planners and emergency personnel at the local, State, regional and federal levels.

1.2. Intended Audience

This Software Requirements Specifications (SRS) document is written for the HAvBED software development team and AHRQ. This document will outline the detail of the HAvBED system as derived from several sources including: the HAvBED Advisory Board, the HAvBED Project Team, review of various medical resource tracking systems, the AHRQ Task Order: Health Care System Preparedness and Surge Capacity for Bioterrorism and Public Health Emergencies Requirements, and the HAvBED Technical and Cost Proposal.

1.3. Project Scope

The HAvBED demonstration system, when fully developed and implemented, will collect and display sample national hospital bed and resource availability information to be utilized for planning and response to a medical disaster. The information HAvBED will collect and display is considered highly confidential; security is a high priority.

HavBED will gather data via two mechanisms:

  1. A data interface which monitors and receives data from existing local, State and regional hospital status of reporting systems, which may require minor modifications to ensure standardization reporting.
  2. A Web-based data entry system allowing manual data entry for hospitals that do not participate in any other bed reporting system.

The HAvBED system will offer the ability to display levels of data from the national level to individual hospital information. The system will display data in two formats: a report format available for printing and a Geographic Information Systems (GIS) map display.

The HAvBED system is a 12-month information technology proof-of-concept project. The project development will run from October 2004-May 2005; the testing phase will begin early in development and end in May 2005. This will be an iterative IT development project due to time constraints. The final demonstration of the HAvBED system to the HAvBED Advisory Board will be in June 2005. The final report is due following completion of this task order. At that time, the HAvBED demonstration system will become the property of AHRQ.

1.4. References

Other HAvBED development documentation referenced in this document include the Use Cases, the Data Flow Diagram and the Wireframes.

Return to Contents

2. Overall Description

2.1. Product Perspective

The HAvBED system is a stand-alone demonstration that will be interfaced with three hospital resource data monitoring systems that have been developed for State, local and regional use and an internet-based product to provide and data entry for hospitals that do not participate in such data monitoring systems. The three hospital resource data monitoring systems, EMSystem®, HERDS and the Washington State system, will send relevant data to the HAvBED demonstration system for data storage and display. This national system is a new product; there is no knowledge of a previous development attempt of this type of system which interfaces with existing systems.

2.2. Product Features

The proposed major features of this product include:

  1. Display of timely, accurate and standardized bed availability data.
  2. A secure login assuring confidentiality of data.
  3. Displaying data in a report format with the ability to print.
  4. Displaying data in a map format (GIS), with the ability to print.
  5. Displaying data with the ability to drill-down (to federal, regional, State and local information) based upon predetermined access needs.
  6. Manual data entry for medical facilities to enter relevant data.
  7. Internet access to this system for data entry and display.
  8. Contact information for each participating medical facility across the nation.
  9. American Hospital Association (AHA) data accessibility.
  10. Forecasted surge bed capacity for facilities 24 and 72 hours in the future.

2.3. User Classes and Characteristics

The pathway the user will be allowed to take is determined at log-in, based upon the predetermined access permissions specified for that individual user. The user classes and characteristics are identified as follows:

1. Manual Data Entry (MDE) Pathway User

There are two types of MDE users:

  1. Hospital or medical facility personnel who are entering data into the Web-based HAvBED system because their hospital does not participate in one of the already interfacing systems.
  2. Hospital or medical facility personnel from an already interfacing system who are manually editing or adding data (such as surge capacity beds).

These users will have access to only their facility's data, both in the data display and data entry modes. When this user is finished viewing or entering data, the user will then log out and the system will return to the homepage.

Figure 1 shows this schematically.

2. Data Display (DD) Pathway User

There are many types of data display users based upon the permission level they are granted to view data in the HAvBED system. This user can be generally defined as medical emergency planners and responders at multiple levels including National, Regional, State, Metropolitan Area, and City. This user will be able to view the data in two formats: report or map; the system will open separate windows for viewing each format. The login provided to this user will only allow DD, not MDE. For purposes of this demonstration, display of data via this pathway will be predetermined by the user's level of display access and will be limited to National (including individual States) or State (multiple States may be allowed).

Figure 2 shows this schematically.

3. Administrative User

This class of user will be allowed to full access to the Manual Data Entry and Data Display pathways as well as being able to create/edit user and facility profiles.

Figure 3 displays the pathways available to the administrative user.

Note: Each user profile will contain user name, user pass code and level of access allowed. If access for that user is limited to a single facility, that facility identification number will also be in the profile. (Go to Section 3.6 below for further details.)

2.4. Operating Environment

The HAvBED system will use a Web server and a database server. The system will utilize the internet, allowing user accessibility from virtually any location within the nation.

For this project, the team ordered two PowerEdge 1850 Servers. These servers have:

  • Intel Xeon Processors at 2.8GHz/1 MB Cache.
  • 1GB DDR2 400MHz Memory.
  • 36GB, Ultra 320 SCSI Hard Drives.

The code, servers and databases will all be housed and maintained within the Denver Health IT department during the entire development process. Although this product will encompass some GIS maps, there are no other software or applications with which this system will need to collaborate within its physical operating environment, although the system will be configured across the Denver Health IT firewall.

HAvBED will interface with three other systems in order to receive data (one-way); those systems are located in New York, Milwaukee and Seattle.

2.5. Design and Implementation Constraints

  1. The most important constraint on the development process is the time limitation. This development will have a very quick turn-around. Development is slated to begin in October 2004 and end in June 2005, encompassing early testing during development. This will limit the product to the highest priority features, with recognition of some identified features as useful future functionality.
  2. The development of the project will use a SQL database, Webservices and eXtensible Markup Language (XML) as a data interchange format. The project team reviewed the HL7 format for use in this development, but identified problems utilizing HL7, mainly due to a lack of richness in specifying the type of data elements to be transmitted from the participating systems. The HL7 format could possibly be incorporated into future development of this product if additions are made to the types of data elements allowed.
  3. The project team investigated incorporating GIS software into this product. HAvBED is designed to utilize map-based information, and will most likely use static ESRI ARCInfo maps for this demonstration. The team originally reviewed ESRI ARC software products identifying ARCIMS as the software package most compatible functionally with the HAvBED system. However, at this point, the amount of .net coding and hardware and system support necessary to make the GIS display component internet compatible is felt to be prohibitive, making the use of truly dynamic mapping problematic. Unless future research identifies a more efficient way to incorporate GIS into HAvBED, static ARCInfo maps will be included in late development after HAvBED has received data from the partnering systems. These static maps will be programmed to be interactive for drill-down functionality for the final demonstration.

2.6. User Assistance/Help

HAvBED will have a user help component built into the system. Every screen available to the any level user will have a help function available providing an explanation of the screen and a "how to" explanation of the task the user is currently working with in HAvBED. For example, if a user is in the data entry screen, the Help function will display an explanation of the data entry process.

The user Help function will also describe the color-coding built into the data report screen.

The help function of HAvBED will also include contact information for the system administrator.

Another feature of the system will allow the user to mouse over column titles and have a pop-up window show the definitions. For example, mousing over a column named "Current Beds Available" will show the definition of that title for user clarification.

2.7. Assumptions and Dependencies

External factors that this project are dependent upon are the development of communication interfaces with the partnering systems. There are many factors involved in developing the interface including recognition of important data elements and a timeline for completion and ongoing communication with the partnering systems. These will all be important to the completion of the interfaces.

Return to Contents

3. System Features

3.1. User Login

The user will open the HAvBED homepage/login and enter a username and password, then press "enter" on the computer keyboard. Both the username and the password fields are open text, allowing a maximum 10 digit alphanumeric entry. The minimum entry for these fields is 5 alphanumeric digits. If the user enters a username and/or password with too many or too few characters, HAvBED will ask the user to re-enter the login. If the user tries to re-enter three times and is unsuccessful, HAvBED will ask the user to contact the HAvBED system administration for assistance (offering contact information).

User Permissions

When the login is successful and the user presses enter, the system will do a check to determine what level of access this user has, and if so, for what health facility. If this user is allowed manual data entry access, the system will take the user to the data display screen for the facility for which the user is allowed to enter data. If this user is allowed data display access (more than a single institution), the system will take the user to the Data Area Selection Display (go to 3.3, below).

3.2. Manual Data Entry (MDE)

3.MDE.1. Description and Priority

The manual data entry feature is a high priority for this system. It allows a user with appropriate permission to review and edit information for his/her institution in the HAvBED database.

3.MDE.2. Stimulus/Response Sequences

Upon entry to the MDE pathway, the user will be presented with the current HAvBED data for his facility as shown below. Note that the "24 hour beds" and "72 hour beds" may be made available for data entry and display based upon an option set by a system administrator. An example of these data for the user's institution are shown in Figure 4.

If "Edit" is selected on this page, the user will be taken to a similar display that will allow the updating of any of the data items.

Functionality of the data entry window includes:

  1. The "Current Beds Available" column is "softly" capped by the AHA bed data already in the HAvBED database. This is due to the fact that the facility may create additional surge beds, greater than the static AHA number for that category. If a user enters a number larger than the AHA bed number for that facility, HAvBED will show a warning message: "The number you have entered is greater than expected. Please confirm this number." The user will click "Confirm" or "Re-enter" on the message. "Confirm" will result in the system accepting the data. All of these fields should allow a null or zero entry without a resulting error message.
  2. The remarks field will have a fifty alphanumeric character limit. The remarks entered in this window will show in the Report detail window as a notation (or symbol) with each hospital bed type (under "Current Beds Available"). When the user mouses over this notation in the Report window, a pop-up window will show the remarks that were entered in the Data Entry window. These remarks will remain until the next manual data entry user removes them.
  3. After the data is entered, the user will press the "Submit" button on the window. These data will then be used to update the database, and replace the Data Entry window with Hospital Data Display window. This window allows the user to view the data that have just been updated.
  4. The print function in the Data Entry Feedback window will simply print what is displayed in the window. This print menu feature is not available in the Data Entry window (the functionality is not needed in this window).
  5. Mousing over the columns "Current Beds Available", "24hr Beds Available", and "72hr Beds Available" will show a pop-up definition of those terms. (All other terminology definition and explanation of window functionality will be listed in the 'Help' menu option.)

Alternative Care Facility ("Care Station") Data Entry

If the user is entering data for the Alternative Care Facility type of facility, the only fields available in the Facility Data Entry window are:

  1. Surge Beds Available (includes Current, 24 hr and 72hr beds).
  2. Current Beds Remarks.
  3. Decontamination Facility Availability.
  4. Ventilator Capable (Y/N).
  5. Ventilators Available.
  6. Ventilators In Use.

3.3. Data Report Display (DRD)

3.DRD.1. Description and Priority

The data report display window allows the user to view the data for whatever level of information the user chooses from the data display window, based upon the predetermined level of data access allowed for each specific user. This functionality is a high priority for this system, allowing the data for a nation, region, State, metro area, or hospital to be formatted in a report that can be printed.

3.DRD.2. Stimulus/Response Sequences

The user will open the homepage/login window, enter a username and password and press "Enter" on the keyboard. The system will run a check to determine what access this user has. When the system determines this user has access to only the data display process, the window is immediately changed to the Data Display window.

In this window, the user has the ability to choose the level of data from drop-down menus, based upon predetermined permissions. The menu offers:

  1. National
  2. Regional:
    1. FEMA/NDMS/PHS Federal Regions:
      1. Region I.
      2. Region II.
      3. Region III.
      4. Region IV.
      5. Region V.
      6. Region VI.
      7. Region VII.
      8. Region VIII.
      9. Region IX.
      10. Region X.
    2. CDC Federal Regions:
      1. New England.
      2. Mid-Atlantic.
      3. East North Central.
      4. West North Central.
      5. South Atlantic.
      6. East South Central.
      7. West South Central.
      8. Mountain.
      9. Pacific.
    3. East/West Regions:
      1. East.
      2. West.
  3. State:
    1. A listing of all fifty States in the U.S., including Washington D.C.
  4. County: [Future enhancement]
    1. A listing of AHA data hospitals by county (the State abbreviation will be included with the county name listing for clarification).
  5. Metro Area: [Future enhancement]
    1. Metropolitan Statistical Areas (from the AHA data).
  6. City:
    1. City listings from the AHA data.
  7. Hospital:
    1. Hospital name.
  8. Other:
    1. User-defined criteria (at this time zip code defined search)

Go to Appendix A for definitions of the menu options.


The data display will contain many layers of information from which to choose. The National, Regional and State menus are designed as a separate drop-down search from the County, Metro Area, City and Hospital menus.

The drop-down menu must highlight the choice the user makes, and when highlighted, the choice (eg Region) will open an appropriate sub-menu, allowing the user to make a desired selection (FEMA regions, CDC regions, etc) which, in turn will cause an additional sub-menu to open, displaying the types of regions. The user will then select the specific region and then select "Map" or "Text Report" to retrieve the desired data.

3.4. Report Text Display (RTD)

3.RTD.1. Description and Priority

The report window allows the user to view textual data by the level of display chosen in the Data Display window. This window will have several features allow the user to filter, print and define the data display.

3.RTD.2. Stimulus/Response Sequences

Once the user makes a choice in the Data Display window and presses "Report," the system opens a new window showing the user-defined data in a report format. The user will be able to see a summary first, followed by detailed information listing by hospital. The detailed information will be viewed by scrolling down in the window. This window will have three print options: print summary, print detail and print summary and detail. These options will be available to the user from a fly-over menu when the user presses the "Print" button. The fly-over menu will also highlight the choice the user makes with a mouse click, then immediately will disappear and begin the print job.

At this point, the user will have the ability to go back to the Data Display window and choose another user-defined data report opening a new window. The user will also have the ability to map this same user-defined data in the report window when the "Map Display" button is pressed in the report window. Using "Map Display" from the report window will open a new window.

When the user is done viewing the information in the report window, they can choose to click on the "Log-out" button. The HAvBED system will log the user out of that window and move that window back to the home page/log in; and time out of all other windows open.

The Report window will list "Current Beds Available", "Surge Beds Available" (two columns of "24 hours" and "72 hours"), "AHA Survey Beds", "Acute Care Facility Emergency Department Status" (Open or On Divert), "Decontamination Facility Availability" (Available or Unavailable) and "Hospitals with Ventilators" (Available or In Use).

The detail of the report (individual hospital listings) will include the number of patients waiting in the Emergency Department.

One important function in the detail of the report window is the ability to view by page 1,2,3,4,5,etc., listing twenty hospitals per page. The detail of the report window can list thousands of individual institutions and without this functionality, loading this page could bring down the system.

An important feature in this report is an asterisk symbol indicating that the actual number of available beds may be equal to or greater than the number shown (for all the current bed types, not including "Alternative Care Beds"). The detail of the report will indicate a ≥1 for bed numbers greater than one; otherwise zero will be listed. EMSystem®, under normal operating conditions, would not send any actual bed number for a category, only that the institution is not on divert for that category of bed (and thus, having one or more beds of this class available). Including this symbol after the bed number allows the user to see there is equal to or more than the number of beds available. During the test period, EMSystem® will activate a bed poll page for their users asking them to fill in actual bed numbers for the "Current Beds Available" by bed type listed in the HAvBED system. The user will be able to click on the help file to determine what the asterisk represents in the report.

The report window will have several features listed below by priority. These will be included as development time allows:

  1. The detail list will have contact information with each hospital and symbols to represent: NDMS:

Logo of the National Disaster Medical System (NDMS).

TRICARE:

Logo of the Tricare medical system.

or Alternative Care Site (Care Station):

Symbol for an Alternative Care Site (Care Station).

This information will default to the information from the AHA database, but will be updated with the information from the partnering systems. The following systems will be updating the contact information as needed:
  • Washington: hospital name, street address, city, zip code, area code, local telephone number, NDMS facility, TRICARE facility, county.
  • EMSystem®: hospital name, local telephone number.
  • HERDS: n/a.
The AHA data will contain: hospital name, name of chief administrator, street address, city, State two digit abbreviation, zip code, area code and local telephone number.
  1. The detail list will differentiate between Acute Care Facilities and Alternative Care Sites by using a symbol indicating an Alternative Care Site. The detail list will also use symbols to differentiate between NDMS and TRICARE facilities. HAvBED will use NDMS and TRICARE entities' symbols for this purpose.
  2. Color-coding in the display of the information. In the detail of the report window listed by hospital, the current beds vacant and the last update time information will have the font change to a blue color after 24 hours have passed without an update.
  3. The detail list will default to listing individual hospital information by alphabetized State, then alphabetized by hospital within the States. The detail list will also allow the user to order the information by hospital, city and State by clicking on the headers of these columns if this implementation detail is easily achievable.
  4. The ED divert status, ventilator availability and decontamination availability will be color coded both in the summary and detail area of the report page. The detail area will show the ED open status, decon available and ventilator available number will show the font as green. ED on divert, decon unavailable and ventilator in use will show the font as red. The summary area will show the text background (not font) as red or green to the corresponding information.
  5. The open date field will default to the current day, but allow the user to input a past date for historical data. For example, if the user puts in a historical date of 1/13/04, the system will display data up through that date (if easily achievable-this feature may be a future enhancement).
  6. The report window will also allow the user to open up a window showing the detail hospital information by clicking on the hospital name. In order to view the summary again, the user will be able to press a "Go back to summary" link that will appear in this detail window.
  7. The summary list will allow displaying information by State, Region, County, Metro Area or City within the level of information specified by the user in the Data Display window (based upon the user's allowed level of access).
    If the user is viewing National information, Regional and State options for data will be available. For Regions, State, Metro Area and County options will be available. For State, County,
  8. The detail list will allow the user to re-order the detail hospital data by the column headings: Hospital, County, City and State
3.RTD.3. Functional Requirements
  1. The system must be able to interpret the login as a data display level user and bring that user to the Data Display window.
  2. The HAvBED system must be able to present data by the level of viewing information chosen in the data display window.
  3. HAvBED must have the ability to print by summary, detail, and summary with detail in the report window.

3.5. Map Data Display (MDD)

3.MDD.1 Description and Priority

The map data display window allows the user to view bed availability data by geographic location. This function is a high priority within the HAvBED system. The HAvBED system will incorporate GIS functionality (through static GIS maps, as feasible) for this feature.

3.MDD.2. Stimulus/Response Sequences

After the user chooses the scope of data to view from the Data Display window, the user presses the "Map Display" button. The system will open a new window display a GIS map with the same scope of information (i.e. national, regional, etc.) the user had chosen in the Data Display window. From this point, the user is able to "drill-down" in the GIS maps to lower levels of information. For example, if the user chose Region VIII in the data display window, and the map display window appeared with a GIS map of Region VIII, then the user would be able to drill down by State, metro area, city and hospital.

  1. Through the map display window, the user will also be able to view the same level of information in the report window by pressing the "Report" button. This will open a new window with the same level of information, but in a report format (go to 3.3 RTD for report window functionality).
  2. The user will also be able to view the Report data through the Map Display window in a simple format. This Map Display window will have a "Data" button that will show a fly-over data summary by "Current Beds Available", "24 hr Beds Available", "72 hr Beds Available" and "AHA Survey Beds".
  3. The GIS map will have various symbols representing important information such as airports; hospitals and alternative care sites. These symbol options will include:
    1. The hospital symbols may be color-coded; green indicating the emergency department is available and red indicating the emergency department is on divert status.
    2. The symbols will also include the NDMS, TRICARE and alternative care facility symbols featured in the Report window.
    3. These symbols will be displayed in a symbol key located at the lower right side of the window. The user will be able to move this key with the mouse.

When finished, the user will log-out. HAvBED will go back to the home page/log in window, and time out of the other open windows.The GIS map component will be integrated in one of three ways:

  1. Static Maps:
    The map display button in HAvBED will link to .jpgs. This option will allow data fly-over from the Report window. This will also use static bed number pulls from the HAvBED database.
  2. Interactive Maps:
    The map display button in HAvBED will open the desktop ArcVIEW GIS software. This desktop software will allow user-defined graphs and regions for the summary data display. This option will use static bed number pulls from the HAvBED database.
  3. Server-based GIS and ArcIMS:
    This option is the most development-intensive, in terms of time constraint, programming, and expense. If achievable, this is the most desirable solution.
3.MDD.3. Functional Requirements
  1. The Map Data Display window will have a print option; HAvBED must be able to print out the GIS map.
  2. The Map Data Display window will have a "Data" button with a fly-over menu containing the same data as the report window-this data must be on the same level (national, regional, etc.) as the GIS map in the window.
  3. The system must be able to open a report window with the same level of data displayed in the map data display window.

3.6 Administrative Functions

Create Facility Option: Administrative users will have the ability to create new facilities in the database. HAvBED will allow two options: Hospital or Alternative Care Site (Care Station) facility creation. This window will have radio buttons for the user to choose between these types of facilities. It will also contain text fields for:

  1. Institution or Facility Name.
  2. Name of Chief Administrator (or Contact Person for Alternative Care Facilities).
  3. Street Address.
  4. City.
  5. State.
  6. Zip Code.
  7. Area Code.
  8. Local Telephone Number.
  9. County.
  10. AHA Hospital Identification Number (or ID number for Alternative Care Facility).
  11. Hospital (or Care Site) Latitude/Longitude.
  12. Metropolitan Statistical Area (MSA) Code.
  13. NDMS Participant (user will enter yes or no).
  14. TRICARE Participant (user will enter yes or no).

The required fields are the facility name, AHA number or ID number, complete address, chief administrator or contact person, and local telephone number. There will be a "Save" button at the bottom of this window.

Most of these types of information (except for TRICARE and NDMS participants) are already within the AHA data for facilities within the HAvBED database, and whatever information the user updates will change the defaulted AHA information.

User Profile Creation: Administrative users will be able to create and maintain user profiles. User profile data fields for this demonstrations system will include:

  1. User Name.
  2. User E-mail.
  3. User phone number.
  4. Facility code for which the user may enter data (AHA number).
  5. Level of data retrieval access allowed (National, State, None).
  6. If State level of data retrieval, which States that user may view.

Return to Contents
Proceed to Next Section

 

AHRQ Advancing Excellence in Health Care