PATIENT COMMUNICATION
Fault tolerance This fault tolerance is one of the key operational advantages of a TCP/IP based nursecall system as it ensures that all patient calls are registered on the nurses’ station unit providing the functionality of a wireless system without the signal interruption issues that can be associated with wireless technology. However, this reliability is only guaranteed if the nursecall system is fully TCP/IP based using a single IP network to carry data from source to destination without passing through any intermediate network protocols en-route. This involves designing a TCP/IP system that sends all data over a single IP network. However, not all IP nursecall systems are designed in this way. Some are based on a TCP/IP backbone for the complex nurses’ station end of the system but then use another protocol – such as Lonworks, EIB, or Canbus – at ward level. The use of additional protocols could, potentially, increase the risk of data being lost in transmission or retransmitted in the wrong sequence, reducing the overall integrity of the system.
Approaches to IP While a system that uses a TCP/IP backbone should still offer many of the benefits associated with TCP/IP based technology, including remote monitoring, ease of reconfiguration and data logging, these can be less straightforward in the way that they are delivered if the system is not fully TCP/IP- based. Problems can also arise as the hospital’s needs grow or change and there is a requirement to introduce additional technologies, bedhead services or links to hospital data applications. While some might argue that the use of
TCP/IP for the core call system as well as the system backbone provides an over-specified solution, in fact, procurement of a high specification system that is likely to reduce capital expenditure further down the line is aligned to best value principles. Only a fully TCP/IP-based system can be effectively integrated with media streams (providing radio at the bedside), voice systems (VOIP), the building management system, internet systems for email or sms alerts, or
38
communication of events to clinical staff via LED corridor displays, touchscreen all in one PC, or standard PCs… and who knows what other technologies in the future too. Conversely, proprietary speech or non-IP
based systems incorporated into a IP nursecall system limit its overhaul, expansion and integration possibilities. For example, while a fully IP-based system can integrate VoIP at the bed head as a simple extension number, allowing either a patient or a clinician to initiate a speech call, this becomes more complicated if the nursecall system is not centralised on a single IP network. While integration of additional
technologies is possible with any IP-based nursecall system, the essential consideration is that fully IP-based systems can provide one low-cost interface for all additional integrated systems, rather than requiring multiple protocols to be supported to provide for each additional feature. This means that, over time, a fully-IP-based system will be more cost- effective. Following the TCP/IP typical ‘Star Topology’ every device is connected in a fully IP-based system using industry standard Ethernet cabling. Each device can be programmed and interrogated uniquely, and therefore programmed uniquely for specific functionality. Power and data can be provided to a device using a single cable, reducing installation times and costs and avoiding the scheduling, disruption and infection control issues associated with wiring upgrades. It is also important to note that a fully-IP
based nursecall system will make it easier for some additional features to operate at optimum quality. For example, higher bandwidth data streams such as entertainment and speech can be delivered more easily through a source to destination
IP network than they can through a series of independent protocols. With a fully IP-based nursecall system, one integrated multi-media head end can service an entire site using a multicast Ethernet protocol: Internet Group Management Protocol (IGMP). Designed to filter the audio data streams so that the end- user only gets the channel they select, this requires a bandwidth at the bed head and allows regulation of the data bandwidths on the Ethernet switches, complexities that cannot be achieved if the system is not on an end-to-end IP network.
Functionality differences One of the key differences in functionality between a fully IP-based system and one with an IP backbone is the disparity in remote management capabilities. Fully-IP based systems can be monitored by the maintenance department or remotely via an ADSL link and firewall, allowing fault identification and rectification. This offers potential reductions in the preventative maintenance regime and reduces the risk of system failure, downtime and time-consuming repairs. The ease and efficiency of remote monitoring of the entire system, as opposed to individual zones, also has implications for planning, care delivery and reporting. In the hospital environment it is inevitable
that needs change, in response to changes in patient demographic, hospital resources, policy or developments in medical science. As a consequence, space may need to be reallocated, perhaps involving the subdivision of a ward, for example, or the expansion of a specialist department. Traditionally, such changes have meant re-wiring the existing nursecall system. A fully IP-based nursecall system, however, can be reconfigured remotely, enabling the hospital to reallocate
‘A fully IP-based nursecall system, however, can be reconfigured remotely, enabling the hospital to reallocate beds to different wards and different nurses’ stations without having to make any physical changes.’
IFHE DIGEST 2013
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84