Patent Description:
A medical facility may include a plurality of rooms where each room may include one or more medical devices. Each medical device (MD) may be permanently fixed within a room or movable between the plurality of rooms. In addition, each medical device may be wirelessly controlled by a respective control device (CD) and the control device may be permanently fixed within a room or movable between the plurality of rooms. Accordingly, given the portable nature of medical devices and/or control devices, as well as the use of such devices with a plurality of subjects, systems and/or methods are desirable to ensure that a particular medical device is in wireless communication with a particular control device.

Wireless radios typically can transmit in excess of many meters. In a hospital environment, where there may be a wall unit or other device used to communicate with devices in a room, this could mean a plurality of devices could appear in a list of devices to pair with in a typical wireless pairing scenario, including devices in neighboring rooms or areas. A caregiver may not be able to easily select which device is in their room. For example, if a hospital bed were to be paired with the incorrect wall unit, the nurse call and bed data would be associated with the incorrect bed/occupant. This could delay care or result in improper dosage of medication (due to incorrect subject weight). Thus, the pairing process benefits from being as automated as possible and easier for the caregiver to select the proper room device.

<CIT> discloses a method to verify a wireless connection between an infusion pump and a remote controller. The controller providing identification information specific to the controller to the infusion pump. The infusion pump providing identification information specific to the infusion pump to the controller. Control of the infusion pump by the controller is then permitted upon acceptance of the remote controller's identification information in the infusion pump and acceptance of the infusion pump's identification information in the controller.

<CIT> discloses a method for associating electronic devices for communicating data. A first device receives a discovery-for-pairing message from a second device. The first device transmits a pairing response to the second device on determination that the first device is pairable. The devices are paired in response to the second device receiving the message that the first device is pairable.

<CIT> discloses an automatically pairable medical device comprising a processor configured to receive, over a first communication channel an identifier associated with a control device within a line-of-sight of the medical device. The processor further configured to receive at least one identifier over a second communications channel associated with at least one control device. The medical device then automatically pairs with the control device associated with the matching identifier over the second communications channel.

<CIT> discloses a method for pairing a portable device with a medical device. The method includes displaying an association code on a dynamic display of the medical device and determining whether the portable device is positioned relative to the medical device within a predetermined range of positioning parameters. The portable device is paired to the medical device only if the portable devie is positioned relative to the medical device within the predetermined range of positioning parameters and the association code is optically read from the dynamic display of the medical device with the portable device.

In one aspect, a pairable medical device may include a communication system configured to communicate via a communication channel, a processor, a display device configured to display an interface, and a memory storing program instructions. The program instructions, when executed by the processor, cause the processor to scan for wireless broadcasts based upon received input or satisfying a scanning criterion. The program instructions also cause the process to receive, based upon the scan, identifying data wirelessly broadcast from a plurality of control devices. The program instructions further cause the processor to output information to the interface identifying the control device. The identifying data received from the plurality of control devices is presented on the interface according to a filtering criterion and a sorting criterion. The sorting criterion comprises location information within the identifying data or respective signal strengths of each wireless broadcast. The program instructions further cause the processor to receive input from the interface selecting one of the plurality of control devices. The program instructions further cause the processor to receive a command from the control device. The program instructions further cause the processor to physically interact with a user based upon the command received from the control device. The program instructions further cause the processor to send wireless confirmation of pairing to the control device and subsequently send wireless confirmation of unpairing to the control device. The program instructions further cause the processor to perform a scan for wireless broadcasts in response to the unpairing, based upon received input or satisfying the scanning criterion.

In such an aspect, according to some embodiments, the pairable medical device comprises a medical bed, a pump, a rail-mounted lift, or a computer. In an additional aspect, the scanning criterion is based upon the medical device being plugged in for power. In another aspect, the scanning criterion is based upon the medical device having brakes engaged. In an additional aspect, the filtering criterion comprises a device manufacturer, a device type, or a device model.

In a further aspect, a pairable control device may comprise a communication system configured to communicate via a communication channel, a processor, and a memory storing program instructions. The program instructions, when executed by the processor, cause the processor to wirelessly broadcast self-identifying data based upon being unpaired. The program instructions further cause the processor to receive pairing confirmation from a medical device. The program instructions further cause the processor to stop the wireless broadcast in response to the received pairing confirmation. The program instructions additionally cause the processor to receive a subsequent unpairing confirmation from the medical device. The program instructions further cause the processor to resume broadcasting the self-identifying data in response to receiving the unpairing confirmation.

In such another aspect, according to some embodiments, the self-identifying data comprises a first data field comprising a device name and a second data field comprises manufacturer data. In other aspects, the second manufacturer data further comprises an identifier unique to a manufacturer, followed by between <NUM> to <NUM> octets of data.

In a further aspect, a system for assisted pairing of devices may include a pairable control device that may include a first communication system configured to communicate via a communication channel, a first processor, and a memory storing first program instructions. The memory storing program instructions, when executed by the first processor, cause the first processor to wirelessly broadcast self-identifying data based upon being unpaired. The program instructions further cause the first processor to receive pairing confirmation from a medical device. The program instructions further cause the first processor to stop the wireless broadcast in response to the received pairing confirmation. The program instructions further cause the first processor to receive a subsequent unpairing confirmation from the medical device. The program instructions further cause the first processor to resume broadcasting the self-identifying data in response to receiving the unpairing confirmation. The medical device may include a display device configured to display an interface a second communication system configured to communicate via the communication channel. The medical device may be additionally configured to scan for wireless broadcasts based upon received input or satisfying a scanning criterion. The medical device may be further configured to receive, based upon the scan, identifying data wirelessly broadcast from a plurality of control devices. The medical device may be further configured to output information to the interface identifying the control device. The identifying data received from the plurality of control devices is presented on the interface according to a filtering criterion and a sorting criterion. The sorting criterion comprises location information within the identifying data or respective signal strengths of each wireless broadcast. The medical device may be further configured to receive input from the interface selecting the control device. The medical device may be further configured to send wireless confirmation of pairing to the control device. The medical device may be further configured to subsequently send wireless confirmation of unpairing to the control device. The medical device may be further configured to perform a scan for wireless broadcasts in response to the unpairing, based upon received input or satisfying the scanning criterion.

In such a further aspect, according to some embodiments, self-identifying data comprises a first data field comprising a device name and a second data field comprises manufacturer data comprises an identifier unique to a manufacturer, followed by between <NUM> to <NUM> octets of data. In other aspects, the scanning criterion is based upon the medical device being plugged in or the medical device having brakes engaged. The filtering criterion may include a device manufacturer, a device type, or a device model.

In yet another aspect, a method for assisted medical device wireless pairing with a control device may include scanning, at the medical device, for wireless broadcasts based upon received input or satisfying a scanning criterion. The method may further include receiving, based upon the scan, identifying data wirelessly broadcast from a plurality of control devices. The method may further include outputting, to an interface at the medical device, information identifying the control device. The identifying data received from the plurality of control devices may be presented on the interface according to a filtering criterion and a sorting criterion. The sorting criterion may comprise location information within the identifying data or respective signal strengths of each wireless broadcast. The method may further include receiving input from the interface selecting one of the plurality of control devices. The method may further include sending wireless confirmation of pairing to the control device. The method may further include receiving a command from the control device. The method may further include physically interacting with a user based upon the command received from the control device. The method may further include subsequently sending wireless confirmation of unpairing to the control device. The method may further include performing an updated scan for wireless broadcasts in response to the unpairing, based upon received input or satisfying the scanning criterion.

In such still a further aspect, according to some embodiments, the pairable medical device comprises a medical bed, a pump, a rail-mounted lift, or a computer. In another such aspect, the scanning criterion may be based upon the medical device being plugged in. In other such aspects, the scanning criterion may be based upon the medical device having brakes engaged. Additional such aspects may include a filtering criterion comprising a device manufacturer, a device type, or a device model.

In still a further aspect, a method for assisted control device wireless pairing with a medical device may include wirelessly broadcasting self-identifying data from the control device based upon being unpaired. The method may further include receiving pairing confirmation from the medical device. The method may further include stopping the wireless broadcast in response to the received pairing confirmation. The method may further include receiving a subsequent unpairing confirmation from the medical device. The method may further include resuming broadcasting of the self-identifying data in response to receiving the unpairing confirmation.

In such still a further aspect, according to some embodiments, the self-identifying data may comprise a first data field comprising a device name and a second data field comprises manufacturer data. Still other such aspects may include the second manufacturer data further comprising an identifier unique to a manufacturer, followed by between <NUM> to <NUM> octets of data.

In still a further aspect, a method for assisted wireless pairing of a medical device and a control device may include wirelessly broadcasting, from the control device, self-identifying data based upon being unpaired. The method may further include scanning, at the medical device, for wireless broadcasts based upon received input or satisfying a scanning criterion. The method may further include receiving at the medical device, based upon the scan, identifying data wirelessly broadcast from a plurality of control devices. The method may further include outputting, from the medical device to the interface, information identifying the control device. The identifying data received from the plurality of control devices may be presented on the interface according to a filtering criterion and a sorting criterion. The sorting criterion may comprise location information within the identifying data or respective signal strengths of each wireless broadcast. The method may further include receiving input from the interface selecting one of the plurality of control devices. The method may further include sending wireless confirmation of pairing from the medical device to the control device. The method may further include receiving, at the control device, pairing confirmation from the medical device. The method may further include stopping the wireless broadcast from the control device in response to the received pairing confirmation. The method may further include subsequently sending wireless confirmation of unpairing from the medical device to the control device. The method may further include receiving at the control device a subsequent unpairing confirmation from the medical device. The method may further include resuming broadcasting of the self-identifying data at the control device in response to receiving the unpairing confirmation from the medical device. The method may further include performing an updated scan for wireless broadcasts at the medical device in response to the unpairing, based upon received input or satisfying the scanning criterion.

In such yet a further aspect, according to some embodiments, the self-identifying data may include a first data field comprising a device name and a second data field comprises manufacturer data comprises an identifier unique to a manufacturer, followed by between <NUM> to <NUM> octets of data. The scanning criterion may be based upon the medical device being plugged in or the medical device having brakes engaged. In other such aspects, the filtering criterion may include a device manufacturer, a device type, or a device model.

Additional features and advantages of the embodiments described herein will be set forth in the detailed description which follows, and in part will be readily apparent to those skilled in the art from that description or recognized by practicing the embodiments described herein, including the detailed description which follows, the claims, as well as the appended drawings.

Reference will now be made in detail to embodiments to pair a medical device and a control device using wireless radio frequency, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts. Various embodiments of the present disclosure are depicted in <FIG>. In general, a medical facility <NUM> may include a plurality of rooms and/or a plurality of floors (e.g., Rooms A and B on one floor, other rooms may be on other floors). In such aspects, one or more medical devices (e.g. MDA, MDB, and/or MDC) and one or more control devices (CDA, CDB, CDC, and/or CDD), may be distributed amongst the rooms, floors (see <FIG>), and/or within sub-spaces within a given room (e.g., a large triage room with multiple beds, hospital rooms that are shared by <NUM> or more subjects, etc.).

In one aspect, referring to <FIG>, a control device (e.g., CDD) and a medical device (e.g., MDC) may be fixedly positioned within a room (e.g., Room B). A control device CD may be any device capable of pairing/unpairing (also referred to herein as connecting/disconnecting) with a medical device, and sending commands to control a medical device. By way of non-limiting example, a control device may be any device capable of wirelessly pairing with a medical device and issuing commands to the medical device, such as a tethered hand control unit, a wireless hand control unit, a wall mounted control unit, any type of computer (tablet, smartphone, laptop, desktop, etc.), and the like. A medical device may any medical device capable of wirelessly pairing/unpairing with a control device, and implementing commands received from a control device. By way of non-limiting example, a medical device may be a medical bed, a pump, a rail-mounted lift, a computer, and the like. In this aspect, a control device (CDA, CDB, CDC, CDD, and/or the like) may be permanently located in a particular location, such as room A or room B. When unpaired, a control device may broadcast data having multiple fields, such as a device name field. A device name field (hereinafter also referred to as an identifier) may be any suitable text, such as a location descriptor ("Control Device A Room A East") that would typically be human-readable and descriptive of its location. In some aspects, a control device may be relocated to another location and/or have its device name field updated accordingly. A manufacturer-specific data field may include customized data used in the advertising of packets as part of the data broadcast. In aspects, some utilizing Bluetooth for wireless communications, the manufacturer-specific data field may include a company identifier, brand identifier, model identifier, device-type identifier, and the like. In some aspects, this may be followed by additional data, such as <NUM> octets of data, although any suitable amount/type of data may be utilized in other aspects. Any suitable wireless protocol may be utilized, such as Bluetooth, BLE, Zigbee, Z-Wave, 6LoWPAN, Thread, and the like.

In some aspects, control devices (CDA, CDB, CDC, CDD, and/or the like) may wirelessly transmit (e.g., via a Bluetooth RF signal and/or radio frequency identification (RFID)) their identifiers (CDAID, CDBID, CDCID, CDDID, and/or the like) and/or manufacturer-specific data fields (CDAManu, CDBManu, CDCManu, CDDManu, and/or the like) to medical devices (MDA, MDB, MDC, and/or the like). Since a wireless signal may penetrate the walls and/or floors of the medical facility <NUM>, a number of medical devices within range (e.g., up to <NUM> feet for Class <NUM> Bluetooth, up to <NUM> feet for Class <NUM> Bluetooth, and/or the like) may wirelessly receive the control device identifiers (CDAID, CDBID, CDCID, and/or the like). Another control device CDA resides in a different room, namely room A. Both CDA and CDD are broadcasting data, which include the respective device name fields (CDAID and CDDID) and the respective manufacturer-specific data fields (CDAManu and CDDManu). By contrast, other control devices are paired with medical devices, and therefore not broadcasting data. Within room A, medical device MDA is paired with control device CDB. Similarly, within room B, medical device MDB is paired with control device CDC. Paired control devices CDB and CDC are not broadcasting data in this aspect because, once paired, control devices may not broadcast data again until unpaired. In other aspects, control devices may continue broadcasting data to other medical devices during pairing. Each medical device (e.g., MDC) may be configured to scan its wireless communication channel (e.g., Bluetooth channel). Medical device MDC scans the identifiers and manufacturer-specific data received from control devices CDA and CDD. A medical device in this aspect may not continue to scan once paired to a control device. In other aspects a medical device may continue to scan while paired to a control device.

Continuing with the same aspect, <FIG> depicts a block diagram illustrating control devices wirelessly advertising to a medical device and a plurality of medical devices wirelessly paired to other control devices that are distributed amongst the plurality of rooms of the medical facility. In some aspects, a control device CDA may pair with a medical device MDC such that the medical device MDC pairs to the identified control device CDA. Once paired, the control device CDA may transmit control signals to the medical device MDC and the medical device MDC may begin to receive control signals (also known as instructions herein) from the control device CDA. Additionally, the medical device MDC may transmit status updates to the control device CDA and the medical device MDC may receive status updates from the control device CDA. Since the medical device MDC is now paired, control device CDA is no longer broadcasting data. By contrast, control device CDD is still not paired and thus continues broadcasting data. In another aspect, if the medical device MDC stops receiving instructions (or any other data in some aspects) from control device CDA, medical device MDC may be configured to automatically disassociate from control device CDC over their respective wireless communication channels and/or vice versa if the control device CDC no longer receives any data from the medical device MDC. As discussed herein, a medical device and/or control device may provide an indicator (visual, audio, and the like) of pairing and/or unpairing.

Continuing with the aspect of <FIG>, <FIG> depicts an exemplary medical device graphical interface <NUM> illustrating a plurality of wireless control devices selectable according to signal strength <NUM> and/or room location within the medical facility. The medical device graphical interface <NUM> in this aspect is presented on a touch display located on a medical device, although any suitable device capable of displaying a graphical interface <NUM> may be utilized. Here, the medical device is scanning for data broadcast from control devices after having been wheeled into room A. As discussed herein, medical device actions such as applying the brakes or being plugged into the wall for power may initiate the medical device to begin scanning. As shown in the medical device graphical interface <NUM>, three control devices are presented as selectable options. Each medical device may be presented with its device name field <NUM>, which in this aspect may include the room number in the device name. In some aspects, the device name filed <NUM> may be updated by any appropriate user or administrator. In other aspects, any other suitable identifying information may be included (floor, building, control device type, and the like) in the device name field <NUM>. Other types of data fields may be utilized for display such as room number, floor number, building, and the like, by which control devices may be sorted and/or filtered. Control devices may be filtered by any suitable criteria, such as manufacturer or control device type, which may be contained in the manufacturer-specific data field. In this aspect, control devices from other manufacturers are not displayed even if they are broadcasting data. This can help ensure compatibility and the integrity of communications between the medical device and any control devices satisfying the filtering criteria. Among control devices that meet the filtering criteria, such as being from a specified manufacturer, control device options may be sorted by any suitable criteria. In this aspect, control devices CDA, CDE, CDF, are sorted by their respective Bluetooth signal strengths <NUM>, although any quantity and/or type of sorting criteria may be utilized, such as room number, floor number, manufacturer, and the like.

<FIG> depicts illustrative internal components of a control device <NUM> that are communicatively coupled to one another to provide wireless link pairing with and control of a medical device, according to one or more embodiments of the present disclosure. As shown in <FIG>, the control device <NUM> may include a local interface <NUM> (e.g., a bus) that communicatively interconnects the various components, including, but not limited to, a processing device <NUM>, memory <NUM>, input/output hardware <NUM>, network interface hardware <NUM>, and/or a data storage device <NUM>.

The processing device <NUM>, such as a computer processing unit (CPU), may be the central processing unit of the control device <NUM>, performing calculations and logic operations required to execute a program. The processing device <NUM>, alone or in conjunction with one or more of the other elements disclosed in <FIG>, is an illustrative processing device, computing device, processor, or combination thereof, as such terms are used in this disclosure.

The memory <NUM>, such as read only memory (ROM) and random access memory (RAM), may constitute illustrative memory devices (i.e., non-transitory, processor-readable storage media). Such memory <NUM> may include one or more programming instructions thereon that, when executed by the processing device <NUM>, cause the processing device <NUM> to complete various processes, such as the processes described herein. Optionally, the program instructions may be stored on a tangible computer-readable medium such as a digital disk, flash memory, a memory card, a USB drive, an optical disc storage medium (e.g., Blu-ray™, CD, DVD), and/or other non-transitory processor-readable storage media.

In some embodiments, the program instructions contained on the memory <NUM> may be embodied as a plurality of software modules, where each module provides programming instructions for completing one or more tasks. For example, as shown in <FIG>, the memory <NUM> may contain one or more of operating logic <NUM>, communications logic <NUM>, and UI logic <NUM>. It should be understood that the various logic modules described herein with respect to <FIG> are merely illustrative, and that other logic modules, including logic modules that combine the functionality of two or more of the modules described hereinabove, may be used without departing from the scope of the present disclosure.

Still referring to <FIG>, the data storage device <NUM>, which may generally be a storage medium that is separate from the memory <NUM>, may contain a data repository for storing electronic data and/or the like relating to the location of the control device <NUM>, an identification of the control device <NUM>, configuration settings, UI data, and/or the like. The data storage device <NUM> may be any physical storage medium, including, but not limited to, a hard disk drive (HDD), memory, removable storage, and/or the like. While the data storage device <NUM> is depicted as a local device, it should be understood that the data storage device <NUM> may be a remote storage device that is remotely located from the control device <NUM>, such as, for example, a server computing device or the like. Illustrative data that may be contained within the data storage device <NUM> may include, for example, location data <NUM>, configuration data <NUM>, UI data <NUM>, pairing data <NUM>, and/or the like. Pairing data <NUM> may include identification data (serial number, etc.) one or more medical device identifiers to which the control device <NUM> is or has been paired via the methods as described herein.

The input/output hardware <NUM> may generally include a wireless system <NUM>, an indicator <NUM>, a location system <NUM>, and a user interface system <NUM>. The wireless system <NUM> may include a transceiver <NUM> configured to transmit and to receive wireless signals (e.g., RF, Bluetooth, UWB, and/or the like) according to the respective wireless protocols. In some aspects, data transmission techniques including encryption/decryption, forward error correction, and/or the like may be instituted. The indicator <NUM> may include a light emitting diode, indicator light, and/or the like. The location system <NUM> may include a Global Positioning System (GPS), a Global Navigation Satellite System (GLONASS), a Wi-Fi locating system, and/or the like. The user interface system <NUM> may include a display <NUM> and/or user interface controls <NUM> configured to receive control inputs for transmission via the input/output hardware <NUM> and to display outputs received from the input/output hardware <NUM>.

The network interface hardware <NUM> may generally provide the control device <NUM> with an ability to interface with one or more external devices, such as, for example, a medical facility server, a nurse station, and/or the like. Communication with external devices may occur using various communication ports (not shown). An illustrative communication port may be attached to a communications network, such as the Internet, an intranet, a local network, a direct connection, and/or the like.

It should be understood that in some embodiments, the input/output hardware <NUM> and the network interface hardware <NUM> may be combined into a single device that allows for communications with other devices, regardless of whether such other devices are located within the control device <NUM>.

It should be understood that the components illustrated in <FIG> are merely illustrative and are not intended to limit the scope of the present disclosure. More specifically, while the components in <FIG> are illustrated as residing within the control device, this is a non-limiting example. In some embodiments, one or more of the components may reside external to the control device. Similarly, one or more of the components may be embodied in other devices not specifically described herein. Furthermore, various control devices are described herein (e.g., <FIG>) and are non-limiting examples. Other control devices may include a user's personal cell-phone, a nurse's call system device, and/or the like with wireless communication channel capabilities.

<FIG> depicts illustrative internal components of a medical device <NUM> that are communicatively coupled to one another to provide wireless link pairing with a control device, according to one or more embodiments of the present disclosure. As shown in <FIG>, the medical device <NUM> may include a local interface <NUM> (e.g., a bus) that communicatively interconnects the various components, including, but not limited to, a processing device <NUM>, memory <NUM>, input/output hardware <NUM>, network interface hardware <NUM>, and/or a data storage device <NUM>.

The processing device <NUM>, such as a computer processing unit (CPU), may be the central processing unit of the medical device <NUM>, performing calculations and logic operations required to execute a program. The processing device <NUM>, alone or in conjunction with one or more of the other elements disclosed in <FIG>, is an illustrative processing device, computing device, processor, or combination thereof, as such terms are used in this disclosure.

In some embodiments, the program instructions contained on the memory <NUM> may be embodied as a plurality of software modules, where each module provides programming instructions for completing one or more tasks. For example, as shown in <FIG>, the memory <NUM> may contain one or more of operating logic <NUM>, communications logic <NUM>, and movement logic <NUM>. It should be understood that the various logic modules described herein with respect to <FIG> are merely illustrative, and that other logic modules, including logic modules that combine the functionality of two or more of the modules described hereinabove, may be used without departing from the scope of the present disclosure.

Still referring to <FIG>, the data storage device <NUM>, which may generally be a storage medium that is separate from the memory <NUM>, may contain a data repository for storing electronic data and/or the like relating to the location of the medical device <NUM>, an identification of the medical device <NUM>, configuration settings, and/or the like. The data storage device <NUM> may be any physical storage medium, including, but not limited to, a hard disk drive (HDD), memory, removable storage, and/or the like. While the data storage device <NUM> is depicted as a local device, it should be understood that the data storage device <NUM> may be a remote storage device that is remotely located from the medical device <NUM>, such as, for example, a server computing device or the like.

Illustrative data that may be contained within the data storage device <NUM> may include, for example, location data <NUM>, configuration data <NUM>, pairing data <NUM>, and/or the like. Pairing data <NUM> may include one or more control device identifiers to which the medical device <NUM> is or has been paired via the methods as described herein.

The input/output hardware <NUM> may generally include a user interface system <NUM>, a wireless system <NUM>, an indicator <NUM>, and a location system <NUM>. The user interface system <NUM> may include a display <NUM> and/or user interface controls <NUM> configured to receive control inputs for transmission via the input/output hardware <NUM> and to display outputs received from the input/output hardware <NUM>. The wireless system <NUM> may include a transceiver <NUM> configured to transmit and to receive wireless signals (e.g., RFID, RF, Bluetooth, UWB, and/or the like) according to the respective wireless protocols. In some aspects, data transmission techniques including encryption/decryption, forward error correction, and/or the like may be instituted. The indicator <NUM> may include a light emitting diode, indicator light, and/or the like. The location system <NUM> may include a Global Positioning System (GPS), a Global Navigation Satellite System (GLONASS), a Wi-Fi locating system, and/or the like.

The network interface hardware <NUM> may generally provide the medical device <NUM> with an ability to interface with one or more external components, such as, for example, a medical facility server, a nurse station, and/or the like. Communication with external devices may occur using various communication ports (not shown). An illustrative communication port may be attached to a communications network, such as the Internet, an intranet, a local network, a direct connection, and/or the like.

It should be understood that in some embodiments, the input/output hardware <NUM> and the network interface hardware <NUM> may be combined into a single device that allows for communications with other devices, regardless of whether such other devices are located within the medical device <NUM>.

It should be understood that the components illustrated in <FIG> are merely illustrative and are not intended to limit the scope of this disclosure. More specifically, while the components in <FIG> are illustrated as residing within the medical device <NUM>, this is a non-limiting example. In some embodiments, one or more of the components may reside external to the medical device <NUM>. Similarly, one or more of the components may be embodied in other devices not specifically described herein.

<FIG> depicts one illustrative wireless link pairing system <NUM> including a rail-mounted lift <NUM> as an illustrative medical device and a plurality of remote devices <NUM>, <NUM>, <NUM>, as control devices, according to one or more embodiments of the present disclosure. Referring to <FIG>, the rail-mounted lift <NUM> is coupled to a rail <NUM>. According to various aspects, the rail <NUM> may extend along a ceiling of a room (e.g., Room A of <FIG>), along a ceiling of more than one room (e.g., Room A and Room B of <FIG>), and/or the like. More specifically, the rail-mounted lift <NUM> includes a lift unit <NUM> that is slidably coupled to the rail <NUM> via a carriage <NUM>. The lift unit <NUM> may be used to support and/or lift a subject with a lifting strap <NUM> which is coupled to a motor (not shown) contained within the lift unit <NUM>. The motor facilitates extending or retracting the lifting strap <NUM> from the lift unit <NUM>, thereby raising and lowering a subject attached to the lifting strap <NUM>. According to various embodiments, a subject may be attached to the lifting strap <NUM> with a sling bar <NUM> or a similar accessory attached to the lifting strap <NUM> via a coupling <NUM>. The sling bar <NUM> or a similar accessory may be attached to a harness or a sling in which the subject is positioned, thereby facilitating the lifting operation.

Various components of the rail-mounted lift <NUM>, such as the lift unit <NUM> and/or components thereof, may be operated with a tethered hand control unit <NUM>, a wireless hand control unit <NUM> and/or a wall-mounted control unit <NUM> communicatively couplable to the lift unit <NUM>. In view of <FIG>, the tethered hand control unit <NUM> may be directly wired to the lift unit <NUM> and/or wirelessly coupled or paired to the lift unit <NUM> (e.g., according to the methods described herein) to facilitate remote operation of the rail-mounted lift <NUM>. According to various aspects, the tethered hand control unit <NUM> may include a display <NUM> and one or more user interface controls 322A (e.g., to extend lifting strap <NUM>), 322B (e.g., to retract lifting strap <NUM>). Similarly, the wireless hand control unit <NUM> may be wirelessly coupled or paired to the lift unit <NUM> (e.g., according to the methods described herein) and may include a display <NUM> and one or more user interface controls 326A (e.g., to extend lifting strap <NUM>), 326B (e.g., to retract lifting strap), 326C (e.g., to translate lift unit <NUM> in a first lateral direction L1 along rail <NUM>), 326D (e.g., to translate lift unit <NUM> in a second lateral direction L2 along rail <NUM>), and the wall-mounted control unit <NUM> may be wirelessly coupled or paired to the lift unit <NUM> (e.g., according to the methods described herein) and may include a display <NUM> and one or more user interface controls 330A (e.g., to extend lifting strap <NUM>), 330B (e.g., to retract lifting strap <NUM>), 330C (e.g., to translate lift unit <NUM> in a first lateral direction L1 along rail <NUM>), 330D (e.g., to translate lift unit <NUM> in a second lateral direction L2 along rail <NUM>). Further user interface controls of the wall-mounted control unit <NUM> may activate the lift unit <NUM>, pair a subject with the lift unit <NUM>, return the lift unit <NUM> to a "home" position/location, receive information from the lift unit <NUM> (e.g., battery status, magnitude of load supported by the lift unit, and/or the like), actuate an emergency stop of the lift unit <NUM>, reset the lift unit <NUM>, and/or the like.

Referring to <FIG>, according to further aspects of the present disclosure, the rail-mounted lift <NUM> (e.g., <FIG>) may be operated with a sling bar control unit <NUM> positioned on the sling bar <NUM> and/or a coupling control unit <NUM> positioned on the coupling <NUM> attached to a distal "D" end of the lifting strap <NUM>. The sling bar control unit <NUM> may be wirelessly coupled or paired to the lift unit <NUM> (e.g., according to the methods described herein) and may include one or more user interface controls 402A (e.g., to extend lifting strap <NUM>), 402B (e.g., to retract lifting strap <NUM>). Similarly, the coupling control unit <NUM> may be wirelessly coupled or paired to the lift unit <NUM> (e.g., according to the methods described herein) and may include one or more user interface controls 412A (e.g., to extend lifting strap <NUM>), 412B (e.g., to retract lifting strap <NUM>).

In light of <FIG>, <FIG>, a plurality of control devices (e.g., a tethered hand control unit <NUM>, a wireless hand control unit <NUM>, a wall-mounted control unit <NUM>, a sling bar control unit <NUM>, a coupling control unit <NUM>, and/or the like) may already be physically present in a room in the aspect. In other aspects, control devices may be physically brought into the room, and/or physically taken out of the room. According to some aspects of the present disclosure, a medical device (e.g., the rail-mounted lift <NUM>) may be fixedly positioned within a room. In such aspects, referring to <FIG> and <FIG>, control devices that physically remain in that room (e.g., wall-mounted control unit <NUM>) and physically remain coupled to the medical device itself in that room (e.g., tethered hand control unit <NUM>, coupling control unit <NUM>), remain wirelessly connected to the medical device, and the medical device may be configured to remain paired with one or more of such control devices. For example, the rail-mounted lift <NUM> may store pairing data (<FIG>, reference <NUM>, e.g., associated CD IDs in a fixed pairings file), in its data storage device (<FIG>, reference <NUM>) for each control device that physically remains in its room and/or physically remains coupled to the rail-mounted lift <NUM>. Further in such aspects, referring to <FIG> and <FIG>, one or more control devices may not physically remain in that room (e.g., wireless hand control unit <NUM>, sling bar control unit <NUM>). In such aspects, the medical device may be configured to not only pair with such control devices as they are brought into a room but also periodically or continually monitor pairings with such control devices. Periodically, as described herein, may refer to a regularly occurring interval or time period (e.g., every "X" seconds, every "Y" minutes, and/or the like). Continuing the example, the rail-mounted lift <NUM> may store pairing data (e.g., <FIG>, reference <NUM>, e.g., associated CD IDs in a transient pairings file), in its data storage device (e.g., <FIG>, reference <NUM>) for each control device that may not physically remain in its room and the rail-mounted lift <NUM> may periodically determine whether each control device identifier (e.g., CD ID) is still being received over its wireless communication channel. According to various aspects, if control device input (e.g., stored in a transient pairings file) is still being wirelessly received, the medical device (e.g., rail-mounted lift) may remain paired with that control device and if the paired control device identifier is not still being wirelessly received, the medical device may automatically disassociate from that control device (e.g., the medical device considered as physically taken out of the room).

According to other aspects of the present disclosure, a medical device (e.g., a rail-mounted lift <NUM>) may not be fixedly positioned within a room. For example, a lift unit may be moved along a rail <NUM> (<FIG>) from one room (e.g., <FIG>, Room A) to another room (e.g., <FIG>, Room B). In such aspects, referring to <FIG> and <FIG>, control devices that physically remain coupled to the medical device itself (e.g., tethered hand control unit <NUM>, coupling control unit <NUM>), remain wirelessly connected to the medical device and the medical device may be configured to remain paired with all such control devices. For example, the rail-mounted lift <NUM> may store pairing data (<FIG>, reference <NUM>, e.g., associated CD IDs in a fixed pairings file), in its data storage device (<FIG>, reference <NUM>) for each control devices that physically remains coupled to the rail-mounted lift <NUM>. Further in such aspects, referring to <FIG> and <FIG>, one or more control devices may not be physically coupled to the medical device itself. This may include control devices that physically remain in a given room (e.g., wall-mounted control units <NUM>) and/or control devices that may not physically remain in any given room (e.g., wireless hand control unit <NUM>, sling bar control unit <NUM>). In such aspects, the medical device may be configured to not only pair with such control devices but also periodically or continually monitor pairings with such control devices. Continuing the example, the rail-mounted lift <NUM> may store pairing data (e.g., <FIG>, reference <NUM>, e.g., associated CD IDs in a transient pairings file), in its data storage device (e.g., <FIG>, reference <NUM>) for each control device that physically remains in a given room and that may not physically remain in any given room and the rail-mounted lift <NUM> may periodically determine whether each control device identifier (e.g., CD ID) is still communicating with the rail-mounted lift <NUM> over its wireless communication channel.

According to various aspects, upon detecting movement (e.g., translation along rail <NUM>) the medical device may be configured to continually monitor pairings with such control devices. Accordingly, if a control device identifier (e.g., CD ID of a wireless hand control unit <NUM> being used to translate or move the rail-mounted lift <NUM> between rooms, CD ID of a sling bar control unit <NUM> being moved with the rail-mounted lift <NUM> between rooms) or other data is still being wirelessly received, the medical device (e.g., rail-mounted lift) may remain paired with the control device(s) and if the control device identifier (e.g., CD ID of a wall-mounted control unit <NUM> in a former room, CD ID of a sling bar control unit <NUM> not moved to a new room) or other data from the control device is not still being wirelessly received, the medical device may automatically disassociate from any such control device(s). Further in such an aspect, the medical device may be configured to provide on its graphical interface <NUM> for pairing new control devices (e.g., wall-mounted control unit <NUM> in new room) as the medical device transitions between rooms.

<FIG> depicts a flow diagram of an illustrative method <NUM> for pairing a medical device and a control device using a wireless channel, according to one or more embodiments of the present disclosure. Referring to <FIG>, a medical device MDX <NUM> may identify and pair with a control device CDX <NUM>, wherein the dashed vertical line in the center of the flow diagram demarcates the respective operations of the medical device MDX <NUM> and the control device CDX <NUM>. At block <NUM>, the CDX may be unpaired and wirelessly broadcast self-identifying data, which may include a device name and/or manufacturer-specific data (manufacturer, brand, model, device, type, and the like). At block <NUM>, the MDX may scan for wireless broadcasts based upon receiving input (such as a user pressing a button on MDX or a button within the medical device interface) or satisfying a scanning criterion. For example, MDX may be a bed, in which setting its brakes or being plugged into a wall for power may automatically cause MDX to scan for control devices. Setting the brakes or being plugged into the wall may be criteria that indicate, for example, that MDX has reached its intended destination (such as a particular room or partition within a room) and scanning is now appropriate. In this way, MDX can conserve power by avoiding unnecessary scanning until a destination has been reached.

At block <NUM>, the medical device MDX may receive the identifying data wirelessly broadcast from CDX. Although the wireless broadcast from CDX in block <NUM> is depicted as intersecting within the flowchart prior to the scanning by MDX at block <NUM>, the wireless broadcast in block <NUM> may intersect at any point up and/or including reception of the CDX at block <NUM>. At block <NUM>, the medical device MDX may output information to the interface (e.g., <FIG>) identifying the control device CDX, in which the manufacturer-specific data may be filtered (e.g., handheld control devices from a specific manufacturer may be displayed for selection on the interface). At block <NUM>, the medical device MDX may receive input at the interface selecting the control device. For example, a user may touch a screen selecting CDX from among other eligible control devices. At block <NUM>, the medical device MDX may send wireless confirmation of the pairing to the control device CDX. In this aspect, the medical device interface may add the medical device MDX to the list of selectable medical devices. At block <NUM>, the control device CDX may receive pairing confirmation. In some aspects, the control device CDX, may provide an indication of pairing/unpairing events, such as the indicator <NUM> in <FIG>, which may be a light such as an LED. At block <NUM>, the control device CDX may stop its wireless broadcast due to being paired with a medical device MDX. At block <NUM>, the control device CDX may send one or more commands to the medical device MDX. At block <NUM>, the medical device MDX may receive the one or more commands from the control device CDX. At block <NUM>, based on the received command(s), the medical device MDX may physically interact with a user. As used herein, physical interaction with a user may include, by way of non-limiting examples, taking diagnostics or measurements (size/proportions, weight, temperature, heartrate, glucose, blood pressure, brainwaves, biorhythms, and the like) of a user, introducing or removing any suitable substance from any part of a user, diagnosing and/or alleviating/treating any disease or other ailment of a user, and/or assisting with the support, mobility, positioning, restraint, and/or comfort of the user.

At block <NUM>, the medical device MDX may send wireless confirmation of unpairing, which may be accomplished via the medical device interface. This may be, for example, when the medical device MDX (a bed in this non-limiting example) is being moved to another room. At block <NUM>, the control device CDX may receive subsequent confirmation of the unpairing. In some aspects, this may entail a visual, audio, or other indication associated with the control device CDX, such as the indicator <NUM> in <FIG>. At block <NUM>, the control device CDX may resume broadcasting self-identifying data in order to become paired with another medical device, such as a different bed that may be wheeled into the room in which CDX resides. At block <NUM>, the medical device MDX may perform an updated scan for wireless broadcasts. This may be done, for example, when the medical device MDX has been wheeled into another room such that the brakes are engaged and/or the medical device MDX is plugged into the wall.

<FIG> depicts a flow diagram of an illustrative method <NUM> for a control device to issue commands or control inputs to a paired medical device, according to one or more embodiments of the present disclosure. According to various aspects, method <NUM> may be utilized for all control functions or only certain functions (e.g., actuating a motor, turning on a pump, and/or the like). Referring to <FIG>, at block <NUM>, a control device CDX may be paired with a medical device MDX over its wireless communication channel, as described herein. At decision block <NUM>, the control device CDX may be configured to determine (e.g., based on inputs received via user interface controls <NUM> of <FIG>) whether a command or control input is to be issued or transmitted to the medical device MDX. If it is determined that a command or control input is not to be issued or transmitted to MDX, the control device CDX may remain paired with the medical device identifier MDXID over its wireless communication channel at block <NUM>. If it is determined that a command or control input is to be issued or transmitted to the medical device MDX, the control device CDX may be configured to determine whether the wireless communication channel is weak (e.g., below a predetermined threshold wireless signal strength) at decision block <NUM>.

If it is determined that the wireless communication channel is weak, the control device CDX may be configured to automatically disassociate from the medical device MDX over the wireless communication channel at block <NUM>. At block <NUM> (shown in phantom as an optional operation), the control device CDX may be configured to update its visual indicator to reflect the disassociation (e.g., LED off). If it is determined that the wireless communication channel is not weak, the control device CDX may be configured to, at block <NUM>, issue the command or control input to the medical device MDX over its wireless communication channel. According to such aspects, if a medical device MDX is moved to an out-of-range location (e.g., no longer within the wireless range of the control device CDX), then the control device CDX may be unable to issue a command or control input to the medical device MDX, despite being otherwise able to over a strong wireless communication channel.

According to another embodiment, referring back to <FIG>, the control device <NUM> may include a location system <NUM> and the medical device <NUM> may include a location system <NUM>. In such aspects, the medical device <NUM> and/or the control device <NUM> may be configured to further transmit their respective location information (e.g., MD LOC, CD LOC) with their respective identifiers (e.g., MD ID, CD ID) as described herein. In such aspects, the control device <NUM> may be configured to compare a received MD LOC (from the medical device) with its CD LOC as part of its process of pairing with a medical device. In some aspects, an initial range (e.g., about <NUM> to about <NUM> radius) may be used for initial pairing and a control range (e.g., average size of room) may be used for disassociation. In further aspects, the control device <NUM> may be configured to adjust/correct its CD LOC as well as the received MD LOC using a medical facility location MF LOC location beacon with known coordinates. Likewise, the medical device <NUM> may be configured to adjust/correct its MD LOC using a medical facility location MF LOC location beacon with known coordinates. According to various embodiments, such aspects may be used to further confirm the other identification methods as described herein. According to the various embodiments described herein, each wireless communication channel (e.g., Bluetooth channel) may be configured as a single-path communication channel or a dual-path communication channel.

It should be appreciated that while elements are described as optional, this is only with respect to one or more illustrative embodiments, such as program instructions stored in <NUM> <FIG> and <NUM> <FIG>, as well as the features depicted in <NUM> <FIG>, <NUM> <FIG>, and <NUM> <FIG>. That is, these elements may be required in other embodiments. In addition, the depiction of these elements as optional does not imply that the processes described with respect to other elements in the respective figures are required.

It should now be understood that the systems and methods described herein are suitable for pairing a medical device and a control device using a wireless link (e.g., Bluetooth channel). In particular, the systems and methods described herein identify a configurable, pairable wireless connection (e.g. Bluetooth channel) to be used to execute control actions for a medical device (e.g., a portable medical bed) to ensure that the control inputs are coming from a control device (e.g., a tethered hand control unit, a wireless hand control unit, a wall-mounted control unit, a sling bar control unit, a coupling control unit, and/or the like) located in the same room as the medical device. Such systems and methods ensure that the control inputs coming from the control device are only directed to a medical device based upon user input received at the medical device that selects for pairing and/or control of the medical device.

Claim 1:
A system for assisted pairing of devices, the system comprising:
a pairable control device (<NUM>), comprising:
a first communication system configured to communicate via a communication channel;
a processor (<NUM>); and
a memory (<NUM>) storing first program instructions, the program instructions, when executed by the first processor, causing the first processor to:
wirelessly broadcast self-identifying data based upon being unpaired;
receive pairing confirmation from a medical device (<NUM>);
stop the wireless broadcast in response to the received pairing confirmation;
receive a subsequent unpairing confirmation from the medical device (<NUM>); and
resume broadcasting the self-identifying data in response to receiving the unpairing confirmation; and
the medical device (<NUM>), comprising:
a display device configured to display an interface (<NUM>); and
a second communication system configured to communicate via the communication channel, wherein medical device (<NUM>) is configured to:
scan for wireless broadcasts based upon received input or satisfying a scanning criterion;
receive, based upon the scan, identifying data wirelessly broadcast from a plurality of control devices (<NUM>);
output information to the interface (<NUM>) identifying the plurality of control devices (<NUM>);
wherein the identifying data received from the plurality of control devices (<NUM>) is presented on the interface (<NUM>) according to a filtering criterion and a sorting criterion;
wherein the sorting criterion comprises location information within the identifying data or respective signal strengths (<NUM>) of each wireless broadcast;
receive input from the interface (<NUM>) selecting one of the plurality of control devices (<NUM>);
send wireless confirmation of pairing to the selected control device (<NUM>);
subsequently send wireless confirmation of unpairing to the control device (<NUM>); and
perform a scan for wireless broadcasts in response to the unpairing, based upon received input or satisfying the scanning criterion.