Patient support apparatus system

Abstract

A system for monitoring compliance with desired operating parameters of patient support apparatuses in a healthcare facility includes a patient support apparatus and a server. The patient support apparatus forwards status data and occupancy data to the server indicating which state each of a plurality of components is currently in, and whether the patient is currently occupying the patient support apparatus. The server is adapted to receive admission data indicating whether the patient has been admitted or discharged from the healthcare facility, determine whether the patient support apparatus is in a use state, determine if a plurality of components are in their desired states, and determine an overall compliance value. The use state may be defined by the patient support apparatus being occupied, the patient being admitted, and a fall risk being assigned to the patient. The system may alternatively or additionally compute individual compliance values for the individual components.

Description

STR03 FP-718A PATIENT SUPPORT APPARATUS SYSTEM CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. provisional patent application serial number 63 / 739,217 filed December 27, 2024, by inventors Richard Mayoras et al. and entitled PATIENT SUPPORT APPARATUS SYSTEM, the complete disclosure of which is incorporated herein by reference.BACKGROUND

[0002] The present disclosure relates to patient support apparatuses, such as beds, cots, stretchers, recliners, or the like. More specifically, the present disclosure relates to a system for monitoring how the patient support apparatuses are used and determining whether such usage complies with a healthcare facility’s standards.

[0003] Patient support apparatuses are often used in healthcare facilities to support patients during their stay. Some healthcare facilities may expect their caregivers to use the patient support apparatuses in accordance with one or more standards while caring fortheir patients.SUMMARY

[0004] According to various versions, a system is provided that automatically monitors and records the compliance, or lack of compliance, of patient support apparatuses with one or more standards set by the healthcare facility. The system automatically determines compliance in a manner that excludes time periods that are not of interest to the healthcare facility, such as any one or more of the following: the patient support apparatus is not occupied, the patient has not been admitted to the healthcare facility (or has been discharged), the patient has not been assigned a fall risk classification, the patient support apparatus is not connected to the healthcare facility’s local area network, or a caregiver is present in the same room as the patient support apparatus. The system, in some versions, may keep track of not only the individual compliance of specific components of the patient support apparatuses with the desired standards, but may also determine an overall compliance level of the patient support apparatus with the desired standards. In some versions, the system may also determine combined compliance levels that are based on the compliance levels of multiple patient support apparatuses. The system allows a user to sort and filter compliance data according to a variety of different parameters, including, but not limited to, specific caregivers, specific locations, specific patient support apparatuses, specific times (including specific shifts), specific components, etc. In some versions, the system may automatically gather patient fall information from an Electronic Health Records (EHR) server, or other source, and correlate the fall information with the compliance data. These and other features and functions of the present disclosure will be apparent to one skilled in the art in light of the following written description and the attached drawings.

[0005] According to a first version of the present disclosure, a system for monitoring compliance is provided that includes a patient support apparatus and a server. The patient support apparatus includes aa support surface adapted to support a patient thereon, a plurality of components adapted to be changed to different states, and a controller. The controller is adapted to forward status data and occupancy data to the server. The status data indicates which state each of the plurality of components is currently in, and the occupancy data indicates whether the patient support apparatus is currently occupied by the patient or not. The server is adapted to perform the following: (i) receive the occupancy data and the status data from the patient support apparatus; (ii) receive admission data indicating whether the patient has been admitted or discharged from a healthcare facility; (iii) determine when the patient support apparatus is in a use state, the use state being defined by (a) the patient support apparatus being occupied by the patient; (b) the admission data indicating the patient is admitted to the healthcare facility; and (c) a fall risk classification being assigned to the patient; (iv) determine if each of the plurality of components is in a desired state while the patient support apparatus is in the use state; and (v) determine an overall compliance value for the patient support apparatus. The overall compliance value is based on how many of each of the plurality of components are in their desired state while the patient support apparatus is in the use state.

[0006] According to other aspects of the present disclosure, the server is adapted to receive first and second state data. The first state data identifies which of the different states of each of the plurality of components is the desired state when the fall risk classification is a high fall risk classification, and the second state data identifies which of the different states of each of the plurality of components is the desired state when the fall risk classification is a medium fall risk classification.

[0007] In some aspects, the server is adapted to determine the overall compliance value by determining an individual compliance value for each of the plurality of components.

[0008] The server, in some aspects, is adapted to determine the individual compliance value for each of the plurality of components by determining if an individual component of the plurality of components is in the desired state while the patient support apparatus is in the use state.

[0009] The server, in some aspects, is adapted to determine the individual compliance value without considering what state the individual component is in while the patient support apparatus is not in the use state.

[0010] In some aspects, the server is adapted to determine the overall compliance value by summing together each of the individual compliance values.

[0011] In some aspects, the plurality of components includes the following: a brake, a siderail, an exit detection system, and a litter frame.

[0012] The server, in some aspects, is adapted to determine a first individual compliance value for the exit detection system by determining if the exit detection system is in an armed or disarmed state, and todetermine a second individual compliance value for the exit detection system by determining if the exit detection system is armed at a first sensitivity level or a second sensitivity level.

[0013] In some aspects, the patient support apparatus includes a location transceiver adapted to wirelessly receive location information from a location beacon, and the controller is adapted to forward the location information to the server. The server is adapted to determine what room the patient support apparatus is currently located in using the location information.

[0014] In some aspects, the server is adapted to display a screen showing the overall compliance value of the patient support apparatus.

[0015] The server, in some aspects, is adapted to display a screen on which a user can select each one of the plurality of components, and the server is adapted to show the individual compliance value for whichever component is selected.

[0016] In some aspects, the server is adapted to repetitively determine the overall compliance value and store the repetitively determined overall compliance values in a first record.

[0017] The server, in some aspects, is adapted to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and to store the caregiver assignments in the first record.

[0018] In some aspects, the server is adapted to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, the server is adapted to determine a filtered overall compliance value of the patient support apparatus.

[0019] The filtered overall compliance value, in some aspects, only includes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and excludes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

[0020] In some aspects, the server is adapted to repetitively determine the individual compliance values and store the repetitively determined individual compliance values in a first record.

[0021] The server, in some aspects, is adapted to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and the server is adapted to store the caregiver assignments in the first record.

[0022] The server, in some aspects, is adapted to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, the server is adapted to determine filtered individual compliance values of the patient support apparatus.

[0023] The filtered individual compliance values, in some aspects, only include the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and exclude the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

[0024] The patient support apparatus, in some aspects, includes an exit detection system adapted to issue an alert when the exit detection system is armed and the patient exits the patient support apparatus. The controller is adapted to forward data indicating a response time to the server, and the server is adapted to use the response time in determining the overall compliance value.

[0025] The response time, in some aspects, is equal to an amount of time from an issuance of the alert by the exit detection system to a caregiver silencing the alert.

[0026] According to another aspect of the present disclosure, a software application embodied in a non-transitory computer readable medium is provided. The software application, when executed by a processor of a server, is adapted to instruct the server to perform the following: repetitively receive first status data from a patient support apparatus indicating a current state of a first component of the patient support apparatus; repetitively receive second status data from the patient support apparatus indicating a current state of a second component of the patient support apparatus; receive first user-defined data indicating a first desired state of the first component; receive second user-defined data indicating a second desired state of the second component; determine a first individual compliance value for the first component, the first individual compliance value indicating how often the first component is in the first desired state during a first time period; and determine a second individual compliance value for the second component, the second individual compliance value indicating how often the second component is in the second desired state during the first time period.

[0027] According to still other aspects of the present disclosure, the software application is adapted to instruct the server to determine an overall compliance value for the patient support apparatus. The overall compliance value is based on a combination of the first individual compliance value and the second individual compliance value.

[0028] In some aspects, the software application is adapted to instruct the server to exclude from the first time period any time in which any of the following are true: (a) the patient support apparatus is not occupied by a patient, (b) the patient is not admitted to a healthcare facility, and (c) the patient has not been assigned a fall risk classification.

[0029] In some aspects, the first user-defined data and the second user-defined data correspond to a first fall risk classification of a patient, and the software application is adapted to instruct the server to receive third user-defined data indicating a third desired state of the first component and fourth user-defined dataindicating a fourth desired state of the second component. The third and fourth user-defined data correspond to a second fall risk classification of the patient.

[0030] The software application, in some aspects, is adapted to instruct the server to determine whether the patient meets the first fall risk classification or the second fall risk classification, and if the patient meets the second fall risk classification to perform the following: (1) determine a third individual compliance value for the first component, the third individual compliance value indicating how often the first component is in the third desired state during a third time period; and (2) determine a fourth individual compliance value for the second component, the fourth individual compliance value indicating how often the second component is in the fourth desired state during the third time period.

[0031] In some aspects, the first component is one of a brake, a siderail, an exit detection system, or a litter frame of the patient support apparatus.

[0032] In some aspects, the first component is an exit detection system, the first desired state is an armed state, and the software application is adapted to instruct the server to perform the following: repetitively receive third status data from the patient support apparatus indicating a current sensitivity level of the exit detection system; receive third user-defined data indicating a desired sensitivity level of the exit detection system; and determine a sensitivity compliance value for the exit detection system, the sensitivity compliance value indicating how often the exit detection system is armed at the desired sensitivity level during the first time period.

[0033] In some aspects, the software application is adapted to instruct the server to determine an overall compliance value for the patient support apparatus, wherein the overall compliance value is based on a combination of the first individual compliance value, the second individual compliance value, and the sensitivity compliance value.

[0034] The software application, in some aspects, is adapted to instruct the server to receive location information from the patient support apparatus and to determine what room the patient support apparatus is currently located in using the location information.

[0035] The software application, in some aspects, is adapted to instruct the server to display a screen showing the overall compliance value of the patient support apparatus.

[0036] In some aspects, the software application is adapted to instruct the server to display a screen on which a user can select the first component or the second component, to show the first individual compliance value in response to the user selecting the first component, and to show the second individual compliance value in response to the user selecting the second component.

[0037] The software application, in some aspects, is adapted to instruct the server to allow a user to select the first time period.

[0038] In some aspects, the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to a patient at different times, and the server is adapted to store the caregiver assignments in a first record.

[0039] In some aspects, the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine a filtered overall compliance value of the patient support apparatus.

[0040] The filtered overall compliance value, in some aspects, is determined by excluding from the first time period any time during which the particular caregiver was not assigned to the patient.

[0041] In some aspects, the software application is adapted to instruct the server to repetitively determine the first and second individual compliance values and store the repetitively determined first and second individual compliance values in a first record.

[0042] The software application, in some aspects, is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to a patient at different times, and to store the caregiver assignments in the first record.

[0043] In some aspects, the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine filtered first individual compliance values and filtered second individual compliance values of the patient support apparatus.

[0044] The filtered individual compliance values, in some aspects, only include the repetitively determined first individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and exclude the repetitively determined first individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

[0045] In some aspects, the filtered second individual compliance values only include the repetitively determined second individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and exclude the repetitively determined second individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

[0046] In some aspects, the software application is adapted to instruct the server to determine a response time of a caregiver to an exit detection alert issued by the patient support apparatus. The response time is an amount of time from an issuance of the exit detection alert to the caregiver silencing the exit detection alert.

[0047] In some aspects, the software application is adapted to instruct the server to use the response time in determining the overall compliance value and / or in determining an individual compliance value.

[0048] The software application, in some aspects, is adapted to instruct the server to determine the overall compliance value for the patient support apparatus by weighting the first individual compliance value differently from the second individual compliance value.

[0049] In some aspects, the software application is adapted to instruct the server to allow a user to specify a first weighting value and a second weighting value, and to determine the overall compliance value by weighting the first individual compliance value with the first weighting value and by weighting the second individual compliance value with the second weighting value.

[0050] According to another aspect of the present disclosure, a system for monitoring compliance is provided. The system includes a plurality of patient support apparatuses and a server. Each of the plurality of patient support apparatuses includes a support surface adapted to support a patient thereon, a plurality of components adapted to be changed to different states, and a controller adapted to forward status data to the server. The status data indicates which state each of the plurality of components is currently in. The server is adapted to perform the following: (i) receive the status data from the plurality of patient support apparatuses; (ii) determine desired states for each of the components of each of the plurality of patient support apparatuses; (iii) determine a first set of overall compliance values for each of the patient support apparatuses, wherein each overall compliance value in the first set of overall compliance values is based on how often the plurality of components of an individual patient support apparatus of the plurality of patient support apparatuses are in desired states; (iv) receive a filtering selection from a user of the server, the filtering selection defining a subset of the first set of overall compliance values; (v) determine a second set of filtered overall compliance values by removing the subset from the first set of overall compliance values; and (vi) display the second set of filtered overall compliance values.

[0051] According to still other aspects of the present disclosure, the filtering selection defines at least one of the following: a particular location within a healthcare facility, a particular time period, a particular healthcare facility, a particular patient fall risk classification, or a particular caregiver.

[0052] In some aspects, the server is adapted to display the second set of filtered overall compliance values in a graphical form.

[0053] In some aspects, the graphical form includes a graph having an X-axis corresponding to time and a Y-axis corresponding to the filtered overall compliance values.

[0054] The controller of each patient support apparatus, in some aspects, is adapted to forward occupancy data to the server. The occupancy data indicates whether each patient support apparatus of the plurality of patient support apparatuses is currently occupied by a patient or not. The server may be adapted to receive the occupancy data from the plurality of patient support apparatuses, and exclude from thedetermination of the first set of overall compliance values time periods during which respective ones of the patient support apparatuses are not occupied.

[0055] In some aspects, the server is adapted to receive admission data from a second server. The admission data indicates whether patients have been admitted to a healthcare facility. The server is adapted to exclude from the determination of the first set of overall compliance values time periods during which respective patients of the plurality of patient support apparatuses are not admitted to the healthcare facility.

[0056] In some aspects, the server is adapted to communicate with the plurality of patient support apparatuses via a network connection, and to exclude from the determination of the first set of overall compliance values time periods during which the network connection of respective patient support apparatuses of the plurality of patient support apparatuses is broken.

[0057] The plurality of components, in some aspects, includes a brake, a litter frame, one or more siderails, one or more lifts for controlling a height of the litter frame, a head of bed angle, and an exit detection system.

[0058] The server, in some aspects, is adapted to determine a combined compliance value. The combined compliance value is generated by combining together multiple overall compliance values from a group of the patient support apparatuses.

[0059] In some aspects, the group of multiple patient support apparatuses are selectable by a user.

[0060] The server, in some aspects, is adapted to present the user with at least one of the following groups of multiple patient support apparatuses to select from: (a) a first group of patient support apparatuses at a particular location within a healthcare facility; (b) a second group of patient support apparatuses assigned to patients having a particular fall risk classification; (c) a third group of patient support apparatuses having patients assigned to a particular caregiver; or (d) a fourth group of patient support apparatuses located at a particular healthcare facility.

[0061] According to another aspect of the present disclosure, a software application embodied in a non-transitory computer readable medium is provided. The software application, when executed by a processor of a server, is adapted to instruct the server to perform the following: receive status data from a plurality of patient support apparatuses; determine desired states for each of a plurality of components of each of the plurality of patient support apparatuses; determine a first set of overall compliance values for each of the patient support apparatuses, wherein each overall compliance value in the first set of overall compliance values is based on how often the plurality of components of an individual patient support apparatus of the plurality of patient support apparatuses are in desired states; receive a filtering selection from a user of the server, the filtering selection defining a subset of the first set of overall compliance values; determine a second set offiltered overall compliance values by removing the subset from the first set of overall compliance values; and display the second set of filtered overall compliance values.

[0062] According to other aspects of the present disclosure, the filtering selection defines at least one of the following: a particular location within a healthcare facility, a particular time period, a particular healthcare facility, a particular patient fall risk classification, or a particular caregiver.

[0063] In some aspects, the software application is adapted to instruct the server to display the second set of filtered overall compliance values in a graphical form.

[0064] The graphical form, in some aspects, includes a graph having an X-axis corresponding to time and a Y-axis corresponding to the filtered overall compliance values.

[0065] In some aspects, the software application is adapted to instruct the server to receive occupancy data from each of the patient support apparatuses in the plurality of patient support apparatuses, the occupancy data indicating whether each respective patient support apparatus is currently occupied by a patient or not; and to exclude from the determination of the first set of overall compliance values time periods during which respective ones of the patient support apparatuses are not occupied.

[0066] In some aspects, the software application is adapted to instruct the server to receive admission data from a second server, the admission data indicating whether patients have been admitted to a healthcare facility; and to exclude from the determination of the first set of overall compliance values time periods during which respective patients of the plurality of patient support apparatuses are not admitted to the healthcare facility.

[0067] In some aspects, the software application is adapted to instruct the server to exclude from the determination of the first set of overall compliance values time periods during which a network connection of respective patient support apparatuses of the plurality of patient support apparatuses is broken.

[0068] The plurality of components, in some aspects, includes a brake, a siderail, an exit detection system, and a litter frame.

[0069] The software application, in some aspects, is adapted to instruct the server to determine a combined compliance value. The combined compliance value is generated by combining together multiple overall compliance values from a group of the patient support apparatuses.

[0070] In some aspects, the software application is adapted to instruct the server to allow a user to select the group of multiple patient support apparatuses.

[0071] The software application, in some aspects, is adapted to instruct the server to present the user with at least one of the following groups of multiple patient support apparatuses to select from: (a) a first group of patient support apparatuses at a particular location within a healthcare facility; (b) a second group of patient support apparatuses assigned to patients having a particular fall risk classification; (c) a third group of patientsupport apparatuses having patients assigned to a particular caregiver; or (d) a fourth group of patient support apparatuses located at a particular healthcare facility.

[0072] According to still another aspect of the present disclosure, a software application is provided that is embodied in a non-transitory computer readable medium. The software application is adapted, when executed by a processor of a server, to instruct the server to perform the following: receive occupancy data from a patient support apparatus, the occupancy data indicating whether the patient support apparatus is currently occupied by a patient or not; receive status data from the patient support apparatus, the status data indicating which state each of a plurality of components of the patient support apparatus is currently in; receive admission data indicating whether the patient has been admitted or discharged from a healthcare facility; determine when the patient support apparatus is in a use state, the use state being defined by (a) the patient support apparatus being occupied by the patient; (b) the admission data indicating the patient is admitted to the healthcare facility; and (c) a fall risk classification being assigned to the patient; determine if each of the plurality of components is in a desired state while the patient support apparatus is in the use state; and determine an overall compliance value for the patient support apparatus. The overall compliance value is based on how many of each of the plurality of components are in their desired state while the patient support apparatus is in the use state.

[0073] According to other aspects of the present disclosure, the software application is adapted to instruct the server to receive first and second state data. The first state data identifies which state of each of the plurality of components is the desired state when the fall risk classification is a high fall risk classification, and the second state data identifies which state of each of the plurality of components is the desired state when the fall risk classification is a medium fall risk classification.

[0074] The software application, in some aspects, is adapted to instruct the server to determine the overall compliance value by determining an individual compliance value for each of the plurality of components.

[0075] In some aspects, the software application is adapted to instruct the server to determine the individual compliance value for each of the plurality of components by determining if an individual component of the plurality of components is in the desired state while the patient support apparatus is in the use state.

[0076] In some aspects, the software application is adapted to instruct the server to determine the individual compliance value without considering what state the individual component is in while the patient support apparatus is not in the use state.

[0077] The software application, in some aspects, is adapted to instruct the server to determine the overall compliance value by summing together each of the individual compliance values.

[0078] In some aspects, the plurality of components includes a brake, a siderail, an exit detection system, and a litter frame.

[0079] The software application, in some aspects, is adapted to instruct the server to determine a first individual compliance value for the exit detection system by determining if the exit detection system is in an armed or disarmed state, and to determine a second individual compliance value for the exit detection system by determining if the exit detection system is armed at a first sensitivity level or a second sensitivity level.

[0080] In some aspects, the software application is adapted to instruct the server to receive location information from the patient support apparatus and determine what room the patient support apparatus is currently located in using the location information.

[0081] The software application, in some aspects, is adapted to instruct the server to display a screen showing the overall compliance value of the patient support apparatus.

[0082] In some aspects, the software application is adapted to instruct the server to display a screen on which a user can select each one of the plurality of components, and the server is adapted to show the individual compliance value for whichever component is selected.

[0083] The software application, in some aspects, is adapted to instruct the server to repetitively determine the overall compliance value and store the repetitively determined overall compliance values in a first record.

[0084] In some aspects, the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and to store the caregiver assignments in the first record.

[0085] In some aspects, the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine a filtered overall compliance value of the patient support apparatus.

[0086] The filtered overall compliance value, in some aspects, only includes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and excludes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

[0087] In some aspects, the software application is adapted to instruct the server to repetitively determine the individual compliance values and store the repetitively determined individual compliance values in a first record.

[0088] In some aspects, the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and to store the caregiver assignments in the first record.

[0089] In some aspects, the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine filtered individual compliance values of the patient support apparatus.

[0090] In some aspects, the software application is adapted to instruct the server to only include the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and to exclude the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

[0091] In some aspects, the software application is adapted to instruct the server to receive a response time from the patient support apparatus and to use the response time in determining the overall compliance value. The response time measures an amount of time from an issuance of an exit alert by an exit detection system to a caregiver silencing the exit alert.

[0092] Before the various versions disclosed herein are explained in detail, it is to be understood that the claims are not to be limited to the details of operation or to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The versions described herein are capable of being practiced or being carried out in alternative ways not expressly disclosed herein. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. The use of "including" and "comprising" and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. Further, enumeration may be used in the description of various versions. Unless otherwise expressly stated, the use of enumeration should not be construed as limiting the claims to any specific order or number of components. Nor should the use of enumeration be construed as excluding from the scope of the claims any additional steps or components that might be combined with or into the enumerated steps or components.BRIEF DESCRIPTION OF THE DRAWINGS

[0093] FIG. 1 is a perspective view of a patient support apparatus incorporating various aspects of the present disclosure;

[0094] FIG. 2 is a plan view of a caregiver control panel of the patient support apparatus;

[0095] FIG. 3 is a block diagram of a compliance system for monitoring the compliance of patient support apparatuses to one or more healthcare facility standards;

[0096] FIG. 4 is a block diagram of the system of FIG. 3 showing additional details of several servers that may communicatively interact with the compliance system;

[0097] FIG. 5 is an example of a screen shown by the compliance system in response to a user electing to display brake compliance values;

[0098] FIG. 6 is an example of a screen shown by the compliance system in response to a user electing to litter height compliance values;

[0099] FIG. 7 is an example of a screen shown by the compliance system in response to a user electing to display siderail compliance values;

[0100] FIG. 8 is an example of a screen shown by the compliance system in response to a user electing to display siderail compliance values;

[0101] FIG. 9 is an example of a screen shown by the compliance system in response to a user electing to display overall compliance values;

[0102] FIG. 10 is an example of a screen shown by the compliance system in response to a user electing to display overall compliance values and fall risk details for a plurality of healthcare facilities;

[0103] FIG. 11 is an example of a screen shown by the compliance system in response to a user electing to display first and second overall compliance values for a plurality of healthcare facilities;

[0104] FIG. 12 is an example of a screen shown by the compliance system in response to a user electing to display overall compliance values and alarm response times for a plurality of healthcare facilities; and

[0105] FIG. 13 is an example of a screen shown by the compliance system in response to a user electing to display exit detection sensitivity compliance values and fall risk details for a plurality of healthcare facilities.DETAILED DESCRIPTION

[0106] An illustrative patient support apparatus 20 usable in a compliance system 150 of the present disclose is shown in FIG. 1. Although the particular form of patient support apparatus 20 illustrated in FIG. 1 is a bed adapted for use in a hospital or other medical setting, it will be understood that patient support apparatus 20 could, in different versions, be a cot, a stretcher, a recliner, or any other structure capable of supporting a patient while the patient is in a healthcare facility, such as, but not limited to, a hospital and / or a mental health facility. For purposes of the following written description, patient support apparatus 20 will be primarily described as a bed with the understanding that the following written description applies to these other types of patient support apparatuses.

[0107] In general, patient support apparatus 20 includes a base 22 having a plurality of wheels 24, a lift subsystem comprising a pair of lifts 26 supported on the base, a litter frame 28 supported on the lifts 26, and a support deck 30 supported on the litter frame 28. Patient support apparatus 20 further includes a headboard 32, a footboard 34, and a plurality of siderails 36. Siderails 36 are all shown in a raised position in FIG. 1 but are each individually movable to a lower position in which ingress into, and egress out of, patient supportapparatus 20 is not obstructed by the lowered siderails 36. In some versions, siderails 36 may be moved to one or more intermediate positions as well.

[0108] Lifts 26 are configured to raise and lower litter frame 28 with respect to base 22. Lifts 26 may be hydraulic actuators, electric actuators, or any other suitable device for raising and lowering litter frame 28 with respect to base 22. The lifts 26 may be constructed and / or operated in any of the manners disclosed in commonly assigned U.S. patent publication 2017 / 0246065, filed on February 22, 2017, entitled LIFT ASSEMBLY FOR PATIENT SUPPORT APPARATUS, the complete disclosure of which is hereby incorporated herein by reference. Other manners for constructing and / or operating lifts 26 may, of course, be used.

[0109] In the illustrated version, lifts 26 are operable independently so that the tilting of litter frame 28 with respect to base 22 can also be adjusted. That is, litter frame 28 includes a head end 38 and a foot end 40, each of whose height can be independently adjusted by the nearest lift 26. Patient support apparatus 20 is designed so that when an occupant lies thereon, his or her head will be positioned adjacent the head end 38 and his or her feet will be positioned adjacent the foot end 40. By independently controlling lifts 26, litter frame 28 can be moved to a Trendelenburg position (in which head end 38 is lower than foot end 40) and / or a reverse Trendelenburg position (in which head end 38 is higher than foot end 40).

[0110] Litter frame 28 provides a structure for supporting support deck 30, the headboard 32, footboard 34, and siderails 36. Support deck 30 provides a support surface for a mattress 42, or other soft cushion, so that a person may lie and / or sit thereon. Support deck 30 is made of a plurality of sections, some of which are pivotable about generally horizontal pivot axes. In the version shown in FIG. 1, support deck 30 includes at least a head section 44, a seat section 46, and a foot section 48, all of which are positioned underneath mattress 42 and which generally form flat surfaces for supporting mattress 42. Support deck 30 may include fewer or greater numbers of these sections in different versions. Head section 44, which is also sometimes referred to as a Fowler section, is pivotable about a generally horizontal pivot axis between a generally horizontal orientation (not shown in FIG. 1 ) and a plurality of raised positions (one of which is shown in FIG. 1). Seat section 46 and foot section 48 may also be pivotable about generally horizontal pivot axes.

[0111] It will be understood by those skilled in the art that patient support apparatus 20 can be designed with other types of mechanical constructions, such as, but not limited to, that described in commonly assigned, U.S. Patent No. 10,130,536 to Roussy et al., entitled PATIENT SUPPORT USABLE WITH BARIATRIC PATIENTS, the complete disclosure of which is incorporated herein by reference. In other versions, the mechanical construction of patient support apparatus 20 may be the same as, or nearly the same as, the mechanical construction of the Model 3002 S3 bed manufactured and sold by Stryker Corporation of Kalamazoo, Michigan. This mechanical construction is described in greater detail in the Stryker Maintenance Manual for the MedSurg Bed, Model 3002 S3, published in 2010 by Stryker Corporation of Kalamazoo,Michigan, the complete disclosure of which is incorporated herein by reference. It will be understood by those skilled in the art that patient support apparatus 20 can be designed with still other types of mechanical constructions, such as, but not limited to, those described in commonly assigned, U.S. Pat. No. 7,690,059 issued to Lemire et al., and entitled HOSPITAL BED; and / or commonly assigned U.S. Pat. publication No. 2007 / 0163045 filed by Becker et al. and entitled PATIENT HANDLING DEVICE INCLUDING LOCAL STATUS INDICATION, ONE-TOUCH FOWLER ANGLE ADJUSTMENT, AND POWER-ON ALARM CONFIGURATION, the complete disclosures of both of which are also hereby incorporated herein by reference. The mechanical construction of patient support apparatus 20 may also take on still other forms different from what is disclosed in the aforementioned references.

[0112] Patient support apparatus 20 further includes a plurality of control panels 54 that enable a user of patient support apparatus 20, such as a patient and / or an associated caregiver, to control one or more aspects of patient support apparatus 20. In the version shown in FIG. 1 , patient support apparatus 20 includes a footboard control panel 54a, a pair of outer siderail control panels 54b (only one of which is visible), and a pair of inner siderail control panels 54c (only one of which is visible). Footboard control panel 54a and outer siderail control panels 54b are intended to be used by caregivers, or other authorized personnel, while inner siderail control panels 54c are intended to be used by the patient associated with patient support apparatus 20. Each of the control panels 54 includes a plurality of controls 50 (see, e.g. FIGS. 2-3), although each control panel 54 does not necessarily include the same controls and / or functionality.

[0113] Among other functions, controls 50 of control panel 54a allow a user to control one or more of the following: change a height of litter frame 18, raise or lower head section 44, activate and deactivate a brake for wheels 24, arm and disarm an exit detection system 140 (FIG. 3), select a sensitivity level for the exit detection system 140, arm and disarm a multi-component monitoring system 142, configure what components are to be monitored by the multi-component monitoring system 142, communicate with the particular IT infrastructure installed in the healthcare facility in which patient support apparatus 20 is positioned, and perform still other functions, some of which are described in greater detail below. One or both of the inner siderail control panels 54c also include at least one nurse-call control that enables a patient to call a remotely located nurse (or other caregiver). In addition to the nurse-call control, one or both of the inner siderail control panels 54c may also include one or more controls for controlling one or more features of a television, room light, and / or reading light positioned within the same room as the patient support apparatus 20.

[0114] Control panel 54a includes a display 52 (FIG. 2) configured to display a plurality of different screens thereon. Display 52 may be a touchscreen-type display, although it will be understood that a nontouchscreen display may alternatively be used. Display 52 displays one or more visual indicators, one or morecontrols, and / or one or more control screens, and / or other types of information, as will be discussed more below. Display 52 may comprise an LED display, an OLED display, or another type of display.

[0115] Surrounding display 52 are a plurality of navigation controls 50a-f that, when activated, cause the display 52 to display different screens on display 52. For example, when a user presses navigation control 50a, control panel 54a displays an exit detection control screen on display 52 that includes one or more icons that, when touched, control an onboard exit detection system 140. The exit detection system 140 is adapted to be armed and disarmed by a caregiver. When armed, exit detection system 140 issues an exit alert when a patient exits from patient support apparatus 20. When disarmed, exit detection system 140 does not monitor the patient’s movement and therefore does not issue an exit alert when the patient exits. Some exit detection systems 140 may also have different sensitivity levels that can be selected by a caregiver. The sensitivity level refers to how far the patient has to move toward exiting the patient support apparatus 20 before the exit alert is issued. A high sensitivity level will trigger an exit alert with only an initial movement toward exiting the patient support apparatus 20, while a low sensitivity level may not trigger an exit alert until the patient is fully out of, or nearly fully out of, patient support apparatus 20.

[0116] As will be discussed in greater detail below, some healthcare facilities have rules about when exit detection system 140 is to be armed. Such rules may be specified according to a fall risk classification of the patient assigned to patient support apparatus 20. In other words, if a patient is deemed a high fall risk, the healthcare facility may require that the exit detection system 140 is always armed. Further, some healthcare facilities may have rules specifying what sensitivity level exit detection system 140 should be set at, and in what situations. As will be discussed in greater detail below, compliance system 150 may be implemented to keep track of the caregivers’ usage of exit detection system 140 and determine whether its usage (including what sensitivity level is being used), or lack of usage, is in compliance with the healthcare facility’s rules. Exit detection system 140, in some versions, may include any of the same features and / or functions as, and / or may be constructed in any of the same manners as, the exit detection systems disclosed in commonly assigned U.S. patent application 62 / 889,254 filed August 20, 2019, by inventors Sujay Sukumaran et al. and entitled PERSON SUPPORT APPARATUS WITH ADJUSTABLE EXIT DETECTION ZONES; U.S. patent application serial number 17 / 318,476 filed May 12, 2021, by inventors Sujay Sukumaran et al. and entitled PATIENT SUPPORT APPARATUS WITH AUTOMATIC EXIT DETECTION MODES OF OPERATION; and / or the exit detection system disclosed in commonly assigned U.S. patent 5,276,432 issued to Travis and entitled PATIENT EXIT DETECTION MECHANISM FOR HOSPITAL BED, the complete disclosures of all of which are incorporated herein by reference.

[0117] When a user presses navigation control 50b (FIG. 2), control panel 54a displays a monitoring control screen that includes a plurality of control icons that, when touched, control an onboard multi-componentmonitoring system that monitors a plurality of components of patient support apparatus 20. The multicomponent monitoring system is customizable by a caregiver so that the caregiver can select which components are to be monitored, and which ones are not to be monitored. When the caregiver selects a given component to monitor, the caregiver may also be able to select what state the component is desirably in. The monitoring system is then adapted to issue an alarm if any of the monitored components are not in their respective desired states. If all of the components are in their respective desired states, then the monitoring system 142 does not issue any alarms (and, in some versions, may illuminate one or more green lights on the patient support apparatus 20). Monitoring system 142 is adapted to be armed and disarmed. When armed, it monitors the user-selected components to see if they are in their desired states and, if not, it issues an alarm. When disarmed, monitoring system 142 does not monitor the states of any components. As will be discussed in greater detail below, some healthcare facilities have rules about when monitoring system 142 is to be armed. Still further, some healthcare facilities may have rules about which specific components of the patient support apparatus 20 are to be monitored by monitoring system 142. As will be discussed in greater detail below, compliance system 150 may be implemented to keep track of the usage of monitoring system 142 and determine whether its usage (including which specific components are being monitored), or lack of usage, is in compliance with the healthcare facility’s rules. Further details of one type of monitoring system 142 that may be built into patient support apparatus 20 are disclosed in commonly assigned U.S. patent application serial number 62 / 864,638 filed June 21, 2019, by inventors Kurosh Nahavandi et al. and entitled PATIENT SUPPORT APPARATUS WITH CAREGIVER REMINDERS, as well as commonly assigned U.S. patent application serial number 16 / 721,133 filed December 19, 2019, by inventors Kurosh Nahavandi et al. and entitled PATIENT SUPPORT APPARATUSES WITH MOTION CUSTOMIZATION, the complete disclosures of both of which are incorporated herein by reference. Other types of monitoring systems may be included within patient support apparatus 20 for monitoring parameters of the patient support apparatus 20.

[0118] When a user presses navigation control 50c (FIG. 2), control panel 54a displays a scale control screen that includes a plurality of control icons that, when touched, control a scale system 144 of patient support apparatus 20. Scale system 144 is adapted to detect how much weight is being supported on litter frame 28. Scale system 144 may include a taring function, and / or an equipment log function, which allows a user to distinguish the patient’s weight from the weight of other objects on patient support apparatus 20. Some healthcare facilities have rules about how often a patient’s weight is to be taken, how often scale system 144 is to be zeroed, and / or other rules about how scale system 144 is to be used. As will be discussed in greater detail below, compliance system 150 may be implemented to keep track of the usage of scale system 144 and determine whether its usage, or lack of usage, is in compliance with the healthcare facility’s rules.

[0119] Scale system 144 may take on a variety of different forms and include a variety of different features and functions. In some versions, the scale system may include any of the same features, components, and / or and functions as the scale systems disclosed in the following commonly assigned patent references: U.S. patent application serial number 62 / 889,254 filed August 20, 2019, by inventors Sujay Sukumaran etal. and entitled PERSON SUPPORT APPARATUS WITH ADJUSTABLE EXIT DETECTION ZONES; U.S. patent application serial number 63 / 255,211 filed October 13, 2021 , by inventors Sujay Sukumaran etal. and entitled PATIENT SUPPORT APPARATUS WITH AUTOMATIC SCALE FUNCTIONALITY; U.S. patent 10,357,185 issued to Marko Kostic et al. on July 23, 2019, and entitled PERSON SUPPORT APPARATUSES WITH MOTION MONITORING; U.S. patent 11 ,33,233 issued to Michael Hayes et al. on June 15, 2021, and entitled PATIENT SUPPORT APPARATUS WITH PATIENT INFORMATION SENSORS; U.S. patent application 16 / 992,515 filed August 13, 2020, by inventors Kurosh Nahavandi et al. and entitled PATIENT SUPPORT APPARATUS WITH EQUIPMENT WEIGHT LOG; and U.S. patent application serial number 63 / 255,223, filed October 13, 2021, by inventors Sujay Sukumaran et al. and entitled PATIENT SUPPORT APPARATUS WITH PATIENT WEIGHT MONITORING, the complete disclosures of all of which are incorporated herein by reference. The scale system 144 may utilize the same force sensors that are utilized by the exit detection system, in some versions, or it may utilize one or more different sensors.

[0120] When a user presses navigation control 50d (FIG. 2), control panel 54a displays a motion control screen that includes a plurality of control icons that, when touched, control the movement of various components of patient support apparatus 20, such as, but not limited to, the height of litter frame 28 and the pivoting of head section 44. In some versions, patient support apparatus 20 may be configured to display a motion control screen in response to the user pressing control 50d that may be the same as, or similar to, the motion control screen 216 disclosed in commonly assigned U.S. patent application serial number 62 / 885,953 filed August 13, 2019, by inventors Kurosh Nahavandi et al. and entitled PATIENT SUPPORT APPARATUS WITH TOUCHSCREEN, the complete disclosure of which is incorporated herein by reference. Other types of motion control screens may be displayed on display 52 of patient support apparatus 20.

[0121] When a user presses navigation control 50e (FIG. 2), control panel 54a displays a motion lock control screen that includes a plurality of control icons that, when touched, control one or more motion lockout functions of patient support apparatus 20. Such motion lockout functions prevent the patient, or other unauthorized personnel, from using one or more of the controls on patient control panels 54c (and, in some cases, one or more of the controls on caregiver control panels 54a and / or 54b). The lockout controls of patient support apparatus 20 may include any of the features and functions as, and / or may be constructed in any of the same manners as, the motion lockout features, functions, and constructions disclosed in commonly assigned U.S. patent application serial number 16 / 721,133 filed December 19, 2019, by inventors Kurosh Nahavandi etal. and entitled PATIENT SUPPORT APPARATUSES WITH MOTION CUSTOMIZATION, the complete disclosure of which is incorporated herein by reference. Other types of motion lockouts may be included within patient support apparatus 20.

[0122] In general, pressing on navigation control 50e brings the user to one or more screens that allow the caregiver to selectively disable and enable the functionality of one or more controls on the patient control panels 54c and / or the caregiver control panels 54b and / or 54a. Thus, if a caregiver does not want the patient to be able to move any portions of patient support apparatus 20, he or she may use control 50e to navigate to a lockout screen that enables the caregiver to disable those controls on control panels 54c (and / or 54b and / or 54a) that control movement of any portions of patient support apparatus 20. In some versions, the lockout screen(s) displayed in response to pressing control 50e provide the caregiver with the option for disabling any of the controls on control panels 54b and / or 54c, while in other versions, the lockout screens provide the caregiver with the option for disabling only a selected subset of the controls on control panels 54b and / or 54c (such as, but not limited to, the subset of motion controls).

[0123] Some healthcare facilities may have rules about when one or more lockout functions are to be activated, as well as which specific lockout functions are to be activated. As will be discussed in greater detail below, compliance system 150 may be implemented to keep track of the usage of these lockout functions and determine whether their usage (including which specific functions are locked out), or lack of usage, is in compliance with the healthcare facility’s rules.

[0124] When a user presses on navigation control 50f (FIG. 2), control panel 54a displays a menu screen that includes a plurality of menu icons that, when touched, bring up one or more additional screens for controlling and / or viewing one or more other aspects of patient support apparatus 20. Such other aspects include, but are not limited to, diagnostic and / or service information for patient support apparatus 20, mattress control and / or status information, configuration settings, audio settings, location information, and other settings and / or information. One example of a menu screen is the menu screen 100 disclosed in commonly assigned U.S. patent application serial number 62 / 885,953 filed August 13, 2019, by inventors Kurosh Nahavandi et al. and entitled PATIENT SUPPORT APPARATUS WITH TOUCHSCREEN, the complete disclosure of which is incorporated herein by reference. Other types of menus and / or settings may be included within patient support apparatus 20.

[0125] FIG. 3 illustrates a first version of a compliance system 150 according to the present disclosure. Compliance system 150 includes one or more patient support apparatuses 20 in communication with a patient support apparatus server 86 (or remote server 122). Patient support apparatus server 86 (and / or remote server 122) may be in communication with one or more other servers that are part of a healthcare facility local area network 56, such as an Electronic Medical Records server 136 and / or an Admission,Discharge, and Transfer (ADT) server 138. The patient support apparatus server 86, like all of the servers discussed herein, includes one or more conventional microprocessors. Patient support apparatus server 86 is adapted to execute a software application 110 that receives status data from one or more patient support apparatuses 20, receives data from one or more other servers, processes some or all of the received data, and determines compliance metrics for one or more of the patient support apparatuses 20. The compliance metrics may indicate an individual compliance level of maintaining a single component of a patient support apparatus 20 in a desired state, and / or the compliance metrics may indicate an overall compliance level of maintaining a plurality of components of a patient support apparatus 20 in their desired states, and / or the compliance metrics may indicate a combined compliance level of maintaining multiple patient support apparatuses in desired states. As will be discussed in greater detail below with respect to FIG. 4, software application 110 may communicate with a plurality of other servers on a local area network 56 of the healthcare facility and use those communications to obtain some of the information it needs to perform some of the compliance monitoring and assessment functions described herein.

[0126] FIG. 3 illustrates in greater detail some of the internal components of patient support apparatus 20. As shown therein, patient support apparatus 20 includes a controller 58, a brake 60, a brake sensor 62, a network transceiver 64, a plurality of lift sensors 66, a plurality of siderail sensors 68, a memory 70, a foot angle sensor 72, a caregiver proximity sensor 74, a Head of Bed (HoB) angle sensor 76, and a locator / nurse call interface 78. Patient support apparatus 20 further includes lifts 26, siderails 36, control panel 54a (as well as control panels 54b and 54c, which are not shown in FIG. 3), as well as still other components that are not shown in FIG. 3. Patient support apparatus 20 may be coupled to a conventional AC power outlet 106 (FIG. 4) by a conventional power cable 102. Alternatively, or additionally, patient support apparatus 20 may include one or more batteries for supplying power.

[0127] Exit detection system 140 (FIG. 3) may include a plurality offeree sensors, such as load cells (not shown), that detect the weight of a patient supported on support deck 30. Memory 70 may include a unique ID 82 that uniquely identifies that particular patient support apparatus 20 and distinguishes that particular patient support apparatus 20 from other patient support apparatuses 20. It will be understood by those skilled in the art that patient support apparatus 20 may be modified to include additional components not shown in FIG. 3, as well modified to include fewer components from what is shown in FIG. 3 (i.e. omit one or more of the components shown in FIG. 3), and / or a combination of both additional and fewer components.

[0128] Controller 58 (FIG. 3) is constructed of any electrical component, or group of electrical components, which is capable of carrying out the functions described herein. In many versions, controller 58 is a conventional microcontroller, or group of conventional microcontrollers, although not all such versions need include a microcontroller. In general, controller 58 includes any one or more microprocessors, fieldprogrammable gate arrays, systems on a chip, volatile or nonvolatile memory, discrete circuitry, and / or other hardware, software, or firmware that is capable of carrying out the functions described herein, as would be known to one of ordinary skill in the art. Such components can be physically configured in any suitable manner, such as by mounting them to one or more circuit boards, or arranging them in other manners, whether combined into a single unit or distributed across multiple units as part of an embedded network. When implemented to include an embedded network, the embedded network may include multiple nodes that communicate using one or more of the following: a Controller Area Network (CAN); a Local Interconnect Network (LIN); an l-squared-C serial communications bus; a serial peripheral interface (SPI) communications bus; any of RS-232, RS-422, and / or RS-485 communication interfaces; a LonWorks network, and / or an Ethernet. The instructions followed by controller 58 in carrying out the functions described herein, as well as the data necessary for carrying out these functions, are stored in an onboard memory 70, and / or in one or more other memories accessible to the one or more microprocessors, microcontrollers, or other programmable components of controller 58. Memory 70 also includes a unique identifier that uniquely identifies the particular patient support apparatus into which it is incorporated, such as, but not limited to, a serial number.

[0129] Brake 60 (FIG. 3) is adapted to be activated and deactivated by a user. When activated, brake 60 stops one or more of the wheels 24 of patient support apparatus 20 from rolling, thereby substantially preventing patient support apparatus 20 from moving. Brake 60 may be constructed in a variety of different conventional manners. In some versions, brake 60 may be activated mechanically in response to a user pressing on a pedal, or other mechanical device, while in other versions, brake 60 may be activated electrically in response to a user pressing on a button, or the like, on a control panel 54. In still other versions, brake 60 may be activated and deactivated both mechanically and electrically. Brake sensor 62 may be any conventional sensor whose outputs can be used to determine the state of brake 60.

[0130] Brake sensor 62 is adapted to detect whether brake 60 is currently activated or inactivated. Brake sensor 62 reports this information to controller 58 which, as will be discussed in greater detail below, forwards the current brake status (i.e. whether brake 60 is activated or deactivated) to patient support apparatus server 86 (and / or a remote server 122). Brake sensor 62 may be any conventional sensor for detecting the activation and deactivation of brake 60, including, but not limited to, a mechanical sensor, a magnetic sensor, a portion of software, a pressure sensor, etc. Patient support apparatus server 86 (and / or remote server 122) uses this brake state information to determine whether the usage of the brake is, or is not, in compliance with the healthcare facility’s standards, as will be discussed in greater detail below. In some versions, if monitoring system 142 is armed, controller 58 may also use this brake state information to issue an alert if the brake 60 is a component being monitored by monitoring system 142 and brake 60 is not in its desired state (e.g. inactivated).

[0131] Network transceiver 64 (FIG. 3) is, in at least one version, a Wi-Fi radio communication module configured to wirelessly communicate with wireless access points 112 of local area network 56. In such versions, network transceiver 64 may operate in accordance with any of the various IEEE 802.11 standards (e.g. 802.11b, 802.11 n, 802.11g, 802.11 ac, 802.11ah, etc.). In other versions, network transceiver 64 may include, either additionally or in lieu of the Wi-Fi radio and communication module, a wired port for connecting a network wire to patient support apparatus 20. In some such versions, the wired port accepts a category 5e cable (Cat-5e), a category 6 or 6a (Cat-6 or Cat-6a), a category 7 (Cat-7) cable, or some similar network cable, and transceiver 64 is an Ethernet transceiver. In still other versions, network transceiver 64 may be constructed to include the functionality of the communication modules 56 disclosed in commonly assigned U.S. patent application serial number 15 / 831 ,466 filed December 5, 2017, by inventor Michael Hayes et al. and entitled NETWORK COMMUNICATION FOR PATIENT SUPPORT APPARATUSES, the complete disclosure of which is incorporated herein by reference.

[0132] Regardless of the specific structure included with network transceiver 64, controller 58 is able to communicate with the local area network 56 (FIG. 3) of a healthcare facility in which the patient support apparatus is positioned. When network transceiver 64 is a wireless transceiver, it communicates with local area network 56 via one or more wireless access points 112. When network transceiver 64 is a wired transceiver, it communicates directly via a cable coupled between patient support apparatus 20 and a network outlet positioned within a room 80 of the healthcare facility in which patient support apparatus 20 is positioned. As will be discussed in greater detail below with respect to FIG. 4, local area network 56 includes a plurality of servers that are utilized for different purposes by the compliance system 150 disclosed herein, and patient support apparatus 20 communicates with one or more of those servers (e.g. patient support apparatus server 86) via transceiver 64 as part of the compliance system 150.

[0133] Lift sensors 66 (FIG. 3) are sensors that are adapted to detect how high or low each lift 26 is currently extended. Lift sensors 66 may be conventional sensors. In some versions, each lift 26 includes an internal actuator and that internal actuator may include a corresponding lift sensor 66 that detects a position and / or angle of its associated actuator and feeds the sensed position / angle to controller 58. Controller 58 may use the outputs from these lift sensors 66 as inputs into a closed-loop feedback system for controlling the motion of the actuators and the litter frame 28. Controller 58 also uses the outputs from the lift sensors 66 to determine the height of litter frame 28 above the floor. Still further, when the height of each lift is different, controller 58 may use the outputs from the lift sensors 66 to determine the tilt of litter frame 28. In some versions, lifts 26 and / or lift sensors 66 may be constructed in any of the same manners as disclosed in commonly assigned U.S. patent application serial number 15 / 449,277 filed March 3, 2017, by inventors Anish Paul et al. and entitled PATIENT SUPPORT APPARATUS WITH ACTUATOR FEEDBACK, the completedisclosure of which is incorporated herein by reference. In such versions, the lift sensors 66 may be constructed to include any of the encoders and / or switch sensors disclosed in the aforementioned ‘277 application. Lift sensors 66 may also, or alternatively, be any conventional sensor whose outputs can be used to determine the height and / or tilt angle of litter frame 28.

[0134] As will be discussed in more detail below, controller 58 may forward the height and / or tilt angle of litter frame 28 to patient support apparatus server 86. Patient support apparatus server 86 is adapted to determine whether the current height and / or tilt of litter frame 28 is, or is not, in compliance with the healthcare facility’s standards, as will be discussed in greater detail below. In some healthcare facilities, standards are set for limiting the height of litter frame 28 to less than a threshold in order to reduce the likelihood of a patient falling when getting out of patient support apparatus 20, and / or reducing the severity of any injury that might occur if a patient does fall while exiting patient support apparatus 20. When such height thresholds are met, the patient support apparatus 20 is sometimes referred to as being in “low height.” This “low height” may refer to litter frame 28 being at its lowest possible height, or it may refer to its height being at any height that is less than a defined threshold. In some versions, if monitoring system 142 is armed, controller 58 may also use this litter frame height information to issue an alert if litter frame 28 is a component being monitored by monitoring system 142 and litter frame 28 is not in its desired state (e.g. below a threshold height).

[0135] Siderails sensors 68 (FIG. 3) are adapted to detect when each siderail sensor 68 is in a raised or lowered position. That is, each siderail 36 includes a corresponding siderail sensor 68 that detects when that particular siderail 36 is in a raised position and when it is in a lowered position. Each siderail sensor 68 outputs a signal to controller 58 informing controller 58 of the current position (up / down) of its corresponding siderail 36. Controller 58, as will be discussed, forwards this information to patient support apparatus server 86, which determines whether the current position of each siderail 36 is, or is not, in compliance with the healthcare facility’s standards, as will be discussed in greater detail below. In some healthcare facilities, standards are set for the total number of siderails 36 that should be in their raised positioned, and / or which specific siderails 36 should be in their raised position. Compliance system 150 is configured to determine whether each of these standards is met. In some versions, if monitoring system 142 is armed, controller 58 may also use the current siderail positions to issue an alert if one or more siderails 36 are components being monitored by monitoring system 142 and any of the siderails 36 are not in their desired states (e.g. raised). Siderails sensors 68 may be any conventional sensor whose outputs can be used to determine the current position of a corresponding siderail 36.

[0136] Memory 70 may be a conventional non-volatile memory, such as, but not limited to, a hard drive, a flash memory, solid state memory, and / or other types of memory. Memory 70 includes, among other things, a unique ID 82 that uniquely identifies that particular patient support apparatus 20 and distinguishes thatparticular patient support apparatus 20 from other patient support apparatuses 20. Unique ID 82 may be transmitted by controller 58 in messages it sends to patient support apparatus server 86 and / or remote server 122, thereby informing the recipient server 86 and / or 122 of the particular patient support apparatus 20 that sent the message. Unique ID 82 may also be included with messages sent to a wall unit 84, as described below, thereby informing the particular wall unit 84 of the source of the message. In sum, the inclusion of unique ID 82 in the messages controller 58 transmits enables the recipient device to know which patient support apparatus 20 the message originated from.

[0137] Foot angle sensor 72 (FIG. 3) is adapted to detect an angle of foot section 48 of support deck 30 with respect to the ground. That is, foot angle sensor 72 is adapted to determine whether foot section 48 is currently in a flat (relative to ground) orientation, or if it is angled. Foot angle sensor 72 reports the foot angle it detects to controller 58. As will be discussed in more detail below, controller 58 may forward the foot angle of foot section 48 to patient support apparatus server 86. Patient support apparatus server 86 is adapted to determine whether the current foot angle is, or is not, in compliance with the healthcare facility’s standards, as will be discussed in greater detail below. In some versions, if monitoring system 142 is armed, controller 58 may also use the foot angle information to issue an alert if foot section 48 is a component being monitored by monitoring system 142 and foot section 48 not in its desired state (e.g. below a threshold angle, or at zero degrees). Foot angle sensor 72 may be any conventional sensor whose outputs can be used to determine the angle of foot section 48.

[0138] Caregiver proximity sensor 74 (FIG. 3) may be constructed in a variety of different manners. However constructed, caregiver proximity sensor 74 is adapted to detect when a caregiver is positioned in the same room as patient support apparatus 20, or within a threshold distance of patient support apparatus 20. In some versions, caregiver proximity sensor 74 may include one or more ultra-wideband (UWB) sensors that are adapted to range with (i.e. determine their distances from) a UWB sensor built into a caregiver’s badge 120 (FIG. 4) and / or mobile device. In other versions, caregiver proximity sensor 74 may include one or more RFID transceivers and / or Bluetooth transceivers that are adapted to determine the position of a caregiver’s badge 120, wherein the caregiver’s badge 120 includes a corresponding RFID transceiver and / or Bluetooth transceiver. In still other versions, caregiver proximity sensor 74 may include one or more cameras, or transceivers for communicating with one or more cameras, which are adapted to visually detect the presence of a caregiver within the room. When caregiver proximity sensor 74 is implemented as a UWB sensor, it may be constructed in accordance with, and / or include any of the functionalities of, the UWB transceivers 132 disclosed in commonly assigned PCT patent application serial number PCT / US2024 / 054540 filed November 5, 2024, by applicant Stryker Corporation and entitled PATIENT SUPPORT APPARATUS WITH ENVIRONMENTAL INTERACTION, the complete disclosure of which is incorporated herein by reference. In some versions, theproximity of a caregiver may also, or alternatively, be determined using a conventional Real Time Locating System (RTLS) that utilizes RFID tags worn by the caregivers, or other similar technology.

[0139] Caregiver proximity sensor 74 informs controller 58 when a caregiver is detected (and in some versions, when no caregiver is detected) within the vicinity of patient support apparatus 20 (e.g. within the same room 80). As will be discussed in greater detail below, controller 58 may forward status data to patient support apparatus server 86 informing server 86 of the presence of absence of a nearby caregiver. Compliance system 150 may use this information to determine whether patient support apparatus 20 is being used in compliance with one or more healthcare facility standards. For some healthcare facilities, the standards for the usage of patient support apparatus 20 may be relaxed or suspended while a caregiver is in the room. The relaxation and / or suspension of the standards may be due to the fact that the caregiver is in the process of changing the settings of patient support apparatus 20 and / or the caregiver is ensuring that the patient is safe (e.g. does not fall) regardless of the state of patient support apparatus 20.

[0140] Head of Bed (HoB) angle sensor 76 (FIG. 3) may be constructed in a variety of different manners. However constructed, HoB sensor 76 is adapted to detect an angular orientation of the head section 44 (aka the Fowler section) of patient support apparatus 20. HoB sensor 76 reports the head section 44 angle it detects to controller 58. As will be discussed in more detail below, controller 58 may forward the head section angle to patient support apparatus server 86. Patient support apparatus server 86 is adapted to determine whether the current HoB angle is, or is not, in compliance with the healthcare facility’s standards, as will be discussed in greater detail below. In some instances, the healthcare facility may require a minimum HoB angle in order to help prevent the patient from experiencing ventilator associated pneumonia. In some versions, if monitoring system 142 is armed, controller 58 may also use the HoB angle information to issue an alert if head section 44 is a component being monitored by monitoring system 142 and head section 44 is not in its desired state (e.g. below a threshold angle). HoB angle sensor 76 may be any conventional sensor whose outputs can be used to determine the angle of head section 44.

[0141] Locator / nurse call interface 78 (FIG. 3) may be a wired interface, a wireless interface, or both a wired and wireless interface. Locator / nurse call interface 78 is adapted to communicatively couple patient support apparatus 20 with a conventional nurse call system 88 and, in some instances, with a nearby wall unit 84 that may act as a location beacon. When implemented as a wired interface (not shown), a cable is connected at one end to interface 78 and at the other end to a conventional nurse call outlet 90 (FIG. 4). The outlet 90 is typically built into a wall of a hospital room 80 and is electrically coupled to a conventional nurse call system 88. In many versions, the nurse call outlet 90 is a 37 pin outlet that the cable couples to, thereby enabling patient support apparatus 20 to communicate directly with nurse call system 88. In some versions, interface 78 of patient support apparatus 20 is constructed in accordance with any of the cable interfaces 92disclosed in commonly assigned U.S. patent application serial number 15 / 945,437 filed April 4, 2018, by inventors Krishna Bhimavarapu et al. and entitled PATIENT SUPPORT APPARATUSES WITH RECONFIGURABLE COMMUNICATION, the complete disclosure of which is incorporated herein by reference.

[0142] In the version shown in FIG. 3, interface 78 is a wireless interface that is adapted to wirelessly communicate with the nurse call outlet 90, thereby eliminating the need for a caregiver to connect a cable to patient support apparatus 20 in order for the patient support apparatus 20 to be coupled to nurse call system 88. In some versions, nurse call interface 78 includes a radio module, such as the radio module 60 disclosed in commonly assigned U.S. patent application serial number 14 / 819,844 filed August 6, 2015, by inventors Krishna Bhimavarapu et al. and entitled PATIENT SUPPORT APPARATUSES WITH WIRELESS HEADWALL COMMUNICATION, the complete disclosure of which is incorporated herein by reference. In such versions, a wall unit 84 is included and coupled to the nurse call outlet 90 by way of a cable 92 (FIG. 4). Patient support apparatus 20 uses interface 78 to wirelessly communicate with wall unit 84, and wall unit 84 is coupled to outlet 90 via cable 92 (FIG. 4). Wall unit 84 acts a communication intermediary between patient support apparatus 20 and wall outlet 90. In some versions, wall unit 84 may include any one or more of the same structures and / or functions of the headwall module 38 disclosed in the aforementioned ‘844 application.

[0143] In some versions, interface 78 may also, or alternatively, perform any of the functions of the nurse call interfaces disclosed in commonly assigned U.S. patent application serial number 62 / 833,943 filed April 15, 2019, by inventors Alexander Bodurka et al. and entitled PATIENT SUPPORT APPARATUSES WITH NURSE CALL AUDIO MANAGEMENT, the complete disclosure of which is also incorporated herein by reference. Still other types of wireless communication between the patient support apparatus 20 and a nurse call outlet 90 may be implemented.

[0144] In the illustrated version, interface 78 (FIG. 3) also includes a location receiver that is adapted to detect a wireless signal emitted from a nearby location transceiver 94 incorporated into wall unit 84. Wall unit 84 is positioned at a fixed and known location within the healthcare facility. Although FIG. 3 only illustrates a single one of these wall units 84, it will be understood that a particular healthcare facility includes many of these wall units 84 mounted throughout the healthcare facility. Each location transceiver 94 may be a wireless short range transmitter that broadcasts a wireless, short range signal containing a unique identifier. The short range signal, in some versions, is broadcast via infrared communication and is only detectable by a receiver (e.g. a receiver built into interface 78) when that receiver is positioned within several meters of the location transceiver 94. Consequently, the location receiver is only able to detect the signals from a location transceiver 94 when patient support apparatuses 20 is positioned adjacent (e.g. within several meters) of one of these location transceivers 94 of a wall unit 84. If / when a location receiver of interface 78 is able to detect the unique signal from a particular location transceiver 94, the corresponding patient support apparatus 20 can thereforeconclude that it is currently positioned adjacent that particular location transceiver 94. This allows the current location of the patient support apparatus 20 to be identified. In some healthcare facilities, one or more of the patient rooms 80 may not be completely private rooms, but instead may be shared with one or more other patients. In such situations, it is typical to mount two or more wall units 84 (each of which has its own location transceiver 94) within such a room— one on the headwall of the bay where the first patient support apparatus 20 normally resides and the other on the headwall of the bay where the second patient support apparatus 20 normally resides (and still more if the room is shared by more than two patients).

[0145] In some versions of patient support apparatus 20, the location receiver of nurse call interface 78 is an ultra-wideband (UWB) transceiver adapted to receive and / or transmit UWB signals. When so implemented, the location transceiver 94 is also a UWB transceiver. By exchanging UWB signals between themselves (e.g. ranging), the UWB location transceiver(s) of patient support apparatus 20 are able to determine their distance from the UWB location transceiver 94 of a nearby wall unit 84. In some versions, patient support apparatus 20 may include multiple UWB location transceivers positioned at known locations onboard patient support apparatus 20 and those multiple UWB location transceivers may use ranging with the UWB transceiver 94 of wall unit 84 to determine the orientation of patient support apparatus 20 relative to wall unit 84, and / or relative to the wall to which it is attached, and / or relative to the room 80 in which the wall unit 84 is positioned. In some versions, wall units 84 and / or patient support apparatus 20 may include any of the same UWB functionality as the locator units 60 and / or patient support apparatuses 20 disclosed in commonly assigned U.S. provisional patent application serial number 63 / 597,412 filed November 9, 2023, by inventors Michael Graves et al. and entitled PATIENT SUPPORT APPARATUS WITH ENVIRONMENTAL INTERACTION, the complete disclosure of which is incorporated herein by reference.

[0146] When interface 78 (FIG. 3) receives a wireless signal from an adjacent location transceiver 94, controller 58 forwards the received signal, including a unique ID of the wall unit 84 and the unique ID 82 of patient support apparatus 20 to patient support apparatus server 86 (FIGS. 3-4). Software application 110 includes and / or utilizes a table that correlates the unique IDs of wall unit 84 to locations (e.g. rooms 80) within the healthcare facility. Software application 110 is thereby able to determine the location of each patient support apparatus 20 within the healthcare facility (at least all of those that are positioned adjacent a location transceiver 94).

[0147] When wall units 84 (FIGS. 3-4) are configured to function both as locators and as wireless links to a nurse call wall outlet 90, patient support apparatuses 20 may transmit audio signals to, and receive audio signals from, (such as the patient’s voice, a caregiver’s voice, a television’s audio signals, and / or other audio signals) wall unit 84, which in turn communicates the audio signals to nurse call system 88 via wall outlet 90 and / or from a television within the room 80. In such versions, the audio signals may be transmitted to and fromwall units 84 via one or more RF transceivers 96, which may include one or more Bluetooth transceivers and / or UWB transceivers.

[0148] Wall unit 84 (FIGS. 3-4) also includes an interface 98 that oversees the communications between wall outlet 90 and wall unit 84. In some versions, interface 98 may include the headwall interface 118, the TV controller 116, and the configuration circuity 114 of the locator units 60 disclosed in commonly assigned U.S. patent application serial number 63 / 615,806 filed December 29, 2023, by inventors Michael Graves etal. and entitled PATIENT SUPPORT APPARATUS AND ASSET MONITORING, the complete disclosure of which is incorporated herein by reference. In other versions, interface 98 may be constructed in other manners and / or include other functions.

[0149] In general, interface 98 is adapted to change the electrical state of one or more pins that are in electrical communication with wall outlet 90 (via cable 92). Interface 98 changes these electrical states in response to instructions from a controller built into wall unit 84. For example, if the exit detection system 140 of patient support apparatus 20 detects a patient exit, controller 58 of patient support apparatus 20 sends an exit alert signal to wall unit 84 and the controller of wall unit 84 responds by instructing interface 98 to change the electrical state of at least one pin that is used to signal an exit alert (or a generic priority alert) to nurse call system 88 via wall outlet 90.

[0150] In some designs, interface 98 (FIG. 3) may be constructed in the same manner as, and / or may include any one or of the functions as, the cable interface 88 described in commonly assigned U.S. patent application serial number 63 / 193,778 filed May 27, 2021, by inventors Krishna Bhimavarapu etal. and entitled PATIENT SUPPORT APPARATUS AND HEADWALL UNIT SYNCING, the complete disclosure of which is incorporated herein by reference. Alternatively, or additionally, interface 78 may be constructed in the same manner as, and / or may include any one or more of the same functions as, the headwall interface 120 disclosed in commonly assigned U.S. patent application serial number 63 / 131,508 filed December 29, 2020, by inventors Kirby Neihouseret al. and entitled TOOL FOR CONFIGURING HEADWALL UNITS USED FOR PATIENT SUPPORT APPARATUS COMMUNICATION, the complete disclosure of which is incorporated herein by reference.

[0151] Wall units 84 may also, or alternatively, include any of the structures and / or functionality of the wall modules disclosed in any of the following commonly assigned U.S. patent references: patent number 8,102,254 issued January 24, 2012 to Becker et al. and entitled LOCATION DETECTION SYSTEM FOR A PATIENT HANDLING DEVICE; patent application serial number 14 / 819,844 filed August 6, 2015, by inventors Krishna Bhimavarapu et al. and entitled PATIENT SUPPORT APPARATUSES WITH WIRELESS HEADWALL COMMUNICATION; patent application serial number 62 / 600,000 filed December 18, 2017, by inventor Alex Bodurka, and entitled SMART HOSPITAL HEADWALL SYSTEM; and patent application serial number62 / 598,787 filed December 14, 2017, by inventors Alex Bodurka et al. and entitled HOSPITAL HEADWALL COMMUNICATION SYSTEM, the complete disclosures of all of which are incorporated herein by reference.

[0152] Patient support apparatus 20 is shown in FIGS. 3-4 in communication with local area network 56 of the healthcare facility. It will be understood that the precise structure and contents of the local area network 56 will vary from healthcare facility to healthcare facility. FIG. 4 illustrates in greater detail the contents of a common hospital’s local area network 56, along with patient support apparatus server 86 and several electronic devices 104. It will be understood that the specific servers shown in FIG. 4 and their functionality may be modified from what is shown and described herein. For example, all or some of the functions of software application 110 may be combined with, either partially or wholly, any one or more of the other servers shown in FIG. 4 and / or described herein. Additionally, the functionality of any one or more of the servers shown in FIG. 4 and / or described herein may also be combined, either partially or wholly, with any other ones of these other servers. For example, one or more of the functions of ADT server 138 may be combined with EMR server 136 and / or a nurse call server 134. Other combinations of functionality are, of course, also possible.

[0153] As shown in FIG. 4, local area network 56 may include a plurality of servers, including a conventional Admission, Discharge, and Tracking (ADT) server 138 a conventional nurse call server 134, a conventional Electronic Medical Records server 136, and a plurality of conventional wireless access points 112. Local area network 56 also includes patient support apparatus server 86 that, together with one or more patient support apparatuses 20, implement a version of the compliance system 150 according to the present disclosure. Still further, network 56 includes a conventional Internet gateway 108 that couples local area network 56 to the Internet 114, thereby enabling the servers and / or patient support apparatuses 20 to communicate with computers outside of the healthcare facility, such as, but not limited to, a geographically remote server 122. In some versions, all or some of the functions of software application 110 of patient support apparatus server 86 are carried out by geographically remote server 122, while in other versions software application 110 of patient support apparatus server 86 is configured to implement all or some of its functions without accessing geographically remote server 122.

[0154] ADT server 138, which may be a conventional server, stores patient information, including the identity of patients and the corresponding rooms 80 and / or bays within rooms to which the patients are assigned. That is, ADT server 138 includes a patient-room assignment table 116 (FIG. 4), or functional equivalent to such a table. The patient-room assignment table 116 correlates rooms, as well as bays within multi-patient rooms, to the names of individual patients within the healthcare facility. The patient’s names are entered into the ADT server 138 by one or more healthcare facility staff whenever a patient checks into the healthcare facility and the patient is assigned to a particular room within the healthcare facility. If and / or when apatient is transferred to a different room and / or discharged from the healthcare facility, the staff of the healthcare facility update ADT server 138. ADT server 138 therefore maintains an up-to-date table 116 that correlates patient names with their assigned rooms. ADT server 138 may be a conventional server marketed by Cerner Corporation of North Kansas City, Missouri; EPIC Systems of Madison, Wisconsin; Allscripts Healthcare Solutions, Inc. of Chicago, Illinois; and / or by other companies. Still other types of ADT servers 138 may, of course, be used. In some versions, ADT server 138 and / or a portion of its functions may be integrated into, or combined with, those of EMR server 136.

[0155] EMR server 136 (FIGS. 3-4) stores the medical records of individual patients. Such patient records identify a patient by name and the medical information associated with that patient. Such medical information may include all of the medical information generated from the patient’s current stay in the healthcare facility as well as medical information from previous visits. An abbreviated EMR table 118 (FIG. 4) shows an abbreviated example of two types of medical information that may be entered into a patient’s medical records: a risk assessment of the patient’s risk of falling (high, low, medium) and data indicating whether a patient has been admitted to, or discharged from, the healthcare facility. In some healthcare facilities, the data indicating whether a patient has been admitted or discharged may be maintained in ADT server 138 although, as noted, in some healthcare facilities, one or more of the functions of ADT server 138 may be combined with the functions of EMR server 136, or vice versa. It will be understood that EMR table 118 will typically include vast amounts of data beyond what is shown in FIG. 4, and such data may include, among numerous other types of information, an indication as to whether or not a particular patient is currently on, or has been prescribed treatment with, a ventilator.

[0156] It will be understood that the term “EMR server,” as used herein, also includes Electronic Health Records servers, or EHR servers for short, and that the present disclosure does not distinguish between electronic medical records and electronic health records. EMR server 136 may be a conventional server marketed by Cerner Corporation of North Kansas City, Missouri; EPIC Systems of Madison, Wisconsin;Allscripts Healthcare Solutions, Inc. of Chicago, Illinois; and / or by other companies. Still other types of EMR servers 124 may, of course, be used.

[0157] A nurse call server 134 is shown in FIG. 4 that includes a caregiver assignment table 124 that matches specific caregivers to specific rooms and / or bays within the healthcare facility. Although table 124 only shows caregivers assigned to a single room, it will be understood that each caregiver is typically assigned to multiple rooms. In some nurse call systems, caregivers are assigned to specific patients, rather than to specific rooms. Compliance system 150 is configured to work with both types of nurse call systems. Compliance system 150 is also adapted to work with healthcare facilities that utilize a separate caregiver assignment server (not shown), rather than nurse call server 134, to assign caregivers to rooms and / or patients. Nurse call server134 may be a conventional server marketed by Rauland-Borg (now owned by Ametek, Inc. of Berwyn, Pennsylvania); by West-Com Nurse Call System, Inc. of Fairfield, California; and / or by other companies.

[0158] Regardless of whether caregiver assignment table 124 is stored within nurse call server 134 or some other server on network 56, nurse call server 134 is configured to communicate with caregivers and patients. That is, whenever a patient on a patient support apparatus 20 presses, or otherwise activates, a nurse call control, the nurse call signals pass through wall outlet 90. Wall outlet 90 is coupled via wire to nurse call server 134 and / or to another structure of the nurse call system that then routes the call to the appropriate nurse. The nurse is thereby able to communicate with the patient from a remote location.

[0159] Local area network 56 may include additional structures not shown in FIG. 4, such as, but not limited to, one or more conventional work flow servers and / or charting servers that monitor and / or schedule patient-related tasks for particular caregivers, and / or one or more conventional communication servers that forward communications to particular individuals within the healthcare facility, such as via one or more portable devices (smart phones, pagers, beepers, laptops, etc.). The forwarded communications may include data and / or alerts that originate from patient support apparatuses 20 as well as data and / or alerts that originate from patient support apparatus server 86.

[0160] Wireless access points 112 are configured, in at least some versions, to operate in accordance with any one or more of the IEEE 802.11 standards (e.g. 802.11g, 802.11 n, 802.11ah, etc.). As such, patient support apparatuses 20 and electronic devices 104 that are equipped with Wi-Fi capabilities, and that have the proper authorization credentials (e.g. password, SSID, etc.), can access local area network 56 and the servers hosted thereon. This allows patient support apparatus 20 to send messages to, and receive messages from, software application 110 of patient support apparatus server 86. This also allows authorized electronic devices 104 to access patient support apparatus server 86 and / or remote server 122, thereby allowing them to interact with compliance system 150.

[0161] Software application 110 (FIG. 3) of patient support apparatus server 86 is configured to construct a table 126 (FIG. 4), or a functionally equivalent type of data structure, which determines in which specific rooms 80— and / or bays within the rooms of the healthcare facility— each of the patient support apparatuses 20 is currently located. Software application 110 determines these room and / or bay locations by using the known location of each wall unit 84 (with their corresponding location transceivers 94) within the healthcare facility (which may be determined via a surveying procedure during the installation of wall units 84) and the known IDs of each wall unit 84. Each location transceiver 94 sends a unique wall unit ID to an adjacent patient support apparatus 20 when the patient support apparatus 20 is positioned within a close proximity of the patient support apparatus 20. The patient support apparatus 20, in turn, forwards this unique wall unit ID, along with its unique patient support apparatus ID 82, to software application 110. Software application 110 thenuses these two IDs, along with the known location of the wall units 84, to determine the location of each patient support apparatus 20.

[0162] Software application 110 also receives status conditions from each patient support apparatus 20. Such status conditions may include data from any of the sensors 62, 66, 68, 72, 74, 76, 140, 142, and / or 144 onboard patient support apparatus 20, including data relating to the condition of the patient, data relating to the condition of patient support apparatus 20, and / or data relating to the environment (e.g. room) in which patient support apparatus 20 is positioned. Each patient support apparatus 20 sends these status conditions to software application 110 with its corresponding unique patient support apparatus ID 82. Software application 110 is therefore able to correlate incoming patient support apparatus status conditions with specific patient support apparatuses 20 and specific locations within the healthcare facility. In other words, software application 110 is able to construct a data structure like table 126 of FIG. 4, which includes the room location and status conditions for each of the patient support apparatuses 20 within the healthcare facility (or within a portion of the healthcare facility).

[0163] In the example shown in FIG. 4, table 126 includes data indicating the state of brake 60, siderails 36, exit detection system (EDS) 140, monitoring system 142, and litter frame 28. It will be understood that table 126 may be modified from the example shown in FIG. 4. Such modifications may include the addition of additional status data, the removal or omission of one or more of the status data points shown in FIG. 4, and / or a combination of both additional status data points and the removal of one or more status data points.

[0164] Although not shown in table 126 of FIG. 4, software application 110 may also correlate the information of table 126 to one or more additional pieces of information, such as specific caregivers, specific patients, and / or other pieces of information. For example, software application 110 may determine which caregivers are associated with each of the patient support apparatuses 20 based on the caregiver-to-room assignment data it receives from nurse call server 134 (i.e. the data of table 124). By using this caregiver-to-room assignment data, software application 110 is able to determine which caregiver(s) are assigned to each of the patient support apparatuses 20. Further, software application 110 may determine which patients are associated with each of the patient support apparatuses 20 based on the patient-to-room assignment data it receives from ADT server 138 (i.e. the data of table 116). By using this patient-to-room assignment data, software application 110 is able to determine which patient is assigned to each of the patient support apparatuses 20. Further, by knowing which patient is assigned to each patient support apparatus 20, software application 110 is able to assign medical information received from EMR server 136 to each of the patient support apparatuses 20. Such medical information may include information indicative of the fall risk of a patient, the usage of a ventilator, the admission / discharge state of a particular patient, the presence of a respiratory precaution, and / or other information. In summary, software application is supplied with sufficientdata to know the current status of each patient support apparatus 20, the room in which each patient support apparatus 20 is assigned, the caregiver assigned to that room and / or patient support apparatus 20, the patient assigned to each patient support apparatus 20, and the patient’s data contained with EMR server 136.

[0165] In some versions, software application 110 is configured to determine patient-to-room, patient-to-bed, patient-to-bed-bay, patient-to-caregiver, caregiver-to-room, caregiver-to-patient-support-apparatus, and / or caregiver-to-bed-bay correlations in any of the manners disclosed in commonly assigned U.S. patent application serial number 62 / 826,097, filed March 29, 2019 by inventors Thomas Durlach et al. and entitled PATIENT CARE SYSTEM, and / or commonly assigned Indian patent application serial number 202211062036 filed October 31, 2022, in the Indian Patent Office by inventors Thomas Durlach et al. and entitled CAREGIVER ASSISTANCE SYSTEM, the complete disclosures of both of which are incorporated herein by reference. In some versions, software application 110 may further be modified to carry out any of the staffing errors, and other error-notification functions, disclosed in the aforementioned ‘097 application.

[0166] Local area network 56 of the healthcare facility may be a conventional local area network and, in many cases, will have a conventional gateway 108 and / or router that connects the network 56 to the Internet 114. In such situations, patient support apparatus server 86 may be omitted and / or supplemented with a remote server 122 that may execute a remote version 110a of software application 110. That is, compliance system 150 does not require a software application 110 that is executed on a local server (e.g. patient support apparatus server 86) in order for it to operate. Instead, in some instances, a remote version 110a of software application 110 may reside on a remote server 122 that is in communication with one or more patient support apparatuses 20 and one or more of the servers on local area network 56. In such instances, remote software application 110a may perform the functions of local software application 110 and local software application 110 may be omitted. Still further, one or more of the functions of local or remote software application 110 or 110a may be carried out by a mobile software application 110b that is executed by an electronic device 104. For purposes of the following written description, all references to software application 110 will be understood as being applicable to remote software application 110a and / or mobile software application 110b. In other words, software application 110 may be executed, in different versions, on server 86 exclusively, on remote server 122 exclusively, on one or more electronic devices 104 exclusively, and / or in different combinations of two or more of these devices. Still other configurations are possible for implementing compliance system 150.

[0167] Patient support apparatus server 86 (FIGS. 3-4) is adapted to be accessible to one or more authorized electronic devices 104, thereby allowing selected personnel of the healthcare facility to utilize and view the data compiled by compliance system 150. Such electronic devices 104 may come in a variety of different forms. Each electronic device 104 includes at least one display 130, which may be a conventional display, such as an LED display, an OLED display, or another type of display. As shown in FIG. 4, someelectronic devices 104 are mobile electronic devices 104a intended to be carried by a user (e.g. a caregiver) while other display devices are stationary or semi-stationary electronic devices 104b that generally remain in one location. Mobile electronic devices 104a may take on different forms, such as, but not limited to, smart phones, tablets, laptop computers, badges, Computers on Wheels (COWs), and others. Stationary electronic devices 104b may also take on different forms, such as, but not limited to, smart televisions, displays, desktop computers, and others. For purposes of the following written description, reference to electronic devices 104 will refer to both electronic devices 104a and 104b, unless otherwise stated.

[0168] Compliance system 150 may be configured such that electronic devices 104 communicate with software application 110 via a conventional web browser. Alternatively, system 150 may be configured such that electronic devices 104 are adapted to execute a specialized or native software application (other than a conventional web-browser) that is downloaded to the electronic device 104 and that is tailored to be executed by the particular operating system of the electronic device 104 (e.g. Android, iOS, Windows, etc.). The specialized software application is executed by the microcontroller(s) of the electronic device 104 and carries out displaying the data of compliance system 150, as described herein.

[0169] For those electronic devices 104 that connect to software application 110 via a conventional web-browser, it may be necessary for a caregiver associated with an electronic device 104 to utilize the conventional web-browser application contained within the electronic device 104 to navigate to a particular web page, or other URL, associated with software application 110. Any conventional web-browsing software may be used for this purpose, including, but not limited to, Microsoft’s Bing or Internet Explorer web browsers, Google’s Chrome web browser, Apple’s Safari web browser, Mozilla’s Firefox web browser, etc. The particular URL accessed with the web browser may vary for different healthcare facilities and can be customized by authorized IT personnel at the healthcare facility. In some versions, a domain name may be associated with software application 110 that is resolved by a local DNS server to the IP address of patient support apparatus server 86 (e.g. www.compliance-app.com) and / or to remote server 122. As was also noted, some electronic devices 104 may include their own native software applications that are programmed to interact with software application 110, thereby avoiding the usage of a web browser to access software application 110. Access to software application 110 may be achieved in other manners.

[0170] Software application 110 may be configured to require a user to enter a username and / or password via the electronic device 104 before the user is able to access software application 110. After entering the appropriate information into an electronic device 104, the software application 110 is configured to instruct the electronic device 104 to display compliance data regarding one or more patient support apparatuses 20 and / or one or more patients that are positioned within the healthcare facility. Such data mayinclude any of the screens shown in FIGS. 5-13, although still other screens and / or data may be displayable by compliance system 150.

[0171] Software application 110 is adapted to assist the administrators of a healthcare facility in determining how well, or how poorly, their caregivers follow the healthcare facility’s standards for the usage of the facility’s patient support apparatuses 20. In general, software application 110 is adapted to gather accurate data regarding the actual usage of patient support apparatuses 20, compare that usage to the healthcare facility’s standards, record the results, and allow authorized users to view the levels of compliance with the facility’s standards.

[0172] In order to carry out its functions, an authorized individual of the healthcare facility is able to utilize one or more electronic devices 104 to input the desired usages standards for the patient support apparatuses 20 within the healthcare facility. Such usage standards define such things as whether brake 60 is to be activated, whether (and which ones of) siderails 36 are to be raised, what height litter frame 28 is to be in, whether exit detection system 140 is to be armed (and if, at what sensitivity level), whether monitoring system 142 is to be armed, and / or whether other features of patient support apparatus 20 are to be in one or more desired states. The standards that are input into compliance system 150 may also include additional data, such as specialized standards for different categories of fall risks for the patient. In other words, patient who are a high fall risk may dictate different desired usage standards for patient support apparatus 20 than patients who are at a lower fall risk. Other data regarding the patient may also dictate what standards of usage are to be followed for patient support apparatus 20 (e.g. patients on a ventilator may need to have the HoB angle above 30 degrees, and / or a lockout on the patient support apparatus 20 prohibiting the head section 44 from pivoting below 30 degrees). Still other types of standards may be input into patient support apparatus server 86 using one or more electronic devices 104, including standards that may be based on specific locations within the healthcare facility (e.g. wings, floors, departments, units, etc.), standards that may be based on specific times of the day, week, or calendar, standards that may be based on specific health conditions of the patients, standards that may be based on different models of patient support apparatuses 20, and / or standards that may be based on still other factors.

[0173] The communication interface used by software application 110 controls the communications between software application 110 and the patient support apparatuses 20 and / or electronic devices 104 with which it is in communication (FIGS. 3-4). The communication interface may also control the communications between software application 110 and the servers with which it is in communication. All of these communications, in at least one version, are carried out using conventional Internet packet routing. That is, patient support apparatuses 20 send data in packets that have an IP address corresponding to patient support apparatus server 86, and server 86 sends message packets back to patient support apparatuses 20 thatinclude an IP address corresponding to the particular patient support apparatus(es) 20 to which the messages are intended. In some versions, each patient support apparatus 20 includes a static IP address that is stored on the patient support apparatus 20, while in other versions, the patient support apparatuses 20 consult a local Dynamic Host Configuration Protocol (DHCP) server (not shown) on local area network 56 and the DHCP server assigns a network address to the patient support apparatuses 20.

[0174] When communicating with other servers within the healthcare facility, the communication interface of software application 110 may utilize different communication protocols, such as, but not limited to, Link Layer Protocol (LLP), Hyper-Text Transfer Protocol Secure (HTTPS), and / or Simple Mail Transfer Protocol (SMTP), etc. In order to facilitate the communication between patient support apparatus server 86 and the other servers of local area network 56, the communication interface may utilize a conventional interface engine, such as, but not limited to, the Redox cloud platform that is commercially available from Redox, Inc. of Madison, Wisconsin. Alternatively, or additionally, the communication interface may utilize a conventional iGUANA interface engine (HL-7 or otherwise) available from iNTERFACEWARE, Inc. of Toronto, Ontario. Such interfaces allow software application 110 to communicate with different types and / or brands of Electronic Health Record (EHR) systems, such as, but not limited to, those marketed by Cerner corporation, Epic Corporation , Allscripts, etc. Still other types of communication interfaces may be used.

[0175] The web API that may be used in some versions of software application 110 provides a portal for authorized devices, software applications, and / or servers to access the data of software application 110. In some versions, electronic devices 104 communicate with software application 110 via the web API by using a web browser built into the electronic devices 104 that accesses one or more Uniform Resource Locators (URLs) that direct the web browser to software application 110. The web API, in some versions, uses JavaScript Object Notation (JSON) to communicate with the web browsers of the electronic devices 104. In other versions, the web API uses Extensible Markup Language (XML) to communicate with the web browsers of the electronic devices 104. Still other types of communication may be used.

[0176] In some versions, the web API may be configured to communicate with the electronic devices 104 using the conventional GET, POST, DELETE, and UPDATE verbs of the Hyper-Text Transfer Protocol (HTTP). These are used for providing RESTful service (i.e. Representational State Transfers) between web API and the electronic devices 104. For those aspects of software application 110 that utilize two way interactive communication, conventional web socket protocols (e.g. IETF RFC 6455, or the WebSocket API in Web IDL (Interface Description Language) that is standardized by the World Wide Web Consortium (W3C)) may be used for communication between the web API and the electronic devices 104. Alternatively, or additionally, conventional pull and push requests may be used for this communication, as well as, but not limited to, server-sent events and / or long polling. Still other communication techniques may be used. In someversions, such communications are encrypted such that at least those messages containing patient data are secured against interception. Such encryption takes place, in at least one version, as part of a RESTulf Web service (RWS).

[0177] In general, software application 110 performs the following functions: gathers data from patient support apparatuses 20 about their current states, their assigned patients, and / or the environment in which the patient support apparatus 20 is positioned; gathers data from EMR server 136 and / or ADT server 138 about the patients assigned to patient support apparatuses 20; processes the data, determines if the data indicates usage of patient support apparatus 20 in accordance with one or more healthcare facility standards, saves the data, and present the data to authorized viewers in a variety of different manners that enable healthcare personnel to better understand how well, or how poorly, they are meeting their own standards of usage of patient support apparatuses 20.

[0178] FIG. 5 illustrates an example of a first screen 160 that may be displayed by software application 110 of compliance system 150 for a particular healthcare facility (e.g. “central valley hospital”). As with all of the screens shown in FIGS. 5-13, first screen 160 may be displayed on display 130 of any electronic device 104 that is in communication with patient support apparatus server 86. First screen 160 illustrates a compliance selection pane 162, a date range selector 164, a unit chart 166, and a date chart 168. Compliance selection pane 162 includes a plurality of compliance options 170a-f. When a user selects one of the compliance options 170a-f, software application 110 is adapted to change the content of unit chart 166 and date chart 168. That is, when a user selects compliance option 170a, software application 110 is configured to display overall patient support apparatus compliance values in both charts 166 and 168. These overall compliance values indicate how one or more patient support apparatuses are complying overall with all of the healthcare facility’s usage standards. If a user selects bed exit option 170b, software application 110 is configured to display compliance values that are specific to an individual component of patient support apparatus 20; namely, exit detection system 140. That is, software application 110 populates charts 166 and 168 with data showing compliance levels, or lack of compliance levels, with the healthcare facility’s standards for operating exit detection system 140.

[0179] If a user selects siderail option 170c (FIG. 5), software application 110 is configured to display individual compliance values that indicate the specific level of compliance, or non-compliance, of the siderails of patient support apparatus 20 with the healthcare facility’s siderail standards. If a user selects low-height option 170d, software application 110 is configured to display individual compliance values that indicate the specific level of compliance, or non-compliance, of the litter frame 28 with the healthcare facility’s height standards for litter frame 28. If the user selects brake option 170e, software application 110 is configured to display individual compliance values that indicate the specific level of compliance, or non-compliance, of the brake 60 with thehealthcare facility’s standards for brake 60. And if the user selects the other option 170f, software application 110 is configured to display individual and / or overall compliance values that indicate the specific level of compliance, or non-compliance, of one or more other components of patient support apparatus 20 with the healthcare facility’s standards for those one or more other components.

[0180] Date range selector 164 (FIG. 5) allows a user of software application 110 to specify the date range of the data that is shown in charts 166 and / or 168. That is, date range selector 164 allows a user to select what time period is to be viewed in charts 166 and / or 168. Software application 110, in some versions, is adapted to calculate overall compliance values and individual compliance values for each patient support apparatus 20 within the healthcare facility in real time, or near real time. Further, software application 110 is configured to store these calculated compliance values in a memory and to subsequently allow any authorized user of software application 110 to view these compliance values. Date range selector 164 allows the user to select compliance values for whichever dates or of interest to the user.

[0181] Unit chart 166 displays the brake compliance values of patient support apparatuses 20 according to the individual units of a healthcare facility. As is customary, many healthcare facilities divide their facility into different units (sometimes also referred to as departments, or other terms), such as an intensive care unit, a burn unit, a post-operative unit, etc. Unit chart 166 displays the compliance values in a bar graph format for all of the patient support apparatuses 20 in a particular unit of the healthcare facility. For example, a first unit 172a is shown in the far left of unit chart 166. The first unit 172a has a ninety-nine percent compliance range (over the selected time period) for usage of brake 60 in accordance with the healthcare facility’s brake usage standard. Each unit 172 may be labeled at the bottom of its corresponding bar graph so that viewers of first screen 160 are able to identify the corresponding units within the healthcare facility. In the example shown in FIG. 5, first unit 172a is labeled “SO RCVY,” which is an abbreviation for a particular unit at “Central Valley Hospital.” Other abbreviations and names may, of course, be used.

[0182] In the example of FIG. 5, unit chart 166 has been generated by software application 110 in a manner showing, from left to right, the units with the highest compliance levels to the lowest compliance levels. Thus, first unit 172a has a ninety-nine percent compliance level, which is the highest level, while second unit 172b (shown all the way to the right of chart 166) has the lowest compliance level of ninety-five percent.Software application 110 is configured to allow a user to have unit chart 166 generated in different orders along its horizontal axis. For example, instead of displaying the highest to lowest compliance values from left to right, software application 110 may display unit chart 166 with the lowest to highest compliance values from left to right. As another alternative, a user may configure software application 110 to display unit chart 166 such that the unit names are arranged in alphabetical order from left to right (or from right to left). As yet anotheralternative, a user may configure software application 110 to display unit chart 166 in a manner whereby the units 172 are arranged according to different floors of the healthcare facility, or in still other manners.

[0183] Time chart 168 (FIG. 5) displays the brake compliance values of all of the patient support apparatuses 20 in the healthcare facility over a given time period. The given time period may be the time period entered by the user using date selector 164, or it may be a different time period that is selectable by the user. In the example shown therein, the combined brake compliance values of the patient support apparatuses 20 was maintained above ninety percent for substantially the entire time period with the exception of several days in late November (where the compliance level dropped down to seventy-two percent).

[0184] Software application 110 is configurable by a user to display time chart 168 for individual units, as well as the entire healthcare system. Thus, in the example shown in FIG. 5, time chart 168 illustrates the compliance level of all of the patient support apparatuses 20 within the Central Valley Hospital over the illustrated time period. If a user wished to see only the compliance values for a particular unit over this same time period (or another time period), software application 110 allows the user to do this. In some versions, this may be done by clicking on (or touching) one of the bar graphs shown in unit chart 166 of the desired unit. In some versions, the user can select multiple of these bar charts and software application 110 will combine these multiple units together and display time chart 168 according to the selected multiple units. Software application 110 therefore allows a user to select whichever units they want, and then generate a time chart 168 showing the compliance values over time for those selected units.

[0185] Software application 110 is configured to determine the compliance value for a particular component of patient support apparatus 20 (e.g. brake 60) by determining what percentage of time the brake meets the healthcare facility’s standard while the patient support apparatus 20 is in what will be referred to herein as a “use state.” A use state may be defined in different manners, but in at least one version, the use state refers to any time the following conditions are all true: (a) the patient support apparatus 20 is occupied by a patient, (b) a fall risk classification for the patient has been completed and stored in a server accessible to patient support apparatus server 86 (e.g. EMR server 136), (c) the patient has been admitted to the healthcare facility, as indicated by ADT server 138 and / or EMR server 136, and (d) the patient support apparatus 20 is “online,” (i.e. the communication channel, such as WiFi, between patient support apparatus 20 and patient support apparatus server 86 is operational). It will be understood that these four conditions may be changed in different versions of software application 110. Such changes may include the addition of one or more other conditions, the elimination of one or more of these four conditions, and / or a combination of added and removed conditions.

[0186] In some versions of compliance system 150, software application 110 may be configured to add the following condition to the definition of a patient support apparatus’s “use state:” no caregiver is present in the same room as (or in a defined proximity to) patient support apparatus 20. When this condition is added,compliance system 150 does not consider patient support apparatus 20 to be out of compliance with any healthcare facility standards while a caregiver is in the same room as (or in a defined proximity to) patient support apparatus 20. This condition may be utilized in order to give caregivers a chance to configure patient support apparatus 20 in its desired states without having the time necessary for this initial set-up count against the compliance measurements for that particular caregiver. This condition may also, or alternatively, be utilized under the assumption that the presence of the caregiver near the patient will mitigate against any undesirable consequences of the patient support apparatus 20 not being configured in its desired states. Whatever the reason for the caregiver-presence condition, software application 110 is adapted to allow users to add or remove this condition from the definition of the patient support apparatus’s “use state,” thereby causing software application 110 to determine the compliance values in different manners. As was discussed previously, software application 110 is able to determine when a caregiver is present (or absent) from a given room (or defined proximity to a patient support apparatus 20) from the caregiver proximity sensor 74 of patient support apparatus 20 (whose detection results are forwarded by controller 58 to software application 110 via network transceiver 64).

[0187] When patient support apparatus 20 is not in a “use state” (however defined and customized by a user), software application 110 does not use the time the patient support apparatus spends in the non-use state when determining the compliance values of the patient support apparatus. This makes the compliance values a more accurate indicator of how well the caregivers are providing proper care to their patients. For example, if no patient is currently on a patient support apparatus 20, the particular states of the various components of the patient support apparatus 20 generally do not affect the care provided to that patient. As a result, there is no need to measure the compliance of any components of patient support apparatus 20 during these time periods.

[0188] Similarly, because a healthcare facility often defines its usage standards for patient support apparatuses 20 according to the fall risk classification of the patient assigned to the patient support apparatus 20, it may not make sense to measure the compliance of a particular patient support apparatus 20 for a patient whose fall risk has not yet been determined since the particular usage standards for that patient cannot be determined. However, in some versions of software application 110, a default usage standard may be defined for situations in which a patient’s fall risk classification has not yet been determined, and in such systems, the “use state” may be defined such that a patient’s fall risk classification is not a prerequisite condition for the patient support apparatus 20 being in a “use state.” In other words, software application 110 may be customized such that a patient support apparatus 10 may be in a use state despite a missing fall risk classification for a patient. In such situations, software application 110 may use the fact of the missing fall riskclassification to select the appropriate standard for determining the compliance values of the patient support apparatus 20.

[0189] As mentioned, software application 110 may consider a patient support apparatus 20 to be in a non-use state when it is off-line (i.e. not communicatively coupled to patient support apparatus server 86). When patient support apparatus 20 is off-line, software application 110 is not able to receive data from the patient support apparatus 20, which means it cannot accurately determine the current states of the components of patient support apparatus 20, which in turn means that it cannot determine whether the patient support apparatus 20 is currently being used in compliance with the healthcare facility’s standards or not. Accordingly, software application 110 may exclude such off-line time periods from the determination of the compliance values of a patient support apparatus 20. Alternatively, in some versions of patient support apparatus 20, controller 58 is configured to automatically store in its memory 70 the states of its components while it is off-line and then, when patient support apparatus 20 subsequently goes on-line, controller 58 forwards all of the past component state data stored in memory 70 that indicates what the states were of its component during the time period it was off-line. Software application 110 can then retroactively determine the patient support apparatus’s compliance values for that off-line time period. In this manner, compliance values can be determined for patient support apparatuses 20 even during time periods when the patient support apparatus 20 was off-line (albeit retroactively).

[0190] As noted, software application 110, in some versions, also excludes from its compliance value calculations time periods when a patient has not been admitted to the healthcare facility. One reason for this exclusion is to avoid using status data from a patient support apparatus 20 that may not be applicable to a patient. In other words, if a patient has not yet been admitted, or has been discharged, then the status data received from patient support apparatus 20 may not be relevant to determining whether patient support apparatus 20 was used with a particular patient in accordance with the healthcare facility’s standards.

[0191] As was also noted, software application 110, in some versions, excludes from its compliance value calculations time periods when no patient is detected on patient support apparatus 20. The presence and absence of a patient onboard patient support apparatus 20 may be detected, in some versions, using scale system 144. When a weight above a threshold (e.g. fifty pounds) is detected by scale system 144, controller 58 sends a signal to software application 110 indicating a patient is present on patient support apparatus 20. When no weight above the threshold is detected by scale system 144, controller 58 sends a signal to software application 110 indicating that no patient is present on patient support apparatus 20. In alternative versions, different methods may be used for determining the occupancy status of patient support apparatus 20. Such alternative versions include, but are not limited to, one or more cameras onboard patient support apparatus 20and / or within the vicinity of patient support apparatus 20, one or more vital sign sensors, and / or one or more other sensors and / or techniques.

[0192] In some versions, software application 110 determines the overall compliance value of a patient support apparatus 20 by combining together multiple individual compliance values forthat patient support apparatus 20. The individual compliance values are each determined for a corresponding component of the patient support apparatus 20. For example, software application 110 may determine an individual compliance value for the usage of brake 60 for a particular patient support apparatus 20 by determining how long the patient support apparatus 20 was (or is) in a use state, and then determining what percent of that time the brake 60 was activated during that use state. For example, if the patient support apparatus 20 was in a use state for, say, ten hours, and during those ten hours, the brake was activated for only nine hours, software application 110 concludes the individual brake compliance value to be ninety percent.

[0193] Software application 110 may compute individual compliance values for the other components of patient support apparatus 20 in a similar manner. For example, if a patient support apparatus 20 was in a use state for ten hours, and the exit detection system 140 was only armed for five hours, the individual compliance value for exit detection system usage would be fifty percent. Similarly, if the exit detection system 140 was armed at the incorrect sensitivity level for, say, 2.5 hours of the five hours it was armed, the individual compliance value for the usage of the correct exit detection system sensitivity level would be twenty-five percent (i.e. the exit detection system was only armed at the correct sensitivity level for 2.5 hours out of the ten— 2.5 hours at the wrong sensitivity level, and five hours at no sensitivity level at all, which is also the wrong sensitivity level). Similar calculations of individual compliance values may be made for the height of litter frame 28, the positions of siderails 36, and, in some versions, the usage of monitoring system 142 (including, in some versions, the selection of what components are monitored by monitoring system 142). Individual compliance values may also be calculated for still other components of patient support apparatuses 20 in some versions of software application 110.

[0194] After software application 110 has calculated individual compliance values for the various components of a patient support apparatus 20, software application 110 may be configured to determine an overall compliance value for the patient support apparatus 20 by averaging together the individual compliance values. In some versions, the individual compliance values may all be equally weighted when they are average together to determine the overall compliance value of the patient support apparatus 20. Alternatively, software application 110, in some versions, allows a user to customize the weighting of different individual compliance values when determining the overall compliance value of a patient support apparatus 20. Thus, for example, if a healthcare facility views a brake 60 being activated as more important than, say, the height of litter frame 28 being in a low height state, the individual compliance value for brake 60 usage may be weighted more heavily(by a user-selected weighting value) than the individual compliance value for the litter frame 28 height usage when computing the overall compliance value for patient support apparatus 20.

[0195] After an overall compliance value for a patient support apparatus 20 has been determined by software application 110, software application 110 may determine a combined compliance value for multiple patient support apparatuses 20 by combining together the individual overall compliance values for each of the patient support apparatuses 20. In some versions, software application 110 may determine a combined compliance value by simply averaging together the overall compliance values of multiple patient support apparatuses 20. In some versions, software application 110 is customizable by its user such that the user can specify different weightings when determining a combined compliance value. For example, a user may specify that one or more units within the healthcare facility are to have their respective patient support apparatuses 20 weighted more heavily when determining a combined compliance value. In such cases, the user is free to specify how much to weight the overall compliance values of the patient support apparatuses 20 that are located in those one or more units.

[0196] FIG. 6 illustrates an example of a second screen 180 that may be displayed by software application 110 of compliance system 150 for a particular healthcare facility (e.g. “central valley hospital”). As with all of the screens shown in FIGS. 5-13, second screen 180 may be displayed on display 130 of any electronic device 104 that is in communication with patient support apparatus server 86 and software application 110. Second screen 180 includes compliance selection pane 162, date range selector 164, unit chart 166, and date chart 168. In the example shown in FIG. 6, a user has selected the low-height compliance option 170d from the selection pane 162. Accordingly, software application 110 has populated unit chart 166 and date chart 168 with individual compliance values that specifically relate to how well the patient support apparatuses 20 are complying with the healthcare facility’s low height standards. That is, charts 166 and 168 of FIG. 6 show compliance levels, or lack of compliance levels, with the healthcare facility’s standards for keeping the height of litter frame 28 at or below a designated threshold.

[0197] In the example shown in FIG. 6, unit chart 166 displays the low-height compliance values of patient support apparatuses 20 according to the individual units of the healthcare facility. As shown therein, the unit “SO SCUD” has a low-height compliance value of seventy-nine percent. The unit “SO RCVY” has a low-height compliance value of only four percent. As with unit chart 166 of FIG. 5, software application 110 allows the user to select the order in which the units are arranged on unit chart 166. Thus, instead of displaying the units in rank order of highest-to-lowest compliance values from left to right, the user is free to configure software application 110 to display the units in other orders, as has already been discussed.

[0198] Time chart 168 of FIG. 6 illustrates the low-height compliance values of all of the patient support apparatuses 20 in the healthcare facility over a given time period. The given time period may be thetime period entered by the user using date selector 164, or it may be a different time period that is selectable by the user. In the example shown therein, the combined low-height compliance values of all of the patient support apparatuses 20 were maintained above sixty percent for substantially the entire time period with the exception of a day or two around August 20 (where the low-height compliance level dropped down to forty-four percent).

[0199] As was noted, software application 110 is configurable by a user to display time chart 168 for individual units, as well as the entire healthcare system. Thus, in the example shown in FIG. 6, time chart 168 illustrates the low-height compliance levels of all of the patient support apparatuses 20 within the Central Valley Hospital over the illustrated time period. If a user wished to see only the low-height compliance values for a particular unit over this same time period (or another time period), software application 110 allows the user to do this. In some versions, this may be done by clicking on (or touching) one of the bar graphs shown in unit chart 166 of the desired unit. In some versions, the user can select multiple of these bar charts and software application 110 will combine these multiple units together and display time chart 168 according to the selected multiple units. Software application 110 therefore allows a user to select whichever units they want, and then generate a time chart 168 showing the compliance values over time for those selected units.

[0200] FIG. 7 illustrates an example of a third screen 190 that may be displayed by software application 110 of compliance system 150 for a particular healthcare facility (e.g. “central valley hospital”). Third screen 190 includes compliance selection pane 162, date range selector 164, unit chart 166, date chart 168, and a filter window 192. In the example shown in FIG. 7, a user has selected the siderail compliance option 170c from the selection pane 162. Accordingly, software application 110 has populated unit chart 166 and date chart 168 with individual compliance values that specifically relate to how well the patient support apparatuses 20 are complying with the healthcare facility’s standards for the four siderails 36 of patient support apparatus 20. That is, charts 166 and 168 of FIG. 7 show compliance levels, or lack of compliance levels, with the healthcare facility’s standards for keeping each of the four siderails 36 in their desired states (raised or lowered).

[0201] In the example shown in FIG. 7, unit chart 166 displays four separate siderail compliance values for the patient support apparatuses 20 of each unit of the healthcare facility. The four separate siderail compliance values correspond to the compliance value for the first siderail 36 at the right, head-end corner of patient support apparatus 20, the second siderail at the right, foot-end corner of patient support apparatus 20, the left, head-end corner of patient support apparatus 20, and the left, foot-end corner of patient support apparatus 20. It will be understood that software application 110, in some versions, allows a user to select and display overall a single siderail compliance value that averages together (weighted or unweighted) the fourindividual siderail compliance values. In such versions, unit chart 166 will include a single compliance value for the four siderails 36, rather than the four separate siderail compliance values shown in FIG. 7.

[0202] As with all of the charts 166, software application 110 allows the user to select the order in which the units are arranged on unit chart 166. That is, the user is free to display the units in different orders from what is shown in FIG. 7.

[0203] Time chart 168 of FIG. 7 illustrates the siderail compliance values of all of the patient support apparatuses 20 in the healthcare facility over a given time period. The given time period may be the time period entered by the user using date selector 164, or it may be a different time period that is selectable by the user. In the example shown in FIG. 7, time chart 168 includes four different graphs, each corresponding to one of the four siderails of patient support apparatus 20. Thus, the viewer of third screen 190 can see how often, and on what days, for example, the right head-end siderail 36 was in its desired state. The same is true for the other three siderails 36. As with the unit chart 166 for siderail-compliance values, the time chart 168 that displays siderail compliance values may be modified to display only a single siderail compliance value that combines together the four siderail compliance values. Alternatively, or additionally, software application 110 may allow a user to specify a standard for siderail usage that doesn’t specifically apply to all four siderails (e.g. at least three siderails 36 must be up, and two of them must be on the head end 38 of patient support apparatus 20). In such cases, software application 110 may display a time chart 168 (or a unit chart 166) that displays the compliance values forthat particular standard instead of, or in addition to, compliance values for each individual siderail 36.

[0204] Time chart 168 of FIG. 7, as with all of the time charts 168, may be configurable by a user to display time chart 168 for individual units, for the entire healthcare system, and / or according to still other criteria. Indeed, software application 110 is adapted, in some versions, to display a filter window 192 in response to a user selecting a filtering option (not shown) on any of the screens shown in FIGS. 5-9. Filtering window 192 allows a user to filter what data is shown in unit charts 166 and time charts 168. In the example of filtering window 192 shown in FIG. 7, filtering window 192 includes five filtering options 194a-e.

[0205] Filtering option 194a (FIG. 7) allows a user to select which healthcare facilities are to have their data displayed in charts 166 and 168. Filtering option 194a is only available to healthcare systems that own or operate multiple healthcare facilities, or that otherwise have access to the compliance data of multiple healthcare facilities. After the user has selected one or more specific healthcare facilities via filtering option 194a, software application 110 populates charts 166 and 168 with data that is derived from only the specific healthcare facilities selected by the user.

[0206] Filtering option 194b (FIG. 7) allows a user to filter what data is shown in unit chart 166 and time chart 168 according to what floor the patient support apparatuses 20 are located on. Thus, if the userselects, say, the sixth floor, software application 110 will populate charts 166 and 168 with the combined compliance values of only those patient support apparatuses 20 that are located on the sixth floor of the healthcare facility. If one or more units do not have any patient support apparatuses on the sixth floor, software application 110 may display an indication of that fact on unit chart 166, or it may eliminate that unit from unit chart 166 altogether. Regardless of how this fact is conveyed on unit chart 166, software application 110 will not use the data from any patient support apparatuses 20 located in those non-sixth floor units when populating time chart 168.

[0207] Filtering option 194c (FIG. 7) allows a user to filter what data is shown in unit chart 166 and time chart 168 according to the specific room and / or rooms selected by the user. Data from any patient support apparatuses 20 that are not located in the selected room(s) is then omitted from charts 166 and 168. In other words, software application 110 only populates charts 166 and 168 with data from the patient support apparatuses 20 that are located in the rooms specified by the user via room-filtering option 194c.

[0208] Filtering option 194d (FIG. 7) allows a user to filter what data is shown in unit chart 166 and time chart 168 according to specific caregiver shifts. Caregivers typically work in healthcare facilities for specified time periods (e.g. eight hours, ten hours, etc.) during the day and then are replaced by different caregivers for other specified time periods. Software application 110 allows a user to filter out the compliance values according to the changing work shifts of the healthcare facility. This allows a user to see if there is any correlation to the compliance values according to the different worker shifts.

[0209] Filtering option 194e (FIG. 7) allows a user to filter what data is shown in unit chart 166 and time chart 168 according to specific fall risks of patients. For example, is a user wishes to see the compliance levels of the patient support apparatuses 20 for high fall risk patients, he or she can select this via filtering option 194e. If the user wishes to see the compliance levels of patient support apparatuses 20 for medium or low fall risk patients, he or she can also select this via filtering option 194e. As was explained previously, software application 110 obtains the fall risk classifications of each patient from EMR server 136, ADT server 138, and / or another server.

[0210] It will be understood that software application 110 may include additional and / or different filtering options 194 from what is shown in FIG. 7. It will also be understood that filtering window 192 may be utilized by a user on any of the screens of FIGS. 5-9 and / or with any of the compliance options 170a-f. Still further, it will be understood that the filtering options 194 of filter window 192 may be combined with each other. Thus, for example, if a user wishes to only view the compliance levels for high fall risk patients on the fifth floor of the healthcare facility, he or she may select high fall risk patients using filtering option 194e and the fifth floor using filtering option 194b, and software application 110 will only display data in charts 166 and 168 that corresponds to the high fall risk patients on the fifth floor.

[0211] FIG. 8 illustrates an example of a fourth screen 200 that may be displayed by software application 110 of compliance system 150 for a particular healthcare facility (e.g. “central valley hospital”). Fourth screen 200 includes compliance selection pane 162, date range selector 164, unit chart 166, and date chart 168. Fourth screen 200 also includes an armed selector 202a, a count selector 202b, and a duration selector 202c. In the example shown in FIG. 8, the user has selected the exit detection system compliance option 170b from the selection pane 162. Accordingly, software application 110 has populated unit chart 166 and date chart 168 with individual compliance values that specifically relate to how well the patient support apparatuses 20 are complying with the healthcare facility’s standards for arming exit detection system 140 of the patient support apparatuses 20. That is, charts 166 and 168 of FIG. 8 show compliance levels, or lack of compliance levels, with the healthcare facility’s standards for arming exit detection system 140.

[0212] Unit chart 166 of FIG. 8 illustrates the compliance levels of patient support apparatuses 20 according to each healthcare facility unit. Time chart 168 of FIG. 8 illustrates the compliance levels of patient support apparatuses 20 over a selected time period. For both charts 166 and 168 of FIG. 8, the compliance levels are specific to the armed or disarmed state of the exit detection system 140 of the patient support apparatuses 20. In some versions of software application 110, a separate screen may be displayable for displaying the compliance values of the sensitivity level of the exit detection system 140. In other words, in some versions, software application 110 may include in compliance selection pane 162 two compliance options 170: one for displaying the level of compliance with the healthcare facility’s standards for arming exit detection system 140, and a second one for displaying the level of compliance with the healthcare facility’s standards for the specific sensitivity level of the exit detection system. Alternatively, or additionally, software application 110 may be configured to display both the armed and sensitivity compliance levels on the same unit and / or time charts 166 and / or 168, similar to the manner in which the four siderail compliance levels are displayed in FIG.7.

[0213] As was noted, screen 200 of FIG. 8 includes an armed selector 202a, a count selector 202b, and a duration selector 202c. In the example shown in FIG. 8, the user has selected the armed selector 202a. In response to the user selecting armed selector 202a, software application 110 displays unit chart 166 and time chart 168 based on how often the patient support apparatuses 20 have their exit detection system armed in compliance with the healthcare facility’s standards. If the user selects the count selector 202b, software application 110 is configured to change unit and time charts 166 and 168 to indicate how often an exit detection alert was actually issued by the exit detection systems 140 (according to unit in chart 166 and according to time in chart 168). If the user selects alarm duration selector 202c, software application 110 is configured to change charts 166 and 168 to indicate how long each exit alert lasted (i.e. the time from issuance of the exit alert until the time a caregiver responded and turned off the alert). When displaying the duration of each exit alert,software application 110 may be configured to average together the exit alert durations that occur on the same day and / or in the same unit. Alternatively, software application 110 may display individual duration data for each exit alert.

[0214] FIG. 9 illustrates an example of a fifth screen 210 that may be displayed by software application 110 of compliance system 150 for a particular healthcare facility (e.g. “central valley hospital”). Fifth screen 210 includes compliance selection pane 162, date range selector 164, unit chart 166, and date chart 168. In the example shown in FIG. 9, the user has selected the compliance option 170a from the selection pane 162, which refers to the fall risk classification of patients. Accordingly, software application 110 has populated unit chart 166 and date chart 168 with individual compliance values that specifically relate to how well the patient support apparatuses 20 are complying with the healthcare facility's standards for patients that have been classified as having certain fall risks. That is, charts 166 and 168 of FIG. 9 show compliance levels, or lack of compliance levels, with the healthcare facility’s standards for operating patient support apparatuses 20 when a patient having a specific fall risk is assigned to those patient support apparatuses 20.

[0215] In the example shown in FIG. 9, software application 110 has included compliance levels for patient support apparatuses 20 that are assigned to both high fall risk and low fall risk patients. It will be understood that, of course, a user of software application can select only a single fall risk, or more than two fall risks, and software application 110 will display all of the compliance data for the selected fall risks in charts 166 and 168.

[0216] All of the screens 160, 180, 190, 200, and 210 shown in FIGS. 5-9 also include a home option 174 included as part of compliance selection pane 162. Home option 174, when selected by a user, causes software application 110 to display in charts 166 and 168 overall compliance values of patient support apparatuses 20. That is, instead of showing the individual compliance values for individual components of patient support apparatuses 20 (e.g. brake, siderails, exit detection system, etc.) the screen shown in response to a user selecting home option 174 displays the overall compliance values of the patient support apparatuses 20. As was mentioned previously, software application 110 may be configured, in some versions, to calculate an overall compliance value of a patient support apparatus 20 by averaging together the individual compliance values generated for each component of the patient support apparatus 20 that is being monitored for compliance.

[0217] FIGS. 10-13 illustrate examples of additional and / or alternative screens that may be displayed by software application 110 on any display 130 of any electronic device 104 that is in communication with patient support apparatus server 86 and software application 110. FIG. 10 illustrates a sixth screen 220 that displays compliance data generated by compliance system 150 for multiple healthcare facilities. Sixth screen 220 includes a data selector column 222 having a plurality of individual data selectors 224, a total compliancecolumn 226, a selected compliance column 228, a column selector 230, a bar graph selector 232, a line graph selector 234, a share control 236, a download control 238, and a date range selector 164. Data selector column 222 allows a user to select what compliance data they wish to see in the selected compliance column 228. That is, each selector 224 in data selector column 222 can be moved to the right (selected) or moved to the left (unselected). When moved to the right (selected), software application 110 is adapted to display data in the selected compliance column 228 that is based on the specific selectors 224 that have been selected in data selector column 222.

[0218] Selector 224a (FIG. 10) is selected when the user wishes to see the overall compliance values for patient support apparatuses 20. That is selector 224 is selected when the user wishes to see compliance values for all of the components of patient support apparatuses 20 that are being monitored by compliance system 150. When the user selects selector 224a, software application 110 is adapted to not display any selectors 224 for any specific components. However, if the user does not select selector 224a, software application 110 is adapted to display selectors 224e-l (or other selectors) corresponding to all of the compliance-monitorable components of patient support apparatus 20. An example of these component selectors 224e-l is shown in FIG. 11.

[0219] Selectors 224b-d (FIG. 10) are selected when the user wishes to see the compliance values for patient support apparatuses 20 according to the fall risk scores of the patients assigned to the patient support apparatuses 20. In the example shown in FIG. 10, the user has selected all three of the selectors 224b-d. Accordingly, software application 110 is configured to display in column 228 the compliance values for patient support apparatuses 20 having high fall risk patients assigned thereto, the compliance values for patient support apparatuses 20 having medium fall risk patients assigned thereto, and the compliance values for patient support apparatuses 20 having low fall risk patients assigned thereto. As can be seen in FIG. 10, software application 110 may be configured to separately display the overall compliance values for each of these categories of fall risks.

[0220] First column 226 displays the overall compliance values for the indicated healthcare facilities that takes into account all of the components being monitored by compliance system 150. This is therefore the broadest or most generic measure of the healthcare facility’s compliance levels. As noted, second column 228 displays the compliance levels of whatever set or subset of patient support apparatuses 20 the user selects. This set or subset of compliance values represents a user-defined class of compliance values that is narrower than what is shown in first column 226.

[0221] Sixth screen 220, as well as the screens of FIGS 11-13, also include a column selector 230, bar graph selector 232, and line graph selector 234. When column selector 230 is selected, software application 110 displays the user-specified data (as specified in data selector column 222, or elsewhere) incolumns, such as the two columns 226 and 228 shown in FIGS. 10-13. When bar graph selector 232 is selected, software application 110 displays the user-specified data in one or more bar charts, similar to the bar charts 166 of FIGS. 5-9. When line graph selector 235 is selected, software application 110 displays the user-specified data in one or more line graphs, similar to the line graphs of charts 168 of FIGS. 6-9. Software application 110 may include still other options, or fewer options, for displaying the user-specified data.

[0222] Share control 236 allows the user of software application 110 to share the data shown in the screens of FIGS. 10-13, such as by automatically inputting this data into an email, a text message, or other form of communication. Download control 238, when activated, causes software application 110 to download the data shown in the screens of FIGS. 10-13 into one or more desired file formats (e.g. a .csv file format for spreadsheets, a .txt format for a word processing application, etc.). Date range selector 164 operates in the same manner previously described and allows a user to specify the date range for the data shown in the screens of FIGS. 10-13.

[0223] FIG. 11 illustrates a seventh screen 240 that displays compliance data generated by compliance system 150 for multiple healthcare facilities. Seventh screen 240 differs from sixth screen 220 in that the user has selected individual data selectors 224, rather than the all-data selector 224a. Specifically, in the example shown in FIG. 11, the user has selected selectors 224f-224l, and unselected selectors 224a and 224e. Accordingly, software application 110 only displays in second column 228 the compliance values for the components selected in selector column 222. It can therefore be seen that selector column 222 performs a similar function as the compliance selection pane 162 of FIGS. 5-9, except that a user can combine selectors 224 in any desired combination, wherein in selection pane 162, the user is present with only a pre-specified set of options 170a-170f.

[0224] FIG. 13 illustrates a ninth screen 260 that displays overall compliance data generated by compliance system 150 for multiple healthcare facilities in first column 226, and that displays exit detection sensitivity compliance levels in column 228. That is, as can be seen from data selector column 222, the user has selected the first sensitivity level selector 224p, the second sensitivity level selector 224f, and the third sensitivity level selector 224q. Accordingly, software application 110 displays in second column 228 the levels of compliance of patient support apparatuses 20 in meeting the healthcare facility’s standards for all three sensitivity levels of exit detection system 140. In other words, software application 110 determine how often the patient support apparatuses 20 are set to each of the three different sensitivity levels, how often those selections meet the standards set by the healthcare facility, and then generates a compliance level for each of the different sensitivity levels and displays that in column 228.

[0225] It will be appreciated that, in some versions of software application 110, software application 110 may be configured to determine individual and / or overall compliance values that are based on theresponse time of caregiver to exit detection alerts. In other versions, software application 110 may keep track of the response times to exit detection alerts, but not factor that data into any compliance values. When using such response times as inputs to compliance values, the healthcare facility may input an acceptable amount of time it expects its caregiver to respond to an exit detection alert, and compliance system 150 can monitor and record compliance, or lack of compliance, with that expected time. Alternatively, or additionally, the user may input a range of acceptable times for responding to the exit detection alert, and use those ranges for monitoring compliance. In some versions, different compliance levels may be assigned based on different lengths of time it takes for a caregiver to respond to an exit detection alert.

[0226] I n some versions of software application 110, patient support apparatus server 86 is adapted to collect data from EMR server 136 regarding actual patient falls, and / or injuries to a patient caused by a patient fall. This data may include the time of the fall, the particular patient, and, in some cases, additional data regarding the fall. Software application 110 may be configured to add this fall data to its stored records and display this actual fall data in concert with the compliance data it gathers. In this manner, healthcare facility workers can see how their compliance levels, or lack of compliance levels, are correlated to, if at all, actual patient falls that occur in their healthcare facility. Such information can be useful to the healthcare facility for taking appropriate steps as an institution to help reduce and / or mitigate such patient falls.

[0227] In some versions, software application 110 may be configured to also provide any one or more of the functions of the software application 110 disclosed in commonly assigned Indian patent application serial number 202411053339 filed July 12, 2024, by applicant Stryker Corporation and entitled PATIENT SUPPORT APPARATUS SYSTEM, the complete disclosure of which is incorporated herein by reference.

[0228] It will be understood that, although the foregoing description has included various features and functions of software application 110, software application 110 may be modified to include a subset of any one or more of these features or functions, as well as to include additional features or functions beyond those described explicitly herein. For example, software application 110 may, in some versions, include any of the features or functions of the software application 110 disclosed in commonly assigned PCT patent application serial number PCT / US2024 / 014966 filed February 8, 2024, by applicant Stryker Corporation and entitled PATIENT SUPPORT APPARATUS SYSTEM; and / or the software application disclosed in commonly assigned PCT patent application PCT / US2023 / 036362 filed October 31, 2023, by applicant Stryker Corporation and entitled CAREGIVER ASSISTANCE SYSTEM, the complete disclosures of both of which are incorporated herein by reference.

[0229] Software application 110 may also be configured to send notifications and / or alerts in real time while monitoring one or more patient support apparatuses 20 for compliance levels. For example, software application 110 could send alerts to caregiver mobile devices including a time element, e.g., if head siderail isdown for more than 10 minutes for a high fall risk patient or head of bed angle is below 30 degrees for more than 20 minutes for an aspiration precaution patient, then send an alert. Still other types of situations could be reported with other time elements.

[0230] Software application 110 may also be configured to monitor head-of-bed angles for compliance with healthcare facility protocols, and such compliance values can be charted, generated, and / or displayed in any of the manners discussed herein. Such compliance monitoring for the head-of-bed angles may vary depending on different patient conditions / situations, e.g., on a ventilator, aspiration precautions, etc. For example, software application 110 could be configured to retrieve patient condition(s) from the EMR server 136, and then overlay the typical healthcare facility protocol to keep that patient’s head of bed angle at or above 30-degree angle (to minimize change of pneumonia or aspiration). If that angle goes below 30, software application 110 can notify caregivers immediately and / or after a time delay, and / or generate one or more compliance reports for the situation.

[0231] Various additional alterations and changes beyond those already mentioned herein can be made to the above-described versions. This disclosure is presented for illustrative purposes and should not be interpreted as an exhaustive description of all versions or to limit the scope of the claims to the specific elements illustrated or described in connection with these versions. For example, and without limitation, any individual element(s) of the described versions may be replaced by alternative elements that provide substantially similar functionality or otherwise provide adequate operation. This includes, for example, presently known alternative elements, such as those that might be currently known to one skilled in the art, and alternative elements that may be developed in the future, such as those that one skilled in the art might, upon development, recognize as an alternative. Any reference to claim elements in the singular, for example, using the articles “a,” “an,” “the” or “said,” is not to be construed as limiting the element to the singular.

Claims

CLAIMSWhat is claimed is:

1. A system for monitoring compliance, the system comprising a patient support apparatus and a server, wherein the patient support apparatus includes:a support surface adapted to support a patient thereon;a plurality of components adapted to be changed to different states;a controller adapted to forward status data and occupancy data to the server, the status data indicating which state each of the plurality of components is currently in, and the occupancy data indicating whether the patient support apparatus is currently occupied by the patient or not;wherein the server is adapted to perform the following:(i) receive the occupancy data and the status data from the patient support apparatus;(ii) receive admission data indicating whether the patient has been admitted or discharged from a healthcare facility;(iii) determine when the patient support apparatus is in a use state, the use state being defined by (a) the patient support apparatus being occupied by the patient; (b) the admission data indicating the patient is admitted to the healthcare facility; and (c) a fall risk classification being assigned to the patient;(iv) determine if each of the plurality of components is in a desired state while the patient support apparatus is in the use state; and(v) determine an overall compliance value for the patient support apparatus, wherein the overall compliance value is based on how many of each of the plurality of components are in their desired state while the patient support apparatus is in the use state.

2. The system of claim 1 wherein the server is adapted to receive first and second state data, the first state data identifying which of the different states of each of the plurality of components is the desired state when the fall risk classification is a high fall risk classification, and the second state data identifying which of the different states of each of the plurality of components is the desired state when the fall risk classification is a medium fall risk classification.

3. The system of claim 1 wherein the server is adapted to determine the overall compliance value by determining an individual compliance value for each of the plurality of components.

4. The system of claim 3 wherein the server is adapted to determine the individual compliance value for each of the plurality of components by determining if an individual component of the plurality of components is in the desired state while the patient support apparatus is in the use state.

5. The system of claim 4 wherein the server is adapted to determine the individual compliance value without considering what state the individual component is in while the patient support apparatus is not in the use state.

6. The system of claim 4 wherein the server is adapted to determine the overall compliance value by summing together each of the individual compliance values.

7. The system of claim 4 wherein the plurality of components includes the following: a brake, a siderail, an exit detection system, and a litter frame.

8. The system of claim 7 wherein the server is adapted to determine a first individual compliance value for the exit detection system by determining if the exit detection system is in an armed or disarmed state, and the server is adapted to determine a second individual compliance value for the exit detection system by determining if the exit detection system is armed at a first sensitivity level or a second sensitivity level.

9. The system of claim 1 wherein the patient support apparatus includes a location transceiver adapted to wirelessly receive location information from a location beacon, the controller is adapted to forward the location information to the server, and the server is adapted to determine what room the patient support apparatus is currently located in using the location information.

10. The system of claim 1 wherein the server is adapted to display a screen showing the overall compliance value of the patient support apparatus.

11. The system of claim 3 wherein the server is adapted to display a screen on which a user can select each one of the plurality of components, and the server is adapted to show the individual compliance value for whichever component is selected.

12. The system of claim 1 wherein the server is adapted to repetitively determine the overall compliance value and store the repetitively determined overall compliance values in a first record.

13. The system of claim 12 wherein the server is adapted to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and the server is adapted to store the caregiver assignments in the first record.

14. The system of claim 13 wherein the server is adapted to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, the server is adapted to determine a filtered overall compliance value of the patient support apparatus.

15. The system of claim 14 wherein the filtered overall compliance value only includes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and excludes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

16. The system of claim 3 wherein the server is adapted to repetitively determine the individual compliance values and store the repetitively determined individual compliance values in a first record.

17. The system of claim 16 wherein the server is adapted to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and the server is adapted to store the caregiver assignments in the first record.

18. The system of claim 17 wherein the server is adapted to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, the server is adapted to determine filtered individual compliance values of the patient support apparatus.

19. The system of claim 18 wherein the filtered individual compliance values only include the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and exclude the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

20. The system of claim 1 wherein the patient support apparatus includes an exit detection system adapted to issue an alert when the exit detection system is armed and the patient exits the patient support apparatus, the controller adapted to forward data indicating a response time to the server, and wherein the server is adapted to use the response time in determining the overall compliance value.

21. The system of claim 20 wherein the response time is equal to an amount of time from an issuance of the alert by the exit detection system to a caregiver silencing the alert.

22. A software application embodied in a non-transitory computer readable medium and adapted, when executed by a processor of a server, to instruct the server to perform the following:repetitively receive first status data from a patient support apparatus indicating a current state of a first component of the patient support apparatus;repetitively receive second status data from the patient support apparatus indicating a current state of a second component of the patient support apparatus;receive first user-defined data indicating a first desired state of the first component; receive second user-defined data indicating a second desired state of the second component; determine a first individual compliance value for the first component, the first individual compliance value indicating how often the first component is in the first desired state during a first time period; anddetermine a second individual compliance value for the second component, the second individual compliance value indicating how often the second component is in the second desired state during the first time period.

23. The software application of claim 22 wherein the software application is adapted to instruct the server to determine an overall compliance value for the patient support apparatus, wherein the overall compliance value is based on a combination of the first individual compliance value and the second individual compliance value.

24. The software application of claim 23 wherein the software application is adapted to instruct the server to exclude from the first time period any time in which any of the following are true: (a) the patient support apparatus is not occupied by a patient, (b) the patient is not admitted to a healthcare facility, and (c) the patient has not been assigned a fall risk classification.

25. The software application of claim 22 wherein the first user-defined data and the second user-defined data correspond to a first fall risk classification of a patient, and wherein the software application is adapted to instruct the server to receive third user-defined data indicating a third desired state of the first component and fourth user-defined data indicating a fourth desired state of the second component, wherein the third and fourth user-defined data correspond to a second fall risk classification of the patient.

26. The software application of claim 25 wherein the software application is adapted to instruct the server to determine whether the patient meets the first fall risk classification or the second fall risk classification, and if the patient meets the second fall risk classification to perform the following:determine a third individual compliance value for the first component, the third individual compliance value indicating how often the first component is in the third desired state during a third time period; anddetermine a fourth individual compliance value for the second component, the fourth individual compliance value indicating how often the second component is in the fourth desired state during the third time period.

27. The software application of claim 22 wherein the first component is one of a brake, a siderail, an exit detection system, or a litter frame of the patient support apparatus.

28. The software application of claim 22 wherein the first component is an exit detection system, the first desired state is an armed state, and the software application is adapted to instruct the server to perform the following:repetitively receive third status data from the patient support apparatus indicating a current sensitivity level of the exit detection system;receive third user-defined data indicating a desired sensitivity level of the exit detection system; anddetermine a sensitivity compliance value for the exit detection system, the sensitivity compliance value indicating how often the exit detection system is armed at the desired sensitivity level during the first time period.

29. The software application of claim 28 wherein the software application is adapted to instruct the server to determine an overall compliance value for the patient support apparatus, wherein the overallcompliance value is based on a combination of the first individual compliance value, the second individual compliance value, and the sensitivity compliance value.

30. The software application of claim 22 wherein the software application is adapted to instruct the server to receive location information from the patient support apparatus and to determine what room the patient support apparatus is currently located in using the location information.

31. The software application of claim 23 wherein the software application is adapted to instruct the server to display a screen showing the overall compliance value of the patient support apparatus.

32. The software application of claim 22 wherein the software application is adapted to instruct the server to display a screen on which a user can select the first component or the second component, to show the first individual compliance value in response to the user selecting the first component, and to show the second individual compliance value in response to the user selecting the second component.

33. The software application of claim 22 wherein the software application is adapted to instruct the server to allow a user to select the first time period.

34. The software application of claim 23 wherein the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to a patient at different times, and the server is adapted to store the caregiver assignments in a first record.

35. The software application of claim 34 wherein the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine a filtered overall compliance value of the patient support apparatus.

36. The software application of claim 35 wherein the filtered overall compliance value is determined by excluding from the first time period any time during which the particular caregiver was not assigned to the patient.

37. The software application of claim 22 wherein the software application is adapted to instruct the server to repetitively determine the first and second individual compliance values and store the repetitively determined first and second individual compliance values in a first record.

38. The software application of claim 37 wherein the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to a patient at different times, and to store the caregiver assignments in the first record.

39. The software application of claim 38 wherein the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine filtered first individual compliance values and filtered second individual compliance values of the patient support apparatus.

40. The software application of claim 39 wherein the filtered first individual compliance values only include the repetitively determined first individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and exclude the repetitively determined first individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient; andthe filtered second individual compliance values only include the repetitively determined second individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and exclude the repetitively determined second individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

41. The software application of claim 23 wherein the software application is adapted to instruct the server to determine a response time of a caregiver to an exit detection alert issued by the patient support apparatus, the response time being equal to an amount of time from an issuance of the exit detection alert to the caregiver silencing the exit detection alert.

42. The software application of claim 41 wherein the software application is adapted to instruct the server to use the response time in determining the overall compliance value.

43. The software application of claim 23 wherein the software application is adapted to instruct the server to determine the overall compliance value for the patient support apparatus by weighting the first individual compliance value differently from the second individual compliance value.

44. The software application of claim 23 wherein the software application is adapted to instruct the server to allow a user to specify a first weighting value and a second weighting value, and to determine the overall compliance value by weighting the first individual compliance value with the first weighting value and by weighting the second individual compliance value with the second weighting value.

45. A system for monitoring compliance, the system comprising a plurality of patient support apparatuses and a server, wherein each of the plurality of patient support apparatuses include:a support surface adapted to support a patient thereon;a plurality of components adapted to be changed to different states;a controller adapted to forward status data to the server, the status data indicating which state each of the plurality of components is currently in; andwherein the server is adapted to perform the following:(i) receive the status data from the plurality of patient support apparatuses;(ii) determine desired states for each of the components of each of the plurality of patient support apparatuses;(iii) determine a first set of overall compliance values for each of the patient support apparatuses, wherein each overall compliance value in the first set of overall compliance values is based on how often the plurality of components of an individual patient support apparatus of the plurality of patient support apparatuses are in desired states;(iv) receive a filtering selection from a user of the server, the filtering selection defining a subset of the first set of overall compliance values;(v) determine a second set of filtered overall compliance values by removing the subset from the first set of overall compliance values; and(vi) display the second set of filtered overall compliance values.

46. The system of claim 45 wherein the filtering selection defines at least one of the following: a particular location within a healthcare facility, a particular time period, a particular healthcare facility, a particular patient fall risk classification, or a particular caregiver.

47. The system of claim 45 wherein the server is adapted to display the second set of filtered overall compliance values in a graphical form.

48. The system of claim 47 wherein the graphical form includes a graph having an X-axis corresponding to time and a Y-axis corresponding to the filtered overall compliance values.

49. The system of claim 45 wherein the controller of each patient support apparatus of the plurality of patient support apparatuses is adapted to forward occupancy data to the server, wherein the occupancy data indicates whether each patient support apparatus of the plurality of patient support apparatuses is currently occupied by a patient or not; andwherein the server is adapted to perform the following:receive the occupancy data from the plurality of patient support apparatuses; and exclude from the determination of the first set of overall compliance values time periods during which respective ones of the patient support apparatuses are not occupied.

50. The system of claim 49 wherein the server is adapted to receive admission data from a second server, the admission data indicating whether patients have been admitted to a healthcare facility, and wherein the server is adapted to exclude from the determination of the first set of overall compliance values time periods during which respective patients of the plurality of patient support apparatuses are not admitted to the healthcare facility.

51. The system of claim 50 wherein the server is adapted to communicate with the plurality of patient support apparatuses via a network connection, and the server is adapted to exclude from the determination of the first set of overall compliance values time periods during which the network connection of respective patient support apparatuses of the plurality of patient support apparatuses is broken.

52. The system of claim 45 wherein the plurality of components includes the following: a brake, a siderail, an exit detection system, and a litter frame.

53. The system of claim 45 wherein the server is adapted to determine a combined compliance value, the combined compliance value generated by combining together multiple overall compliance values from a group of the patient support apparatuses.

54. The system of claim 53 wherein the group of multiple patient support apparatuses is selectable by a user.

55. The system of claim 54 wherein the server is adapted to present the user with at least one of the following groups of multiple patient support apparatuses to select from: (a) a first group of patient support apparatuses at a particular location within a healthcare facility; (b) a second group of patient support apparatuses assigned to patients having a particular fall risk classification; (c) a third group of patient support apparatuses having patients assigned to a particular caregiver; or (d) a fourth group of patient support apparatuses located at a particular healthcare facility.

56. A software application embodied in a non-transitory computer readable medium and adapted, when executed by a processor of a server, to instruct the server to perform the following:receive status data from a plurality of patient support apparatuses;determine desired states for each of a plurality of components of each of the plurality of patient support apparatuses;determine a first set of overall compliance values for each of the patient support apparatuses, wherein each overall compliance value in the first set of overall compliance values is based on how often the plurality of components of an individual patient support apparatus of the plurality of patient support apparatuses are in desired states;receive a filtering selection from a user of the server, the filtering selection defining a subset of the first set of overall compliance values;determine a second set of filtered overall compliance values by removing the subset from the first set of overall compliance values; anddisplay the second set of filtered overall compliance values.

57. The software application of claim 56 wherein the filtering selection defines at least one of the following: a particular location within a healthcare facility, a particular time period, a particular healthcare facility, a particular patient fall risk classification, or a particular caregiver.

58. The software application of claim 56 wherein the software application is adapted to instruct the server to display the second set of filtered overall compliance values in a graphical form.

59. The software application of claim 58 wherein the graphical form includes a graph having an X-axis corresponding to time and a Y-axis corresponding to the filtered overall compliance values.

60. The software application of claim 56 wherein the software application is adapted to instruct the server to perform the following:receive occupancy data from each of the patient support apparatuses in the plurality of patient support apparatuses, the occupancy data indicating whether each respective patient support apparatus is currently occupied by a patient or not; andexclude from the determination of the first set of overall compliance values time periods during which respective ones of the patient support apparatuses are not occupied.

61. The software application of claim 60 wherein the software application is adapted to instruct the server to perform the following:receive admission data from a second server, the admission data indicating whether patients have been admitted to a healthcare facility; andexclude from the determination of the first set of overall compliance values time periods during which respective patients of the plurality of patient support apparatuses are not admitted to the healthcare facility.

62. The software application of claim 61 wherein the software application is adapted to instruct the server to exclude from the determination of the first set of overall compliance values time periods during which a network connection of respective patient support apparatuses of the plurality of patient support apparatuses is broken.

63. The software application of claim 56 wherein the plurality of components includes the following: a brake, a siderail, an exit detection system, and a litter frame.

64. The software application of claim 56 wherein the software application is adapted to instruct the server to determine a combined compliance value, the combined compliance value generated by combining together multiple overall compliance values from a group of the patient support apparatuses.

65. The software application of claim 64 wherein the software application is adapted to instruct the server to allow a user to select the group of multiple patient support apparatuses.

66. The software application of claim 65 wherein the software application is adapted to instruct the server to present the user with at least one of the following groups of multiple patient support apparatuses toselect from: (a) a first group of patient support apparatuses at a particular location within a healthcare facility; (b) a second group of patient support apparatuses assigned to patients having a particular fall risk classification; (c) a third group of patient support apparatuses having patients assigned to a particular caregiver; or (d) a fourth group of patient support apparatuses located at a particular healthcare facility.

67. A software application embodied in a non-transitory computer readable medium and adapted, when executed by a processor of a server, to instruct the server to perform the following:receive occupancy data from a patient support apparatus, the occupancy data indicating whether the patient support apparatus is currently occupied by a patient or not;receive status data from the patient support apparatus, the status data indicating which state each of a plurality of components of the patient support apparatus is currently in;receive admission data indicating whether the patient has been admitted or discharged from a healthcare facility;determine when the patient support apparatus is in a use state, the use state being defined by (a) the patient support apparatus being occupied by the patient; (b) the admission data indicating the patient is admitted to the healthcare facility; and (c) a fall risk classification being assigned to the patient;determine if each of the plurality of components is in a desired state while the patient support apparatus is in the use state; anddetermine an overall compliance value for the patient support apparatus, wherein the overall compliance value is based on how many of each of the plurality of components are in their desired state while the patient support apparatus is in the use state.

68. The software application of claim 67 wherein the software application is adapted to instruct the server to receive first and second state data, the first state data identifying which states of each of the plurality of components is the desired state when the fall risk classification is a high fall risk classification, and the second state data identifying which states of each of the plurality of components is the desired state when the fall risk classification is a medium fall risk classification.

69. The software application of claim 67 wherein the software application is adapted to instruct the server to determine the overall compliance value by determining an individual compliance value for each of the plurality of components.

70. The software application of claim 69 wherein the software application is adapted to instruct the server to determine the individual compliance value for each of the plurality of components by determining if an individual component of the plurality of components is in the desired state while the patient support apparatus is in the use state.

71. The software application of claim 70 wherein the software application is adapted to instruct the server to determine the individual compliance value without considering what state the individual component is in while the patient support apparatus is not in the use state.

72. The software application of claim 70 wherein the software application is adapted to instruct the server to determine the overall compliance value by summing together each of the individual compliance values.

73. The software application of claim 70 wherein the plurality of components includes the following: a brake, a siderail, an exit detection system, and a litter frame.

74. The software application of claim 73 wherein the software application is adapted to instruct the server to determine a first individual compliance value for the exit detection system by determining if the exit detection system is in an armed or disarmed state, and to determine a second individual compliance value for the exit detection system by determining if the exit detection system is armed at a first sensitivity level or a second sensitivity level.

75. The software application of claim 67 wherein the software application is adapted to instruct the server to receive location information from the patient support apparatus and determine what room the patient support apparatus is currently located in using the location information.

76. The software application of claim 67 wherein the software application is adapted to instruct the server to display a screen showing the overall compliance value of the patient support apparatus.

77. The software application of claim 69 wherein the software application is adapted to instruct the server to display a screen on which a user can select each one of the plurality of components, and to show the individual compliance value for whichever component is selected.

78. The software application of claim 67 wherein the software application is adapted to instruct the server to repetitively determine the overall compliance value and to store the repetitively determined overall compliance values in a first record.

79. The software application of claim 78 wherein the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and to store the caregiver assignments in the first record.

80. The software application of claim 79 wherein the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine a filtered overall compliance value of the patient support apparatus.

81. The software application of claim 80 wherein the filtered overall compliance value only includes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and excludes the repetitively determined overall compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

82. The software application of claim 69 wherein the software application is adapted to instruct the server to repetitively determine the individual compliance values and store the repetitively determined individual compliance values in a first record.

83. The software application of claim 82 wherein the software application is adapted to instruct the server to receive caregiver assignments indicating which caregivers are assigned to the patient at different times, and to store the caregiver assignments in the first record.

84. The software application of claim 83 wherein the software application is adapted to instruct the server to allow a user to specify a particular caregiver, and, in response to specifying the particular caregiver, to determine filtered individual compliance values of the patient support apparatus.

85. The software application of claim 84 wherein the software application is adapted to instruct the server to only include the repetitively determined individual compliance values from the first record that were determined while the particular caregiver was concurrently assigned to the patient, and to exclude therepetitively determined individual compliance values from the first record that were determined while the particular caregiver was not concurrently assigned to the patient.

86. The software application of claim 67 wherein the software application is adapted to instruct the server to receive a response time from the patient support apparatus and to use the response time in determining the overall compliance value, the response time measuring an amount of time from an issuance of an exit alert by an exit detection system to a caregiver silencing the exit alert.

87. The software application of claim 67 wherein the use state is defined by an absence of any caregivers within a same room in which the patient support apparatus is located.

Images