Table Of Contents
Connected Imaging—Horizon Medical Imaging Collaboration Application Deployment Guide
Key Objectives and Capabilities
Collaboration and Image Sharing
Places in the Network (PIN) Dependency
CUPC/Study Filtered List Overview
Create Filtered List Messaging Flow
Delete Filtered List Messaging Flow
Unified Communications—Communication Manager
Hospital Phone Integration (Phone and PSTN)
Unified Communication—Cisco Unified Presence
Cisco Unified Personal Communicator
Unified Communications—Cisco Unified MeetingPlace Express
Redundancy and Reliability Subsystem
Unified Communication Components
Cisco Unified Communication Manager
Extension Mobility Personal Identification Numbers (PIN)
Configuring Cisco Unified CM for LDAP Authentication and User Import
Configuring LDAP Directory Information in CUCM
Configuring LDAP Authentication Information in CUCM
MeetingPlace Express Authentication Proxy Setting
Extension Mobility Service Parameter Configuration
Adding CUPC to HMI Application
Connected Imaging—Horizon Medical Imaging Collaboration Application Deployment Guide
January 7, 2009
About the Document
Introduction
This document describes the implementation and configuration of the Connected Imaging—Horizon Medical Imaging (CI-HMI) Collaboration Open Loop solution for healthcare.
Intended Audience
The target audience for this solution is new and existing healthcare providers. It is assumed that administrators of CI-HMI Collaboration have experience with installation and acceptance of the products covered by this network design. In addition, it is assumed that the administrator understands the procedures required to upgrade and troubleshoot networks at a basic level.
Typical users of this guide include the follow groups:
•
Customers with technical staff experienced enough to perform the installation and configuration of the elements required for this solution.
•
Cisco SEs and Advanced Services personnel assisting customers with the implementation of the elements required for this solution.
•
Service integrators and Cisco partners assisting customers with the implementation of the elements required for this solution.
•
System administrators who are responsible for installing and configuring internetworking equipment and who are familiar with Cisco IOS and Cisco Unified Communications.
Executive Summary
The McKesson HMI Collaboration is a healthcare solution jointly developed by Cisco and McKesson to address the need of radiologists to rapidly and easily collaborate with other interested parties when reviewing studies. HMI Collaboration focuses on improving communications management throughout the imaging workflow to improve overall radiologist, technologist, and other caregivers' productivity as well as patient care. It uses Cisco's Unified Communications (UC) suite integrated through UC APIs and the Cisco Unified Application Environment (CUAE) to enhance the features and capabilities of existing McKesson's Picture Archive Communications System (PACS).
HMI Collaboration focuses on improving the daily workflows of radiologists and enables them to differentiate their services through greater collaboration with their customers, the referring physicians. With the focus on communications and workflow, the chief of radiology, radiologists, and senior executives within a healthcare organization are the target customers. The solution opens opportunities for Cisco to expand its relationships with customers, outside of IT, with highly clinical relevant capabilities. The solution also expands Cisco presence outside the hospital as it extends out to referring physicians with CUAE external communications integration.
The initial target market is the imaging services area, because this is where healthcare organizations are investing significant funds. Upon successful market entry through imaging, it has the capabilities to expand into other clinical pathways to make Cisco UC pervasive throughout the healthcare environment.
The solution targets a market leader, McKesson, as the key technology partner. McKesson has reviewed the UC suite and integration opportunities and determined how to use the UC capabilities to differentiate their own imaging application functions. McKesson built an interface module to link the CUPC API and CUAE environments to the PACS application. The interface enables the passing of clinical context from the PACS reports to Cisco UC without requiring modification of PACS application coding.
The development of the solution required designing, building, and implementing a CUAE application unique to the solution. The objective was to develop a CUAE product that can be sold directly to customers and sold through technology partners as a product. Along with these product revenues, support revenues that are unique to the product may also be generated.
HMI Collaboration is segmented into two key phases: open loop and closed loop collaboration. Open loop focuses on improving the timeliness, efficiency, and ease of use of integrated communications and collaboration. It addresses the constant interruptions faced by radiologists as well as the time delays associated with finding and communicating with colleagues. It also simplifies collaboration by using integrated image sharing for collaboration.
The Joint Commission 2008 Patient Safety Goal 2C is to "measure, assess and, if appropriate, take action to improve the timeliness of reporting, and the timeliness of receipt by the responsible licensed caregiver, of critical test results and values." Closed loop builds on the open loop capabilities to include enhanced communications and reporting to help meet the Joint Commission goal.
This document is specific to open loop. Closed loop will be covered in a separate document that will be written when these capabilities are available.
Key Objectives and Capabilities
The open loop communications workflows are driven by the following key clinical requirements:
•
Improve diagnosis and treatment effectiveness with image and application sharing for real-time collaboration between radiologists, technologists, specialists, and general physicians.
•
Align the communications tools and pathways with the acuity of care to effect contacting and communicating the needed party in a timely manner.
•
Eliminate time lost by enabling reaching an available radiologist, technologist, or physician through the synchronous and asynchronous communications.
The HMI Collaboration solution addresses these requirements with an integrated offering of PACS application and Cisco UC components. The integrated solution provides the following three key capabilities:
•
Collaboration and Image Sharing
Presence and Availability
Presence and availability aligns communication pathways and tools with clinical workflows and information for proper synchronous and asynchronous communications.
Communications Setup
Communications setup establishes the most efficient communications channel between the radiologist and colleague based on the presence and availability information.
Collaboration and Image Sharing
Collaboration and image sharing uses the Cisco Meeting Place Express to share images during an imaging consult to improve diagnosis and treatment effectiveness. This collaboration between radiologists, specialists, technologists, and physicians to access and share images in real-time greatly increases the treatment's effectiveness.
Solution Overview
CI-HMI Collaboration is a solution based on McKesson's HMI Picture Archive Communications System (PACS) and the Cisco Unified Communications (UC). The solution seamlessly integrates the Cisco Unified Personal Communicator and MeetingPlace Express directly on the HMI radiology workstation and incorporates a custom application running on a CUAE platform. These applications rely on the Cisco UC infrastructure consisting of Cisco Unified Communications Manager, Cisco Unified Presence, and a custom application running on the Cisco Unified Application Environment. The PACS system and UC infrastructure are built on the foundation of the Cisco Medical-Grade Network (MGN), providing a robust, reliable network infrastructure for the solution.
SONA Mapping
The Cisco Service-Oriented Network Architecture (SONA) provides a foundation for the CI-HMI Collaboration solution. This architecture identifies an end-to-end system, providing a variety of services and a resilient infrastructure to support the application. Although this is an application layer solution, it relies on a variety of SONA services to function effectively in the healthcare environment. The solution is built on Cisco Unified Communications, so all of those components come into play. Patient data is involved and there are stringent requirements for the handling of patient data (see Appendix A—HIPAA Overview) , making security essential. This is a standard Unified Communications deployment in a mission-critical environment; therefore, all of the benefits of management are required. Figure 1 and Figure 2 show the specific services used by the CI-HMI Collaboration solution.
Figure 1 Cisco SONA Framework
Figure 2 Cisco SONA—Detailed View
Places in the Network (PIN) Dependency
The CI-HMI Collaboration solution uses multiple place-in-the-networks as depicted in Figure 3.
Figure 3 Foundational Horizontal Supporting Architectures
The references to the PINs are listed in Table 1.
Network Architecture
The network architecture for this solution is based on Cisco's Medical-Grade Network (MGN) architecture, providing high availability and scalability. It is beyond the scope of this document to discuss the Cisco MGN architecture in detail. The MGN incorporates best practices for high availability, scalability, security, and collaboration applied to a healthcare network. Cisco's best practices for these can be found at the Cisco Design Zone at the following URL:
http://www.cisco.com/go/designzone
The following are typical places where this solution can be deployed:
•
Small hospitals
Small hospitals (performing on average of 100,000 exams per year) may have their own dedicated PACs and storage systems to serve technologies and radiologists. Local modality endpoints ingest images from CTI, Mammo, and Catscan into the PACs systems. The infrastructure usually consists of basic IP connectivity and switching capabilities.
•
Remote clinics
Remote clinics may only house viewers to image examination, without any modalities. In this case, the clinic uses a WAN link back to the centralized PACs systems.
•
Mid-size hospitals and large clinics
A mid-size hospital is generally large enough to own its own PACs systems and MGN infrastructure. In this case, both modality and viewing services would be located at the campus. An MGN architecture should be deployed at this size hospital.
•
Large hospitals and centralized data centers
A large size hospital will own the PACs system as well as serve both modalities and viewers within the hospital infrastructure. For very large operations, the hospital may support a centralized data center that supports large storage systems for images. In this type of deployment model, remote clinics send or retrieve images over the wide area network. In addition, mid- or small-size clinics/hospitals may also use the centralized PACs storage.
•
Modalities
Diagnostic equipment used to capture images such as X-rays, CTs, etc.
•
Viewers
Image views enables radiologists and physicians to view high-resolution images stations. Images are accessed from the manufacturer's PACS systems.
•
Wide area networks (WANs)
Network that connects remote locations to the the data center.
Deployment Model
The deployment model will vary significantly depending on the size of the facility where the solution is deployed. Since this is an application layer solution, the underlying network should be transparent as long as Cisco best practices are followed. For our testing, we assumed a large hospital would have the most complex infrastructure; therefore, we tested on a large network running OSPF with Cisco 3750s in the access layer and redundant Cisco 6500s in the distribution, core, and data center layers. The test network is detailed in Solution Test Bed. Figure 4 shows a typical deployment scenario for a large hospital.
Figure 4 Connected Imaging—HMI Collaboration Deployment Scenario
Solution Architecture
This solution is a tight integration of a third-party application (McKesson's HMI) and the Cisco UC system. Figure 5 shows a high level overview of the solution's architecture.
Figure 5 Connected Imaging —HMI Collaboration High Level Architecture
Architecture
Figure 6 shows details of the solution components.
Figure 6 Cisco/McKesson HMI Collaboration Architecture Essential Components
The CI-HMI Collaboration solution consists of the following components.
Applications Components
Table 2 through Table 4 list the application components of the solution.
The PACS workstation and monitors listed above are sold by McKesson with the operating system (OS) and software preconfigured and customized for the PACS application. Since none of the custom or third-party applications access the phone directly, all the testing was performed with the Cisco 7971G phones with SCCP70.8-3-1S code. For single sign-on (SSO), the CUAE plugin initiates extension mobility through the Communications Manager. Extension Mobility is thoroughly tested by Cisco on all supported phones.
Physician Components
Table 5 lists the physical components of the solution.
The testing was performed using a Lenovo T60p running Windows XP Professional Version 2002 SP2 on the physician's computer. Figure 7 illustrates the Cisco UC tools integrated into the HMI user interface to use new ways for radiologist and physicians to communicate.
Figure 7 Cisco UC Tools integrated with McKesson PACS
HMI Collaboration Overview
The CI-HMI Collaboration solution tightly integrates Cisco's UC system with McKesson's HMI PACS, allowing radiologists to easily and efficiently communicate with physicians, technologists, and other radiologists. This solution required the development of two components. The first is an application on CUAE. When the radiologist logs into the workstation, the application performs an Extension Mobility (EM) login with the radiologist's name . This causes the phone to assume the extension of the radiologist as well as the radiologist's speed dials and other personal preferences. The second is a module McKesson developed for the HMI Workstation that passes the login credentials to the CUAE and passes the names of individuals associated with a study to the Cisco Unified Personal Communicator (CUPC) when the radiologist needs to communicate.
Radiologist Experience
The objective of this solution is to enhance the radiologist's ability to communicate and collaborate with colleagues without impacting workflow. There is no change in the user login process. Extension mobility login to the phone is transparent to the user and activated as part of the radiologist signing on to the diagnostic viewer workstation. On the diagnostic workstation, there is a new button on the screen labeled Communicate. When this button is selected, the Cisco Unified Personal Communicator pops up on the Worklist Monitor populated with a dynamically created Buddy List of the individuals associated with the study being displayed. See Figure 8 and Figure 9.
Figure 8 Typical Image
Figure 9 Communicate Button
This dynamic list includes the status (available, on the phone, do not disturb) along with the preferred method of communication of the individuals associated with the study. The radiologist can then "click-to-talk" on the radiology station phone, start an instant message chat session, or send an email. If a call is established, a screen sharing collaboration session can be launched from within CUPC. This allows the radiologist to share images with the called party. Either party can control the McKesson application, allowing either party to manipulate and/or annotate the image. When the radiologist hits the Sweep button closing out the open studies, the dynamically created buddy lists associated with those studies are deleted from the Unified Presence within CUPC. If the radiologist opens CUPC with no study open, there is no dynamic buddy list, just the listed predefined by the user. When the radiologist logs off of the workstation, the workstation phone reverts to its default configuration, allowing other clinical users to use the work area as needed.
Single Sign-On (SSO) Overview
Cisco has a plugin on the Cisco Unified Application Environment (CUAE) to provide an SSO capability. This system receives a login request from the workstation, extracts the login credentials and location of the requests, and initiates extension mobility on the phone associated with the workstation. Extension mobility will load the stored profile for the radiologist logging in, making his extension and services (like speed-dial) available on the appropriate phone. See Figure 10 through Figure 12.
Figure 10 Cisco IP Phone Before Login
Figure 11 Cisco IP Phone Logged in via SSO and Extension Mobility
Figure 12 Connected Imaging - HMI Collaboration SSO Architecture
The major components that comprise the SSO system are as follows:
•
CUAE 2.4 runtime environment
•
Critical result plugin developed by Cisco Advanced Services
•
McKesson HMI Collaboration Module
These components interact with the HMI workstation, the EMApp module on Cisco Unified Communications Manager. The Cisco Unified Call Manager inturn interacts with Active Directory and the end device.
Configuration Requirements
In order for the applications to function properly, the following configuration must be performed on the Unified Communications Manager:
•
Extension mobility proxy user —A generic application user must be configured in CUCM and granted standard EM authentication proxy rights. This user will be used to perform extension mobility logins on behalf of the other users. The user will be named em and the password will be cisco.
•
AXL user—An application user must be created to read Call Manager configuration data. This is required to obtain the phone name before an extension mobility login can be completed. This user will be named axl and the password will be cisco. It must have standard AXL API access.
•
Radiologist—The UserName passed from the workstation to the CUAE application will identify the radiologist who is logged. The user created in Call Manager must have the same name as the user logging into the HRS workstation. This facilitates a seamless login without having to prompt for a second user name.
•
Radiology workstation phone— The phone associated with a workstation must have the ComputerName passed from the workstation to the CUAE application in the phone's Description field on the Unified Call Manager. This parameter is the ComputerName variable from the workstation. The phone must be registered on the Unified Call Manager so that the description is available through AXL. This allows the CUAE application to determine the correct phone to login.
Sign-On Messaging Flow
Figure 13 shows an overview of the message flow of the single sign-on application.
Figure 13 Connected Imaging - HMI Collaboration Single Sign On Message Flow
The following steps describe the flow shown in Figure 13:
Step 1
The process starts with the radiologist logging into the workstation. The HMI Collaboration application sends an HTTP GET message to the critical results plugin on the CUAE over port 8000. Embedded in the get request is the user name and workstation name.
Step 2
The CUAE sends an AXL request to the Communications Manager to convert the workstation name into the phone name.
Step 3
CUCM returns the phone name.
Step 4
The CUAE app sends extension mobility (EM) logout request for the workstation phone to the EMApp module in the Unified CM on port 8080. This is to ensure the phone is in a default state.
Step 5
If the phone is logged in, the default configuration is restored and a reset is sent to the phone over port 2000.
Step 6
The CUCM returns a status message to the CUAE.
Step 7
The CUAE application sends an EM login request to the Unified Call Manager on port 8080.
Step 8
The Unified Call Manager authenticates the user using the proxy credentials of the CUAE Application User.
Step 9
Unified CM then builds a configuration file for the phone using the information about the user in the Active Directory and locally on the Unified Call Manager.
Step 10
This configuration file is placed on the TFTP server.
Step 11
The Cisco Unified Call Manager sends an SCCP reset command to the phone on port 2000, causing it to reset with the newly created configuration.
Sign-Off Messaging Flow
Figure 14 shows an overview of the message flow of the single sign-off application.
Figure 14 Connected Imaging —HMI Collaboration Single Sign Off Message Flow
The following steps describe the flow shown in Figure 14:
Step 1
When the radiologist logs off of the workstation, the HMI Collaboration application sends an HTTP GET message to the critical results plugin on the CUAE over port 8000. Embedded in the get request is the user name and workstation name. Embedded in the get request is the user name and workstation name.
Step 2
The CUAE sends an AXL request to the Communications Manager to convert the workstation name into the phone name.
Step 3
The CUCM returns phone.
Step 4
The CUAE application sends an EM logout request for the workstation phone to the EMApp module in the Unified CM on port 8080.
Step 5
The Cisco Unified CM sends an SCCP reset command to the phone on port 2000, causing it to reset with the default profile.
Step 6
The CUCM returns a status message to the CUAE.
CUPC/Study Filtered List Overview
When the radiologist activates the Communicate button on the workstation (see Figure 15), the HMI Collaboration module checks to see if CUPC is running. If it is not running, the HMI Collaboration module launches the CUPC application. Using a CUPC API, the HMI Collaboration module dynamically creates a new buddy list on CUPC with the accession number of the study being reviewed as the group name. It then uses the CUPC API to populate the group with the individuals associated with the study. When the studies are closed, the presence group and users created for the study are deleted. CUPC interacts with the HMI Collaboration module, the Cisco Unified Presence server, and the Active Directory to accomplish these tasks.
Figure 15 Communicate Button Detail from Radiology Workstation Screen
Figure 16 CUPC Pop Up
Figure 17 Detail of Filtered Dynamic "Buddy List" for a Study
Create Filtered List Messaging Flow
Figure 18 shows an overview of the message flow to create and populate the dynamic Buddy List on CUPC.
Figure 18 Dynamic Filtered List Creation Flow
The following steps describe the flow shown in Figure 18:
Step 1
The Communicate button is activated.
Step 2
The HMI Collaboration module issues a request to CUPC through the CUPC API to create a new presence group with the name of the Study Accession number.
Step 3
Using SOAP/HTTPS, CUPC requests the Cisco Unified Presence (CUP) Server to create a new presence group with the name of the Study Accession number.
Step 4
The CUP server then inserts the new group on the CUPC client using SIP/SIMPLE.
Step 5
Using the CUPC API, the HMI Collaboration module passes a name associated with the current study to be inserted in the newly created group.
Step 6
CUPC searches the Active Directory for names that match.
Step 7
AD returns matching names.
Step 8
For each directory entry returned, CUPC requests that the user be added to the group on the CUP server using SOAP/HTTPS.
Step 9
For each user submitted, the CUP server inserts the user in the group on CUPC using SIP/SIMPLE.
Steps 5 to 9 are repeated until all of the names associated with the study are in the filtered list.
Delete Filtered List Messaging Flow
When the radiologist activates the Sweep button, all open studies are closed. At that point the HMI Collaboration module issues a request to delete the group(s) associated with the closed study or studies. Figure 19 shows the messaging flow associated with the delete process.
Figure 19 Dynamic Filter List Deletion Flow
The following steps describe the flow shown in Figure 19:
Step 1
The radiologist activates the Sweep button on the workstation
Step 2
The HMI Collaboration module sends a request to delete the presence group associated with each study that was open through the CUPC API.
Step 3
Using SOAP/HTTPS, CUPC requests that the group associated with the study be deleted on the CUP server.
Step 4
Using SIP/SIMPLE, the CUP server deletes each user associated with the study group.
Step 5
Once all users are deleted, the CUP server deletes the group on CUPC using SIP/SIMPLE.
Solution Subsystems
Unified Communications—Communication Manager
Cisco Unified Communication (UC) is a key component of the CI-HMI Collaboration solution. Some of the key products are further discussed in this section. The following key functions are delivered by the UC system:
•
Either SCCP or SIP is supported on handsets that support SIP
•
Basic point-to-point calling
•
Call hold
•
Call transfer
•
Adhoc call conferencing
•
Speed dial
•
Video calling
Extension Mobility
Extension mobility (EM) is a key feature in HMI Collaboration. EM is supported on both wired and wireless handsets provided by the CI-HMI Collaboration solution.
In normal operation, upon launching the EM service, found by pressing the Services button on the phone, users can login using their user ID and PIN number. Once logged in, the phone inherits the profile for that staff employee. For the radiology phone, this process is automated so that the radiologist does not have to change his or her normal workflow.
Video Telephony
For this solution, video telephony is implemented using the Cisco Unified Video Advantage. If the two parties in the call have the CUVA cameras active, the applications installed on the PC and radiology workstation, and video telephony is set up on the Unified CM, the call will automatically be a video call. Again, the focus is on minimizing the workflow impact for the radiologist and maximizing the ability to collaborate.
Voice Gateway
While a voice gateway is used in this solution to communicate with the radiologist's colleagues when they are not on site, there are no special requirements for the gateway in this solution. The call is just a standard voice over IP (VoIP) call. The various gateways have been tested by Cisco as part of their certification process. Refer to Csco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x. A typical gateway is used for testing.
Hospital Phone Integration (Phone and PSTN)
Since the CI-HMI Collaboration solution may be integrating with a hospital's telephony system, the UC system used for HMI Collaboration should support any existing procedures the hospital may have in place. Some of the considerations include:
1.
Handsets should be able to call any existing hospital phone by interfacing through the voice gateway to the hospital's PBX (if it exists). If the UC system supports the hospital's phone system, then calls are placed directly from the handset without the need for a voice gateway.
2.
Calls made from supported handsets connect to the PSTN through the voice gateway on the UC system or through the voice gateway to the hospital's PBX then to the PSTN. If the voice gateway connects directly the PSTN, the call manager will implement the dial plan rules for a hospital's policy on PSTN calls.
3.
If the Cisco voice gateway connects directly with the PSTN, the Call Manager needs to determine calls for the inbound-side to allow calls to the radiology workstations directly or not.
4.
Additional voice traffic generated by the solution should be factored into the voice infrastructure. Gateway scaling may need to be recalculated and the trunking adjusted.
Unified Communication—Cisco Unified Presence
Cisco Unified Presence is another key component of the CI-HMI Collaboration solution. The solution consists of two components: the Cisco Unified Presence Server and the Cisco Unified Personal Communicator. The system is used to provide availability information on the individuals associated with a particular study, and the individuals in the radiologist's personal buddy list.
Cisco Unified Presence
Cisco Unified Presence is a standards-based platform that collects information from multiple sources about user availability and communications capabilities to provide rich presence status and facilitate presence-enabled communications with Cisco Unified Communications and other critical business applications.
Cisco Unified Presence enables you to deploy Session Initiation Protocol (SIP) technology to support new voice services in your enterprise environment. SIP enhances the voice network by providing a core set of behaviors for session establishment and control that can be applied in a wide array of features and services. In addition to core SIP support, Cisco Unified Presence uses SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLEs) technology to support both instant messaging (IM) and presence.
Cisco Unified Presence consists of a SIP presence engine and a SIP proxy function. The presence engine collects user presence information (such as busy, idle, away, or available status) as well as user capabilities (such as the ability to support voice, video, IM, and web collaboration) and compiles the data in a repository for each user. This repository is accessed by the applications and features that each user employs. Unique user rules and privacy can be applied by each user to ensure that only authorized applications and users have access to presence information. The SIP proxy function allows for efficient and accurate routing of both presence and general SIP messaging through the enterprise.
Cisco Unified Personal Communicator
The Cisco Unified Personal Communicator (CUPC) is the client residing on the radiologist workstation and individuals (physicians, technologists, etc.) workstations. This client on the radiologist workstation interacts with the HMI Collaboration module, Cisco Unified Presence, Cisco Unified CM, Cisco Unified MeetingPlace Express, and Active Directory (or other LDAPv3 compliant directory service supported by CUPC) to provide the following:
•
Availability information on the individuals associated with a study
•
Preferred communications method of the individuals associated with a study
•
Single button dial of individuals associated with a study on the radiology workstation phone
•
Single button instant messaging with individuals associated with a study
•
Single button screen sharing when on a call using Cisco Unified MeetingPlace Express
This client is the primary control interface to the Unified Communications system for the user. See Figure 20.
Figure 20 CUPC Pop Up
Unified Communications—Cisco Unified MeetingPlace Express
Unified MeetingPlace Express is an integrated voice, web and video conferencing solution for scheduled or reservationless meetings in a Cisco Unified Communications environment. While this application provides for scheduled or reservationless meetings and may potentially be used by the end customer, for this solution the primary service provided is the ability for the radiologist to share a study with the referring physician or other caregiver involved in the study. It is launched directly from CUPC and the shared study may be annotated by either participant. Web conferencing access is available from Windows, Mac OS, Linux, and Solaris platforms using standard browsers (such as Internet Explorer, Safari, and Firefox) and the Adobe Flash Player. Encrypted access is supported through HTTPS and SSL. Specific requirements vary by release. For the technical details of CUMPE, refer to the Data Sheet at the following URL:
http://www.cisco.com/en/US/partner/products/ps6533/products_data_sheets_list.html
Quality of Service
Table 6 represents the desired markings of quality-of-service (QoS) for packets that originate from the various endpoint sources. The goal of this suggested packet marking is to stay in compliance with the campus and the Unified Communications best practice designs. The only difference is in the data packets. The desired markings for the certain data packets are elevated in priority since these messages are for critical message delivery in the hospital environment.
Packet Marking
The markings of these packets may occur at various locations. Some applications may or may not have the ability for marking. Table 7 illustrates the packet marking design for this solution.
End-to-End QoS
For this solution, auto-QoS is the method used for all Layer 3-capable switch and router interfaces. The main Place-in-the-Network for this solution is the campus network. A Layer 2 access switch with a Layer 3 uplink from the access switch with auto-QoS defined. The remainder of the campus design will follow the design recommendations provided in the Enterprise QoS Solution Reference Network Design Guide Version 3.3.
Redundancy and Reliability Subsystem
The testing of the CI-HMI Collaboration solution consisted of testing the points of direct integration between the Cisco Unified Communications system, the McKesson HMI workstation, and the McKesson PACS. A complete testing was performed of all the functions unique to the solution.
All other network components such as the Cisco Unified Communication Manager (CUCM) and network infrastructure (routers, firewalls, and switches) should each employ attributes common to achieving high availability (HA) design. Certain components of the overall solution may be capable of providing HA services. The CUAE does not provide redundancy. Additionally, the McKesson HMI workstation is not tested for redundancy.
The testing of the following is not within the scope of the testing for the CI-HMI Collaboration solution:
•
The testing of Cisco Unified Communications as it pertains directly to those technologies. The CI-HMI Collaboration solution uses the testing that was performed to date on these technologies for the testing of horizontal solutions.
•
Scalability testing.
The overall design of the network supporting the CI-HMI Collaboration conforms to the best practices for core, distribution, and access layers. The following reference design guides are used:
•
Designing a Campus Network for High Availability
•
Data Center High Availability Clusters Design Guide
These guides can be found at the following URL: http://www.cisco.com/go/designzone
In practice, all three layers in the network design are configured in a redundant fashion; therefore, eliminating any single points of failure within the network infrastructure. The CUAE application contains no redundancy. Each task issued to the CUAE is independent and no state is maintained. After a station logs on, the CUAE can fail and restart with no impact.
Figure 21 Campus Layout
Network Core
The core is designed with Layer 3 full-mesh connectivity to the distribution layer, preventing Layer 2 loops from occurring. Only hardware-based forwarding is permitted in the core in order to provide the highest possible wire-rate service possible.
Because the core is Layer 3 between the distribution layers, the resulting size of the spanning tree domain is contained to within the switches that comprise the network core. Through the use of a routing protocol between the core and distribution layer, equal cost load-balancing is used to provide both additional bandwidth and redundancy.
Distribution Layer
The distribution layer is comprised of a number of dual connected switches which have full-mesh Layer 3 connectivity back to the core, and typically full-mesh Layer 2 connectivity to the access layer switches for the access layer(s) to which they support.
No single point of failure exists within the network layer. In addition, rapid convergence around a failure is achieve through optimized Layer 3 routing protocols and Rapid PVST+ spanning tree for Layer 2 connections.
Through the use of Gateway Load Balancing Protocol (GLBP), Hot Standby Redundancy Protocol (HSRP), and Virtual Router Redundancy Protocol (VRRP), an environment that fosters load sharing and high availability is achieved.
Access Layer
The access layer can be architected as a Layer 2 or 3 design. Through the use of a Layer 3 design, all links are load balanced and optimized for rapid network convergence. In Layer 2 designs, the use of Rapid PVST+ spanning tree provides loop free Layer 2 connectivity with the advantage of rapid convergence in the event that there is a failure.
Redundancy for single homed hosts is not supported. Instead, this solution relies on redundant hosts connected to different switch fabrics.
Unified Communication Components
The UC components that comprise this solution are any MCS-based servers, but typically MCS-7825 servers. CI-HMI Collaboration uses Unified Communication Manager 6.1 and Cisco Unified Presence 6.0 in a multi-node configuration. Each CUCM 6.1 server and CUP 6.0 server is single-homed and has connectivity to separate switch fabrics.
Each of the Cisco Unified Communication Manager and Unified Presence servers is configured and licensed to provide redundancy in the event that a server fails or the connectivity to that server is impacted due to an upstream failure.
Cisco Unified Communication Manager
Communication Manager 6.1 provides redundancy through a mechanism of a primary and one or more secondary servers. The primary server is referred to as the publisher, as it publishes its configuration database to other Communication Manager servers referred to as subscribers.
Cisco Unified Presence
Cisco Unified Presence 6.0 uses the same model as Cisco Unified Communications Manager.
HIPAA Considerations
The Health Insurance Portability and Accountability Act (HIPAA) of 1996 provides for the protection of identifiable patient information. This information is known as Protected Health Information (PHI) or Electronic Protected Health Information (EPHI). The information shared in this solution is EPHI. This has implications for the various modes of communications. For more detail on HIPAA, refer to Appendix A—HIPAA Overview.
Electronic protected health information should not be incorporated into email. Email is typically not encrypted and may later be compromised. Email should be disabled on CUPC or the users should be made aware that PHI cannot be communicated in email.
Instant Messaging (IM)
The instant messaging (IM) in Cisco Unified Personal Communicator does not cache or save dialog, so it is safe from a residual information perspective. The data stream used for IM is not encrypted. IM should not be used to communicate Protected Health Information. If instant messaging must be used for EMHI communications, any sessions across an open network must use an encrypted VPN tunnel.
Screen Sharing
While a MeetingPlace Express meeting may be recorded, only the voice portion is recorded and it is saved on the CUMPE server, within the closed network. No information is cached on the remote PC. The default configuration for MeetingPlace Express is to not encrypt the sharing session. MeetingPlace Express should be configured to use SSL encryption when there will be screen sharing outside the closed network. (See Table 8.)
Solution Validation Overview
This section provides an overview of the testing strategy used for the CI-HMI Collaboration solution.
Validation
The purpose of the validation testing as it applies to this solution is to provide reasonable assurance that the end-to-end solution, as described in the testing documentation, conforms to the basic principles of its intended operation.
Validation Test Strategy
Table 9 describes the general categories of testing performed.
Solution Test Bed
In addition to the solution components listed previously, the following network components were used in testing the solution. While this network is typical of a hospital network, as long as the network follows Cisco best practices with the caveats listed in this document, the network should not impact the performance of the solution.
Solution Test Bed (Physical)
Figure 22 shows the physical layout used to validate CI-HMI Collaboration solution.
Figure 22 Solution Test Bed
Figure 23 show the addresses of the devices used in the solution.
Figure 23 Test Device Addressing
Figure 24 shows the physical topology of the solution.
Figure 24 Logical Typology of Test Bed
Test Bed Components
Table 10 lists the network components of the solution.
Solution Configuration
This section covers the configuration of the components required to successfully implement the solution. It is assumed that the Unified Communications system had been configured as recommended using best practices as defined in the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x.
User Credentials Management
Cisco Unified CM (CUCM) relies on two separate components to satisfy the user provisioning and user authentication requirements independently. User provisioning is performed with a one-way synchronization of user data from the corporate directory to the CUCM embedded database. The synchronization uses standard LDAPv3 and can be triggered manually or scheduled periodically to ensure that changes are incorporated into the Cisco IP Communications system. This solution avoids the need to write anything to the corporate directory, and it does not require any schema extensions.
User authentication is enabled independently from user provisioning, and it provides authentication of end-user passwords against the corporate directory credentials. With this approach, the Cisco IP Communications system preserves all of its real-time functionality even when the corporate directory is unavailable or unreachable.
LDAP Synchronization
This process uses an internal tool called Cisco Directory Synchronization (DirSync) on Unified CM to synchronize a number of user attributes (either manually or periodically) from a corporate LDAP directory. When this feature is enabled, users are automatically provisioned from the corporate directory. This feature applies only to end users, while application users are kept separate and are still provisioned through the Unified CM Administration interface.
It is recommended that Unified CM is integrated with the same Active Directory that is used by HMI. This provides a single point for user database management and ensures the same user names in the radiologist organizational units (OU).
LDAP Authentication
This process enables the IMS library to authenticate user credentials against a corporate LDAP directory. When this feature is enabled, End User passwords are authenticated against the corporate directory, while Application User passwords are still authenticated locally against the Unified CM database. Cisco Extension Mobility PINs are also still authenticated locally. Maintaining and authenticating the application users internally to the Unified CM database provides resilience for all the applications including CUP and MeetingPlace Express and features that use these accounts to communicate with Unified CM, independently of the availability of the corporate LDAP Directory (see Figure 25).
Extension Mobility Personal Identification Numbers (PIN)
Cisco Extension Mobility PINs are hard coded because the automatic login is performed by CUAE as described in the Single Sign-On (SSO) Overview.
Figure 25 CUCM LDAP Integration Supporting MeetingPlace and CUCP Logins
Configuring Cisco Unified CM for LDAP Authentication and User Import
Configuring LDAP Directory Information in CUCM
Step 1
In the main Cisco Unified Communications Manager Configuration page, select the System tab and browse to LDAP/LDAP Directory. Select Add New.
Step 2
In the LDAP Server Information block, add the server address.
Step 3
In the LDAP Directory Information block, add the LDAP Configuration name, the LDAP Administrator name, LDAP Administrator password and password confirmation.
Step 4
Select Save.
(See Figure 26.)
Figure 26 LDAP Directory Configuration
Configuring LDAP Authentication Information in CUCM
Step 1
In the main Cisco Unified Communications Manager Configuration page, select the System tab and browse to LDAP/LDAP Authentication.
Step 2
In the LDAP Server Information block, add the server address.
Step 3
In the LDAP Authentication for end users block, check the Use LDAP Authentication for End Users, add the LDAP Administrator name, LDAP Administrator password and password confirmation.
Step 4
Select Save.
(See Figure 27.)
Figure 27 LDAP Authentication


























