Table Of Contents
IT and Voice Services Departments
Nurse Connect-Radianta Overview
Beacon Alert Manager CUAE Architecture
Radianta Beacon Alert Manager—CUAE Platform
Solution Features and Components
Unified Communications Components
Radianta Beacon Alert Manager Components
Nurse Connect-CUAE QoS Considerations
Cisco Unified Communications Manager
Nurse Connect Voice Considerations
Voice over Wireless LAN (VoWLAN)
High Availability (HA) Considerations
Cisco Unified Communications Component Cisco Infrastructure
Security and Authentication Components
IP Phone and Beacon Alert Manager/CUAE Communication
Voice Gateway to Rauland Responder IV Nurse Call System
Active Directory and Cisco Secure ACS
Communication Manager Configuration
Nurse Call Voice Callback Configuration
XML Services Redundancy on CUCM
Subscribing the Phone to the Beacon Alert Manager XML Service
Creating an Extension Mobility Device Profile
Installing Radianta Nurse Connect
Verifying CUAE Application Install
Accessing the Radianta Nurse Connect Administration Page
Installing Nurse Connect License
Configuring Alert Destinations (Outputs)
Configuring TAP Connections (Nurse Call Systems)
Assignment of Patients to Caregivers
Management and Operational Considerations
Nurse Connect Logs and Reports
Netformx DesignXpert Supported Design
Precidia Technologies iPocket232™ Configuration
Unable to Receive Alerts on Cisco IP Phones
Callback to Patient Rooms is Not Working
Call to a Patient Room is of Poor Quality
Miscellaneous Operational issues
Cisco Nurse Connect
Solution Overview
Cisco Nurse Connect is a Cisco Validated Design (CVD) solution for both the traditional healthcare and long-term care (LTC) environments. The solution improves the communication between the patient or resident and the assigned care provider. By deploying Cisco Nurse Connect, the daily workflow of the nursing staff is greatly enhanced—resulting in less time wasted and improvements in overall care. This is accomplished by the direct integration of Telelocator Alphanumeric Protocol (TAP)-based Rauland Responder IV nurse call system to the Cisco Unified Communications platform and Cisco Unified Mobility through the Radianta's Beacon Alert Manager running within the Cisco Unified Application Environment (CUAE).
With this solution, hospital caregivers can improve care and increase patient satisfaction, as well as reduce the overall cost of care. Hospital patients can request nursing assistance from their bedside and obtain immediate audio communication with their assigned caregiver. Without Nurse Connect, long delays and the fragmentation of clinical workflows are typically encountered resulting in additional inquiries by the staff or patient.
For residents of LTC facilities, requests for assistance can be automatically directed to the care provider assigned to the resident. Two-way audio as well as video communications can be established between the care provider and resident within the privacy of their apartment. Optionally, the video-based communication can be extended to on-call physicians who might be located at another LTC facility or possibly a separate office.
The Nurse Connect solution is an extension to existing TAP-based nurse call systems from vendors such as Rauland. The solution builds upon the Unified Communication framework already present in many healthcare organizations. For those hospitals or LTC facilities that do not have a Unified Communication system deployed, the solution solidifies the need to upgrade from legacy dial-tone only communication systems to a truly modern and extensible Unified Communication solution from Cisco.
In other cases, Nurse Connect can also be integrated to a legacy communication system, providing many of the benefits without the need of a forklift upgrade of the entire phone system. In all cases, the underlying architecture uses Cisco network architectures for various places in the network (PIN) that include the traditional campus, branch, and data center network architectures. In addition, the solution uses the Cisco Unified Mobility architecture through the use of Voice over Wireless LAN (VoWLAN) technologies.
Note
The Nurse Connect solution provides a secondary alerting mechanism only. At no time are Cisco endpoints used as the primary alerting source. The source of the primary alerting mechanism remains with the nurse call system.
Executive Summary
The challenges facing both the traditional acute, ambulatory, and aged care markets are well known problems that stem across many domains from the cost of care, regulations and compliance, lack of information, and an increase of the aged population with multiple chronic diseases. A common open standards-based framework for interoperability is required to enable secure information sharing, simplify organizational processes, improve system performance, and reduce costs. Common quotes on the subject include:
•
•
•
•
•
•
The focus is to give time and resource back to the nursing staff where inefficiencies were created by poor and fragmented communication flows. Improvements can be seen when a highly mobile staff can receive information anywhere within a hospital campus. The time and resources saved can be channeled back to their primary role within the hospital—specifically to providing patient care. The goal of the Cisco Nurse Connect solution is to improve patient care and reduce the operational overhead through the use of the Cisco Unified Communications solution.
Solution Description
The Cisco Nurse Connect CVD solution is an end-to-end system integration that provides hospital IT and system integrators alike with the information needed to design and deploy a system that supports many of the popular TAP-based nurse call systems available in the market today. The solution's primary focus is to facilitate a more efficient information flow between patients and caregivers, as well as among care provider staff members.
Note
Nurse Call Integration
Cisco's Nurse Connect solution complements the primary notification mechanism being used by a particular TAP-based nurse call vendor such as Rauland's Responder IV. Nurse call alerts are those that have been initiated by the patient directly, typically through the use of a pull station or bedside-attached, nurse call device. These alarms are still delivered to the primary nurse call station while secondary messages can be delivered to a series of Cisco Unified IP Phones—both wired and wireless. The Cisco Unified IP Phone 7921G and 7925G 802.11-based phones allow the care provider to establish voice communication to the patient bedside through a single callback button.
After triaging the call, the care provider can optionally set service codes that automatically generate an appropriate workflow that is once again communicated to the appropriately qualified caregiver. An example might be a patient request to alter medication. Such a call would traditionally require the assigned care provider to locate an available licensed practice nurse (LPN) or registered nurse (RN). With Nurse Connect, the assigned primary caregiver can optionally request those services from an appropriately skilled caregiver—typically an RN. The steps traditionally required to manually locate the RN are automated, enhancing both the quality of care while at the same time improving the workflow of two or more caregivers.
Pager Integration
It is commonplace to find text pagers in many healthcare and LTC facilities worldwide. These systems are often connected through a middleware product, or directly connected to the nurse call system. In many cases, the nurse call system in question cannot support two pager-based outputs simultaneously. This situation can result in the need to perform forklift cutovers of the entire pager system to the new voice integrated solution.
The Radianta Beacon Alert Manager for Nurse Connect solution eliminates the issue of an all-or-nothing cutover by providing seamless integration to existing TAP-based paging systems. Because pagers are covered to VoIP handsets over time, the healthcare or LTC organization can migrate at a controlled pace—again providing a cost-effective and patient-safety conscious approach.
Foundational Technology
The foundational technology used to support the delivery of this information can be broken down into the following groups:
•
•
•
•
•
•
Each of the preceding architectural references are addressed at the Cisco's design zone website at the following URL: www.cisco.com/go/designzone.
The Cisco Medical-Grade Network (MGN) architecture describes a framework of best practices for various technologies. It is a requirement and therefore assumed that the best practices of the horizontal technologies used in this solution are strictly observed. For more information on the set of best practices used for campus, data center, mobility, and other applicable technologies, refer to the various design guides found at http://www.cisco.com/go/designzone. In brief, the key technologies of this solutions provide the following important networking advantages:
•
•
•
•
Nurse Connect Target Market
The Cisco Nurse Connect solution is focused on solving communication bottlenecks in healthcare-based facilities ranging from small long-term care (LTC) organizations up to large multi-hospital medical facilities. The benefits are even more apparent in facilities that have large nursing staff that have not had the benefit of mobile communication. Such facilities typically have poor information flow between departments and have difficulty achieving optimal clinical workflow processes.
The solution is targeted at the following:
•
•
•
•
•
•
•
•
In each of the above cases, the Nurse Connect solution supports TAP-based nurse call systems. The solution has been validated against Rauland's Responder IV TAP-based systems.
Solution Benefits
The Cisco Nurse Connect solution is focused on improving communication flow inside a LTC or traditional healthcare environment. The primary focus is on the care provider who is typically very mobile within one or more patient floors. For LTC organizations, the primary focus group is centered on nursing and premise-based on-call staff.
The ultimate recipients of the benefits of this solution are the patients within the facility. In many cases, they are typically not mobile—limited to a specific room or bed. The common theme is the need for immediate care or possibly direct communication with an assigned caregiver. This solution automates that process, providing immediate benefits in access to care for the patient or resident and a much more efficient workflow for the care provider.
Patients and Residents
Benefits to patients and residents are as follows:
•
•
•
•
Caregivers
Benefits to caregivers are as follows:
•
•
•
•
•
•
IT and Voice Services Departments
Benefits for IT and voice services departments are as follows:
•
•
•
•
Solution Scope
To ensure a successful deployment of the Cisco Nurse Connect solution, key design and implementation best practices should be observed. These center around an infrastructure that is compliant with the Cisco MGN. The necessary foundational network characteristics can be achieved through adherence to the set of Cisco best practices for each of the technologies being deployed and outlined in the Cisco MGN architecture.
This document focuses on the system considerations for campus infrastructure, Cisco Unified Communications for Cisco Unified Communications Manager, Cisco Unified IP Phones, and Cisco Unified Mobility technologies in collaboration with the Cisco Unified Application Environment. Design considerations and implementation specifics across key Cisco products—in the context of integration with a TAP-based nurse call system from Rauland (Responder IV)—are covered in this document.
This document does not cover the installation steps required for each product in the solution. For detailed configuration information, consult the specific product documentation. Because the solution spans a wide array of technologies and product sets from both Cisco and third parties (Rauland and Radianta), it is recommended that a certified installation partner be consulted during the planning, configuration, installation, and training phases of a deployment to achieve optimal results.
Nurse Connect
Challenges Experienced
Care providers are faced with an ever increasing number of challenges in today's global healthcare and long-term care industries. Both patient and resident demands are increasing due to an aging population with a lower mortality rate. As the age of the baby-boomer population continues to increase, so too are the numbers of long-term chronic diseases typically encountered. Both the increasingly aged population and multiple chronic conditions are affecting the healthcare and long-term care market in ways not previously experienced.
At the same time that the demands placed on the care system increases, shrinking numbers of medical professionals are available within the industry to meet demand. For the nursing staff assigned to provide care to the patient or resident, nurse call events are typically received at a central nursing station and require overhead audio paging or, worse yet, audio room paging. Disruptions like these on an already stressed clinical workflow result in inefficiencies and overall lower patient safety and satisfaction.
In order to streamline the care process, Cisco developed the Nurse Connect solution. This solution provides the correct and most appropriate caregivers with the information that they need, wherever they are within the healthcare LTC facility. Through the use of the Cisco Unified Wireless Mobility and Cisco Unified Communication technologies, the caregiver can now be presented with timely information that they can view and act upon in a more efficient and streamlined manner.
Using the nurse call system, the care provider can request assistance of various medical emergency teams such as the code, cesarean, respiratory, and cardiac. These alerts are received in real-time as requested at the point-of-care, or from the central nursing station. In addition, the solution provides a means to provide voice communication directly between the patient and caregiver, further enhancing patient care while at the same time providing increases in efficiency.
Nurse Connect Services
The Cisco Nurse Connect solution is comprised of a number of different use cases for functions that build upon a common architectural framework. The solution uses a Cisco Medical-Grade compliant infrastructure which support both a Cisco Unified Communications and Cisco Unified Wireless network architecture.
Nurse Connect Overview
In order to provide efficient patient and resident care, communication among those under care and the nursing staff is critical for optimal care. In any healthcare-related facility—whether it is acute, outpatient, or an aged care facility—a nurse call or life safety system is sure to be deployed within the environment. With the addition of the Cisco Nurse Connect to an existing or yet to be installed nurse call system, augmentation of the system results in a communication system that optimizes the care staff, as well as providing a higher level of satisfaction for the person under care.
The solution provides for text, audio, and vibratory-based alerting wherever the caregiver is located within a facility. The solution uses the Cisco Unified IP Phone 7921G and 7925G wireless handsets that provide the caregiver with unprecedented reliability and communication capabilities.
Figure 1 shows a sample workflow of a traditional nurse call system.
Figure 1 Traditional Nurse Call System Workflow
After the deployment of Nurse Connect, Figure 2 shows the efficiencies gained by all parties when using Nurse Connect to support the nurse call services.
Figure 2 Nurse Connect Workflow
By using the Cisco Nurse Connect solution, resident and patient safety, as well as the overall clinical efficiency, are vastly improved.
Solution Architecture
Mobile Care Architecture
The Cisco Nurse Connect solution plays a critical part in providing information to caregivers both reliably and in real-time. To accomplish this, the solution is based on the Cisco MGN architecture to provide high availability and scalability. It is beyond the scope of this document to discuss the Cisco MGN architecture in detail. For more information about the MGN, refer to the link provided below.
It is important to point out that achieving a level of availability for such systems requires careful review and planning of the end-to-end network topology as it applies to the following:
•
•
•
•
•
For information on the Cisco MGN architecture, refer to http://www.cisco.com/go/healthcare. These designs are based upon the various horizontal technologies that provide the service framework required to support the solution. The horizontal architectures can be found at the following URL: http://www.cisco.com/go/designzone.
The Nurse Connect supporting architectures are described in the campus, data center, and VoWLAN design guides among others.
Figure 3 provides a high-level overview of the typical network architecture upon which this solution would be deployed.
Figure 3 Nurse Connect Architecture Overview
Deployment Model
The deployment of the Nurse Connect solution is based on the campus and data center network architecture designs. Each floor of a hospital should follow the access design's aggregating traffic up to the distribution and core components of the campus network.
It is strongly recommended that the location of the CUAE application server and the Cisco Unified Communication Manager(s) be within the data center. In facilities that plan on using the Cisco Unified IP Phone 7921G and 7925G wireless phones, strict adherence to RF site surveys must be followed for wireless deployment. For details, see the "Voice over Wireless LAN (VoWLAN)" section for the wireless voice prerequisites.
To achieve the most optimal voice and data coverage, follow the design recommendations found in the VoWLAN design guide located at http://www.cisco.com/go/designzone.
Note
Nurse Connect-Radianta Overview
Note
Nurse Connect
The CUAE-based Beacon Alert Manager application server was developed by Radianta (http://www.radianta.com) and is marketed by Radianta as Beacon Alert Manager for Cisco Nurse Connect. By using CUAE as both the development and deployment platform, the evolution of the solution—employing numerous other advanced features—is ensured. CUAE positions the solution to add additional messaging inputs (HL7, XML/SOAP, LBS, HTTP web services, and so on) and to support various display output types—such as Digital Media Signage (DMS), wireless handsets, and smart dual-mode phones.
The CUAE 2.5(1) application server combined with the Beacon Alert Manager for Cisco Nurse Connect from Radianta provides the following features:
•
•
•
•
•
•
•
•
•
•
•
•
The patient or resident nurse call system collects and transfers TAP-based alarm information to the CUAE -based Nurse Connect application using a TCP/IP-based socket connection. These events are then sent to the specified care provider assigned to the patient or resident. The originally configured operation of the nurse call system is not altered and remains the primary alerting mechanism.
Figure 4 illustrates a high-level architecture of a typical Rauland Responder IV nurse call system. The Rauland Responder IV nurse call system consists of a number of different components that can be grouped into the following broad categories:
•
•
•
•
•
Figure 4 Cisco and Rauland Responder IV-Nurse Call Integration
Beacon Alert Manager CUAE Architecture
The Nurse Connect CUAE application server is deployed and installed on an Intel-based server running Windows 2003 R2 SP1. Version 1.1 of the solution facilitates the flow of information between a Rauland Responder IV TAP-based nurse call system to various models of Cisco Unified IP phones, as well as WaveWare-based pagers. See Figure 5.
Figure 5 Beacon Alert Manager CUAE Architecture
Figure 6 shows the typical interaction between a Rauland Responder IV system and CUAE 2.5(1) environment running Radianta's Beacon Alert Manager for Cisco's Nurse Connect application. Included in the overview is the process followed for a single button audio callback to the patient bedside.
Figure 6 Nurse Connect Dial-back Call Flow (Rauland Responder IV)
In Figure 6, the following occurs:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
When the dial-back occurs, the dial-back phone number for the patient bedside nurse call endpoint must be determined. Within the Radianta's Beacon Alert Manager application, a static table is created at install time that maps each patient's bed to a unique phone number. The dial-back phone number is determined and configured within the Rauland Responder IV nurse call system during the initial installation and turn-up.
The phone number of the patient bedside device is static and does not change over time. Because of its static nature, the room/bed-to-dial-back phone number mapping only needs to be completed once within Radianta's Nurse Connect GUI-based administration utility.
The process is very straight forward. Once the TAP message is received with a patient's room/bed number in the message, Radianta Beacon Alert Manager software parses the room and bed number fields from the message and cross references that information with the information configured within the Radianta Beacon Alert Manager system for the specific nurse call system. This process is shown in Figure 7.
Figure 7 Nurse Connect Dial-back Detail (Rauland Respond IV)
Nurse Call Flow
Nurse Call
The Nurse Connect service is used to provide connectivity to TAP-based nurse call systems. In Release 1.1 of Radianta's Beacon Alert Manager for Cisco's Nurse Connect, the only validated TAP-based nurse call system is the Rauland Responder IV system. Radianta created a TAP-based plugin for CUAE that accepts TAP-based alerts and determines the appropriate handset assigned to the caregiver. Due to variations in the implementation of the TAP protocol combined with that of differing room/bed notation, the only presently verified TAP connection is Rauland Responder IV.
The Rauland Responder IV product uses the TAP 1.8 specification. TAP allows a sending system to transfer alphanumeric messages from the Remote Entry Device to a Paging Terminal. In the case of a TAP-based nurse call system, the nurse call system is considered the remote entry device and the Nurse Connect CUAE application server as the paging terminal.
The TAP messages are externally communicated through an RS-232 serial interface. This serial link is typically configured for 9600 baud using even parity and seven data bits. The Rauland Responder IV system is capable of speeds up to 384,000 baud, but unless—specifically configured to a higher speed—its default setting is typically 9600 baud. In some cases, the speed may be set to 300bps. The only way to determine the port configured for TAP as well as its speed and communication parameters is to use the NCDATA configuration tool available only to Rauland resellers and distributors.
Figure 8 is a window from the Rauland Responder IV configuration tool.
Figure 8 Rauland Responder IV Configuration Tool Example Window
After the initial TAP handshaking has completed, the format of the TAP message is as follows:
<STX>123<CR>ABC<CR><ETX>17;<CR>
The start of a transmission block is marked by the <STX> marker which is an ASCII 210. The following characters form the pager directory number which can be of any length, but in the example is three bytes long and contains 123. In a Rauland Responder IV system, this is the "Message Ext" number assigned to the caregiver. Next, a carriage return <CR> defines the end of the first field and marks the beginning of the payload or free form text field. Finally, an ASCII 310 marker is sent, signaling the end of transmission <ETX>.
Because many early serial communication systems lacked error detection and correction, before Microcom Network Protocol (MNP), the TAP protocol has incorporated an error detection and retransmission mechanism. Added to the end of each message block is a cyclical redundancy check (CRC) field. In the example shown above, the 17; is a three-character CRC check that is computed by the remote entry device (nurse call system from Rauland, for example) and added to the tailend of the message. Upon arrival, the paging terminal computes its own checksum using the same CRC algorithm and compares its computed value with the data sent in the message. The paging terminal sends an ACK to the remote entry device in the event that the two match. A NAK message is sent to the remote system when the CRCs do not match, causing the message to be retransmitted.
A high level architectural diagram is shown in Figure 9.
Figure 9 Nurse Connect Dial-back Call Flow (Rauland Responder IV)
In Figure 9, the following occurs:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
RS-232-based Nurse Call Interconnect
Since nurse call systems are classified life safety devices, all supporting servers that augment the system should be located in an environmentally controlled environment. Many times, however, middleware servers are located in wiring closets or worse yet, located under a desk in the nursing area. Historically, the primary reason for this was due to the maximum distance for RS-232 communications and the added expense of extending the RS-232 port's reach to the data center from the care floor.
Considering the critical nature of the overall system, it is imperative that the Nurse Connect server and many of its server-related components reside within the data center. The extension of the RS-232-based communication from the patient floor where the Rauland NCDATA module is located can be accomplished through the use of a serial-to-IP adapter.
Two serial-to-IP adapters were tested with the Nurse Connect solution and are shown in Table 1.
These devices convert the RS-232 serial data into a TCP/IP-based socket connection received by the CUAE application server running the Beacon Alert Manager.
For detailed instructions and recommendations in configuring both the Digi One SP and iPocket232, refer to "Configuring Serial Converters" section.
Radianta Beacon Alert Manager—CUAE Platform
The Radianta Beacon Alert Manager for Cisco Nurse Connect runs within the CUAE. To host this application, a CUAE 2.5(1)-compliant application server must be installed. Depending on the size of the implementation, recommendations for service sizing are highlighted in this document. In cases where the CUAE application server is used to host other applications in addition to Nurse Connect, sizing may vary and require additional server resources. For more information about CUAE, refer to the Cisco CUAE website at: www.cisco.com/go/cuae.
Solution Features and Components
Solution Components
The solution components required for Nurse Connect span several key technologies used in combination to improve clinical communication within a hospital or LTC facility. Featured technologies include the following:
•
•
•
•
•
•
•
Nurse Connect Prerequisites
Both healthcare and LTC organizations have a high level of criticality with respect to wireless mobility. As such, Cisco has instituted a mandatory process for VoWLAN solutions to help ensure all deployments are reliable and highly available. This process requires the completion of the following steps before the order is released for shipment:
1.
2.
3.
4.
5.
Contact your sales representative for details on how to complete these steps.
The following are additional reference documents that will add to successful Nurse Connect deployments:
•
http://www.cisco.com/en/US/partner/products/hw/phones/ps379/prod_bulletin0900aecd805df502.html•
http://www.cisco.com/en/US/partner/products/hw/phones/ps379/products_qanda_item0900aecd805df4e7.shtml•
http://www.cisco.com/go/designzone•
http://www.cisco.com/en/US/partner/products/hw/phones/ps379/prod_bulletin0900aecd804fb75c.html•
http://www.cisco.com/en/US/partner/tech/tk722/tk809/technologies_q_and_a_item09186a00805e9a96.shtmlUnified Communications Components
Table 2 summarizes Cisco Unified Communications components associated with this solution.
Infrastructure Components
Table 3 summarizes infrastructure-related components associated with this solution.
Radianta Beacon Alert Manager Components
Radianta's Beacon Alert Manager application provides the necessary integration between TAP-based nurse call systems and Cisco's Unified Communication environment. Table 4 summarizes the Radianta components used for Cisco's Nurse Connect implementations. Depending on the installation type and size, one of these licenses must be purchased for each TAP instance. A TAP instance maps to a single nurse call system and does not apply to the WaveWare SPS5v7 paging system.
Reference Design Guides
The Cisco Nurse Connect solution is layered upon several foundational technologies. Refer to the design guides listed in Table 5 for detailed information about each of the technologies used within the solution.
Prior to solution deployment, the listed guides should be consulted and best-practices outlined in those publications should be observed to ensure a successful deployment that exhibits all of the attributes of a Cisco Medical-Grade Network.
Designing the Solution
This section focuses on providing design details addressing the following topics:
•
•
Quality of Service
The Nurse Connect solution includes a number of different services with varying levels of criticality. Since the solution optimizes the nurse call workflow, the overall reliability of the end-to-end solution is critical. This section describes the various mechanisms for assuring a high level of service from each of the components of the design. Careful consideration to the end-to-end quality-of-service (QoS) is mandatory for Nurse Connect deployments.
For in-depth design guidance regarding QoS, refer to the Enterprise QoS Solution Reference Network Design Guide Version 3.
QoS Primer
This document is not intended to go into detail about QoS, but to provide a quick review. QoS technology provides the services necessary to eliminate packet loss while minimizing jitter and delay in a converged IP network. It is only effective if implemented end-to-end between each of system that comprise the Nurse Connect solution.
There are three main areas of QoS that must be considered in any Nurse Connect deployment.
•
•
•
Typically, an IP network is comprised of a number of Layer-2 networks—virtual local area networks (VLAN)—that are eventually interconnected using a Layer-3 router to provide inter-VLAN routing services and end-to-end connectivity. Identifying and marking a packet as Layer 3 does not affect how that packet is handled through a Layer-2 network. This is because the Layer-2 network switching fabric does not inspect Layer-3 header information. Likewise, packets that are marked at the Layer-2 layer using class-of-service (CoS) does nothing for traffic as it is routed at Layer 3.
Layer 2 802.1Q/p
Frames marked at Layer 2 using CoS are classified and subject to the queuing policy defined on the switch. Within 802.1p, the precedence is a three-bit field, allowing values between 0 and 7. See Figure 10.
Figure 10 Layer-2 802.1Q/p Priority Field
Table 6 shows the various bit patterns and their values.
Layer-3 DSCP
The ability to mark traffic at Layer 3 has been around and the Differentiated Services Code Point (DSCP) mechanism is the common traffic marking currently used. DSCP uses the older one-byte type-of-service (ToS) field. This was reused to preserve backward compatibility. See Figure 11. The first three bits of the ToS field are commonly referred to as the IP Precedence field. IP Precedence is similar to CoS and varies in values from 0 through 7, with 0 being the lowest priority and 7 being the highest. The next five bits are the DSCP bit indicators, but DSCP actually uses the ToS bits in the overall marking.
Figure 11 Layer-3 QoS DSCP Packet ToS Field
DSCP uses these six bits as shown in Table 7 to indicate the relative service level that should be provided to any traffic such tagged.
Mapping Between Layer-2 CoS and Layer-3 DSCP
When a frame is marked with Layer-3 DSCP and it needs to traverse a series of Layer-2 switches or 802.1Q trunks, how will it be queued in these Layer-2 devices? There is a mapping that takes place between the Layer-3 mapping field (ToS) and the Layer-2 CoS fields. It is important to note that the mapping between Layer 3 and Layer 2 is set by default on various vendor hardware. On Cisco devices, this is handled by a mapping process that can be viewed through the show mls qos maps command. This command shows a number of tables, but for reference the default is shown in the following example output.
6509_R1# sh mls qos mapsDscp-cos map: (dscp= d1d2)d1 : d2 0 1 2 3 4 5 6 7 8 9-------------------------------------0 : 00 00 00 00 00 00 00 00 01 011 : 01 01 01 01 01 01 02 02 02 022 : 02 02 02 02 03 03 03 03 03 033 : 03 03 04 04 04 04 04 04 04 044 : 05 05 05 05 05 05 05 05 06 065 : 06 06 06 06 06 06 07 07 07 076 : 07 07 07 07The mapping is shown in Table 8. These can be changed using the mls qos map cos-dscp 10 15 20 25 30 35 40 45 command. In this case, it would map each of the eight CoS values to the DSCP values shown in the command from lowest CoS priority to highest.
Table 8 Mapping of Layer-3 to Layer-2 CoS
0-7
0
8-15
1
16-23
2
24-31
3
32-39
4
40-47
5
48-55
6
56-63
7
Trusting QoS CoS or DSCP
When a packet arrives on an inbound port of a switch, should the switch trust these markings? In the case of a service provider delivering broadband to the home, for example, it might not be wise to trust frames marked with a high priority. Each edge switch has the ability to either trust CoS, DSCP, or IP Precedence. By default, Cisco switches rewrite the QoS value to 0, effectively nullifying the markings previously marked upstream. This is often misunderstood. As a result, many campus networks reclassify the edge traffic to best-effort, despite QoS marking performed by the application or upstream network.
6509-R1(config-if)# mls qos trust ?cos cos keyworddscp dscp keywordextend extend keywordip-precedence ip-precedence keyword<cr>Cisco IOS Voice Gateway QoS
In order to interface to a nurse call system for voice call-back, the use of a voice gateway might be necessary. This device is a Cisco Integrated Services Router (ISR) such as the Cisco 2800 Series or Cisco 3800 Series and is configured with FXS, T1, or E1 voice interfaces. In many deployments, voice connectivity is required directly to the nurse call system. In these cases, the Cisco ISR gateway might physically reside at the access layer in the network—typically on a nursing floor and collocated in the same wiring closet as the nurse call system.
The voice gateway uses Cisco Modular QoS methods to classify and mark H.323 RAS traffic. Once this traffic is classified and marked, the DSCP bits are set to CS3 through a policy-map. This policy-map is one example of how to mark the H.323 signaling traffic before it enters the access layer edge switches. The exception to this rule is the Precidia iPocket232 running version 5.02.01, which marks all of its traffic AF31.
Once the policy map is configured, it is applied to the voice gateway's outbound interface to police all H.323 RAS traffic and ensure the proper DSCP value is set in each frame matching the policy. By default, the Real-Time Transport Protocol (RTP) audio stream being sent by the voice gateway is marked Expedite Forwarding (EF) by the voice over IP (VoIP) endpoints and complies with the recommended best practices for Cisco campus QoS policies.
The following example maps all H.323 RAS traffic to DSCP CS3:
class-map match-all ras_signalingdescription class map for H.323 RAS trafficmatch access-group 100!!policy-map set-qosclass ras_signalingset dscp cs3!!interface GigabitEthernet0/0description To access layer switch in Nursing floor 4 Northip address 172.21.52.101 255.255.255.240duplex autospeed automedia-type rj45no keepaliveservice-policy output set-qosTAP Generating Sources
TAP-generating systems for Nurse Connect are typically serial RS-232-based devices that employ the TAP protocol for outbound paging notification.
Rauland Responder IV Nurse Call Systems
The Rauland Responder IV product available today and deployed in 1000s of healthcare and LTC facilities worldwide also uses an RS-232 interface to signal paging messages to external systems. The common paging protocol in North America is the TAP protocol. In Europe, a variation to TAP is used: the European Selective Paging Association (ESPA) protocol. While the deployment of TAP and ESPA are not mandated in any area of the world, these protocols are different and not compatible with each other. For Nurse Connect, only the TAP-based protocol is supported and only the format of the payload for Responder IV system from Rauland has been tested.
It is highly recommended that the Beacon Alert Manager CUAE application server be located in the data center in order to provide a physically secure and highly available environment for this critical component to the overall solution.
Because of the long serial cable lengths that are typical for nurse call systems to have serial connectivity to the data center, a conversion of RS-232 serial output to TCP/IP provides a much better solution. In addition, it is possible to mark this serial TAP information over TCP/IP with an appropriate DSCP value. In the case of Nurse Connect, it is recommended marking the paging TAP traffic with a DSCP value of AF31 (assured forwarding, mission-critical data). Most third-party serial-to-IP devices are not capable of marking the traffic themselves and require edge marking at the access layer.
Two examples of third-party RS-232-to-TCP/IP converters follow:
•
•
The Digi One SP device generates TCP traffic on TCP port 2101 for RAW access to the serial data stream. The Radianta Beacon Alert Manager CUAE application server establishes a TCP socket connection to the Digi One SP when the Radianta Beacon Alert Manager service is started.
The Sniffer trace shown in Figure 12 is an example of traffic originating from a NCDATA module of a Rauland Responder IV without the DSCP marking being performed.
Figure 12 Digi One SP Traffic to Nurse Connect without DSCP Marking
In order to mark the traffic generated from the Digi One SP, the following configuration is required at the edge switch:
mls qosclass-map match-all Digi_One_SP_Class_Mapmatch access-group name Digi_One_SP!policy-map Digi_One_SP_Policy_Mapclass Digi_One_SP_Class_Mapset dscp af31!ip access-list extended Digi_One_SPpermit tcp any eq 2101 any!interface GigabitEthernet2/0/13description Digi One SPspanning-tree portfastservice-policy input Digi_One_SP_Policy_MapAfter the marking has been applied to the port to which the Digi One SP is connected, note that the traffic is now marked accordingly with a DSCP value of AF31. See Figure 13.
Figure 13 Digi One SP To Nurse Connect Marked DSCP
The policy mapping is not yet complete. The issue is that the classification only marked traffic flowing in one direction—specifically from the Digi One SP (10.6.2.100) to the Radianta Beacon Alert Manager CUAE application server (10.6.2.42).
In order to solve this problem, a corresponding service-policy command must be applied to the Ethernet port which the Nurse Connect is connected to. In our example however, the classification of SNMP traffic is also included in the service-policy command specification. This is because the Nurse Connect application uses SNMP to query the configured Cisco Unified Communications Managers for information about various handsets registered to Cisco Unified Communications Manager.
mls qos!service-policy input Nurse_Connect_Policy_Mapclass-map match-all Nurse_Connect_Class_Mapmatch access-group name Nurse_Connect!policy-map Nurse_Connect_Policy_Mapclass Nurse_Connect_Class_Mapset dscp af31!ip access-list extended Nurse_Connectremark Nurse Connect uses SNMP to query CUCM for device listpermit udp any any eq snmpremark Default Port for Digi SP One is TCP 2101permit tcp any any eq 2101remark Default Port for Precidia iPocket232 is TCP 9999remark The Precidia iPocket232 using version 5.02.01 is capable of marking its own remark capable of marking its own traffic using a DSCP value of AF31.permit tcp any any eq 9999remark Default Port for HTTP Post to handsets, send messagepermit tcp any any eq wwwremark Set SNMP on UDP 162 to AF31 for TRAPSpermit udp any any eq 162!interface GigabitEthernet2/0/1description Nurse Connect Serverspanning-tree portfastAfter the above service-policy command is applied, traffic from the Nurse Connect server (10.6.2.42) destined for the Digi One SP (10.6.2.100) is marked with DSCP AF31. See Figure 14.
Figure 14 Nurse Connect to Digi One SP (DSCP Marked AF31)
Note
Similarly, the Precidia iPocket232 generates TCP traffic on TCP port 9999. If the iPocket232 is running version 5.02.01, the iPocket232 will self mark all of its traffic as AF31 automatically. In the event that 5.02.01 is not available, port-based marking is necessary and is described below. In order to mark the traffic generated from the Precidia iPocket232, the configuration below is required on the edge switch.
Note
mls qos!class-map match-all Precidia_iPocket232_Class_Mapmatch access-group name Precidia_iPocket232!policy-map Precidia_iPocket232_Policy_Mapclass Precidia_iPocket232_Class_Mapset dscp af31!ip access-list extended Precidia_iPocket232permit tcp any eq 9999 anyinterface GigabitEthernet2/0/11description Precidia iPocket232spanning-tree portfastservice-policy input Precidia_iPocket232_Policy_MapNurse Connect-CUAE QoS Considerations
The Nurse Connect CUAE application server communicates to a number of different hosts. In order to provide a high level of service, each of the various communications protocols used must be appropriately QoS-marked. Table 9 shows a summary of the various communication flows between the Nurse Connect server and various hosts and/or devices that comprise the solution.
Because modular QoS (MQoS) must be used to classify and mark the traffic generated, you must create an access list on the edge switch or upstream router. The following access list can be used as part of a class-map to identify and mark the various traffic flows from the Beacon Alert Manager server through the use of a service-policy.
ip access-list extended Nurse_Connectremark Nurse Connect uses SNMP to query CUCM for device listpermit udp any any eq snmpremark Default Port for Digi SP One is TCP 2101permit tcp any any eq 2101remark Default Port for Precidia iPocket232 is TCP 9999permit tcp any any eq 9999remark Default Port for HTTP Post to handsets, send messagepermit tcp any any eq wwwQoS Summary and Checklist
QoS must be integrated into your solution from the initial design development, in order to implement a robust Nurse Connect solution that provides an assurance level for message delivery and meets the demands found in the healthcare environment.
Voice or mission-critical data traffic should be marked as close to the traffic source as possible. If the generating host is capable of marking the traffic itself, then this feature should be enabled, if it is not enabled by default. If the originating host is not capable of marking the traffic, the use MQoS as described in the preceding section.
Once the traffic generated by both the sending and receiving hosts is marked, the next step is to enable QoS policies on each network component that make up the end-to-end network. This includes wired Layer-2/Layer-3 switches, as well as the wireless components—namely Wireless LAN Controller (WLC).
The following task summary outlines the activities related to QoS implementation for this solution.
Step 1
a.
Step 2
a.
Step 3
Step 4
Step 5
a.
b.
Step 6
Step 7
a.
Step 8
Step 9
Step 10
Cisco Unified Communications Manager
Cisco Unified Communications Manager has a number of services that it provides for a typical installation of Nurse Connect. These include the following:
•
•
•
Some of these traffic flows, by standard telephony standards, are considered critical for voice delivery and are automatically marked by both the handset and the Cisco Unified Communications Manager. Others are not classified as mission-critical and are not marked. Because of the nature of the message content as it relates to patient care, it is imperative that all traffic types originating from Cisco Unified Communications Manager that comprise the overall Nurse Connect solution be properly marked as mission-critical data (AF31).
In the descriptions that follow, we examine each of the different protocols that comprise the solution from a Cisco Unified Communications Manager perspective.
Cisco VoIP endpoint devices generate two primary traffic flows for voice traffic that must be QoS-classified and marked. By default, Cisco Unified Communications Manager performs the marking automatically. These markings involve the signaling channel and the bearer channel.
The signaling channel is responsible for the control of an endpoint—from collecting digits to signaling an inbound or outbound call. The following three signaling traffic types are associated with Nurse Connect solution:
•
•
•
The bearer channel carries the audio or video traffic between endpoints. Again, this is automatically marked by both the endpoints and Cisco Unified Communications Manager. More specifically, the protocol used to carry the packetized voice traffic is RTP. RTP uses User Datagram Protocol (UDP) and is dynamically assigned a UDP port number in the range of 16384-32767. The port selection is coordinated and communicated by the endpoints using the signaling protocol configured for the specific endpoint device.
The third protocol used is Trivial File Transfer Protocol (TFTP). This protocol (UDP 69) is used to transfer the configuration to the phone during each registration performed with Cisco Unified Communications Manager.
The fourth protocol used by Cisco Unified Communications Manager is SNMP. When devices register or unregister from Cisco Unified Communications Manager, a list of device changes is sent to all configured SNMP trap destinations. In the case of Beacon Alert Manager, Cisco Unified Communications Manager must be configured to send SNMP traps to the Beacon Alert Manager CUAE application server on UDP port 162. The destination port for the SNMP traps is UDP 162—a well known port for SNMP usage.
Cisco Unified Communications Manager does not QoS-classify and -mark SNMP traps because these are usually used only for monitoring the availability of the system. However, in the case of Nurse Connect, these SNMP traps are used to keep the Radianta Beacon Alert Manager application up to date with the status of each device as it registers or unregisters from Cisco Communications Manager. Marking of this outbound traffic is not automated and requires MQoS as shown in the following configuration example.
mls qos ! class-map match-all CUCM_Class_Map match access-group name CUCM_MobileCare policy-map CUCM_Policy_Map class CUCM_Class_Map set dscp af31 ! ip access-list extended CUCM_MobileCare remark Set SNMP traps on UDP162 to AF31 for Device Updates to CUAE permit udp any any eq 162 ! interface GigabitEthernet2/0/17 description CUCM Publisher spanning-tree portfast service-policy input CUCM_Policy_MapThe service-policy shown above was applied in the network created to test this solution. After it was implemented on the switch port interface to which a Cisco Unified Communications Manager server was attached, the outbound SNMP traps were appropriately marked as shown in Figure 15. In this example, the Cisco Unified Communications Manager server is 10.6.2.150 and the Radianta Beacon Alert Manager CUAE application server is 10.6.2.42.
Figure 15 Cisco Unified Communications Manager generated SNMP Trap (QoS Marking)
Note
Cisco Unified Communications Manager automatically marks both signaling and bearer traffic, as well as instructing the registered endpoints as to which DSCP classification to use. As a result, the only Cisco Unified Communications Manager QoS marking necessary is the DSCP for phone-based services found in Cisco Unified Communications Manager under System > Enterprise Parameters Configuration, under the DSCP for Phone-based Services option as shown in Figure 16.
Figure 16 Cisco Unified Communications Manager DSCP for Phone-based Services (Change to AF31)
MQoS must be used for the SNMP trap as shown in the preceding service policy example configuration. Validating that all traffic is properly marked should be done during the implementation phase of Cisco's Nurse Connect solution.
Nurse Connect Voice Considerations
Nurse Connect enables the nurse or care provider to call back to the bedside through the nurse call system using a softkey on the phone. This allows the care provider to triage the nature of the call and respond accordingly.
In order to provide voice call-back through the Rauland Responder IV system, the use of a Rauland component called the Nurse Call Telephone Line Interface (NCTLI) must be used. See Figure 17. Each Rauland Responder IV system can support a maximum of three NCTLI modules; with each NCTLI module supporting up to three analog telephone lines. The maximum number of telephone lines supported by any single Rauland Responder IV system is nine.
Figure 17 Rauland NCTLI Module
There are two common methods for providing the call-back mechanism:
•
•
Direct Voice Integration to Rauland Responder IV
In environments where the NCTLI module will be directly connected to the FXS ports on a Cisco ISR voice gateway, we recommend using analog ports on all of the NCTLI interfaces. This will provide for the maximum number of simultaneous calls placed back to the patient bedside.
We recommend using a Cisco ISR, either the Cisco 2800 or Cisco 3800 Series routers, with either two- or four-port FXS ports installed to a maximum of nine ports. Additional Cisco ISRs might be needed if the NCTLI modules are spread out across multiple patient or resident floors. Multiple Cisco ISRs provide a higher level of redundancy and can reduce additional analog cabling costs.
When the nurse call system sends out a TAP page, the information included in the TAP page is the configured Message Extension (shown in Figure 18 as 103) and the text of the message. The message text contains a room and bed number, but does not include the dial-back phone number of the patient device (a pillow speaker, for example).
Figure 18 Rauland Responder IV Console Message Ext
For the Radianta Beacon Alert Manager application to determine the dial-back number to use when the care giver presses the dial-back softkey on his or her phone, it must be found in a statically defined table within the Beacon Alert Manager administrative page administration utility. Once the room/bed has been found in this static table, the dial-back phone number of the patient device (pillow speaker) is obtained.
An example of this room/bed to dial-back phone number mapping is shown in Figure 19 and Figure 20.
Figure 19 Beacon Alert Manager-to-Room Dial-back Mappings
Figure 20 Beacon Alert Manager TAP Connection Room/Bed Dial-back Mapping Example
In the example illustrated in Figure 20, if a TAP message arrives from room 202 bed 1 (typically sent from a Rauland Responder IV as 202:1), the dial-back hunt group phone number is 1000. If the TAP page is from room 202 bed 1(202#1), the dial-back phone number string is 1000202#1. The 1000 is the pilot or hunt group number which directs Communication Manager to forward the call to the ISR voice gateway router. Once the call is routed out the FXS port, the Rauland Responder IV NCTLI module answers the call after one ring and presents a dial-tone. When the ISR detects the ringtone, it plays the additional digits, in this case 202 (signifying room 202), a # to signal to Rauland that a bed number is to follow and 1 for the first bed in the room.
Disconnect Supervision
Disconnect supervision is the term applied to the ability of a telephone endpoint to detect the end of a call and reset itself to either accept or make a new call. With PRI or BRI digital voice interfaces, disconnect supervision is provided through signaling on the D channel. In the case of T1 (channel associated signaling), this is handled through the robbed-bit signaling protocol. In most instances, disconnect supervision on these interfaces are not a problem. For analog interfaces such as FXO, FXS and E&M interface, the process of signaling a disconnection (or end-of-call event) can sometimes be troublesome, depending on the disconnect method used and the age of the hardware. Rauland Responder IV Nurse Call Telephone Line Interface (NCTLI ) headend requires the use of FXS ports for connectivity.
We recommend each port is used on the NCTLI and that each port is individually validated in order to ensure that disconnect supervision is being properly handled between the voice gateway and the legacy system. It is important to test each port, as it has been found that some versions of firmware running on the legacy line cards in some PBXs and nurse call systems do not properly implement the disconnect supervision as required. In some deployments, it might be possible that one nurse call module is running an updated firmware revision that provides the correct disconnect supervision while another module in the same system is running older code. This is why each port must be separately validated for proper operation.
To assist in troubleshooting disconnect supervision problems, refer to the Understanding FXO Disconnect Problems document at the following URL:
http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800ae2d1.shtml
Voice over Wireless LAN (VoWLAN)
The Nurse Connect solution comprises a number of different horizontal technologies such as VoIP and wireless. As such, each of these technologies—as well as other best practices—are not discussed in detail within this design guide. Instead, this document provides a high level overview of design guidance and reference to the supporting horizontal design guides. Customer and implementation partners are strongly urged to review each of the design guides for best practices in order to design and implement a robust, scalable, and secure solution deployment. Each of the supporting design guides can be located on at http://www.cisco.com/go/designzone.
Because of the critical nature of both the healthcare and LTC industries, it is critical that the underlying and supporting infrastructure for VoWLAN—Unified Mobility—is designed and implemented to support the requirements of VoWLAN within the organization facilities.
Many healthcare and LTC environments have sources of radio frequency (RF) interference. These sources are not generally limited to microwave ovens or 2.4 GHz cordless phones. Other sources can include 2.4 GHz video cameras, Bluetooth devices—as well as patient and visitor devices, such as Wi-Fi-enabled PCs and dual-mode phones.
Multipath interference (caused by reflected signals) and co-channel interference from adjacent hospital wings must also be considered. Figure 21 illustrates an exaggerated incorrect deployment strategy. Figure 21 highlights the increased possibility of co-channel interference found in a typical environment due in part to poor design and building floor plan.
Figure 21 Overlapping Co-Channel Interference Example
Due to the rise in consumer devices within the 2.4 GHz ISM band, embedded 2.4 Ghz Bluetooth on the Cisco Unified Wireless IP Phone 7925G, and the limited number of non-overlapping 802.11b/g channels, we recommend migrating voice traffic and critical data-based services to a 5Ghz implementation. On the 5GHz (802.11a) band, all 23 channels (depending on geographic area) are non-overlapping channels. This results in an increased network capacity, improved scalability, and the ability to deploy with a lesser affect of co-channel interference.
QoS Issues
There are a number of QoS-related issues that should be considered during the Nurse Connect design and implementation phases. First, consider QoS as it relates to how VoWLAN is handled. The handsets are configured during the registration process with Cisco Unified Communications Manager for the QoS settings that are to be used.
By default, both the RTP and SCCP/SIP control channels are Layer-3 marked as DSCP EF and CS3 respectively. At Layer 2, the CoS is 3 for call signaling and 5 for voice traffic. For LWAPP-enabled wireless networks, the AP is connected directly to an access-layer switch port. The wireless traffic generated by wireless hosts associated to the AP are encapsulated in LWAPP frames and sent to the controller—typically over a Layer-3 IP network. Trusting the Layer-2 CoS is not necessary at the switch to which the APs are connected. Instead, DSCP should be trusted in LWAPP configurations.
Switch ports to which LWAPP-enabled access points are connected should trust DSCP and can be configured using the commands shown in the following configuration example. For Layer-3 uplinks from the access layer to the distribution layer, DSCP should also be trusted.
interface GigabitEthernet1/0/1description LWAPP Access Pointauto qos voip trustmls qos trust dscp! <SNIP>interface GigabitEthernet1/0/48description L3 uplink to distributionmls qos trust dscpauto qos voip trustno switchport ! {enables port as an Layer-3 routed port, not an Layer-2 based VLAN access port}ip address 10.6.1.1 255.255.255.252srr-queue bandwidth share 10 10 60 20 ! {configured as part of auto qos voip trust command}srr-queue bandwidth shape 10 0 0 0 ! {configured as part of auto qos voip trust command}queue-set 2 ! {configured as part of auto qos voip trust command}! <SNIP>Since the WLC trunks multiple VLANs and maps these to specific service set identifiers (SSID), the WLC connects to the network at Layer 2. As such, trusting CoS as opposed to DSCP is necessary and is shown in the configuration example that follows.
interface GigabitEthernet1/0/1description Connection to Wireless LAN Controllerauto qos voip trustmls qos trust cos ! { Note that due to bug CSCsi78368, the CoS is not being set properly form the WLC. It is therefore necessary to trust DSCP until WLC release 4.2 }! <SNIP>High Availability (HA) Considerations
The goal of a highly available system is to eliminate single points-of-failure and automate the recovery of a failed node. A single point-of-failure can lead to unscheduled outages and sporadic availability. End-to-end monitoring of the system is a critical component in determining overall network system availability. Because a number of different technologies are used in this solution, we assesses each solution component to identify possible effects on relevant high availability (HA) architecture designs. For each major grouping of components, we suggest monitoring systems and techniques that can be employed in order to validate the availability.
Cisco Unified Communications Component Cisco Infrastructure
The Cisco infrastructure required to support the Nurse Connect solution can be broken down into a number of horizontal technologies that are described in the section that follows. It is beyond the scope of this document to describe in detail the various HA aspects of each applicable technology. For an in-depth description, review the relevant Cisco Validated Design (CVD) publications at the following URL: http://www.cisco.com/go/designzone
The overall availability of Nurse Connect depends on the infrastructure upon which it is deployed. The following list provides a summary of items to be considered in the HA planning process:
•
•
•
•
–
–
–
•
–
–
–
•
•
•
•
•
While the preceding list does not capture every consideration, it serves as a short list for the items that must be considered during the gap analysis phase.
Network Components
The network components consist of the Layer-2 and Layer-3 devices that comprise the campus network—specifically the access, distribution and core layers devices and systems. There are a number of Cisco Validated Designs (CVDs) available that describe these elements. on Cisco's Design Zone website (www.cisco.com/go/designzone) that describe these elements in detail. The key publications recommended for Nurse Connect deployment preparation are the following:
•
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html•
http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/campover.html
After reviewing the preceding CVDs, a gap analysis or readiness check should be performed. To help facilitate this step, it might be helpful to engage the expertise of a third-party Cisco Certified implementation partner for each of the areas where any gaps are identified.
In general, to achieve a highly available network architecture, an implementation must be capable of delivering between 99.99 percent and 99.999 percent availability. This represents between 53 and 5.3 minutes of downtime per year, respectively—a goal that is highly desirable for any network delivering critical services as those found in Cisco Nurse Connect solution.
Wireless Mobility Components
High availability for wireless mobility spans a number of different network infrastructure components. It is assumed for this discussion that the existing wired infrastructure has been designed to provide end-to-end high availability.
Access Points
To achieve a redundant wireless network design, careful consideration as to the AP placement is necessary and adherence to the 20 percent cell overlap recommendation is critical. In order to provide hardware level redundancy for a centralized wireless deployment, the WLC will dynamically adjust the power output of APs adjacent to one that is no longer available. This capability and the design aspects of achieving a HA wireless design are discussed in the VoWLAN design guide at the following URL: http://www.cisco.com/go/designzone.
Wireless LAN Controllers
The Wireless LAN Controllers (WLC) provide configuration and management for APs. Much of this management is both automatic and dynamic, and requires a redundant design if high availability is to be achieved. Its not only necessary that there are redundant WLCs, but the failure of any single WLC must not over subscribe the surviving WLCs.
Consider a wireless network consisting of the following (with each WLC at 50 percent of its licensed capacity):
•
•
•
In the event of either Cisco 4402 failing, the surviving WiSM has additional spare capacity to support the 6 or 25 APs from the failed Cisco 4402. However, if the WiSM (or the Cisco 6509 in which the WiSM is installed) fails or has a disruption of connectivity, the surviving Cisco 4402s will not have the spare capacity to support the additional APs (supported by the WiSM). In order to prevent a scenario like this from occurring, it is critical to perform a case-by-case failure analysis and determine whether a design can provide a sufficiently high level of availability as required for Nurse Connect.
Security and Authentication Components
As is the case with any healthcare related solution, security must be thoroughly considered, planned, and implemented on an end-to-end basis. It is important to review the relevant Cisco Validated Design publications for detailed guidance on security as it relates to this solution.
With respect to mobility, which provides much of the service delivery for Nurse Connect, the Wireless and Network Security Integration Solution Design Guide which can be found at the following URL: http://www.cisco.com/go/designzone
The following components comprise the end-to-end Nurse Connect solution:
•
•
•
•
These components are typically spread across the healthcare organization's network, from the datacenter all the way through to the access layer. Working from the datacenter outward, lets review the security ramifications at each location within the network.
Note
Within the data center, a number of Nurse Connect components reside. First, the backend wireless infrastructure such as the WLC and ACS servers, the call control as provided by Cisco Unified Communication Manager, and the TAP-based integration is provided by the Cisco Unified Application Environment (CUAE).
Wireless LAN Controller
Security for the WLC should include basic appliance security, which prevents unauthorized user access to the administrative and configuration sections of the WLC. After this, configuration of the wireless network takes into account a few items such as VLAN creation, SSID assignment, Remote Authentication Dial-In User Service (RADIUS) servers, and the encryption and authentication mechanisms used for each SSID.
Authentication
The recommended configuration is to use IEEE 802.1x key management. This mandates the use of an external RADIUS server to authenticate end user devices. By using Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST), the entire authentication stream is encrypted end-to-end—unlike Lightweight Extensible Authentication Protocol (LEAP) authentication. This approach provides a high level of security across the wireless network during the authentication process.
On the Cisco Unified Wireless IP Phone 7921G and 7925G, the configuration of EAP-FAST is found under Settings > Network Profiles > [Your Profile Name] > WLAN Configuration > Security Mode. Selecting EAP-FAST, and configuring a unique userid and password on the device that conforms to strong security standards is all that's required. See Figure 22.
This userid/password combination can be a locally defined userid/password combination located only on the ACS. Optionally, the userid/password account can exist within the Active Directory domain that ACS can use as an external authentication database to validate userid/password as configured.
Once the userid/password is authentication, a dynamically created Wi-Fi Protected Access (WPA) key is generated by ACS and pushed to the Cisco Unified Wireless IP Phone 7921G to encrypt traffic generated by the device. This includes voice, call control, and XML services. To an observer using a wireless sniffer, all traffic generated by the device is encrypted with dynamically changing keys as provided by the selected crypto mechanism.
Figure 22 EAP-FAST Phone Settings
Another item that must be completed in order to enable EAP-FAST against the Wireless LAN Controller (WLC) is to adjust the 802.1x timeout value. In the ACS, the default is 20 seconds, but on the WLC, the default is 2 seconds. In order for the client to obtain the Protected Access Credentials (PAC) via automatic provisioning on the Cisco Unified Wireless IP Phone 7921G, the value must be changed on the WLC to a higher value. The suggested timeout is 20 seconds on the WLC as indicated in the Cisco Unified Wireless IP Phone 7921 Deployment Guide found on Cisco.com; at URL below. To change the 802.1x timeout on the WLC, use Telnet or Secure Shell (SSH) to connect to the WLC and enter the following command:
(Cisco Controller) > config advanced eap request-timeout 20(Cisco Controller) > show advanced eapEAP-Identity-Request Timeout (seconds)........... 1 EAP-Identity-Request Max Retries................. 20 EAP Key-Index for Dynamic WEP.................... 0 EAP Max-Login Ignore Identity Response........... enable EAP-Request Timeout (seconds).................... 20 EAP-Request Max Retries.......................... 2http://www.cisco.com/en/US/products/hw/phones/ps379/products_implementation_design_guides_list.html
Encryption
Between the Cisco Unified Wireless IP Phone 7921G and the WLC, we recommend using the WPA security protocol with Temporal Key Integrity Protocol (TKIP) encryption and 802.1x-with-Cisco Centralized Key Management (CCKM) key management. This is necessary because the Cisco Unified Wireless IP Phone 7921G does not support Wi-Fi Protected Access 2 (WPA2) with CCKM. The use of WPA/TKIP provides faster roaming over that of WPA/Advanced Encryption Standard (AES). Figure 23 shows the recommended encryption settings as configured on the WLC.
Figure 23 WPA Policy with TKIP WPA Encryption
It is important to understand the scope of the encryption (see Figure 24 ) as it pertains to XML services. XML traffic between the Cisco Unified Wireless IP Phone 7921G or 7925G and the WLC will be encrypted as configured on the WLC. After the XML traffic is decrypted on the WLC, it is sent unencrypted as standard HTTP XML flows. Secure HTTP (HTTPS) is not currently supported by the Cisco Unified Wireless IP Phone 7921G or 7925G.
Figure 24 Scope of Wireless Encryption
Cisco Access Control Server
The Cisco Secure Access Control Server (ACS) provides authentication and authorization services for users of the wireless network. The ACS extends the integration of the user database to a number of external user databases. These external user databases can be Microsoft Active Directory, or other Lightweight Directory Access Protocol (LDAP)-based user directories. In addition to providing authentication services to wireless users, the ACS can also be used to provide administrative access to various network components such as Cisco ISRs and switches. Restricting access to these systems can not only provide the security necessary for the overall security policy of the healthcare provider, but can also increase availability of the Nurse Connect solution caused by unauthorized access.
Nurse Connect-CUAE Components
Nurse Connect uses the Cisco Unified Application Environment to host a TAP-based message forwarding and logging application or plug-in from Radianta called Beacon Alert Manager. This plug-in At the time of the writing of this document, this plug-in provides TAP integration only to Rauland Responder IV systems.
The CUAE application server can reside on a number of different Media Convergence Servers (MCS) depending on volume and use as shown in Table 10 and Table 11.
CUCM and CUAE Communication
Communication between Cisco Unified Communication Manager (CUCM) and Cisco Unified Application Environment (CUAE) use two protocols for Beacon Alert Manager.
•
•
The SNMP protocol is used to provide the Beacon Alert Manager application with periodic updates to the handsets that have registered or unregistered with Communication Manager. Upon Beacon Alert Manager startup and initialization, the application performs an SNMP query from the configured Communication Managers.
From this SNMP query, a list of currently registered phones is obtained on an individual Communication Manager basis. This means that if a CUCM cluster is being used, each of the Communication Managers need to be individually configured in Beacon Alert Manager as if they were standalone servers. This will help assure that each phone registered to CUCM will be addressable by Beacon Alert Manager and therefore able to receive paging.
When configuring the SNMP interface on the CUCM publisher, an option to Apply to all nodes is available and should be configured. Each CUCM server in the cluster will be configured with the CUAE/Beacon Alert Manager application server as the receiver for the SNMP messages.
HTTP is used to push an XML-based set of commands to the phone for execution. This occurs using standards-based HTTP on TCP port 80. Upon receiving the series of commands (play a ringtone, vibrate, retrieve URL and dial number), the phone validates the authenticity of the request using its configured Authorization URL.
IP Phone and Beacon Alert Manager/CUAE Communication
The process of communicating an XML page event to a Cisco handset is straight forward. The list of registered phones was obtained directly from Communication Manager. As part of this process, the IP address, directory number and device name (SEPxxxxxx) of each handset is entered into a dynamic lookup table.
When a TAP message arrives from the configured TAP connection, the table is consulted for the first handset that matched the directory number to which the Nurse Call has indicated should receive the text page. The Beacon Alert Manager application then sends an XML-based set of commands that the phone must execute.
Note
The XML commands are sent to the phone using an HTTP post command on TCP port 80. Once received by the phone, it checks if the userid/password included in the command request is authorized to be executed. The phone uses its Communication Manager configured Authentication URL, which by default points to a authorization URL on CUCM, to authentication the userid/password. The type of command being request is compared with the groups of permissions associated to the application-based userid. If the userid, password, and requested command are successfully verified, an HTTP response is sent back to the phone and the commands are executed.
One of the commands causes the phone to retrieve a specific event-based URL from the Radianta Beacon Alert Manager CUAE application server. This unique URL points to the actual record corresponding to the nurse call event. Again, this HTTP GET is performed using the standard HTTP TCP port of 80.
Voice Gateway to Rauland Responder IV Nurse Call System
In order to provide voice access to legacy nurse call and/or PBX systems, the use of a voice gateway is required. The most common uses case as it relates to nurse call is an audio-based call back to the patient room or ancillary department.
In addition, external voice communication can also be accomplished from any of the phones being used with Nurse Connect by the virtue of the fact that the phones are also part of the overall Unified Communications infrastructure. To provide connectivity to the Rauland Responder IV system, the use of an ISR with an appropriate voice interface is required. Another option is to use various voice capable line cards (Cisco 6608) for the Cisco Catalyst 6500 series platform, and connect both the Rauland Responder IV system and the Unified Communication infrastructure to the legacy PBX.
As part of the Nurse Connect validation process, a Cisco ISR (2600 and 2851) were used with FXS ports, which provide connectivity to nurse call and PBX-based systems. From a high availability perspective, it is recommended that redundant voice gateways be used with the Nurse Connect solution.
In order to use redundant voice gateways, a route group in Communication Manager can be defined that specifies the order in which trunks or voice gateways will be used for any given route pattern. In the event that a voice gateway fails or is no longer reachable, Communication Manager automatically removes that gateway from the list of configured gateways and continue routing calls through the surviving configured gateways.
When connecting redundant voice gateways to PBXs, it is recommend that each voice gateway be connected to PBX ports that are contained on separate PBX shelves in order to provide a level of fault tolerance in the event of a failure or scheduled maintenance of the shelf.
The most common approach however will be to connect a set of voice gateway ISRs using FXS port directly to the Nurse Call Telephone Line Interface (NCTLI) module from Rauland. Remember to provision enough FXS ports to match or slightly exceed that of Rauland Responder IV solution.
Note
Network Services Integration
Active Directory and Cisco Secure ACS
The Nurse Connect solution by itself does not utilize either Active Directory or Cisco Secure ACS. The overall solution however may utilize these services to provide wireless authentication for mobile devices. In addition, access to the ISR voice gateway and other network equipment should be protected using the TACACS protocol available from Cisco Secure ACS.
The Beacon Alert Manager CUAE application server is a Windows 2003 Server, and therefore can participate in the enterprises Active Directory (AD) common to such environments. It is beyond the scope of this solution to provide details of the AD integration. It would, however, be best practice for all Windows-based servers within the data center to be active members of the AD domain.
Domain Name Services (DNS)
Both redundancy and completeness of Domain naming information should be included in the overall design of the network. Many hosts depend upon the ability to correctly resolve the host name of a server. In the case of the Nurse Connect solution, all supported handsets typically require that the hostname of the Communication Manager is able to be resolved using DNS services.
Each time the services key is pressed for example, the URL configured for the services key on the phone is referenced. If the URL contains a hostname-based URL, a DNS query is performed each time by the phone in order to resolve the supplied name to its corresponding IP address.
If during this time, DNS services are inhibited or unavailable for some reason, the overall availability and end user perceived reliability of the solution deteriorates due to the phone's inability to locate its configured XML application services.
In order to provide a high level of service availability and comply with Cisco's best practices, a redundant DNS infrastructure should be employed. In addition, these servers should be connected to the data center network using diverse switching fabric. Similar to that of the DHCP servers, each DNS server should be placed on separate maintenance windows to prevent issues from arising due to hardware or software updates. The Cisco handsets do no cache DNS queries that relate to a DNS query for each XML service selected from the phones menu.
XML Services High Availability
In order to increase the availability of the XML services as accessed from a Cisco handset, it is recommended that either Server Load Balancing (SLB) be used, or an appliance-based load balancing solution be implemented such as the ACE appliance or Content Services Switch (CSS).
For those facilities that do not yet have access to such load balancing products, it is possible to use round robin DNS to provide "round robin" IP address resolution for each of the configured Communication Managers comprising the Unified Communication cluster. With round robin DNS, each successive DNS request made will issue the next IP address for a given hostname in a circular fashion. In the event of a failed Communication Manager or a Communication Manager that no longer has access to the network, this IP address will still be resolved and hence the phones request for its configured XML services will fail.
While this is a disadvantage to round robin DNS, it does provide the end user with the ability to press the services button a second time, for example, and have a possibility of receiving an IP address for one of the surviving Communication Managers within the cluster. However, it is equally possible that during the time that user "A" experienced the address of the failed Communication Manager, another user "B" may have already obtained the address for the surviving Communication Manger. Next time user "A" requests services, he/she would again receive the failed server IP address until such time that his/her request results in one of the surviving Communication Manager IP address being returned.
For this reason, round robin DNS is not recommended for a high availability-based solutions over that of SLB or an appliance-based approaches. It is included here to discuss its capabilities as well as its limitations to the overall user experience.
Network Time Protocol (NTP)
While availability is not typically affected by NTP, it can provide valuable assistance in determining the sequence of events that lead to a disruption of service. In addition, having the time synchronized between the phone, Beacon Alert Manager CUAE application server, network infrastructure and Raulands Responder IV systems, such time synchronization can become important when tracing the delivery of messages as they traverse the overall solution.
Implementing a redundant and hierarchal NTP design can provide valuable information during troubleshooting, resulting in the reduction of service interruptions.
During the configuration of the Communication Managers, it is possible to configure an NTP time server that will be used to provide accurate time information to each handset comprising the Unified Communication solution. Therefore, it is recommended that the Communication Managers be installed using one or more NTP time servers.
Nurse Connect Implementation
This section provides implementation details for the services enabled by CUCM and CUAE for the Nurse Connect solution. This section illustrate the steps required to configure the features across the various components to enable the solution. Design concepts along with limitations are provided in order to provide guidance for a successful implementation.
Network Topology
Figure 25 provides a network topology view and provides a frame of reference as the solution is being implemented. This diagram should be referred to as you implement these infrastructure setup steps outlined in the previous sections as well as the Nurse Connect application discussion covered in this section.
There are a few components that comprise this solution and the placement of these components as they pertain to the various places in the network (campus, data center, etc) that will help to ensure better performance, availability, and security for the solution.
Figure 25 Nurse Connect Network Topology Overview
Configuration Task List
Configuration of the Nurse Connect solution is a multi-step process that involves components across the network infrastructure, Unified Communications, Unified Mobility, the CUAE-based Beacon Alert Manager application server and the Rauland Responder IV nurse call system.
The focus of this checklist is to outline the key steps necessary to enable Nurse Connect in addition to provide pointers to several foundational design guides that should be used in all deployments.
Step 1
a.
1.
2.
3.
a.
Step 2
Step 3
Step 4
Step 5
a.
b.
c.
Step 6
a.
b.
Step 7
Step 8
a.
b.
c.
Note
Unified Communications
Communication Manager Configuration
This section describes the configuration of the Communication Manager. The following provides a detailed checklist of key items to configure to enable Nurse Connect solution.
The following is a summary of CUCM configurations:
•
•
Creating an Application User
Creating an application user account provides the necessary authorization necessary for the Beacon Alert Manager application to interact with the IP phones. Some examples of this interaction is the series of commands being sent to the phone through an HTTP push.
Before a phone can accept and execute a command from an external application (other than Communication Manager), it first checks to see if the application userid/password that is supplied in the command request matches a configured application userid/password and associated role. The role assigns various levels of permission based on different levels of interaction. The phone uses the Authorization URL configured in CUCM under System > Enterprise Parameters, which is communicated to the phone during the Communication Manager registration process.
For Beacon Alert Manager, Standard CTI Enabled is the role required. This permits basic Computer Telephony Integration (CTI) interactions to be made to the phone for a set of predefined functions. This configuration only needs to be performed during the initial installation.
Adding an Application User in CUCM
Step 1
Step 2
Step 3
Note
Figure 26 Configuration of an Application Push User
Step 4
Figure 27 Assignment of Group and Role Permissions
Step 5
Figure 28 Assignment of the Application user to the Standard CTI Enabled Group
Step 6
Step 7
Figure 29 Adding Nurse Connect IP Phones to the Application User
Step 8
Configuring SNMP
SNMP configurations must be defined so that the Beacon Alert Manager CUAE application server receives periodic updates when changes to phone states or configurations occur. Upon startup of the application, an SNMP query is initiated against all configured Communication Managers. Once the query has completed, the list of registered or unregistered phones are communicated to the Nurse Connect application using periodic SNMP traps.
The following steps show how to configure an SNMP community string used to perform the SNMP query and how to configure SNMP traps for periodic updates.
Step 1
Step 2
Step 3
Step 4
Figure 30 SNMP Community String Configuration
a.
b.
c.
d.
e.
Step 5
Step 6
Step 7
Step 8
a.
b.
c.
d.
e.
f.
g.
Figure 31 CUCM SNMP Trap Configuration
Step 9
Step 10
Figure 32 Cisco CallManager SNMP Service Activation
Creating Beacon Alert Manager XML Service
Step 1
Figure 33 Beacon Alert Manager XML Phone Service Configuration
Step 2
http://<CUAE IP Address>:9897/messages?deviceName=#DEVICENAME#
See Figure 34.
Figure 34 CUCM XML Phone Service Configuration Service URL
Installing and Configuring CUAE 2.5(1)
The Beacon Alert Manager application runs on the CUAE application server. It is beyond the scope of this document to highlight the installation and configuration steps necessary for CUAE 2.5(1). Instead, it is recommended that the installation guide for the Cisco Unified Application Environment (2.5.1) be followed. This documentation can be found on Cisco's website at the following URL:
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cuae/2_5/english/install/guide/uaein.html
Note that the CUAE application server can resides on a number of different Media Convergence Servers (MCS) depending on volume and use as shown in Table 12 and Table 13 below.
Once CUAE 2.5(1) has been fully installed, the installation of the Nurse Connect application can be started.
Nurse Call Voice Callback Configuration
The ability of the care provider to quickly establish voice communication to the patient bedside is an important capability of the Nurse Connect solution. There are two primary methods to establish voice dial-back to a Rauland Responder IV nurse call system.
1.
2.
If the callback is to interface directly to a Rauland Responder IV NCTLI module using an FXS interface, a ISR voice gateway is required.
To configure this type of connection, the Communication Manager requires an H.323 voice gateway and optionally an H.323 gatekeeper if the dial plans are complex. The example provided here shows a sample configuration using an ISR voice gateway as an H.323 gateway. In this example, the ISR voice gateway router was directly connected to the Rauland Responder IV NCTLI ports using FXS ports.
Note
The dial plan shown in this example consists of two pilot numbers (1000 and 1001). In the Communication Manager, a route pattern of 1000XXX#X has been configured to route multi-bed roomed callbacks matching that pattern to the ISR voice gateway(s). In order to support rooms with a single bed, which do not require the #<Bed Number> notation, a second route pattern has been configured as 1001XXX.
Step 1
interface FastEthernet0/0 ip address 10.6.2.152 255.255.255.0 duplex auto speed auto h323-gateway voip interface h323-gateway voip bind srcaddr 10.6.2.152Step 2
voice-port 1/0/0 no comfort-noise description To Rauland Responder IV NCTLI Line 1 Port ! voice-port 1/0/1 no comfort-noise description To Rauland Responder IV NCTLI Line 2 PortStep 3
dial-peer voice 1000 pots preference 1 incoming called-number . destination-pattern 1000.T progress_ind setup enable 3direct-inward-dial prefix ,, ! dial-peer voice 100 pots incoming called-number . destination-pattern 1000 progress_ind setup enable 3 direct-inward-dial port 1/0/0 ! dial-peer voice 101 pots incoming called-number . destination-pattern 1000 progress_ind setup enable 3 direct-inward-dial port 1/0/1! Note : The dial-peers 1001, 102 and 103 are used to support single rooms ! (rooms with only 1 bed and therefore do not require the # symbol to signal to ! Rauland that a Bed number is about to be supplieddial-peer voice 1001 pots preference 1 incoming called-number . destination-pattern 1001.T progress_ind setup enable 3direct-inward-dial prefix ,, ! dial-peer voice 102 pots incoming called-number . destination-pattern 1001 progress_ind setup enable 3 direct-inward-dial port 1/0/0 ! dial-peer voice 103 pots incoming called-number . destination-pattern 1001 progress_ind setup enable 3 direct-inward-dial port 1/0/1Step 4
Figure 35 Adding an H.323 Gateway in Communication Manager
Figure 36 Communication Manager H.323 Gateway Configuration
Step 5
Figure 37 Communication Manager Route Pattern - Multi-Bed Rooms
Step 6
Figure 38 Communication Manager Route Pattern —Single Bed Rooms
For those systems that connect to the Rauland NCTLI through an existing legacy PBX, some digit manipulation may be required. Typically in these cases, the system may require some leading digits to be prepended to the dial-string to enable an access code or for two-stage dialing environments. Two-stage dialing is when phone A, in this case a Nurses 7921G or 7925G wireless phone, places a call to a pilot number defined to the PBX (first stage). This pilot or hunt group number then maps the inbound call to the Rauland NCTLI module (second stage).
When the Cisco IP phones execute a dial-string, all digits are passed at once to the voice gateway for execution. In situations where two -stage dialing exists, the phone may need to dial the following digit stream:
1000202#2
The first four digits are the pilot or hunt group (1000), which causes CUCM to route the call through the H.323 trunk to the ISR voice gateway router. The next three digits represent the digits that need to be DTMFed "played" out to the Rauland Responder IV system once it answers the inbound call. In the example above, that is room 202. The # is required by Rauland Responder IV to signal that a bed number is to follow, the final digit is 2.
Reducing Delay in Audio Callback
The Cisco IP phones dial all the digits without pausing as the entire dial-string 1000202#2 was passed to the voice gateway for processing using an IP-based signaling protocol called SCCP or SIP. Pauses are therefore ignored in the dial string.
In environments where two-stage dialing is required, the delay in the timing of the DTMF playout of the second set of digits (202#2) is critical and may require testing various delay schemes.
There are a few sources of delay in two-stage dialing environments:
1.
2.
3.
4.
5.
6.
7.
Pauses may be inserted by the ISR voice gateway in order to time the playout of the digits required to meet the delays unique to the two-stage dialing environment and the inherent delays of various PBX implementations.
It is therefore not possible to provide a configuration that will meet the requirements of all two-stage dialing environments as each one may be different to some degree. Instead, it is recommended that the following document be consulted as it outlines various digit manipulation techniques that can be employed on the ISR voice gateway.
Note
During the validation of Nurse Connect, an ISR voice gateway was configured and connected directly to the NCTLI module using FXS ports. The average call connect time was about 8 seconds with the following steps comprising the delays encountered.
1.
2.
3.
4.
5.
There are a few changes that can be made to reduce the overhead in establishing an audio call between the care provider and patient device, but the savings are relatively small. In general, they can be summarized as follows:
1.
2.
Note
In all, this tuning could save approximately 1.5 second of in establishing the dial-back connection to the patient device. It is not recommended however to tune to these minimums as it increases the likelihood of an unsuccessful callback.
These delays are documented here in order to provide an understanding of the various components involved in a dial-back and the delays they induce.
Note
XML Services Redundancy on CUCM
A number of different XML applications may be subscribed to on a Cisco phone. Some examples would include the Nurse Connect solution, Extension Mobility or other third-party XML applications. When the Services softkey is pressed on the phone, a menu of subscribed applications is presented. This menu is typically delivered by a Communication Manager.
In most cases, the URL used to deliver the menu of subscribed services uses a hostname that points to the Communication Manager. In some deployments, the IP address has been substituted for a hostname eliminating the need for DNS name resolution of the CM hostname.
The inability to either resolve the DNS hostname or the inability of the phone to have IP connectivity to the Communication Manager presents a failure scenario that should be addressed.
In addition to the Services URL, the Authentication URL which is found under System > Enterprise Parameters in Communication Manager will also need to be load balanced among within a CUCM cluster. When the phone is sent a command which it needs to execute, it first checks with its configured Authentication URL to validate that the userid/password specified in the parameters of the command are associated with the phone. If the phone is unable to contact the host specified in the Authentication URL field, it will not execute the commands sent to it.
The single point of failure for XML services can be addressed in a number of different ways. As a best practice, it is recommended to implement a highly available XML service infrastructure by using one of the following three methods.
1.
2.
3.
A sample configuration using IOS SLB is described below. Figure 39 shows a view of the redundancy configuration.
Figure 39 Highly Available XML Services Using IOS Server Load Balancing
Step 1
Step 2
! probe to check for the availability of the server ip slb probe MY-PROBE tcp address 10.1.1.22 port 8080 ! define a equally balanced access to CUCM servers ip slb serverfarm Nurse-Connect-1-1 nat server probe MY-PROBE ! real 10.1.1.20 weight 1 inservice ! real 10.1.1.21 weight 1 inservice ! define the virtual server ip slb vserver Nurse-Connect virtual 10.1.1.22 tcp 8080 serverfarm Nurse-Connect-1-1 inserviceStep 3
Figure 40 Communication Manager URL Parameters using an IOS SLB virtual IP address
Note
IP Phone Configuration
This section covers the configuration for IP phones that are being used with the Nurse Connect solution. Follow this checklist to configure all phones associated with Nurse Connect.
This section covers the following key items:
•
•
Configuring IP Phone
The Cisco IP phones supported with Nurse Connect are as follows:
•
•
•
•
•
•
•
•
•
•
Note
The following phones were tested as part of the Cisco Validated Design: 7921G, 7925G, Cisco 7941G, 7961G, 7970G, 7971G, 7975G, and the 7985G videophone. Follow the steps below to create a phone that will be used for Nurse Connect solution.
Step 1
Step 2
Step 3
Step 4
http://<Nurse Connect/CUAE IP Address>:9897/messages?deviceName=#DEVICENAME#
Step 5
Figure 41 Weak Signal Warning Message
Step 6
Note
Step 7
Figure 42 Communication Manager 7925G Phone Configuration
Subscribing the Phone to the Beacon Alert Manager XML Service
Now that the phone has been defined, XML services can be added to the Cisco IP phone. Follow the steps below if Extension Mobility is not used for the phone. If Extension Mobility is used, then only default device profile for the needs to be subscribed to the Nurse Connect Service.
Step 1
Step 2
Step 3
Figure 43 Subscribing IP Phone to Nurse Connect Service
Step 4
Figure 44 Subscribing IP Phone to Nurse Connect Service
Note
Creating an Extension Mobility Device Profile
The process of creating an Extension Mobility user is similar to that of creating a phone. Instead of defining a physical phone, you are creating a virtual phone in the form of a device profile that will be applied to a physical phone after the user has logged in using the Extension Mobility service. Follow the steps below to setup Extension Mobility.
Note
Step 1
Figure 45 Extension Mobility Default Device Profile
Step 2
Figure 46 Extension Mobility Default Device Profile
Step 3
Figure 47 Extension Mobility Default Device Profile
Step 4
Figure 48 Extension Mobility Subscribe/Unsubscribe Services
Step 5
Figure 49 Extension Mobility Subscribe/Unsubscribe to Extension Mobility and Nurse Connect
Step 6
Figure 50 Adding an End User to CUCM for Extension Mobility
Figure 51 Adding an End User to CUCM for Extension Mobility
For ease of use , it is recommended that the selection of the userID be easy to enter due to the mechanism used for typing an alpha-based userID on a phone keypad. Using upper and lower case in the userID field can be difficult as well for the end user. The PIN, however, is always a number and is therefore easier to type.
Nurse Connect Configuration
This section covers the configuration steps necessary to enable the integration of the Radianta Nurse Connect application to the Rauland Responder IV and Cisco Unified Communication Manager.
The Radianta Nurse Connect configuration consists of the following:
•
•
•
•
•
•
Installing Radianta Nurse Connect
The Nurse Connect product comes from Radianta with its own user guide and integration/installation documentation. The information within this document is intended to show the steps taken during the Cisco validated design process of the solution. For complete and updated information on the installation and configuration of the Radianta Nurse Connect product, refer to the Radianta's website at following:
The Radianta Nurse Connect application is a Cisco Unified Application Environment application and therefore must be installed on a server running on a CUAE 2.5(1) application server. This environment uses the Microsoft Windows 2003 Server-based operating system. As such, the application is installed just like any other Windows-based application. CUAE 2.5(1) must be installed and operational before installing the Nurse Connect application from Radiatna.
Step 1
Figure 52 Radianta Nurse Connect License Agreement
Step 2
•
•
•
•
•
•
It is recommended to leave the database username as "root" but to supply a password that conforms to the Information Security standards implemented by the organization.
When CUAE was initially installed, a userid and password was requested during the installation of the CUAE application server. In the fields shown, enter the CUAE administrative userid and password. This will allow the installer to install the Nurse Connect application.
The web-based userid remains fixed as Administrator, but during the install process the password can be changed. Once again, choose a password that conforms to the Information Security standards implemented by the organization.
The next field requires that the IP address of the server that the Beacon Alert Manager (the CUAE application server) is being installed on. This address is needed so that the Cisco IP phones know the address to use in order to retrieve the alert message. In this case, this would be a statically configured IP address of the CUAE 2.5(1) server.
Note
Figure 53 Nurse Connect Required Installation Settings
Step 3
Figure 54 Nurse Connect Destination Folder
Once the install completes, the verification and Nurse Connect configuration can begin.
Verifying CUAE Application Install
During the end of the installation process, the Nurse Connect installer automatically installs the CUAE component. If the userid/password for CUAE are entered incorrectly, this process fails. If the details button was pressed during the install, near the end you should see an indication as to the success or failure of the CUAE "NurseCallMakerApp" application installation. An example of a successful installation is shown in Figure 55.
Figure 55 Nurse Connect CUAE Application deployment
Step 1
Once there, select Applications > List Applications and the screen in Figure 56 should be displayed.
Figure 56 Nurse Connect CUAE NurseCallMakerApp application
Step 2
Accessing the Radianta Nurse Connect Administration Page
To access the Radianta Nurse Connect configuration and administration page, use Internet Explorer Version 6 or higher and access the following URL:
https://<ip address of CUAE App Server>
Note
Figure 57 Nurse Connect Login screen
Enter the Nurse Connect web GUI username of Administrator followed by the password that was supplied during the installation step above (see Figure 57).
Installing Nurse Connect License
Radianta's Nurse Connect is licensed based on the number of TAP Connections and the number of beds. Included with your purchase is a license file that will enable the configuration of TAP Connections.
Step 1
Figure 58 Nurse Connect Service Status
Step 2
Figure 59 Nurse Connect License
Configuring Alert Destinations (Outputs)
The next step in the configuration process is to define which systems alerts should be sent to. In this release of Nurse Connect, the two types of destinations that are supported are Cisco's Unified Communication Manager and WaveWare SPS5 paging system.
The following versions of Communication Manager are supported by the Radianta Nurse Connect application: 5.x, 6.x, and 7.x. Some versions of Communication Manager 4.x are also supported. For specific information about 4.x support, consult Radianta's website and sales information.
Note
Step 1
Step 2
Figure 60 Nurse Connect Alert Destinations
Note
Step 3
Figure 61 Nurse Connect Alert Destinations
Step 4
Configuring TAP Connections (Nurse Call Systems)
The Rauland Responder IV nurse call system uses Telelocator Alphanumeric Protocol (TAP) to send text alerts over a serial interface. The nurse call alerts are generated on the Rauland Responder IV NCDATA module, and are by default communicated on port 2 using 9600bps, even parity, 7 databits , and 1-stop bit.
Note
The physical connectivity to the NCDATA headend device is described in detail in"Appendix" section. Since the physical connectivity is assumed, the next step is to logically configure the Radianta Nurse Connect application to communicate with the RS232 adapter which is connected to the Rauland Responder IV system. Either the Digi One SP or the Precidia Technologies iPocket232 can be used to connect to the Rauland NCDATA module.
When configuring the RS232 adapter, a TCP port was defined. By default, each product uses the ports listed in Table 14 for RAW access to the RS232 data stream.
Table 14 TCP Ports
Precidia Technologies
iPocket232
TCP Port 9999
Available in v5.02.01
Digi Corporation
Digi One SP
TCP Port 2101
None
•
•
In the pull-down menu, select the Rauland Responder IV as the nurse call. The hostname should be the IP address of the RS-232 adapter connected and configured for this nurse call system. Select the default port for RAW access to the RS-232 TAP stream (refer to Table 14). The values listed in Table 14 are default values, but any TCP port can be used. See Figure 62.
Note
Figure 62 Nurse Connect TAP Connection to a Responder IV system
Associating Alert Destinations
Previously in this configuration process, a series of Alert Destinations were defined. These alert destinations currently consist of Cisco's Unified Communication Manager products as well as WaveWare SPS5v7 TAP-based paging system.
Now that a TAP Connection to the Rauland Responder IV system is created, the next step is to logically associate the various alert destinations (CUCMs) that are created with the nurse call TAP Connection.
By selecting Edit for the TAP Connection, some additional information is displayed including the Alert Destinations.
By selecting the available alert destinations (Communication Managers or WaveWare paging systems) and moving them over to the Associated Alerts column, the system will search the systems in the order shown and attempt to find a matching directory phone number for a device that matches the indicated "pager" phone number sent to it from the nurse call system.
The ordering of this search is important as there may be instances where in multi-hospital environments, which are comprised of many different Communication Manager clusters, a dial-plan overlap may exist. But in order to support the system alerts capability as described below, the system needs to search through its own Communication Manager cluster first, and as a last resort, fall back to the last Communication Manager or pager system defined. Figure 63.
Figure 63 Nurse Connect TAP Connection to a Responder IV System
Defining Dial-back Mappings
When a Rauland Responder IV system is initially installed, each patient's bed is assigned a dial-back phone number. Establishing an audio callback to the Rauland Nurse Call Telephone Line Interface (NCTLI ) module is discussed previously in this document.
The phone numbers assigned to the patient room pillow speakers were statically defined when the original nurse call system was installed. As such, these phone numbers do not change when patients are admitted, discharged, or transferred throughout the facility. Therefore, a static mapping between the room number and, in the case of multi-bed patient, rooms must be configured in the Nurse Connect application. On the TAP Connections tab, selecting mappings provides the administrator with a method of defining these dial-back phone numbers.
A pilot or hunt group phone number is typically assigned to either the existing PBX or newly installed ISR voice gateway router. This pilot phone number must be the first series of digits comprising the dial-back phone number. In our example, a Cisco 2600 and 3800 ISR Voice Gateway router, and a pilot number and route pattern of 1000 were defined and used in Communication Manager. When the end user presses the callback softkey, the digits dialed by the Cisco IP phone will be as follows:
1000XXX#Y
In the above, 1000 represents the pilot number, XXX represents the room callback number as defined in Responder IV system. The # is a delimiter used to inform the Rauland Responder IV system that a bed number is to follow, this is Rauland Responder IV specific. In this case, a 1 would be used in place of Y to reach bed 1.
Figure 64 Nurse Connect TAP Connection to a Responder IV system
In Communication Manager, a route pattern is defined as 1000XXX#X , which is mapped to the H.323 trunk that is used to connect to the Cisco ISR voice gateway router. When the dial-peer configured on the ISR voice gateway router matches the first part of the dial-string 1000203#2, using a dial-pattern of 1000 in the ISR dial-peer statement causes the 1000 to be stripped from the dial-string and are not DTMF- dialed to the Rauland Responder IV system.
Instead, to account for the delay in the Responder IV system in answering the inbound call, a series of pause characters are typically inserted into the beginning of the remaining dial-string 203#2 resulting in ,,203#2 (pause for NCTLI module to answer, then DTMF 203#2 in order to reach room W203, bed 2.
Since the dial-peer in question prepends the added pauses (the commas), it also will direct the call out of the next available FXS port that is connected to the NCTLI module. The omission of the prefix command in the dial-peer will cause the ISR FXS port to DTMF dial the remaining digits upon the detection of a dial-tone. In the event that the dial-tone is not detected, the use of the prepend insertion of commas (1 second delay each) may be necessary.
For those installations where the NCTLI module is connected to an existing legacy PBX, the audio path used between the Cisco Unified Communication Manager controlled gateway may be in a number of different forms as shown in Table 15.
Each of the mappings defined are unique to the TAP Connection or nurse call system for which they are being defined. For a detailed ISR configuration example, refer to "Nurse Call Voice Callback Configuration" section.
Note
Defining System Alert Destinations
System alerts are used to signal various key end devices that a system problem has been encountered with the specific TAP feed for which they are designed. In this case, each time there is a connectivity problem encountered with this TAP instance or the "West Wing Rauland" system, the Nurse Connect application will forward alert messages to each of the configured IP Phone destinations. Select System Alerts as shown in Figure 65.
Figure 65 Nurse Connect TAP Connection to a Responder IV system
Note
Enter the directory number of the Cisco IP phones that should receive an alert message when connectivity and service has been disrupted between the nurse call system and the Nurse Connect application running on the CUAE application server. Typically this may be inclusive of the Duty Nurse Cisco IP phone (wired or wireless) as well as perhaps the helpdesk and other support groups within the healthcare organization using a Cisco IP phone.
In the example shown Figure 66, system alert destinations of x2021 and x207 have been configured.
Figure 66 Nurse Connect System Alerts
By default, the Nurse Connect application will send a keepalive null message to the configured TAP Connection every 5 seconds. If the keepalive is not responded to because of a disruption of service, an alert is sent to each of the configured system alert destinations.
Note
In addition, if the Nurse Connect service is stopped by the administrator from the GUI configuration tool, the system will first generate a system alert message informing each configured system alert destination with a notification of the disruption of service as shown in Figure 67.
Figure 67 System Alert - Service Stopping Message
Likewise, once service has been restarted, a service starting message is sent to all configured system message destinations. See Figure 68.
Figure 68 System Alert - Service Start Message
When the Nurse Connect software successfully completes the TAP Connection handshake with the Rauland Responder IV system, the system alert message( shown in Figure 69 and Figure 70) is sent to all phones configured as a system alert for the respective TAP Connection (or Rauland Responder IV system).
Figure 69 System Alert - TAP Connection Established Message
Figure 70 System Alert - TAP Connection Established Message
At the same time the TAP handshake completed, the Rauland Responder IV NCDATA modules status light for the configured TAP port will illuminate as shown in Figure 71. In addition, the Transmit and Receive lights will blink when data is being sent or received.
Figure 71 Rauland Responder IV NCDATA - TAP Connection Established Status Light
End User WorkFlow Experiences
Assignment of Phones
The workflow for a nurse or care provider as it relates to Nurse Connect begins with the association of Cisco IP Phone to the individual for the duration of their shift. There are three basic mechanisms that can be used by a healthcare or LTC organization to associate a phone to a given care provider. Each of these methods are discussed in detail below. Other variations of these workflows may be used as needed to fit the unique requirements of the healthcare organization.
Using Extension Mobility
Extension Mobility is a Cisco Unified Communication feature which allows for the dynamic assignment of a users "phone profile" to any physical phone onto which the user has logged onto.
The care provider would typically obtain a phone from a gang charger upon the start of their shift. Each of the phones in the charger are not assigned to any caregiver at this time. The phones can optionally have a generic extension phone number applied to them which permits their use for outbound dialing without the need to logon to the extension mobility function.
The physical phone that they have selected has previously been subscribed to the XML service called Extension Mobility by the system administrator. By selecting the services button on the phone, the XML applications or services to which the phone are subscribed are displayed.
By selecting the Extension Mobility application, and entering the nurses assigned userid and password, the phone assumes the users telephone settings or profile. This includes the directory phone number assigned to the individual care provider.
The care provider or nurse has previously been defined in the Rauland Responder IV system with this directory number. Once the duty nurse assigns the nursing staff to individual patients, the association is complete.
Figure 72 shows the steps involved for an Extension Mobility end user.
Figure 72 Extension Mobility End User
Note in Figure 72 above that the phone initially has a directory number of 2021 before the user logs on using Extension Mobility, and after the phone has the 7025 extension.
Upon termination of the shift, the care provider simply needs to logoff the phone by selecting the services menu once again, and executing the Extension Mobility. The user is asked if they intend to logoff, and responding Yes will return the phone to its prior state. See Figure 73.
Figure 73 Log Off
Using Rauland Responder NET
The Responder NET product from Rauland is essentially a software overlay that provides the nursing with a richer graphical interface to the Responder IV nurse call system. One of the unique features of the Responder NET system from Rauland is its ability to use bar codes for care providers and their associated phones and/or pagers.
As the illustration in Figure 74 shows, the addition of a bar code scanner to the workflow has been added. This allows the nurse to scan a bar code from their employee badge for example which uniquely identifies this individual to the Responder NET system. To complete the process, the care provider then scans the bar code attached to a Cisco IP phone.
The bar code assigned to both the care giver and/or Cisco IP phone is simply a unique number that corresponds to the individual and a physical phone. Within the Responder NET system, this unique number is associated with a member of the nursing staff or the static directory number of a phone. Each time the Responder NET system scans the barcode, it automatically associates the barcode with either the individual and/or phone number.
Figure 74 Responder NET Barcode Scanner
This scanning process allows the Responder NET system to dynamically associate the nurse or care provider with an arbitrary phone which the user has selected for their shift. When the duty nurse makes the patient to staff assignment, the Responder NET system automatically directs all alerts generated by the patient to the assigned care provider.
This solution does not require the use of the Cisco Extension Mobility feature, and may already be in use in many of the healthcare organizations with Responder IV systems installed. This allows the healthcare or LTC organization to use statically configured phones for use with their staff.
Without using Extension Mobility, however, the care provider will more then likely have a different phone and therefore phone number for each shift. If ancillary departments or other care provides wish to reach someone on a patient floor by dialing the desired persons phone number, they will not be able to reach the desired party as their phone number has changed.
If such direct reachability is required by ancillary departments or other care providers, the use of Extension Mobility should be considered.
Static Phone Assignments
Some organizations may find that static phone numbers assigned to phones which map to various clinical roles (RN, LPN, Staff, Aide or CNA etc) may be acceptable. In this case, creating a group of phone numbers and statically assigning them to Cisco IP phones is all that is required.
So for example, the third floor RN phone is assigned 3001, third floor LPN assigned 3002 and so on. For the second floor, 2001, 2002 and so on are assigned for the RN, LPN, staff and aid, respectively.
Long Term Care (LTC) facilities might adopt this approach as the care providers assigned to various residents or areas of the campus do not often change over the short period of time. In addition, LTC organizations may find that providing a dedicated phone and directory number to each care provider has a number of advantages over that of a dynamic phone assignment model. This allows the on-duty care provider to be directly reached by a resident that would like to discuss personal care aspects with the need to generate a patient alarm for non-emergency type of service requests.
In most cases, however, the use of Extension Mobility offers the most flexible method of allowing an end user to select any physical phone and having their unique phone settings including directory number applied to the phone.
Assignment of Patients to Caregivers
Within the Responder IV system, the duty or charge nurse typically assigns staff to patients based on the level of care required. Using the Central Station phone that is part of the Rauland Responder IV system, staff assignments can be made.
Selecting the Staff Options will display the current staff members assigned to the Responder IV system as shown in Figure 75.
Figure 75 Rauland Central Station —Assigning Patients to Caregivers
By selecting the staff name through the touch screen user interface, the staff duty information is displayed. The Room Coverage button will then display all rooms assigned to the staff member. It will also list the priority of calls that the staff member has the proper training necessary to respond to. In addition, their role as Primary or Backup is displayed. See Figure 76.
Figure 76 Rauland —Central Station Room Coverage
Receiving an Alert
The Responder IV system will issue a single TAP message for each event and for each responsible care provider that is configured to be notified for the type of alert triggered. The generation of alerts however is not restricted to patients, but can also be generated at the nurses central station through the Pocket Pager function.
Despite which method was used to generate the alert, each and every event generates at least one TAP message that has a specific format as sent by the Rauland system. In the beginning of each TAP message is the directory or pager number to which the alert is to be sent.
Based on the TAP source that generated the alert, the Nurse Connect application attempts to find a matching phone within the associated Communication Managers. When a match is found, it sends a series of commands to the phone requesting that the phone retrieve the message from the web service running on the CUAE application server. In addition to an audible indicator for a new message event on each supported Cisco VoIP phone, the 7921G and 7925G wireless phones also provide a vibratory alert. See Table 16 for the list of phones and features.
To the end user of a Cisco IP phone, the alert contains the exact text that was sent by the Rauland Responder IV system. Appended to the message is the date and time that the message was received.
The display of the message on the Cisco 7925G is identical to that of the Cisco 7921G VoIP phone. An example of a 7971G and 7925G are shown in Figure 77.
Figure 77 Message on Cisco 7971G and 7925G
Acknowledging Alerts
Once an alert has been received, the caregiver can take one of two actions. The first is to establish an audio call to the patient bedside pillow speaker, if the nature of the call is appropriate. In the example shown above, the typical response for a Bath Assist call is to physically respond to the patient as most Bath Assist calls are generated by a pull string-based device that does not have two way audio capabilities.
The other option is to acknowledge the alert by pressing the Ack softkey. This process marks the message in the Nurse Connect database as acknowledged and removes the alert from the list of outstanding unacknowledged messages.
Establishing Audio Callback to the Patient Device
In the event that an audio callback is appropriate for the type of alert received, the care provider needs to simply press the Dial softkey as displayed in the figures above. This will cause the phone to dial the configured dial-string which has been assigned through the mapping function to the patient device that generated the alert.
Note
Setting Service Priorities
Service Priorities is a feature that allows the nursing staff of a Responder IV system to set a second alert for another class of care giver. If the Certified Nursing Assistant (CNA) for example triages the call and while speaking with the patient determines that an RN should be summoned to provide additional assistance, the RN Service Priority can be set by the CNA by pressing "4" while in the audio call with the patient. This DTMF generated tone is received by the Rauland Responder IV system and based on the key pressed will change the dome/corridor light according to the protocol implemented within the healthcare facility.
Table 17 shows the typical Service Priorities that can be generated during an audio call with a patient device. Each healthcare organization however may elect to implement a custom service priority protocol.
Note
Management and Operational Considerations
Nurse Connect Logs and Reports
Activity logs can be obtained from within the Nurse Connect application for a given directory number, or through the use of wild cards a range of directory numbers. The report can be used to troubleshoot problems during the implementation phase, or can be used to establish call volumes.
To produce a report for all activity for extension 2025, enter 2025 in the report Endpoint field as shown in Figure 78.
Figure 78 Nurse Call Reports
Once the report has been generated, a chronological list of events that have occurred for the handset(s) matching the search term used is displayed. In the example below, note that extension 2025 received a Normal and Bath Assist call from Room W202, bed 1.
The Sending_Execute_To_Phone state shows the time in which the phone was sent an execute command asking it to retrieve the message from the web service running on the CUAE application server.
Note
Once the phone retrieves the message after receiving the command to execute an HTTP GET command, a FETCHED flag is indicated for the event. This is positive confirmation that the phone performed an HTTP GET of a unique URL corresponding the nurse call event. The time indicated shows when the phone physically completed the message retrieval and hence at this point in time, the phone should have displayed the message. See Figure 79.
Figure 79 Nurse Call Report (2)
In addition to being able to see various messages that were sent to a phone, it is also possible to review the overall operation of the Nurse Connect solution. In the example below, a report was run against the System Alert directory number that was defined to a particular TAP Connection (Responder IV system).
As shown in the example in Figure 79, the time that the administrator started the service as well as the time that the Nurse Connect application successfully established a TAP Connection to the TAP Connection (Responder IV system) is shown in Figure 80.
Each nurse call alarm message received is assigned a unique event identifier. As the event progresses through the process of being sent to a phone, it passes through a series of states. These states can be used in troubleshooting and have the definitions shown in Table 18.
Figure 80 Sample Messages
Once the service was started, it was determined that a care provider has 16 unacknowledged messages. A system generated reminder message is sent to any phone that has an outstanding unacknowledged message.
Note
Appendix
Netformx DesignXpert Supported Design
The Cisco Nurse Connect solution has been incorporated into the Netformx DesignXpert library updates. Using Netformx, sample solution designs and bill-of-materials can be referenced and, if needed, can be modified to fit the specific deployment scenario required for a given healthcare organization. Over time, when the need to update the design becomes necessary, the Netformx updater mechanism automatically downloads the Cisco verified solution blueprints and corresponding part numbers that comprise the solution to all Netformx subscribers.
The Cisco Industry Solution Engineering team has partnered with Netformx to offer its solution designs in the DesignXpert quoting tool. By using Netformx DesignXpert, quoting a solution becomes significantly simplified, increases productivity, and helps eliminate missed components —promoting customer satisfaction. DesignXpert helps you and your customer establish a validated solution blueprint that becomes a reliable reference source for managing the overall life cycle of the solutions.
More information about the Netformx DesignXpert is available at the following URL:
Configuring Serial Converters
Digi One SP Configuration
The Digi One SP can be used on either the Rauland Responder IV system, or the WaveWare SPS5v7 pager system. Nurse Connect recognizes the Digi One SP as either a "TAP Connection" via Rauland Responder IV or as an "Alert Destination" via a WaveWare SPS5v7 pager system.
When connecting the Digi One SP to a Rauland Responder IV NCDATA port, using a straight-through cable is an option as long as the NCDATA module's serial port is set to Data Communication Equipment (DCE). Since the straight-through cable is an option, the Digi One SP can instead be connected directly to the serial port on the NCDATA module.
Note
The Digi One SP can emulate a number of different serial EIA configurations, such as EIA-232, EIA-422 or EIA-485. Since the Rauland Responder IV uses RS-232 communication, the ports on the Digi One SP should be configured for EIA-232 as shown in Table 19.
When connecting the Digi One SP to the Ethernet network, it will by default use Dynamic Host Configuration Protocol (DHCP) to obtain an IP address and other pertinent DHCP scope information such as default gateway and Domain Name System (DNS) address. To locate the IP address assigned to the Digi One SP, you can examine the DHCP leases by searching for the media access control (MAC) address of the Digi One SP that is printed on the device itself.
Another method of finding the IP address assigned is to look at the address resolution protocol (ARP) table of a device on the local subnet. On a Cisco router or Layer-3 switch, issuing a show arp command will show you all the IP addresses learned along with the associated MAC address. By searching for the MAC address printed on the Digi One SP in the ARP table, it is possible to locate the IP address dynamically assigned.
Using your Internet browser, such as Internet Explorer, enter the assigned DHCP address of the Digi One SP device and login as shown in Figure 81. The default userid and password are root and dbps.
Figure 81 Digi One SP Web Login Screen
Once you are signed onto the Digi One SP, it is recommended that you make the following changes to the configuration.
Step 1
Figure 82 Digi One SP Network Configuration Settings
Step 2
Step 3
Figure 83 Digi One SP Basic Serial Settings (Rauland Responder IV Connected)
Step 4
Figure 84 Digi One SP Advanced Network Settings
Step 5
Step 6
Step 7
Note
Step 8
Each byte of information that is transmitted on the TAP output serial port on the NCDATA module from Rauland must be unaltered. This means that there can be no additions of carriage returns, and so on. Because of this, the TCP port used must remain the default port 2101. See Figure 85.
Figure 85 Digi Configuration and Management (Note Raw TCP port of 2101)
Also note that TCP keepalives are enabled (see Figure 84). This causes the Digi One SP to send a TCP keepalive packet to the Nurse Connect system based on the configured value. The TCP/IP stack on the Nurse Connect system must respond to the keepalive request.
The use of TCP keepalives is really only necessary if a firewall or NAT device exists between the Digi One SP and the Nurse Connect server. In some cases, these TCP connections are timed out and closed if no data has been seen on the TCP connection for a certain period of time. Forcing keepalives reduces the likelihood of this problem occurring. Cisco recommends enabling TCP keepalives at an interval not less than two minutes.
Step 9
Figure 86 Digi One SP Serial Port Security Settings
Figure 87 Verify Digi One SP Serial Port Security Settings
Note
Step 10
Figure 88 Digi One SP Network Security—Change to Custom from a Default of Normal
Step 11
Figure 89 Digi One SP Administrator Password
Precidia Technologies iPocket232™ Configuration
Configuring the iPocket232 is straight forward and requires the use of a PC with a serial port. The following procedure summarizes the necessary steps.
Step 1
Step 2
Figure 90 Precidia iPocket232 Configuration Button
Figure 91 Precidia iPocket232 Main Configuration Menu
Step 3
Figure 92 Precidia iPocket232 Ethernet Settings Configuration
Step 4
Selecting option 2 for Serial Port settings followed by A for the serial protocol, the menu illustrated in Figure 93 is displayed.
Figure 93 Precidia iPocket232 Serial Port settings (WaveWare SPS5)
Step 5
Note
Step 6
Figure 94 Selecting Serial Connection Attributes
The correct speed and serial port settings of the iPocket232 will depend upon the type of device to which it is connected and possibly the way in which that device is configured. Table 20 shows the default serial port settings for both the Rauland Responder IV and WaveWare SPS5 paging system.
Table 20 Default Serial Port Settings
9600
Even
7
1
F-7E1-N
9600
None
8
1
F-8N1-N
At this point in the configuration, the serial port on the iPocket232 should be set to transparent server mode with a speed of 9600, N81 as configured in the preceding example.
Verify this configuration by entering a ? key to refresh the screen if necessary. See Figure 95.
Figure 95 Precidia iPocket232—Confirming Serial Port settings (Transparent, Server, 9600 N81 No Flow Control)
By default, the connection control will be set to Automatic as shown in Figure 95. Other settings might cause intermittent communication problems.
Step 7
Note
Figure 96 Precidia iPocket232 Local (TCP) Port Configuration
Select option D as shown in Figure 96 to configure the local (TCP) port.
Step 8
Figure 97 Precidia iPocket232 Remote IP Address Configuration
Step 9
Figure 98 Precidia iPocket232—Disabling SNMP
Step 10
Figure 99 Precidia iPocket232—Configuration Management
Figure 100 Selecting Management Server and Assigning Address
Figure 101 Confirming New Address Assignment
Step 11
Figure 102 Precidia iPocket232—Setting the Remote (Access) Password
Step 12
Troubleshooting Nurse Connect
This section will aid in troubleshooting setup and operational problems that may be encountered during the installation and turnup phase. It is not intended to act as a comprehensive troubleshooting manual, but instead will provide a structured approach to troubleshooting problems that may arise.
For support of the Beacon Alert Manager CUAE-based application, contact the Radianta technical support. If are problems are encountered with the configuration or operation of Cisco components, the recommended first step is to consult the respective product configuration guides available on cisco.com.
Unable to Receive Alerts on Cisco IP Phones
Step 1
a.
1.
2.
3.
4.
5.
6.
7.
8.
b.
1.
a.
b.
2.
a.
b.
c.
d.
e.
Callback to Patient Rooms is Not Working
The overall callback process can involve various implementations that some level of change of that described in this document. There are however a few common components that should be investigated as described below.
Step 1
a.
b.
c.
d.
e.
f.
1.
2.
3.
4.
5.
Step 2
a.
1.
2.
3.
4.
Call to a Patient Room is of Poor Quality
Remember that the Responder IV patient device (Pillow Speaker) is a half duplex device. This means that audio is only capable of being sent in one direction at a time. If both parties are speaking at the same time, or if there is considerable background noise, the audio duplex connection will switch to that side.
Sometimes various medical devices within a patient room will trigger an audio path that is in one direction, from the patient room to the nurses phone. This prevents the nurse from "overriding" the patient room's noise and can make communication difficult.
Step 1
a.
b.
c.
Miscellaneous Operational issues
Step 1
a.
1.
b.
1.
c.
1.
2.
3.
4.
Step 2
a.
b.
Step 3
a.
Step 4
a.
Step 5
a.
Step 6
a.
Once uploaded, follow the next step to allow Nurse Connect to use it.
b.
Analog1.raw, Analog2.raw, AreYouThere.raw, AreYouThereF.raw, Bass.raw, CallBack.raw, Chime.raw, CiscoStandard.raw, CiscoSymphonic.raw, CiscoSynth.raw, CiscoTechno.raw, Classic1.raw, Classic2.raw, ClockShop.raw, Drums1.raw, Drums2.raw, FilmScore.raw, HarpSynth.raw, Jamaica.raw, KotoEffect.raw, MusicBox.raw, Piano1.raw, Piano2.raw, Pop.raw, Pulse1.raw, Ring1.raw, Ring2.raw, Ring3.raw, Ring4.raw, Ring5.raw, Ring6.raw, Ring7.raw, Sax1.raw, Sax2.raw, Vibe.raw
Step 7
a.
b.
Step 8
a.
