Table Of Contents
Cisco Medical-Grade Network (MGN) 2.0—Wireless Architectures
Wireless Overview in Healthcare
Importance of Wireless in Healthcare
Mobile Nature of Bio-Medical Devices
Strong Authentication and Encryption
Real-Time Location-Based Services
Wireless Architecture Overview
Mobility Services Engine (MSE)
Interference Detection and Avoidance
Dynamic Transmit Power Control
Coverage Hole Detection and Correction
Client and Network Load Balancing
Providing Remote Wireless Services
Hybrid Remote Edge Access Point (H-REAP)
Real-Time Location Services (RTLS)
Rogue Detection and Radio Resource Management (RRM)
BioMedical Device Considerations
Co-Channel and Multifloor Separation
Co-Existence issues w/ other BioMedical devices
Healthcare Guest Access Services
WLAN Controller Guest Access Option
Auto-Anchor Mobility to Support Wireless Guest Access
Environmental and Physical Considerations
JCAHO and Infectious Control Risk Assessment (ICRA) Requirements
PoE Switches and Console Cables
Distributed Antenna Systems (DAS)
Cisco Medical-Grade Network (MGN) 2.0—Wireless ArchitecturesLast Updated: November 18, 2009About the Authors
Stuart Higgins,Vertical Solutions Architect, CMO ESE, Cisco SystemsStuart is Cisco's Healthcare Industry Solution Architect in the Enterprise Solutions Engineering—Industry Solutions Engineering team. In this role, his primary focus to create healthcare architectures, as well as leading the engineering team validatingCisco's healthcare solutions. Stuart has over 20 years working in the healthcare industry, including 17 years at Shared Medical Systems and Siemens Medical Solutions. During his time as an Advisor at SMS, Stuart was responsible for the architecture of the world's largest independently-owned healthcare information network servicing in excess of 1200 healthcare customers and over 600,000 users. As a Cisco Certified Internetwork Expert (CCIE #3194), Stuart has a deep understanding of the issues facing healthcare customers as well as a strong technical understanding of the technologies used to solve them.
Curt Mah, Technical Marketing Engineer, CMO ESE, Cisco SystemsCurt is a Technical Marketing Engineer at Cisco with 15 years of networking experience in the industry. He is focused on developing and validating Cisco solution architectures that optimize workflow and improve productivity for the Healthcare Industry. He has worked in the areas of network consulting and product development and has supported fortune 500 companies in the areas of infrastructure deployment, Routing/Switching/WAN and Security. Curt has architected solutions for Broadband Triple Play (voice, video, data) for Service Providers and Healthcare offerings, including Biomedical Network Admission Control and PACS storage optimization. In addition, Curt has co-authored the Cisco Press book Deploying Cisco Voice over IP Solutions and has spoken at numerous industry events including Networkers/Cisco Live, NetWorld+Interop, and the California Medical Instrumentation Association.
Curt holds a Bachelor of Science degree in Electrical Engineering Technology from California Polytechnic University in San Luis Obispo. Curt is a Cisco Certified Internetwork Engineer (CCIE #3856) in Routing and Switching.
Tony Anderson, Vertical Solutions Architect, CMO ESE, Cisco SystemsTony Anderson, CCIE 4686, is currently a Technical Marketing Engineer focused on Healthcare. In his 11 years at Cisco, Tony has also supported GE as a reseller and worked with Healthcare Application Providers to incorporate Cisco technologies into their solutions. In another role he was responsible for the development of Unified Communications training for partners. His 38 years in the Computer and Networking industries in positions ranging from Systems Engineer to Technical Instructor to Sales Manager gives him a thorough understanding of technology and how to apply those technologies to solve business problems. Tony has CCIEs in Routing & Switching and WAN Switching.
Contents
Contents
Cisco Medical-Grade Network (MGN) 2.0—Wireless Architectures
Introduction
Cisco's Medical-Grade Network (MGN) architecture is based on the set of best practices that apply to each foundational network technology. The term Medical-Grade often carries with it varying definitions that are dependent on the expectations of the individual being asked to define it. As such, Medical-Grade has certain expectations that without a formal definition, results in a discussion with no clear conclusion. In order to properly frame the context in which Cisco 's MGN 2.0 architectures are based, we will define the attributes used to describe a Cisco MGN.
This document is the first in a series of MGN 2.0 architectures that will explore the best practices for other technologies that are critical to healthcare environments worldwide.
In general, an MGN is one that has the following basic attributes or characteristics:
Protected
Healthcare networks world-wide comprise the transmission of data regarding patients ongoing care, diagnosis, treatment and financial aspects. From a clinically-focused regulatory perspective, HIPAA in the United States is usually the first such thought. In other parts of the world, however, other standards exist with much the same intent as HIPAA but with varying degrees of specificity.
It is generally accepted that all clinically-focused networks provide a level of security and protection for the information which is either at rest or in-motion. Cisco has a number of security best practices that can be directly applied to meet the regulatory compliance required by the healthcare organization. There is not a singular manner in which networks can be designed to meet the security requirements of organizations. Because of this fact, the reader should not assume that this document, or any of Cisco's MGN architectures dictate the only "approved" method of providing such security measures. It is the intent of this document to highlight the unique challenges that medical networks face.The starting point are the best practices found on Cisco's Design Zone website at http://www.cisco.com/go/designzone.
A protected medical network is not simply comprised of a set of firewalls at the perimeter of the network, nor does it end when the information is written to disk or tape. An MGN is considered protected when the industry best practices are applied to the entire healthcare environment.
Some wireless examples that are often overlooked include clinical-workstation client security not only on the patient floor, but also offsite as is the case with remote clinicians. The authentication methods used for both wireless network authentication and clinical application/system authentication can be based on a centralized authentication directory. In the case of mobile wireless devices, security policies for these devices must extend beyond the borders of the healthcare network and campus.
Because of the wide scope that security practices play in the healthcare environment, this document relies on the established set of best practices related to wireless security. These can be found on Cisco's Design Zone website: http://www.cisco.com/go/designzone. Unique considerations above and beyond those best practices are called out throughout this document.
Responsive
The term responsive as it relates to Cisco's MGN is often misunderstood as simply a network latency or bandwidth-related concern. While an MGN must exhibit attributes related to high performance, the term responsive is not applied in that manner. Instead, the term responsive refers to the set of architectural attributes that the network must exhibit to expand and respond to the changing clinical requirements. These changes are often driven by new clinical applications or modalities brought into the environment, or may be dictated by a new regulatory requirement. In either case, the network must be architected in such a way that it has some elasticity built into the design, allowing it to meet the challenges set forth.
For example, a wireless network that is meeting all of the current requirements placed on it, and built using the best practices found on Cisco's Design Zone. Then one day a new self service kiosk is brought into the outpatient area to facilitate self service admissions. To identify the patient, credit card information is used between the wirelessly attached kiosk and the ADT/self service admissions system located within the datacenter. The entire network from endpoint to server is required to adhere to Payment Card Industry (PCI) standards. To be Medical-Grade, the network must be architected so that it is able to adapt to the PCI requirements. This requires the wireless network to support WPA or WPA2 using an approved EAP method for authentication. Furthermore, the use of Intrusion Detection and Prevention (IDS)-based systems would need to be implemented (if not already) in such a way as to detect and alert the network operator during the early stages of a wireless attack.
From a pure bandwidth and latency stance, the network must be architected to support the implementation of new applications or modalities. In the example of a 256 slice Computed Tomography (CT), the network should not require a forklift upgrade, but rather provide the ability to expand capacity through a number of well understood and utilized techniques as described in the best practices found on Cisco's Design Zone website (http://www.cisco.com/go/designzone).
In all cases, the ability for the network to be responsive to the new demands placed on it is critical to maintaining uptime, serviceability, and adherence to regulatory changes. Network designs that do not take into consideration such expendability techniques is not considered in the best interest of serving the healthcare community and is therefore not Medical-Grade as defined by Cisco.
Interactive
Care providers interact with patients and clinical staff every minute of the day in any number of settings. The interactive attribute as it is applied to Cisco's MGN relates in the ability of the care provider to interact with the network and its related resources, seamlessly. Different technologies exist to extend the network into a borderless network, including wireless, VPN, and collaborative technologies.
The use of wireless is an obvious choice within the healthcare industry as the care provider is often not tied to a fixed central location. Being able to interact with the clinical resources required while mobile both inside and outside of the hospital's borders is key in providing this interactive characteristic.
For the healthcare provider, wireless computer on wheels, wireless 802.11 and dual-mode smart phones are a small but key set of tools in facilitating this interaction with various backend systems. A wireless network designed specifically for data only services does little to provide reliable voice, video, and biomedical services—all key to providing the care provider with a set of tools to facilitate instructiveness with the patient and the overall supporting care systems.
Cisco's best practices with respect to Borderless Networks, VPN, remote access, wireless, voice over wireless, video and so forth are all available on Cisco's Design Zone website at: http://www.cisco.com/go/designzone.
Resilient
Perhaps one of the most understood attributes of Cisco's MGN is that of resiliency. For the network engineer, this term typically relates to architectures around that of high availability. Indeed, this is exactly what is required by the industry for any MGN. Such networks are said to be six sigma compliant or achieve availability of 99.999% or better. Achieving such high availability from the perspective of the care provider is sometimes a significant challenge as it equates to approximately 5 minutes of downtime per year.
Within data centers that host EMR/EHR systems, such availability at the network layer can indeed be achieved. In some cases, however, the applications used to support the clinical staff are simply not architected to achieve this level of availability and often result in downtimes from the perspective of the caregiver that well exceeding these goals. These outages are mainly due to software upgrades or patches being applied, or in some cases upstream systems such as payers or external testing labs.
In the 802.11 wireless world, however, attempting to architect a network design with 99.999 percent availability is even more challenging due to a number of factors. The 802.11 bands comprising both 2.4Ghz and 5Ghz spectrum are unregulated RF domains. The FCC stipulates that for users of unlicensed bands including the 802.11, that each device must expect and accept interference that may affect reliability.
Even with the best wireless network design, it may not be possible to architect a wireless network that achieves six sigma availability. Simply put, the RF spectrum is a shared medium and as such there is always the chance of outside RF influences, otherwise known as interference. Since hospitals are considered public spaces, it is simply not possible to strictly regulate and prevent such forms of interference from entering the environment.
The increasing popularity of consumer class devices such as Wi-Fi (personal 802.11 to 3G bridges) and Bluetooth devices bring what are essentially interference generators into the clinical workspace. In the case of Wi-Fi, due to the lack of 3G/4G integrated into laptops and other personal computing devices, it is expected to see this technology expanded to new generations of cell phones further increasing the potential for interference. Therefore, it is Cisco's best practice and recommendation to move all critical clinical applications and voice services to the 802.11a or 5Ghz band. The set of best practices can be found on the Design Zone website (http://www.cisco.com/go/designzone).
Even in the unregulated 5Ghz space, there is always a chance of interference generated by other wireless clients (for example, visitors and patients) or even radar sweeps from local airports or weather monitoring stations. Many of these interference generators are typically transient in nature, but to the care provider can significantly interfere with their workflow.
Perhaps the most discussed aspect of wireless reliability comes into play around life safety and patient monitoring-based systems. In the case of patient monitors, the reliability of the physiological data being streamed to a central logging/display and archiving system is crucial. Often times these devices are mandated in the vendors FDA filing as having to respond to physiological changes with a very small window of time. For most vendors in this space, the analysis of the telemetry is performed with the use of the wireless connectivity. Resulting alarms are therefore generated locally by the device itself, and it is this notification that is necessary. While the telemetry information being streamed to a central station is indeed critical for display and historical logging purposes, some level of burden must be placed on the devices themselves with respect to reliability. Unfortunately this is not the case many times, and as a result many such devices have lagged the industry in terms of reliability.
Taking into consideration the shortcomings found in some legacy-based biomedical devices, an 802.11 wireless MGN is one that is designed and implemented using the best possible techniques and resulting architectures. With respect to wireless as compared to wired, such architectures will remain a topic of further discussion within the industry. At the present, however, the reliability of the overall wireless network design, excluding outside RF interference generators, is what Cisco considers Medical-Grade. Over time, biomedical devices will be improved along with that of the 802.11 or other wireless standards available. To the industry, however, the best currently available products and deployment architectures represent the Cisco MGN as it relates to the uniquely challenging wireless network. It is recommended that the reader consult a number of design guides available on this topic which can be found on Cisco's Design Zone website at http://www.cisco.com/go/designzone.
Summary
In conclusion, it is important to reflect on the point that the term Medical-Grade Network (MGN) generates a great deal of discussion, as it should. Given the fact that there are no formal network-specific standards or metrics that can be applied to determine what constitutes an MGN, the reader should understand that the best known industry practices when applied properly can achieve what Cisco terms an MGN.
Such network architectures often comprise the set of attributes as defined in the proceeding section, but what makes an MGN different than other network architectures are the use of biomedical devices, federal regulations and the criticality of systems involved in life safety.
Additionally, over time technologies change, the underlying techniques used to achieve these standards will therefore also change. The network architect and engineering teams responsible for the deployment of medical networks (wired or wireless) must consider the attributes and concerns described above in order to provide the best possible service available with the current state of technology and therefore resulting in what is considered a Cisco MGN.
This document is intended to augment where appropriate and call to light challenges that must be taken into consideration that are not described in the set of best practices found at the Cisco Design Zone website (http://www.cisco.com/go/designzone).
Wireless Overview in Healthcare
Importance of Wireless in Healthcare
It is widely recognized throughout the world that healthcare has one of the most mobile workforce with an incredible dependency on collaborative communication. Coupling the highly mobile and communicative nature with the need to be consistently connected to backend clinical systems and one can quickly conclude that wireless technology is a must have in all acute patient care environments.
Caregivers are not alone when it comes to the need for mobility within the healthcare setting. Many disparate clinical and robotic systems along with bio-medical devices require continuous and secure network connectivity. Again, because these devices are highly mobile, Cisco's wireless technologies provide the needed connectivity in a manner consistent with the high expectations that exist within the medical community.
Cisco's wireless networking products have the exclusive endorsement of American Health Association (AHA). The American Hospital Association (AHA) represents and serves all types of hospitals, healthcare networks, patients, and communities. AHA members include nearly 5000 hospitals, healthcare systems, networks, and other care providers, as well as 37,000 individuals.
Mobile Nature of Caregiver
Throughout the global acute care setting, groups of care providers attend to their daily responsibility of providing quality care to their patients. These groups range from the attending physician to a wide range of specialist. The attending physician, for example, requires connectivity to a number of systems providing voice, alerting/paging (Lab, Pharmacy, Code Teams), clinical (CPOE, EHR, PACS), and in some cases access to their remote office for the scheduling follow-up appointments and procedures.
The nursing staff have a wide range of roles ranging from providing care at the bedside, within the Emergency Department or trauma center and various locations throughout the hospital including OR, Oncology, Lab, Radiology, and so on. In each of these roles, clinicians are highly mobile throughout their day. Staying connected to the supporting healthcare systems, whether it is an electronic device or another colleague working in conjunction with the care provider - Mobility solutions from Cisco, are key to optimizing patient care and driving efficient clinical workflow.
In each case, these groups of caregivers need consistent connectivity to the clinical and scheduling systems in order to reference patient records, enter orders via Computerized Physician Order Entry (CPOE), administer medications, and be notified of alarm events as indicated by a wide array of biomedical devices. In all cases, Cisco's Mobility solutions provide this linkage and improve clinical workflow throughout the continuum of care. See Figure 1.
Figure 1 MGN and the Continuum of Care
Mobile Nature of Bio-Medical Devices
Caregivers are not the only people who are mobile within an acute care setting. Patients are also highly mobile as they traverse various ancillary departments in order to be diagnosed or receive treatment. Often times, the various biomedical devices that are used to monitor the patient's health or deliver treatment also go mobile. For the acutely ill patient population, patient monitors and smart infusion pumps are often transported with the patient to various points of treatment. Likewise, traffic in the reverse direction occurs. An example is when an infusion order is entered into the pharmacy system on behalf of a patient. In some implementations, the order is downloaded to the smart pump providing information such as the infusion rate, dose time and other metrics.
During this period of mobility, the continuous logging of telemetry is often required along with periodic Electronic Medical Record (EMR) updates from the smart infusion pump. Information about the patients' health as well as the delivery of critical medications is recorded within the patients Electronic Health Record (EHR) and used by physicians and caregivers for diagnosis and the monitoring of treatment.
Another example focuses on the biomedical device that is mobilized and brought directly to the patient. For example, consider a mobile ultrasound or C-arm brought directly to the patient's room. Once the studies are acquired by the technologist, they are streamed using 802.11 wireless technology and uploaded to the PACS system for a radiologist to read and provide a diagnosis. Without wireless technology, the study would not be uploaded to the PACS system until the technician plugs the modality into a wired Ethernet port, further delaying workflow and diagnosis.
Figure 2
Voice Services
Providing easy to use and reliable voice services to the mobile care provider is yet another means to improve clinical workflow and ultimately patient care. In a recent JCAHO study, 84 percent of healthcare providers cited a breakdown in communication as the number one cause of Sentinel events leading to patient injury or death. Many of these events were caused by delay of treatment or a breakdown in communication amongst staff members.
Often times a care provider realizes that something is seriously wrong with a patient, but has difficulty in locating the staff necessary. These delays can unfortunately result in poor patient care and at the same time reduce the job satisfaction among caregivers.
Creatively applying voice communications in its many different formats can provide the missing link that are too often encountered in today's dynamic clinical environments. Adding wireless mobility to voice communications allows these services to be available to the caregiver no matter where they may be within the healthcare enterprise. Services include traditional on-net and off-net dialing, voice mail, adhoc-based group paging, patient & biomedical based alarms and conference calling as well as group-based push-to-talk-all available to the caregiver within seconds.
By enabling rapid communication among caregivers using a variety of formats and extending that reach regardless of their physical location is a powerful tool in achieving both higher workflow efficiencies and better overall patient care.
Given the fact that many healthcare providers have existing 802.11-based wireless networks in place, adding voice services and leveraging a common infrastructure is a trend that is increasingly popular within healthcare environments worldwide. One recent healthcare study found that 40 percent of all cellular minutes used by staff were between care providers within the same building. By leveraging the dual-mode capabilities of smart phones, the care provider can be extended reliable voice services which leverage the existing 802.11 network. Not only does this approach reduce costs, but it also extends other information such as presence and access to clinical systems that otherwise could not be used.
Location-Based Services
In healthcare, being able to efficiently locate a medical asset or other care provider not only saves money, but in some cases can contribute significantly to the quality of patient care. A recent report published by the BBC for the UK not-for-profit data standards group GS1 found that 37 percent of the nurses surveyed spent over two hours per-shift searching for missing items. For details, refer to the following URL:
http://news.bbc.co.uk/2/hi/health/7881807.stm
The most common items lost were IV pumps, drip stands, thermometers, pharmaceutical storage keys, and mattresses. For the United Kingdom's National Health System (NHS), this accounted for up to £900m or $1.4 billion dollars in wasted wages annually. This is one healthcare system, and one can argue the accuracy of the statistics but ask any care provider about their personal stories of trying to locate something on a patient floor and in a timely manner and you will quickly conclude the importance of location-based services within any healthcare environment.
Note
Location-based services can be broken down into different technologies. This document only addresses active 802.11-based RFID; other RFID solutions based on passive or infrared technologies are not discussed.
There are a few methods that can be used to provide location-based tracking. The first and simplest is called Cell Origin. In this approach, an asset can be tracked to the area serviced by a single access point. In some environments, this can range from 2500 to 5000 square feet. This approach is highly efficient, because it does not need to apply any complex mathematical formulas to triangulate the position. See Figure 3.
Figure 3 Location-Based Services
Depending on the RFID requirements, this approach may meet the requirements of the healthcare organization. In most healthcare environments, however, such granularity is usually not adequate and therefore is not considered a best practice for a Cisco MGN architecture.
In order to provide near medical-grade location services, it is necessary to triangulate the position of an asset in two dimensions (X & Y) by recording the Receive Signal Strength (RSS) of an asset by three or more access points in a common horizontal plane. By using RSS, tracking is simply a matter of recording the signal strength of the device by three or more access points and applying a path loss (signal loss) algorithm to each recorded samples. This sampling information is collected by a location-processing engine such as that found in the Cisco Mobility Solution Engine (MSE).
In a perfect world, RSS-based systems would provide reasonable accuracy, but the world is not perfect and neither is RSS. This means that as you move away from an access point in one direction and at a consistent rate, the signal level will, in most cases, not drop at an equal and linear rate. These signal fluctuations are caused by obstructions such as walls (open today, closed tomorrow), doors, dietary food carts, Med Carts, Gurneys, and believe it or not, small RF sponges called humans.
To combat these issues, a technique called RF Fingerprinting can be applied to the RSS-based system. This technique records the RF patterns that exist as a tracked object moves around in the RF environment. By recording these patterns and applying them to the RF patterns received in real-time, accuracy can be increased significantly.
In order to locate and record the RF patterns that exist on a patient floor for example, the system must be taught about the patterns. This process is called calibration and requires the recording and physical movement of a test subject such as an RFID tag, 802.11 wireless phone or Computer on Wheels (CoW). Once collected, the RF pattern information is normalized and statistically groomed to provide accurate path loss models that can be applied to the location algorithms. The Cisco MSE provides RF Fingerprint-based location services and if properly calibrated can often provide room-level accuracy.
The value of location-based services is clear, but perhaps the use cases are not. Vendors such as Aeroscout produce active RFID tags that can be not only used to provide location information as described above, but can provide other useful metrics. The Aeroscout T5b and T5c tags provide external temperature probes that can be used to monitor hospital refrigerators and freezers that store vaccines, pharmaceuticals, blood, food, patient test results, and other items. The tags send temperature readings in intervals specified by the administrator (128ms to 3.5 hours)) via the 802.11b/g wireless network. Likewise, the T5h tag provides both real time temperature and humidity monitoring. When a threshold is exceeded, alarm events can be generated informing the appropriate support group within the hospital that an environmental event is occurring.
By taking quick action to such alarm events can prevent the loss of many expensive pharmaceuticals as well as other precious biomedical items such as blood/plasma and, in some cases, donor organs.
For other assets such as wheelchairs, patient monitors and even patients, the T4 RFID tag from Aeroscout features a motion sensor providing real-time updates not only to the location but also whether the tag is in motion. For wheelchairs and other items, having access to its location and utilization is not only important to the care provider, but it can provide some useful information that is often overlooked.
In order to receive federal or state grant monies, healthcare institutions may need to provide positive confirmation that a certain percentage of the asset in question is used. By monitoring the level of usage of each asset in question, a healthcare institution can easily provide the asset-tracking report needed to apply for the grant, while at the same time reducing asset loss due to theft or misplacement.
One final example of location-based services is in providing performance metrics for ancillary departments throughout the hospital. By data mining, the location of gurneys and wheelchairs, choke points within the OR, ED, Radiology and so on can be monitored. Wait times in pre-operation, post-operation and Radiology can be tracked, providing highly useful trending data over time as to the performance and utilization of key areas within the hospital. See Figure 4.
Figure 4 AeroScout 802.11 Active RFID Tags with and without Temperature Sensors
There are many other use cases for medical-grade location-based services within the acute healthcare environment. By using location-based services in both obvious and creative ways, the healthcare organization can leverage the installed infrastructure while at the same time improve clinical workflow and patient care.
Privacy Concerns
While information security is a top priority for any organization, healthcare providers must be especially diligent in protecting confidential patient data. In addition to the evolving threat posed by hackers and other intruders, government regulations such as the U.S. Health Insurance Portability and Accountability Act (HIPAA), establish privacy requirements for protected health information (PHI).
Network-based applications have transformed virtually every industry, and healthcare is no exception. Solutions that allow access to electronic medical records (EMRs), medical management systems, imaging, biomedical information, material management, patient accounting, admitting information, and online claims submissions are becoming commonplace in wireless, wired, and mobile scenarios.
Since the overall network security is only as strong as its weakest link, providers need to be as certain as possible that WLANs are providing the same level of access control and privacy as wired LANs. In contrast to a wired LAN, in which a physical connection controls access to the network, WLANs broadcast data through the air. Any wireless-enabled device in the area-such as a patient's laptop in a waiting room or a wireless PDA in a neighboring office-presents a potential security threat.
Special security considerations should be made to meet the requirements set forth by US and international regulatory bodies and organizations including HIPAA, HITRUST, Data Security Standards (DSS) and PIPEDA.
HIPAA Audits
The Health Insurance Portability and Accountability Act of 1996, or HIPAA, was enacted to safeguard Protected Health Information (PHI) by mandating procedures and controls to assure the public that critical and private information is controlled from loss of confidentiality, integrity, or availability.
An organization is subject to HIPAA if it exchanges data related to the healthcare profession. Improper release of private information has become frequent. News stories often highlight serious infractions such as public posting of diagnosis and patient information or inadvertent release or loss of personal records.
This law requires that all data on patients be kept secure and private. Wireless security becomes a very significant part of any healthcare facility's overall security strategy. Generally, a combination of standard wireless security standards on clients should be considered to meet HIPAA requirements.
HIPAA audits of hospitals by the U.S. Department of Health and Human Services are becoming more frequent. This is raising awareness in the healthcare industry about the prospect of more enforcement actions related to the data security requirements of the federal HIPAA legislation.
The audits being conducted assumes that data privacy mandates are already in place in a healthcare facility. The security rules require organizations that handle electronic health data to implement measures for controlling access to confidential medical information and protecting it against compromise and misuse.
More information about HIPAA can be found at the following URL http://www.hhs.gov/ocr/privacy/
IEC 80001
The IEC 80001 specification is being developed by a joint working group of the IEC 62A committee and focuses on accessing risk analysis of IT-Networks which incorporate medical devices. The first draft of the IEC 80001 included requirements for various roles, responsibilities and life cycle management of networks involved in the support of medical devices.
The responsibility of such networks falls into the domain of the healthcare organization. The responsibility and ultimate accountability is placed upon the senior management of the organization. The organization must at a minimum perform the following functions
•
•
•
•
•
•
Healthcare organizations that maintain and operate networks which include medical devices are urged to consult and implement the IEC 80001 recommendations. By using the prescribed IEC 80001 framework, healthcare organizations can minimize the risk involved in operating such networks. It is beyond the scope of this document to fully describe the risk management process that the IEC 80001 provides. For more information on the IEC 80001 standard, refer to the AAMI website at the following URL: http://www.aami.org.
Cisco provides consultative services that assist healthcare organizations in all aspects of the MGN architecture. This includes preparation, planning, design, implementation, operation, and optimization. By carefully applying a disciplined approach to operating medical networks, healthcare organizations can be better prepared to operate such networks while reducing risk and improving care.
Figure 5 Cisco Lifecycle Services Approach
More information about Cisco's consultative services can be found at the following URL: http://www.cisco.com/go/advancedservices
HITRUST Alliance
Perhaps no other industry can lay claim to the necessity of wireless technology than that of modern healthcare. The Health Information Trust Alliance (HITRUST) exists to ensure that information security becomes a core pillar of, rather than an obstacle, to the broad adoption of health information systems and exchanges. For more information, refer to the following URL:
http://www.hitrustalliance.net/
Information security is critical to the broad adoption, utilization and confidence in health information systems, medical technologies, and electronic exchanges of health information. The main goals of HITRUST are to enable the following:
•
•
The foundation of all HITRUST programs and services is the HITRUST Common Security Framework (CSF), a certifiable framework that provides organizations with the needed structure, detail and clarity relating to information security tailored to the healthcare industry. HITRUST is enhancing and simplifying security and compliance by delivering cost efficiencies to the healthcare industry by establishing common, acceptable practice through the CSF), and other collaborative community initiatives. In addition, HITRUST strives to provide education, guidance, and facilitates organizations towards meeting the requirements of the CSF.
The HITRUST Alliance is lead by a seasoned management team and governed by an executive council made up of leaders from across the healthcare industry and its supporters. These leaders represent the governance of the organization, but other founders also compromise the leadership to ensure the framework meets the short and long term needs of the entire industry. Members of the executive council can be found at the following URL:
http://www.hitrustalliance.net/council.php
Other Regulatory Bodies
A survey of other US and international regulatory bodies that require security measure include the following:
•
The Payment Card Industry (PCI) uses the DSS that affects all healthcare facilities that process, store, or transmit credit or debit card information over their networks. To pass PCI compliance, a healthcare provider must address its procedures, security policies, and technical infrastructure so that it can demonstrate adherence to the PCI DSS v1.2 specification sub-requirements. Once a company becomes compliant, there are ongoing requirements to maintain compliance.
•
The Personal Information Protection and Electronic Documents Act (abbreviated PIPEDA or PIPED Act) is a Canadian law relating to data privacy. It governs how private-sector organizations collect, use and disclose personal information in the course of commercial business. For more information, refer to the following URL: http://laws.justice.gc.ca/en/ShowFullDoc/cs/P-8.6//20090818/en
•
The Data Protection Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data) is a European Union directive which regulates the processing of personal data within the European Union.
•
The Red Flags Rule, a law by the FTC, requires certain businesses and organizations — including many doctors' offices, hospitals, and other health care providers — to develop a written program to spot the warning signs —or red flags— of identity theft.
Strong Authentication and Encryption
For the WLAN network, security is based on both authentication and encryption. Strong authentication and encryption policies are essential in meeting the wireless privacy objectives as described previously. A survey of authentication and encryption policies is listed in Table 1. Details on the availability and recommendations of security features are listed in the appropriated endpoint sections.
Table 1 Authentication and Encryption Policies
Static WEP
802.1x WEP
WPA
WPA 2 (Enterprise)
User, machine or WLAN card
User or machine
User or machine
User or machine
Shared key
EAP
EAP or pre-shared keys
EAP or pre-shared keys
32-bit Integrity Check Value (ICV)
32-bit ICV
64-bit Message Integrity Code (MIC)
CRT/CBC-MAC (Counter mode Cipher Block Chaining Auth Code - CCM) Part of AES
Static keys
Session keys
Per Packet Key rotation via TKIP
CCMP (AES)
One time, Manual
Derived from Pair-wise Master Key (PMK)
Derived from PMK
Derived from PMK
Plain text, 24-bits
Plain text, 24-bits
Extended Initialization Vector (IV)-65-bits with selection/sequencing
48-bit Packet Number (PN)
RC4
RC4
RC4
AES
64/128-bit
64/128-bit
128-bit
128-bit
None
RADIUS
RADIUS
RADIUS
No
No
Yes1
Yes
1 WPA uses the RC4 encryption algorithm and augments a "Temporal Key Integrity Protocol" to aid in improving the strength of the encryption mechanism. Recently, there have been reports that Computer Scientists in Japan have found a way to compromise the encryption.
Wireless Uses in Healthcare
Perhaps no other industry can lay claim to the necessity of wireless technology than that of the modern healthcare environment. As described previously, healthcare's unique mobility requirements coupled with the need for immediate and continuous connectivity to the clinical network provide a challenging set of requirements. Providing access to clinical systems for both the caregivers and biomedical devices is the most common use case for wireless technologies in modern healthcare environment.
Not to be underestimated, healthcare environments world-wide continuously strive to provide optimum patent care, but with the increasing demand to provide that care at a lower flat-price point. In doing so, some innovative uses of wireless technology help drive that goal forward.
This section discusses some of the unique capabilities of 802.11-based wireless technologies within the modern healthcare environment, and provides an overview of how healthcare customers world-wide are using wireless technologies in order to meet their goal of improving patient care.
BioMedical Devices
Biomedical devices such as patient monitors, infusion pumps, and ventilators are the fastest growing population of networked connected devices in a clinical environment. Most of the main vendors in this space support 802.11-based wireless LAN capabilities to provide network access for patient monitors and smart infusion or IV pumps. Vendors must develop risk analysis-based performance metrics for alarm delivery times, and then design a system to meet those requirements.
Smart Infusion pumps in an acute-care setting usually comprise a relatively large number of wireless devices. These types of devices are the most mobile in nature since they will be in close proximity of the patient under care. Security involving the devices and the methods available for authentication and encryption are an important aspect of the deployment of the Medical-Grade network.
Patient monitors comprise the second largest percentage of biomedical devices in a hospital setting. Patient monitoring systems are designed to monitor the physiological conditions of a patient using different metrics. Monitors generally will send the vital signs information about patients to a backend central server on a continuous basis. Unicast or sometimes multicast/broadcast traffic of small, but very frequent intervals (i.e., 300 byte, 4x/sec) is used to communicate patient telemetry and alarm data.
The life critical requirements used for continuous patient monitoring is more critical than smart infusion pumps, and as a result, network connectivity needs to be engineered appropriately.
Voice
As stated previously, healthcare providers are a highly mobile group of people. Providing these caregivers with reliable mobile communications by itself dramatically increases productivity by making the caregivers instantly available for communications, decreasing the time spent tracking down other caregivers and resources. Integrating these mobile devices with the appropriate clinical applications can further improve workflow and productivity. One example of the possibilities is nurse call.
In a traditional Nurse Call system, when a patient pushes a nurse call button, a light is lit outside the patient's room at a central nursing station. The charge nurse at the central nursing station has to call the patient and identify the problem. The charge nurse then will page, via an overhead or room pager, to find an available resource. The nurse must stop what he/she is doing and respond to the request. Finally, the nurse can return to what he/she is doing before being interrupted. By integrating the Nurse Call system with mobile communications, when a patient presses the nurse call button, the nurse assigned to the room will be alerted with a message on the phone. The nurse may then press a single button and talk with the patient to determine the request, and respond immediately if it is urgent, or continue what he/she were doing and respond later if it is not urgent.
Another more specific nurse call example is a code blue alert. Typically, when a code blue is initiated a page is sent to all of the members of the code blue team. Provided the location of the code blue emergency, they then begin the response protocol. By integrating wireless phones and collaboration applications, code blue alerts, a conference call can be automatically setup between the code blue team members and nurse call patient device. This provides immediate collaboration with team members who are not present on the floor in question so as to provide guidance and be aware of the situation prior to attending to the patient. In some cases, this can lead to improved patient care by reducing treatment delays.
These are just a couple of examples of how integrating mobile wireless communications and unified communications can improve caregiver efficiency and patient care. Others exist within an acute care setting including but not limited to dietary, housekeeping, transportation, security, and various others.
Real-Time Location-Based Services
Cisco's Real-time Location Services (RTLS) provides a healthcare facility with the ability to track the location of any WiFi-based device or 802.11 based active RFID tag. As we have described elsewhere in this document, collaborating with the network is one attribute of the MGN architecture. As such, being able to interact with the network when tracking the location of a resource be it a person or medical device is key in optimizing workflow and enhancing overall operational efficiencies.
Note
A RTLS system is comprised of the following items which we will discuss in further detail
•
•
•
•
•
In healthcare environments room level accuracy is the goal with bed level accuracy being the desired golden standard. With location-based technology based on Received Signal Strength Indicator (RSSI), room level accuracy can be achieved provided that one of the following two approaches are used and properly executed.
1.
2.
Note
Historically hospital wireless access-point placement were commonly performed with the sole objective of providing wireless data and voice services. As such, the goal of the RF engineer who performed the site survey was to architect an RF environment that provides adequate data and voice coverage in the required areas. Many times however, location-based service requirements are not taken into account at the onset of the project.
This can be commonly seen when access points are placed in a straight line down the hallway of a patient floor, and no perimeter AP placement was implemented. When this approach is taken, the ability of the Mobility Services Engine (MSE) to create a highly accurate RF path loss profile is significantly reduced. As the distance from the AP is increased, the level of accuracy increases significantly.
Take for example the traditional AP placement strategy shown in Figure 6. In this illustration, the access points are placed down the hallway in a single axis, and the absence of a "convex hull" exists due to the lack of an established AP perimeter results.
Figure 6 Traditional AP Placement
Note how the RF Path Loss (PL) from an asset being tracked typically does not have a significantly different signal level to determine location with a high level of accuracy. In order to provide more accuracy, additional APs on different axis's must be deployed, effectively creating an AP perimeter.
Recently, many healthcare organizations are deploying 802.11n access points within the patient rooms for performance reasons. The hidden benefit to the added performance is the increased accuracy as shown in Figure 7. The diagram shows the beginning of establishing an AP perimeter, but falls sort of providing one for the entire floor as shown in Figure 7.
Figure 7 AP Perimeter
To provide an AP perimeter, deploying APs on multiple axis as well as establishing a complete AP perimeter is critical to increasing accuracy. In the illustrated in Figure 8, an AP perimeter has been established. The resulting "convex hull" provides room-level accuracy in most healthcare environments.
Figure 8 Establishing AP Perimeter
Note
The increased AP density may in some bands, and depending on channel section result in co-channel interference. This is dependent on the construction materials used. Wireless clients operating on the same channel on adjacent floors may also cause co-channel interference. In order to reduce the likelihood of interference on adjacent floors, it is recommended to stagger the APs in such a way as to not "stack" access points, especially on the same channel. In the illustration in Figure 9, note how the APs are not stacked between floors. This approach is recommended if there is "bleed through" from the adjacent floors.
Figure 9 Non-Stacked Access Points
Location-Based Services (LBS) can not only be used to provide location and utilization information, but can also be used to provide environmental measurements. The Joint Commission on the Accreditation of Healthcare Organizations (JCAHO) requires healthcare organizations to provide auditing of all environments used to contain or store temperature sensitive medications or specimens. As such, many healthcare organizations have protocols in place which measure the temperature in various medical refrigerators every hour.
This time consuming task can be automated through the use of 802.11 RFID temperature tags. The measurement data is collected on a configurable time frame and reported back to the Mobility Solution Engine for later reporting. Alternately, alerts can be generated if the measurement falls outside of a configured range.
Server and storage system faults or sometimes even failures have been directly tied to that of ambient temperature. Enabling a Medical-Grade Network not only relies on the basic networking and IT aspects, but also extends to all aspects of operation. Within the Data Center for example, these same tags can be utilized for the collection and historical temperature monitoring, again alerting proper personnel when a fault condition is detected.
Time Differential of Arrival (TDOA) compatible systems can add improved accuracy by measuring the time it takes for a given RF signal sent from an 802.11 device or TAG to be received by two or more sensor stations. Vendors such as Aeroscout have TDOA solutions that require the placement of TDOA based sensors in addition to access-points. TDOA information collected is sent to the Cisco Mobility Time Differential of Arrival (TDOA) compatible systems can add improved accuracy by measuring the time it takes for a given RF signal to be received by two or more sensor stations. Vendors such as Aeroscout have TDOA solutions that require the placement of TDOA based sensors in addition to access-points. TDOA information collected is sent to the Cisco Mobility Services Engine (MSE). The MSE uses the TDOA location algorithm developed by Aeroscout to determine the location. This provides a constant metric that is not affected by changes in the RF environment, that being the time of arrival of a packet. In low ceiling indoor environments however, the use of TDOA systems may be negatively affected by multipath interference. TDOA systems provide high level accuracy in larger indoor environments such as warehousing, or outdoor environments where multipath interference is low.
Depending on the desired accuracy levels required, RSSI, Exciter/Choke Points should be deployed in a healthcare environment. These techniques can be mixed or matched to achieve the requirements set forth by the healthcare organization. For detailed information about LBS, consult Cisco's Design Zone located at the following URL: http://www.cisco.com/go/designzone
Security
Wireless LANs share many of the security challenges that wired networks present. Both require user authentication, authorization, auditing and protection from threats such as viruses and other malicious code. Wireless LANs also present new challenges generally related to the nature of the technology used, which is outside the enterprise's control since it is "in the air". In addition, wireless networks cannot be confined within a physical facility; anyone within transmission range can listen in, masquerade as trusted participants, extend the network, and disrupt operations.
Guest Access Services
It is no surprise that the Internet has become as important to many people world-wide as cellular phone service has become. As such, healthcare organizations and ambulatory-based providers are offering guest Internet services to not only their patient community, but students and contractors as well.
Providing Internet access to the patient community provides much needed access to the outside world during a time when the individual may need such communication mechanisms the most. Providing wireless internet access services involves some common requirements:
•
–
–
–
–
•
–
•
–
–
•
–
The model for students and/or authorized contractors are similar to the requirements outlined above, but may provide additional rights not provided to the general patient and visitor population. These may include additional bandwidth, longer login times, and access to specific internal websites related to job role or student responsibilities.
Many healthcare organizations are looking to outside guest access providers to manage guest Internet services. This hybrid approach allows the guest user to use the existing wireless infrastructure (APs, wireless controllers). The network backhauls the guest access to an egress point in the network where it is handed off to a guest provider. Many service providers offer this service, which has a number of advantages listed below:
•
•
•
•
•
The decision to adopt guest Internet access is one that most organizations have made. The real decisions are based on the access model being used. Should an outside vendor be engaged to manage the service offering, or is there significant capacity both in personnel resources and Internet access to support the service in-house.
For more details about guest access services, refer to Cisco Design Zone website at the following URL: http://www.cisco.com/go/designzone
Note
Clinical Access
Clinical systems refer to systems that support clinical workflow and decision support, including electronic health record (EHR) and computerized physician order entry (CPOE) systems. Often these systems will include laboratory and pharmacy systems as well as imaging applications.
These clinical systems often support 802.11 wireless standards as mobile workstation or computers on wheels, sometimes referred to as CoWs or WoWs. These carts allow caregivers to access clinical systems at the point of care. Healthcare professionals can have real-time access to various applications in a clinical information system (CIS) while mobile or at a patient's bedside.
One of the principal RF-based aspects of CoWs is the inclusion of an external antenna that supports all of the 802.11 bands that will be used. Figure 10 shows the Metro flo 1760 mobile computing workstation. Note the inclusion of an external and predominately located multi-band antenna. Mounting the RF radiator externally can provide significant improvements in performance. For cases where the RF environment changes drastically, as in the case of the automatic closure of fire doors for example, such RF considerations can become a make or break decision.
Figure 10 Metro Flo 1760 Mobile Workstation
Wireless Architecture Overview
Cisco's Medical-Grade Network 2.0—Wireless Architecture is a subset of the overall Cisco MGN architecture. This section provides an overview of the key components, specific design considerations and component placement for the wireless architecture within a healthcare environment.
Figure 11 illustrates the range of technologies and products as part of the wireless architecture.
Figure 11 Wireless Architecture
The wireless architecture is comprised of the following components:
•
•
•
•
The sections below provide an overview of these relevant components.
Access Point
Wireless Access Point (WAP) is a device that allows wireless communication devices to connect to a wireless network using WiFi, Bluetooth, or related standards. The WAP usually connects to a wired network, and can relay data between the wireless devices (such as computers or printers) and wired devices on the network.
Within the Cisco MGN wireless architecture, there are two categories of APs: standalone and lightweight or CAPWAP/LWAPP. This section briefly discusses the various models of AP products available within each category, and contrasts features, functionality, and applications.
Note
Cisco LWAPP and CAPWAP APs
All Cisco APs sold today support the Cisco Unified Wireless architecture and utilize the LWAPP protocol to provide wireless services. Starting in Release 6.0 of the WLC software, LWAPP is replaced by the CAPWAP standard.
•
•
•
•
For further detailed information, see the following link: http://www.cisco.com/en/US/products/ps5678/Products_Sub_Category_Home.html
Wireless LAN Controller (WLC)
Wireless networks have become a necessity today in all healthcare environments. Most acute care environments require deployment of wireless networks on a large scale and there is a mandatory need to manage such large scale deployments centrally.
The Wireless LAN Controller (WLC) is a device that assumes a central role within the wireless network. Traditional roles of access points, such as association or authentication of wireless clients, are done by the WLC. Access points, called lightweight access points (LAPs) in the unified environment, register themselves with a WLC and tunnel all the management and data packets to the WLCs, which then switch the packets between wireless clients and the wired portion of the network. All the configurations are done on the WLC. LAPs download the entire configuration from WLCs and act as a wireless interface to the clients.
For convenience, this document refers to all Cisco Unified Wireless controllers as WLCs due to the general uniformity and commonality of features across all of Cisco's WLC platforms.
The simple timing-dependent operations are generally managed on the lightweight AP, and more complex and less time-dependent operations are managed on the WLC.
For example, the lightweight AP handles the following:
•
•
•
•
•
•
•
•
•
Other functionality is handled by the WLC. Some of the MAC-layer functions provided by the WLC include the following:
•
•
•
•
Termination of 802.11 traffic on a wired interface, except for the REAP and H-REAP, which are discussed later in this guide.
When the WLAN LWAPP tunnel traffic reaches the WLC, it is mapped to the matching VLAN interface configured on the WLC that defined the SSID, operational state, and WLAN security and quality parameters for that WLAN. WLC WLAN parameters define the wired interface to which the WLC WLAN is mapped. The wired interface on the WLC is typically a VLAN configured on a WLC port, but a WLAN client can be mapped to a specific VLAN interface on the WLC based on parameters sent by the AAA server after successful EAP authentication.
The following summarizes the various Cisco Unified Wireless WLCs and their features:
•
•
•
•
•
•
•
Design Considerations
Beginning in Release 5.2 of the WLC software, Control and Provisioning of Wireless Access Points (CAPWAP) was introduced. This IETF standard is based on Cisco's proprietary Lightweight Access Point Protocol (LWAPP) and is used to communicate between APs and WLC. WLCs running software prior to Release 5.2 use the LWAPP protocol for much of the same function. One of the advantages of CAPWAP over LWAPP is the management traffic between the WLC (also known as access controller) and the AP (aka: Wireless Termination Points or WTP) is encrypted. CAPWAP is defined in RFC-5415 and can be found at the following URL: http://www.ietf.org/rfc/rfc5415.txt
LWAPP and the IETF CAPWAP standard are the underlying protocols used in Cisco's centralized WLAN architecture. CAPWAP provides for the configuration and management of WLAN(s), in addition to tunneling WLAN client traffic to and from a centralized WLAN controller (WLC). Figure 12 shows a high-level diagram of a basic centralized WLAN architecture, where lightweight APs connect to a WLC through the use of a tunnel.
Figure 12 CAPWAP and LWAPP APs Connected to a WLC
Authentication
For the Wireless network, user based security is comprised of authentication and encryption. Common security mechanisms for WLAN that are considered Medical Grade are as follows:
•
•
Wireless Networks which use Open Authentication, Wired Equivalent Privacy (WEP) or Cisco's WEP Extension using CKIP) are no longer considered Medical Grade due to their weak security.
Both WPA and WPA2 are defined by the Wi-Fi Alliance, which is the global Wi-Fi organization that created the Wi-Fi brand. The Wi-Fi Alliance certifies inter-operability of IEEE 802.11 products and promotes them as the global, wireless LAN standard across all market segments. The Wi-Fi Alliance has instituted a test suite that defines how member products are tested to certify that they are interoperable with other Wi-Fi Certified products.
The original 802.11 security mechanism, WEP, was a static encryption method used for securing wireless networks. Although it applies some level of security, WEP is viewed as insufficient for securing all forms of clinical communications. In short, WEP should not be used by any modern healthcare organization due to the security risks that it creates. WPA is an 802.11i-based security solution from the Wi-Fi Alliance that addresses the vulnerabilities of WEP. WPA uses Temporal Key Integrity Protocol (TKIP) for encryption and dynamic encryption key generation by using either a pre-shared key, or RADIUS/802.1x-based authentication. The mechanisms introduced into WPA were designed to address the weakness of the WEP solution without requiring hardware upgrades. WPA2 is the next generation of Wi-Fi security and is also based on the 802.11i standard. It is the approved Wi-Fi Alliance interoperable implementation of the ratified IEEE 802.11i standard. WPA 2 offers two classes of certification: enterprise and personal. Enterprise requires support for RADIUS/802.1x-based authentication and pre-shared key (personal) requires only a common key shared by the client and the AP. The new Advanced Encryption Standard (AES) encryption mechanism introduced in WPA2 generally requires a hardware upgrade from earlier versions of WLAN clients and APs, however all Cisco CAPWAP and LWAPP APs support WPA2.
The Cisco Wireless Security suite provides the user with the options to provide varying security approaches based on the required or pre-existing authentication, privacy and client infrastructure. The Cisco Wireless Security Suite supports WPA and WPA2.
Authentication based on 802.1x using the following EAP methods:
•
•
•
•
•
Encryption:
•
•
•
Wireless Control System (WCS)
The Cisco Wireless Control System (WCS) is the platform for wireless planning, configuration, and management and provides the tools to allow network managers to design, control, and monitor wireless networks from a central location. The WCS supports centralized wireless LAN planning and design, RF management, location tracking, IPS, and WLAN systems configuration, monitoring, and management.
With the Cisco WCS, network administrators have a solution for RF prediction, policy provisioning, network optimization, troubleshooting, user tracking, security monitoring, and WLAN systems management. Graphical interfaces make wireless LAN deployment and operations simple and cost-effective. Detailed trending and analysis reports make Cisco WCS vital in supporting ongoing network operations.
Mobility Services Engine (MSE)
The Cisco 3300 Series Mobility Services Engine (MSE) supports a suite of mobility services software in a modular fashion based on network topology and the types of services required. The services include the following:
•
•
•
•
•
•
Campus Design Considerations
The Medical Grade Network architecture defines best practices as applied to both wired and wireless deployments in a converged network. This architecture can be applied towards a campus design and used more specifically in the following settings:
•
•
Figure 13 depicts the acute care campus environment.
Figure 13 Acute Care Campus
•
•
•
Branch Design Considerations
The MGN architecture can be applied towards a branch design. These design principles are used to enable the following settings:
•
•
•
See Figure 14.
Figure 14 Branch Office
In the ambulatory care facility or small office/clinic, an ISR with integrated 802.11AP and security will generally be used. Optionally, the WLCM, the WLC module is specifically designed for Cisco's Integrated Service Router (ISR), can be used and is available in a 6, 8, or 12 AP version. The WLCM appears as an interface on the ISR router that can be configured as a dot1q trunk to provide a routed connectivity to the wired network.
Network Management Tools
As caregivers become reliant on mobile communications devices and biomedical devices migrate to wireless networking, the wireless LAN becomes a mission critical component of in the healthcare infrastructure. There is probably no other industry that use the range of wireless endpoints with their own unique requirements as Healthcare. The data streams from any of these endpoints could potentially contain Protected Healthcare Information (PHI) requiring protection, both by encryption and detecting and eliminating rogue users. At the same time the physical structure contains its own challenges. There may be multiple floors and a combination of old and new structures with some rooms shielded and a requirement of roaming throughout for the mobile communications devices. The Cisco Wireless Control System (WCS) was covered in the previous chapter. This section is going to focus on some additional tools and techniques to manage the wireless infrastructure.
Rogue AP Detection
Protected Healthcare Information (PHI) and other proprietary information traverse the healthcare network. This information must be protected from hackers. A simple entry point into the network for a hacker is a Rogue Access Point. A rogue AP is any AP that is not part of the Enterprise Infrastructure and therefore doesn't have the required security mechanisms in place. Rogue APs may be intentionally introduced by the hacker plugging an AP into the network infrastructure with no security, or security controlled by the hacker. This requires physical access to the network infrastructure. Rogue APs may also be unintentionally introduced into the network when an employee plugs their own AP into the network for their convenience. This AP may be discovered and exploited by a hacker.
The Cisco Unified Wireless Networking solution provides the means to locate and isolate rogue APs in the healthcare network.
The first means of detection is observing/sniffing beacons and 802.11 probe responses. The system may utilize the standard APs used to transport user traffic, or dedicated APs that transport no traffic but are dedicated to scanning for rogue APs. Either model allows the capture of information on ad hoc and rogue clients. For more details on Air/RF detection, see the Wireless Security Design Guide at http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns820/landing_sec_wireless.html.
The location feature of the WCS then uses the detected RF characteristics and known properties of the managed RF network to provide a floor plan indicating the approximate location of a rogue AP. An example of this is shown in Figure 15. The floor plan shows the location of all legitimate APs and highlights the location of a rogue AP using the skull-and-crossbones icon.
Figure 15 Rogue AP Mapping
For more information on the Cisco Unified Wireless Location features, refer to the following URL:
http://www.cisco.com/en/US/products/ps6386/index.html
In cases where the detection mechanism described above is not effective (such as in branch offices that contain only a few APs or where accurate floor plan information isn't available), the Cisco Unified Wireless network provides a couple of mechanisms for tracking/correlating the rogue device to the wired network. When an unknown AP is detected, it must be determined if the AP is a rogue or an AP on an adjacent network. The first means of detecting this is by deploying rogue detector APs. These are APs that have their networks turned off, that listen to the wired network for ARP packets that include the MAC address of the suspected rogue. When the ARP is detected, it verifies that the suspected rogue is in fact connected to the wired network. To be effective at capturing ARP information, the rogue AP detector should be connected to all available broadcast domains using a Switched Port Analyzer (SPAN) port because this maximizes the likelihood of detection.
If a rogue client resides behind a wireless router (a common home WLAN device), their ARP requests are not seen on the wired network, so an alternative to the rogue detector AP method is needed. Additionally, rogue detector APs may not be practical for some deployments because of the large number of broadcast domains to be monitored (such as in the main campus network).
The Rogue Location Discovery Protocol (RLDP) option can aid in these situations. In this case, a standard LAP, upon detecting a rogue AP, can attempt to associate with the rogue AP as a client and send a test packet to the controller, which requires the AP to stop being an active AP and to go into client mode. This action confirms that the rogue AP in question is actually on the network, and provides IP address information that indicates its logical location in the network. Given the difficulties in establishing the location data in branch offices and the likelihood of their being located in multi-tenant buildings, rogue AP detector and RLDP are useful tools that augment location-based rogue AP detection.
Finally, a mechanism is provided to prevent clients from connecting to the rogue AP. Rogue AP-connected clients, or rogue adhoc connected clients, may be contained by sending 802.11 deauthentication packets from local APs. This should be done only after steps have been taken to ensure that the AP is truly a rogue AP, because it is illegal to do this to a legitimate AP in a neighboring WLAN.
To determine whether rogue AP clients are also clients on the enterprise WLAN, the client MAC address can be compared with MAC addresses collected by the AAA during 802.1X authentication. This allows the identification of possible WLAN clients that may have been compromised or users that are not following security policies.
For more details on Rogue AP detection and isolation, see the Wireless Security Design Guide at http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns820/landing_sec_wireless.html
Auto RF
Radio Resource Management (RRM), also known as Auto-RF, can adjust the channel (dynamic channel assignment) and power (dynamic transmit power control) to maintain the RF coverage area. It adjusts the power level of the AP to maintain a set baseline signal strength with neighboring APs. The default signal strength depends on the software version, and this value is configurable. It adjusts the channel of the AP when it notices nearby interference sources on the channel on which the AP is currently located. It continues to optimize the RF coverage for the best reception and throughput for the wireless network.
RRM understands that the RF environment is not static. As different RF affecting variables change (people in the room, amount of devices stored in the facility, leaves on trees for outside deployment, interference from different RF sources, and so on), the RF coverage adjusts to these variables and changes with them. Because these variables change continuously, monitoring for the RF coverage and adjusting it periodically is necessary.
The five major functions of RRM are as follows:
•
•
•
•
•
Dynamic Channel Assignment
The 802.11 MAC layer uses Carrier-Sense Multiple Access/Collision Avoidance (CSMA/CA). With CSMA/CA, two APs on the same channel (in the same vicinity) get approximately half the capacity of two APs on different channels because of the shared wireless channel. This is caused by the 802.11 MAC sensing that the channel is busy, and deferring sending frames until the channel has become free. If the 802.11 MAC defers traffic that is not part of its own AP cell, this is considered interference. Interference from another AP on the same channel is commonly called co-channel interference, and is to be expected in most 2.4 GHz 802.11 deployments, because there are insufficient non-overlapping channels to prevent some channel overlap from occurring. One of the goals of design, planning, and dynamic radio management is to minimize the amount of co-channel overlap, which minimizes co-channel interference and therefore maximizes AP traffic capacity. The Cisco Unified Wireless Network addresses this problem and other co-channel interference issues by dynamically allocating AP channel assignments to avoid conflict. Because the WLC, or a designated WLC (RF Group Leader), has system-wide visibility, it can control how channels are "reused" to minimize co-channel interference.
The WLC examines a variety of real-time RF characteristics to efficiently handle channel assignments, including the following:
•
•
The WLC combines the RF characteristic information to make system-wide decisions. The end result is an optimal channel configuration in a three-dimensional space, where APs on the floor above and below factor into an overall WLAN configuration.
Interference Detection and Avoidance
Interference (as it pertains to a Cisco Unified Wireless deployment) is defined as unwanted RF signals in the same frequency band that can lead to a degradation or loss of service. These signals can either be from 802.11 or non-802.11 sources such as certain microwave ovens or many cordless phones. It can, in certain instances, also include various sources of electromagnetic interference (EMI) such as arc welders or federal/military radar facilities. APs are constantly scanning all channels looking for major sources of interference.
If the amount of 802.11 interference hits a predefined threshold, the WLC attempts to rearrange channel assignments to optimize system performance in the presence of the interference. This might result in adjacent APs being on the same channel, but logically this represents a better scenario than staying on a channel that is otherwise totally unusable because of an interfering AP.
For example, the WLC can respond to a rogue AP on channel 11 by shifting nearby APs to channel 1 or channel 6.
Dynamic Transmit Power Control
Appropriate AP power levels are essential to maintaining a coverage area, not only to ensure correct (not maximum) amount of power covering an area, but also to ensure that excessive power is not used, which would add unnecessary interference to the radiating area. AP power settings are also used to control network redundancy by helping to ensure real-time failover in the event of the loss of an AP. The WLC is used to dynamically control the AP transmit power level based on real-time WLAN conditions. In normal instances, power can be minimized to gain extra capacity and reduce interference among the APs. RRM attempts to balance APs so that they see their neighbors at -65 dBm. If an AP outage is detected, power can be automatically increased on surrounding APs to fill the coverage gap created by the loss of the AP.
RRM algorithms are designed to create the optimal user experience. For example, if the power of an AP is turned down to Level 4 (where level 1 = highest and level 8 = lowest) and the received signal strength indicator (RSSI) value of a user drops below an acceptable threshold, the AP power is increased to provide a better experience to that client. When Dynamic Transmit Power Control (DTPC) is enabled, the access points add channel and transmit power information to beacons. Client devices using DTPC receive the information and adjust their settings automatically.
Coverage Hole Detection and Correction
The coverage hole detection and correction algorithm is aimed at determining coverage holes based on the quality of client signal levels and then increasing the transmit power of the APs to which those clients are associated.
The algorithm determines whether a coverage hole exists when client SNR levels pass below a given SNR threshold. The SNR threshold is considered on an individual AP basis and based primarily on the transmit power of each AP.
When the average SNR of a single client dips below the SNR threshold for at least 60 seconds, this is seen as an indication that the WLAN client does not have a viable location to which to roam. The AP transmit power of that client is increased, correcting the coverage hole.
Client and Network Load Balancing
The IEEE 802.11 standard does not define the process or reasons for client roaming, and therefore it cannot be easily predicted what clients will do in any given situation. For example, all users in a conference room can associate with a single AP because of its close proximity, ignoring other APs that are farther away but with greater free capacity.
The WLC has a centralized view of client distribution across all APs. This can be used to influence where new clients attach to the network if there are multiple "good" APs available. If configured, the WLC can proactively use AP probe responses to guide clients to the most appropriate APs to improve WLAN performance. This results in a smooth distribution of capacity across an entire wireless network. Keep in mind that this load balancing is done at client association, not while a client is connected.
Healthcare Caveats
While there are many benefits to RRA, care should be taken when deploying RRA in the healthcare environment. The client side support for Dynamic Transmit Power Control (DTPC) requires a minimum of CCX 2.0. Medical devices typically have a very long life cycle and may have limited wireless functionality. RRA modifying the characteristics of the network could result in the endpoint being able to receive but have insufficient power to communicate with the access point. See Figure 16.
Figure 16 Dynamic Transmit Power Control
Cisco Spectrum Expert
In the healthcare environment, wireless interference may come from a range of unintentional sources from Bluetooth headsets to microwave ovens, wireless phone, wireless cameras, or intentional interference from jammers. A few documented instances include wireless phones installed by nurses who did not like the wireless communications device the hospital provided, medical devices using 802.11FH that needed code updates, and security cameras installed in a hospital without notifying IT. Figure 17 shows examples of interference.
Figure 17 Typical Wireless Interference
The traces in Figure 17 were captured using the Cisco Spectrum Expert. This device detects, classifies, and locates sources of RF interference in the unlicensed 2.4-GHz and 5-GHz bands. The Cisco Spectrum Expert Wi-Fi (see Figure 18) includes the following components:
•
•
•
The Cisco Spectrum Expert Wi-Fi sensor is a sensor in CardBus card form factor for notebooks. It is supported on Microsoft Windows-based laptops and delivers comprehensive spectrum intelligence. Network administrators can streamline wireless network troubleshooting with better visibility into the RF spectrum and can easily identify and detect sources of wireless interference.
Figure 18 Cisco Spectrum Expert Wi-Fi Application and Cardbus Product (Laptop not included)
The Cisco Spectrum Expert provides a wide range of information on the RF Spectrum under analysis including Channel Utilization, Interference Power, graphs of active devices, Real Time FFT, FFT Duty Cycle, Sweep Spectrograms, and information on the interfering device. Figure 19 to Figure 21 show a typical screen captures from Spectrum Expert analyzing a DECT phone.
Figure 19 Cisco Spectrum Expert Screen Shots
Figure 20 Cisco Spectrum Expert Screen Shots
Figure 21 Cisco Spectrum Expert Screen Shots
The device may be used standalone or integrated with WCS (see Figure 22) in the Cisco Spectrum Intelligence solution. Information from multiple Cisco Spectrum Expert Sensors located in critical areas of the network may be combined in this solution providing a complete view of spectrum usage.
Figure 22 Cisco Spectrum Intelligence Solution
Remote Office Wireless
The need for secure wireless connectivity does not end within the acute care environment. Within the physician's practice as well as clinics, providing a wireless architecture with all of the same robust security architectures found within the hospital setting.
A growing trend world-wide is to extend the wireless security model and the overall wireless management to clinics and practices affiliated with the healthcare system. There are multiple reasons for this trend, but first and paramount is that of security. Today, many clinics and physician practices have connectivity to the main hospital(s) to which they are associated with. This connectivity provides access to lab reports, EHR, E-mail, and scheduling systems.
This section focuses on the overall architecture needed to provide robust wireless within the ambulatory care environment using a centralized security and management model.
Providing Remote Wireless Services
With Cisco's Unified Wireless architecture, there are three methods of operation for 802.11 access points. The fist is commonly referred to as autonomous mode. In autonomous mode, the AP does not require the Wireless LAN Controller (WLC) to operate. This approach, while not optimal will provide wireless services and may be used when the number of access points in the management domain is small (< 5).
In autonomous mode, each access point contains an operating system that allows the access point to execute the configuration stored within the access point. This configuration contains the security mechanism for each of the WLANs (or SSIDs) configured along with power, channel, and other operating parameters and configured.
For those clinics and physician's offices that do not have connectivity back to its parent and supporting healthcare system, autonomous mode makes sense for deployments that contain less than five access points. In this case, the wireless configuration must be manually managed and may from time to time require onsite visits from the supporting staff in order to upgrade the IOS or implement configuration changes.
A better approach over that of autonomous mode is the OfficeExtend Access Point architecture (see Figure 23). In this approach, the APs create an encrypted DLTS VPN tunnel between the access point and a centralized WLC using the Internet to provide connectivity. The benefits of this approach is that it provides centralized management without requiring each remote office to install and maintain a WLC.
Figure 23 OfficeExtend Access Point Architecture
For sites that have connectivity to the supporting healthcare system either through a WAN or VPN connection, the centralized CAPWAP or LWAPP architecture is preferred. This strategy is inclusive of not only clinics and private practices, but may also extend into the physician's home provided that VPN access is also managed to the healthcare system.
Security
Security is a primary concern when it comes to providing remote wireless solutions. Wireless security should not only refer to authentication and encryption, but should also include controlling management access to the wireless and securing the wireless client.
Since all physician practices typically involve the transmission of private patient information, the approach to security must be taken as a serious consideration for all such deployments. In the United States, HIPAA requires that best practices be used by all Covered Entities (CE) in order to safeguard what is commonly referred to as Protected Health Information (PHI). In other countries, various regulatory bodies mandate similar safeguards be in place for the protection of private healthcare information.
With the U.S. Senate approval of the American Recovery and Reinvestment Act of 2009, it is widely anticipated that the adoption of Electronic Health Record (EHR) systems will increase dramatically. With each of these systems deployed within private practices and clinics, the need to extend enterprise class security services for both wired and wireless is necessary.
For clinical users within the remote clinic or practice, 802.1x authentication must be used. This authentication method provides the ability to support a number of different EAP methods that can be tied to individual users which is generally necessary regulatory compliance and accepted security best practices.
In order to ensure that the PHI is not compromised, the use of WPA2 using AES should be implemented on all clinical networks. The use of WPA-TKIP may provide adequate protection today, but it is expected to be outdated in the near future. In addition, and generally a good practice, all web-based EHR systems should employ the use of SSL in order to protect the data that traverses the wired network. While not absolutely necessary, it does provide another level of encryption and improves the overall security posture of the network.
Note
http://www.networkworld.com/news/2009/082709-new-attack-cracks-common-wi-fi.html
http://jwis2009.nsysu.edu.tw/location/paper/A%20Practical%20Message%20Falsification%20Attack%20on%20WPA.pdf
Hybrid Remote Edge Access Point (H-REAP)
Hybrid Remote Edge Access Point (H-REAP) provides local wireless access to network resources within a remote office such as a physician practice or clinic. At the same time, continuous remote management, configuration and monitoring of the wireless infrastructure is provided to a central location, providing real-time administration services.
The H-REAP local-switching architecture provides healthcare systems that provide managed wireless services to remote clinics and offices the ability to extend the organizations approved security model for wireless connectivity directly to the remote location through the use of a private WAN or VPN-based technology. In doing so, wireless users within the remote office are provided with secure wireless access to resources that are local within the office without the need to traverse the WAN or VPN. Examples include EHR or practice management systems operated by the practice, wireless voice services, guest wireless, file storage, and printer resources. See Figure 24.
Figure 24 H-REAP Local-Switching Architecture
H-REAP is supported on the 1130AG, 1140AGN, 1230AG, 1240AG, 1250 access points on the 2100 and 4400 series controllers, the Catalyst 3750G Integrated WLC switch, the Cisco WiSM, and the controller network module for ISRs.
Wireless user authentication with H-REAP deployments operate in one of the two switching modes and three authentication modes.
Switching Modes
The following are the switching modes:
•
•
Authentication Modes
The following are per-WLAN authentication modes:
•
•
•
In order to provide access to the local resources located at the clinic or physician practices, it is recommended that local switching mode is used on the WLAN/SSID used by authorized office staff. In this mode, all traffic generated by the local office staff is sent to the local LAN without the need to traverse the tunnel to the central WLAN controller. See Figure 25.
Figure 25 Authentication for Authorized Office Staff
For guest users, however, it may be desirable to configure the guest services WLAN/SSID to traverse the WLAN and use many of the guest based authentication services. Often times the wireless guest is presented with a set of acceptable use policies (AUP) that must be agreed to prior to permitting access to the Internet. By using the AUP-based authentication service available on the WLC and other such services including rate limiting, wireless guests will have the same experience within the clinic as they do within the hospital. See Figure 26.
Figure 26 Authentication for Guests
Starting in WLC Release 5.0.148, two new H-REAP features were added. In the event of a RADIUS server failure (not a WAN or VPN failure), an H-REAP group can be configured with a backup RADIUS server. Up to 20 groups each containing up to 25 access points can be configured. Local authentication has also been enhanced providing authentication for up to 20 statically configured users. The list of statically defined WLC users is transmitted to each access point within the H-REAP group upon registration with the WLC.
Voice
H-REAP deployments are able to support Voice-over-Wireless LAN (VoWLAN) services. In many remote offices, either a Cisco Unified Communication Manager Express (Unified CME) or Unified Communications 500 series (UC-500) are typically deployed where up to 240 or 50 phones respectively are required.
Standard RF considerations for voice must be followed, and are documented in the Cisco Unified CallManager Express Solution Reference Network Design Guide available on at the following address:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/srnd/design/guide/cmesrnd.html
Note
Real-Time Location Services (RTLS)
RTLS are supported in H-REAP deployments provided that connectivity is maintained to the WLC. Accuracy, however, may not be optimum, or in some cases extremely poor due to the approach to remote office deployments, and the placement of access points not being optimized for RTLS.
In many cases, remote clinics and physician practices do not require more than one or two access points operating in H-REAP mode. When one access point is used for example, there is only one path able to be detected between the wireless clients or RFID tags and the access point. Because of this, simple present or not-present status is the optimum result that can be obtained in a single AP deployment. When two access-points are deployed, accuracy is increased, but again accuracy is not optimal due to the existence of a maximum of two RF paths between the access points and the wireless client or RFID tag.
Unless the wireless network at the remote office was originally designed with location-based services in mind, usually the end result is a sub-optimal LBS solution where granular accuracy is desired.
If high accuracy is desired, the wireless network should be designed with LBS in mind. For information on designing highly accurate LBS wireless networks, refer to the Location-Based Services 4.1 Design Guide found at the following URL:http://www.cisco.com/go/designzone.
Rogue Detection and Radio Resource Management (RRM)
Because many remote deployments have only a small handful of H-REAP-enabled APs, full Radio Resource Management (RRM) functionality might not be supported at each H-REAP site. Full support of the RRM services is available with H-REAP, but the Transmit Power Control (TPC) algorithms are not triggered until four or more access points are within range of each other.
Therefore, some H-REAP installations might never adjust the transmit power of their radios. This is because RRM requires four or more access points within the same administrative domain are within range of each other. In many H-REAP installations, the number of access points deployed does not exceed three and therefore full RRM capabilities might not be available.
Rogue access-point detection is disabled when an H-REAP access point enters standby mode. A standby mode is when connectivity between the access point and the WLC is disrupted. Furthermore, in standby mode, neighbor discovery, interference, channel load, path loss and coverage measurements, rogue containment, and intrusion detection are disabled. These features are disabled as the access point is no longer able to send these metrics to the WLC. Additional information can be found in the Mobility Services Engine - Context Aware Mobility Solution Deployment Guide found at the following URL: http://www.cisco.com/application/pdf/paws/107571/mse-cams-guide.pdf
Wireless Endpoints
BioMedical Device Considerations
Smart Infusion Pumps
Smart Infusion Pumps represent a growing trend in the healthcare industry. Their deployment numbers within an acute-care setting usually represent a relatively large number of wireless devices. For wireless network administrator, considerable concern for the coexistence of these "new" wireless devices with existing wireless devices is warranted. Security involving the devices and the methods available for authentication and encryption are also significant considerations during the design process.
Before we get ahead of ourselves, let's first understand why a wireless Smart Pump requires access to the network. At first, it may seem that an infusion pump requires continuous access to the network. While this is the desired objective, it does not mean a loss in wireless connectivity results in the loss of infusion and negatively impacting the patients treatment.
Most, if not all infusion pump vendors today, have architected their infusion pump products to function in what is referred to as a "protected mode" during disruptions of network connectivity. During the network disruption, manual processes or protocols are used to administer new medication or implement infusion rate changes. During this time, all drug advisories continue to be enforced on the pump since the last medication formulary download. While switching to a manual protocol process is cumbersome, and can result in medical errors if not the clinician does not adhere to the protocol. For this reason, connectivity should be maintained at all times, if possible.
In order to maintain connectivity, wireless services supporting this class of medical device must be pervasive throughout the healthcare campus. Failure to do so may result in the Smart Pump roaming into a service area where access is not available.
A Smart Pumps typically have the following connectivity needs:
•
•
•
•
•
•
•
RF Design Considerations
As stated earlier, a Smart Infusion pump does not stop working when it loses connectivity to the wireless network. Having said this, the objective of all wireless networks is to maintain connectivity throughout the environment that the wireless client operates.
From an RF design perspective, Smart Infusion pumps are relatively non-demanding devices. Their ability to tolerate slow roams, IP address changes and off channel scanning usually does not proper operation.
With regard to roaming, the decision to roam to a "better" access-point is always the responsibility of the 802.11 wireless clients. This has led to various roaming algorithms, yielding wildly different results when compared to other wireless devices. The term stickiness refers to the tendency of a wireless client to "cling" to and remain associated to an access-point beyond a point that other wireless clients would have implemented a roam.
When a wireless client clings to an access point longer than it should, data rates are automatically decreased in order to maintain connectivity. During this time, if the wireless client has a significant amount of data to send or receive, performance of the service area or cell is decreased for all wireless clients within the cell sharing the same 802.11 band. This is due to longer transmission times at the lower data rates, resulting in blocking the ability of other wireless clients from accessing the channel.
As a general rule of thumb, the objective should be to provide 25dbm of SNR in all areas that an infusion pump will operate or be stored. One caveat is that many times the site survey will be performed using a laptop with internal or external wireless cards. The RF characteristics of newer laptops or external wireless cards may be significantly different than that of some biomedical devices. This is due in part to the physical design characteristics affecting the RF aspects of the device. Due to poor antenna placement or lower receiver sensitivity, an area surveyed and considered within the norms of standard best practices may for certain devices may not meet the requirements set forth by the vendor.
One recommendation is that after the sight survey is completed using standard best practices and RF survey techniques that each biomedical device that is slated to be used in the area be introduced and tested in the environment where it will be used. This includes not only the patient room (shown in yellow in Figure 27) but also within the bathroom (shown in blue in Figure 27) with all doors closed to create a worse case test. Note that the bathroom shown on the right in Figure 27 would typically have reduced signal strength due to the additional distance from the hallway than that of the left patient room. Again, the goal is to striving for 25dbm of SNR in all areas where a device would be used.
Figure 27 RF Design
Cisco's Radio Resource Management feature adds additional RF intelligence into the wireless network by allowing the access point to periodically sample other channels, look for rogue AP's and to take RF path loss measurements of adjacent access points. This information is compiled and passed to the wireless controller which recommends and implements certain dynamic changes to the wireless network. During the sampling of other channels (typically 50ms per channel w/ 10ms for channel change), the access point is effectively off the air and no longer communicates to the wireless clients which it serves. This results in an performance reduction of approximately 1.5 percent.
For infusion pumps, the channel scanning interval is not of sufficient duration to cause any connectivity or throughput issues. In areas where Cisco's wireless phones such as the 7921G or 7925G are in use (during active voice calls), the APs do not channel scan. If you suspect that RRM is impacting the performance of your Smart Pump, it is recommend to either disabling RRM, or use a Cisco 7921G or 7925G phone as a troubleshooting step.
Security
The security model for most biomedical devices will vary widely. Most biomedical device vendors focus their engineering efforts upon the clinical and biomedical capabilities of their device as these attributes are typically the main factors in the purchasing decision; and rightfully so. Due to this fact, often times the wireless and security characteristics of the devices lag that of the industry best practices. Many times, the biomedical or IT staff responsible for the wireless network is not included in the purchasing decision as it is often made based solely by the clinical team.
This approach, more times than not, results in the team responsible for the wireless network to respond after the fact and implement the "best" security mechanisms available by the vendor—often not meeting the healthcare systems security mandates on wireless security.
At the present time, the golden standard for wireless security is one based on an Extensible Authentication Protocol (EAP) based on the 802.1x framework. This approach will provide the healthcare system with an authentication model typically employing one of the following EAP types.
Some infusion pump vendors provide a wide array of EAP types that can be implemented. In most deployments, the userid/password credential is unique only down to the implementation of the infusion pump, meaning that one common userid/password is utilized across all infusion pumps.
While both security best practices, and some would argue even HIPAA dictate that a unique userid/password should be used on each infusion pump, the following should be considered before implementing this approach:
•
–
–
•
–
–
•
–
For deployments where the RADIUS servers are located within each hospital, and not centrally located, a unique userid/password should be implemented. In this approach, each serial number and model of Smart Pump would be entered into the RADIUS user authentication database. Using Cisco's ACS, a group for each model of Smart Pump should be created. Within this group, an SSID/VLAN mapping can be specified for each userid/password combination which each map to a unique infusion pump.
Encryption for all biomedical or clinical devices should use WPA2/AES. Because of the relatively newness of WPA2/AES combined with the higher computational hardware requirements, it may not be common to some biomedical devices. See Figure 28.
Figure 28 Security Design
The problem with using lower complexity-based cryptographic technology with wireless is that it is impossible to determine if data is in fact being captured. Such data may not be able to be decrypted using technologies readily available today, but in the future may not protect such data as higher computational capabilities as found in GPUs and advanced mathematical techniques evolve.
For highly secure wireless transmissions, National Institute of Standards and Technology (NIST) WPA2 using AES is recommended. Given the current computational capabilities available to the general public, NIST recommends using key lengths as follows:
2006 - 2010
80 bits
2011 - 2030
112 bits
2031 -> Future
128 bits
NIST recommendation for key management can be found in the following document:
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
In the event that the data is to remain secured past that of the useful life of the recommended key, NIST recommends that the next higher key length be used. It is recommended that AES-128 be used to provide a level encryption to protect PHI data up to 2031. After such time, implementing AES-192 or AES-256 would be indicated.
Co-Existence Issues w/ other Biomedical Devices
Often times, a healthcare system will have a wireless network deployed with CoWs or Workstations on Wheels (WoW) supporting CPoE or a medication administration system. Over time, the next large scale rollout may have been a voice deployment using any number of VoIP wireless handset vendors. The next challenge is typically either a large number of 802.11-based wireless infusion pumps and/or high acuity patient monitoring.
The challenge facing many IT directors and their staff is—what will break when 500 or 1000 infusion pumps are rolled out over the course of a few months? Will the sheer number of problems, authentication request and data traffic negatively impact the existing wireless devices?
In the reverse direction, often times there is concern as to whether or not the existing devices, perhaps generating large amounts of multicast or broadcast traffic, will impact the infusion pumps.In most, if not all cases, the deployment of a large number of Smart Pumps will not negatively impact the wireless network or other wireless devices already on the network.
Most implementations of Smart Pumps create a unique WLAN/SSID to isolate the pumps from the other wireless devices. While doing so may shield the Smart Pump from L2 broadcasts, it would not eliminate a performance impact if one existed as the channel itself is often shared.
A new trend is emerging where biomedical devices are grouped by SSID based on their security model. Devices that can use more advanced methods of authentication and encryption are placed on one SSID with other similarly capable devices.
Medical devices that cannot use such advanced methods of authentication and encryption are similarly grouped onto another common SSID for such devices. These devices are often safeguarded from accessing the wider network through the use of firewalls and access control lists (ACLs).
Older devices that are not capable of dynamically adjusting their power output may generate co-channel interference, especially in the 2.4Ghz band. However note that Smart Pumps do not generate large amounts of data during their use. Only during formulary and firmware updates does their data usage typically spike. These spikes can last a few minutes at most in a typically environment.
During this time however, if a wireless network was designed with cells of varying sizes, a Smart Pump that is not capable of matching the AP's transmit power levels would remain at a constant transmit power level. In the smaller pico cells, the condition might arise where the pumps signal reaches a cell one hop removed which shares the same channel.
Since many biomedical devices cannot adjust their power as directed by the AP, it is recommended that the use of Pico cells on patient floors be avoided in order to reduce the likelihood of co-channel interference.
Traffic Patterns
Highlighted earlier in this section were the typical end systems that Smart Pumps need to communication with. From a data throughput standpoint, both formulary and firmware updates are at the top of the list. In one observed formulary update, data transmissions bursted to about 40kbps for a a duration of approximately 2 minutes. See Figure 29.
Figure 29 Traffic Typically Generated When a Clinician Initiates the Delivery of Medication
The Smart Pump will communicate the delivery of new medication, dose rates and alarm events to the EHR through their Information Center application. During this time, the data sent is a relatively small amount of data as shown in Figure 30.
Figure 30 Data Transfer
In the event that connectivity between the Smart Pump and the vendor's information center application is disrupted, the pump will locally alarm for events requiring immediate attention, and will locally cache the other events until connectivity is restored.
Vendor SLA Requirements
•
•
•
HIPAA / FDA Concerns
With regard to patient privacy, some vendors Smart Pumps contain information that would be classified as PHI and as such all data transmissions between these Smart Pumps and the specific vendors information center application should be encrypted as directed above.
Because there are so many vendors and models of Smart Pumps available on the market, its difficult to provide guidance that is 100 percent accurate for all devices. Some of the areas of investigation should be as follows:
•
•
•
•
•
Patient Monitors
A patient monitoring system provides real-time monitoring of physiological "vital signs" data from patients. Typical types of physiological data are the following:
•
•
•
•
This provides for a mission-critical, real-time system that operates continuously without interruption. Residing on the clinical network are patient monitoring systems (bedside devices and central stations) and telemetry systems that alert clinicians to potentially life threatening situations. Unlike infusion pumps that do not mandate continuous connectivity to the network, patient monitors rely on "always connected" access to the network report the real-time vitals information back to a central station. See Figure 30.
Figure 31 Bedside Patient Monitors
Medical devices are embedded systems, that are controlled by the device manufacturer. A key design principle for medical devices is to keep them as reliable as possible by reducing the number of unnecessary variables. By implementing only those features that are required by the product, a higher degree of product stability can be achieved. To a certain degree, this has balanced the development cycle of devices, where it is possible that certain L3 routing functions may not be developed on certain medical device platforms.
Due to this approach, some vendors require some network segmentation for their products to work on a campus network. This often manifests itself into special requirements where a particular device platform requires L2 adjacencies to function on the network.
Generally, device life cycles are long (7 to 10 years), and some networked medical device systems include software that was designed to operate on these L2 private networks. However, some, patient monitor vendors today support L3 routing and advanced multicast features that make it possible for devices to co-exist on a converged IP network.
Some of the main vendors and products in the patient monitoring space include Philips Intellivue, GE Dash, Draeger Infinity, and Welch Allyn Propaq. These vendors support both wireless and wired deployments as part of their overall architecture.
A typical patient monitor system consists of the following components:
•
•
•
Patient/Bedside Monitors
Family of devices that enable review of vital patient data and clinical decision support. Most vendors in this space support wired Ethernet and/or wireless 802.11 connections.
Patient Monitor Central Stations
Central monitoring stations provide multi-patient waveform and parameter displays, alarm annunciations, and analysis from the patient monitors connected to it.
Database Server
The database server provides short-term data storage for patient monitors. Data for monitored or telemetered patients can be stored, managed and transferred via database servers.
Patient Monitoring Operations
As mentioned previously, the standard implementation of patient monitor systems differs greatly depending on the particular vendor implementation. Vendors tend to fall into 3 basic types of implementation.
•
Patient monitors and centralized stations reside on their own L2 subnet. Patient monitors associate to a central station using broadcast methods and do not allow routing between subnets. In some cases, the vendor also requires that the network be completely dedicated for the patient monitoring application. This reduces the risk of system performance interruptions caused by other devices residing outside the subnet.
•
Patient monitors and centralized stations operate over a L3 routed network. Patient monitors associate to a central station using multicast methods which allows for allow routing between subnets.
Multicast is used for IGMP joins and L3 waveform distribution and general topology, and care group association used for "overview" functions. The "overview" session is a window displayed at the bedside that shows the real-time waves, measurements, alerts, etc. for another patient. A user can request an overview session or can permanently configure an overview session.
Unicast traffic can also be used for connection messages for device type, serial numbers, and equipment labeling.
Multicast for IGMP joins and L3 waveform distribution and general topology, and care group association used for overview session:
•
Devices may operate within a simple routed environment but may have limited multicast functionality or have central stations or database servers that may not be routable. Also, the devices may use a combination of multicast and unicast to operate properly on the network. For example, multicast may be used by the patient monitor to discover the central server, and use unicast to send the wave data to the central station.
Traffic Patterns
Discussed earlier in this section were the typical end systems that patient monitors need to communication with. As noted, patient monitors typically communicate to the centralized information centers/servers and/or multicast out to other patient monitors. It is important to understand the basic functionality of patient monitors traffic patterns and initialization sequences and to understand this impact on wireless connectivity.
IP Addresses
Patient monitor devices use either DHCP, Bootp or static address as methods to IP address assignment.
Initialization Central Server Discovery
If a central station is required in the vendor's patient monitoring system, the bedside monitors are required to execute a central station "discovery" process. This process involves the patient monitoring sending information about the device (i.e., MAC address, station ID, etc.) over a multicast address or broadcast address. Once the central station receives this information, an acknowledgement message is sent back to the new device, and included in the central station group association.
Steady State Operation
Once the device is associated with the group, steady state operation is achieved. During this time, there are two basic methods that the majority of patient monitors will use to advertise their patient data.
•
In this centralized server model, patient monitoring devices communicate directly to a centralized server. Patient monitors send patient vital signs data directly to the server. The server hosts this vital signs data for distribution to other patient monitors that can view patient data within the care group. Devices are typically managed in "association groups" that have been defined at the central station. The concept allows any bedside monitor within the association group to view other monitors also in that group,
Multicast is typically used to distribute this data. Each patient will be assigned a multicast address and the vital signs are multicasted over that address. Devices that want to view that patient monitor's information will issue an IGMP join to that address.
•
In the peer-to-peer model, individual patient monitors act as both multicast receivers and senders to view data of other patient monitors.
Figure 32 shows a sample exchange for a centralized server vendor implementation. Figure 32 shows the details the flow exchange between a bedside patient monitor endpoint and the central station over a router.
Figure 32 Centralized Server Implementation Example
RF Design Considerations
As described previously, roaming is always the responsibility of the 802.11 wireless clients. If a patient monitor is sticky and clings to an access point, data rates are automatically decreased in order to maintain connectivity. During this time, if the wireless client has a significant amount of data to send or receive, performance of the service area or cell is decreased for all wireless clients within the cell sharing the same 802.11 band. This is due to longer transmission times at the lower data rates resulting in blocking the ability of other wireless clients from accessing the channel.
Patient monitor power level and SNR recommendations vary from vendor to vendor. Generally speaking, vendor recommendations will fall into the requirements shown in Table 2.
As previously discussed, take into consideration the characteristics on newer laptops when performing site surveys. The RF characteristics of newer laptops or external wireless cards may be significantly different than that of some biomedical devices.
Additional RF considerations regarding shared spectrum should be noted. Some vendors allow the use of 802.11a VoIP devices to coexist in the 802.11a patient monitor devices. A particular vendor may only allow the 802.11a (5 GHz spectrum). Since the allocation of RF channels is controlled by country-specific regulations, the 5 GHz spectrum is defined as all the channels available to 802.11a devices for the WLAN infrastructure's given location.
In this case, the network must be configured to managed the access of the 802.11a devices (PMs and VoIP phones) both on the uplink and the downlink so that an adequate amount of bandwidth is available for PMs. Here, the WLC and Wireless Control System (WCS) are required.
Deployment entails operating in the unlicensed spectrum with other wireless devices in a non-deterministic contention environment. Careful deployment of 802.11 client devices within the RF space and proper configuration of the WLAN (WLC, switches, APs) must be made to ensure that patient monitors have and maintain access to the WLAN at all times.
The 802.11a spectrum has more capacity by means of a higher number of channels relative to the 2.4 GHs ISM band, typically less co-channel interference and fewer client devices. Here, the medical devices and mission-critical devices can be deployed in the 802.11a band, and data/IT devices can be deployed in the 802.11g band.
RF Site Survey
Complete an RF site survey prior to deploying wireless patient monitors. A complete new site survey in the 5 GHz spectrum across the bands (one measurement in each channel is required) will ensure that the parametric requirements are met across the desired coverage area,
RF Spectrum Analysis
Using an RF spectrum analyzer, verify that the 802.11a RF space within the targeted coverage area is clean and free of interference. Verify that there is no interference across multiple channels. No Interference is defined as any narrow or wide-band signals in the pass-band that are not treated than the 3db above the measured noise floor. A minimum of three measurement should be taken across the entire band.
Signal Strength
Vendors will differ in the minimum signal strength required within the RF coverage area. Some vendors require a signal strength of -67 dBm as measured across the UNII.
SSID Considerations
Most vendors advocate the use of a dedicated SSID mapped to dedicated VLANs. The ESSID used for 802.11 wireless devices generally should be broadcast.
Most implementations of patient monitors create a unique WLAN/SSID to isolate the monitors from the other wireless devices. Figure 33 shows a sample vendor implementation that supports L2 connectivity only. Two independent subnets for two separate patient monitor networks with no routing are used. A common wireless infrastructure is used, but patient monitors must be on their own L2 segment.
Figure 33 Sample SSID Assignment Using two Subnets
In another example, a common wireless infrastructure is used, and patient monitors are being routed which allows the monitors to be on different subnets. The routers are used to route unicast and multicast traffic between the bedside subnet and the rest of the patient monitor network. All of the other segment devices still need to be on the same subnet as shown in Figure 34.
Figure 34 Common Wireless Infrastructure
Co-Channel and Multifloor Separation
The 802.11 infrastructure should generally be greater than 25dB of co-channel separation with the RF coverage area. When deploying the WLAN across multiple floors, floor-to-floor separation is required. Configured channels should be staggered across adjacent floors such that the same channels are not configured for use on adjacent floors and the required co-channel separation is maintained.
IP Address Changes
For most vendor implementations, patient monitors support use of DHCP or BOOTP protocol for obtaining an IP address.
In a Cisco WLC deployment, client IP addresses do not change when they roam within the same mobility group. WLC deployments support client roaming across APs managed by one or more WLCs in the same mobility group on the same or different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the WLCs allows the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active.
Security
The security model for most patient monitors will vary. Most biomedical device vendors focus their engineering efforts upon the clinical and biomedical capabilities of their device as these attributes are typically the main factors in the purchasing decision. As a result, often times the wireless and security characteristics of the devices lag that of the industry best practices. Many times, the biomedical or IT staff responsible for the wireless network is not included in the purchasing decision as it is often made based solely by the clinical team.
Authentication
Although the golden standard for wireless security is one based on an Extensible Authentication Protocol (EAP) based on the 802.1x framework, most patient monitors do not support this authentication model (at time of writing). Most patient monitors surveyed were based on a combination on the following:
•
•
•
Note that the methods of supported authentication methods may vary from vendor to vendor. Most of the top vendors do support WPA +PSK, so there is a degree of higher level authentication.
Encryption
Patient monitors that use WPA-Personal utilize TKIP for encryption while devices support WPA2-Personal use AES-CCMP for encryption. This offers an adequate level of encryption and enable the SSIDs to remain secure in line with best security practices for enterprise class networks.
Co-Existence issues w/ other BioMedical Devices
Most patient monitor implementations recommend a separate SSID for each type of vendor biomedical device, In this case, a unique WLAN/SSID isolates patient monitors from other wireless devices. This does shield patient monitors from L2 broadcasts, but will not eliminate a performance impact if one existed as the channel itself is often shared.
Vendor SLA Requirements
Latency and Jitter
A reasonable packet latency time and jitter is expected and should be kept to a minimum across the network. Latency times in excess of 25 to 100 ms between any device devices may cause application performance degradation or unpredictable behavior. Generally, jitter should be no greater than 5%. Latency and jitter times should be measured on an ongoing basis and under various network load conditions to ensure correct application performance
Impact During Connectivity Loss
In many vendor implementations, the patient monitors must stay in communication with the database servers. If the patient monitors lose communication with the Database Server for longer than the defined parameter (i.e., 15 to 30 seconds) the central servers may timeout and revert to local monitoring mode. This will mean loss of monitoring at the Central stations.
Impacts from Outside Interference
During deployment of the WLAN across adjacent floors, floor-to-floor channel separation is required. Configured channels should be staggered across adjacent floors such that the same channel is not configured for use on adjacent floors and the required co-channel separation is maintained.
In order to maintain the high level of network access that is required for patient monitoring, it is important that IT administrators over-provision the network capacity in the areas where patient monitoring is wirelessly connected to the network. These areas should have additional APs deployed to provide added capacity such that instances where a high number of devices contend for the WLAN and experience a significant reduction in performance is eliminated.
HIPAA / FDA Considerations
Medical device systems are made up of the system functionality and application software and are regulated by the FDA. Vendors must follow the regulatory specifications when designing those products which includes the software, computers as part of the regulated medical device. In some cases, the network may be included in the device's FDA filing. Hospitals may not deploy devices on a network that differs from the device's network specifications. Check the device manufactures design specifications for details on the wireless network requirements.
Any PHI-Related Data
Protected health information (PHI) is any information in the medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment. The 18 identifiers of PHI can be found at the following URL:
http://www.medstarresearch.org/body.cfm?id=159
A dataset of vital signs from a patient monitor by themselves do not constitute protected health information. However, if the vital signs dataset includes medical record numbers, then the entire dataset must be protected since it contains an identifier. In the later case, AES-based wireless encryption is required.
Mobile Radiology
While 802.11 wireless connectivity is available for portable diagnostic medical equipment, it has not been widely deployed due to the large file size of studies. This may change as 802.11n is more widely deployed and available on radiology modalities. The advantage is to allow various studies to be uploaded to a backend PACS or cardiology systems for archival and diagnostic purposes. This improves the workflow of the mobile clinician, allowing the studies acquired in the patient room to be offloaded from the device as the technologist is executing their examination worklist. In the case of portable digital X-rays, the images can exceed 10MB and a single exam and commonly comprises a number of separate images. The result is a study that in many cases can exceed 100MB. Transferring this to a backend PACS system over a wireless network while the technologist is roaming both horizontally and vertically within the building can sometimes be challenging. In addition to the normal challenges with roaming, limited DHCP support in existing modalities aggravate the problem.
Medical-Grade Traffic Patterns
From a pure traffic perspective, DICOM-based traffic is typically treated as best effort. The studies must therefore contend with other wireless traffic generated in a given 802.11 service area. This is because many portable device vendors do not mark their traffic as mission critical data and hence remain unmarked from a QoS perspective. As Figure 35 shows, traffic spikes in excess of 2.5Mbit/s can result as the acquired study is transmitted to the backend PACS system.
Figure 35 Portable Digital X-Ray Wireless Bandwidth Usage—Spikes in Excess of 2.5Mbit/s
As stated, since most medical devices today transmit their data as best effort, it is not unreasonable to assume that in a poorly designed wireless network, such an upload could cause network congestion and negatively affect other applications which may be critical to patient care. In general, uploads should be treated identically to a batch file transfer and therefore receive best effort service. The TCP/IP rate limiting characteristics of TCP slow start and congestion avoidance mechanisms which are native to TCP/IP effectively rate limit the transfers, as well as allowing the transfer to restart during momentary disruptions in connectivity. It is important to note that some more critical wireless applications, such as patient monitors which do not support WMM or QoS may be contending for network resources. This serves as a reminder that a Medical-Grade network requires advanced planning and consideration.
BarCode Scanners
Bar codes enable quick, accurate data entry. This improves accuracy by reducing the likelihood of human error from manual entry, when combined with appropriate hardware and software improves ease of use, can provide timely feedback since there is no delay from scan to data availability, and improve productivity. Barcode scanners are used for a variety of applications within the healthcare environment. Applications can be grouped into the following categories
•
•
•
•
The first three categories include applications like patient records, billing systems, claim systems, maintenance systems, asset tracking, and logistics. While the first three categories are used as they are in manufacturing, retail other industries improving accuracy, timeliness and productivity resulting in cost savings, the last category is unique to the healthcare environment and not only results in cost savings, but improves patient safety and the quality of patient care. Scanning bar codes prior to patient treatment can alert caregivers to potential errors before they occur preventing the error and avoiding patient harm. Clinical applications for bar coding include blood transfusion verification, prescription entry, ordering medical tests, specimen tracking, prescription drug tracking, patient identification and dietary management. One of the most impactful and widely deployed applications is medication administration verification. This application is used to confirm patient identity, the correct drug, correct dose, correct time, and correct caregiver (trained to administer and monitor for side effects).
Scanners may be categorized as: tethered, cordless, and integrated into handheld mobile computers and PDAs. Barcode readers have been used in Healthcare since the 1980, so legacy technology spans those used for bar code readers over that period. For standalone barcode scanners, there is a significant base of legacy 2.4GHz Frequency Hopping used to connect the device to the CoW running the pharmacy application but the cordless technology currently being deployed is almost exclusively Bluetooth.
Co-Existence Issues w/ other BioMedical Devices
While Bluetooth may interfere with the WLAN in the 2.4 GHz range, the short bursty nature of bar code scans and low power due to the close proximity of the tethered CoW or other computing device limits their impact. There have been reported instances where scanners were transmitting a high power and impacting wireless networks. Having the vendor lower the power corrected the problem. Bluetooth interference may be observed using a spectrum analyzer. Figure 36 and Figure 37 show examples of spectrum analysis recorded in hospitals.
Figure 36 Typical Voice Call
Figure 37 shows a spectrum of voice call as displayed on a Cisco Spectrum Expert.
Figure 37 Bluetooth Pairing
This is typical of a Bluetooth device searching for a device to pair with. This should be a one-time event. As stated earlier, the actual barcode scans should be very brief, low bandwidth events but may cause interference if the device is transmitting a high power. Of more concern would be devices like Bluetooth headsets which transmit for longer periods of time and require more bandwidth.
Clinical Systems
Electronic healthcare systems have two major areas of focus. The first is the financial or the patient accounting side and the other clinical informatics aspect. Due to the global and widespread use of clinical EHR systems on the patient floor, this section focuses on the wireless-related design characteristics of such EHR systems.
There are four major categories that can be used to group clinical EHR systems from the delivery system perspective. It is important to understand that EHR systems from different vendors may use one or more of the approaches outlined below. This is because many EHR systems are comprised of a number of different applications, some developed by different business units within the software vendor, and others acquired through mergers and acquisitions.
Some Computerized Physician Order Entry (CPOE) components from a single vendor, for example, may use a thin client-based delivery system while the medical administration component from the same vendor uses a fat client-based approach. Table 3 provides some considerations for each of these delivery approaches, and it is important to consider the attributes associated with each architectural approach.
Note
Being familiar with the attributes of the specific EHR modules, as shown above or the many others not shown, is key to a smooth rollout onto a wireless network. Many EHR applications were written when the LAN was really the only network topology available for reasonably effective hosting. The next phase of evolution was the WAN, which presented a number of challenges specific to latency, bandwidth, and connectivity disruptions due to congestion.
Typically, EHR vendors which can be hosted across a WAN or VPN migrate very well to a wireless infrastructure. This is primarily due to the application tuning that has been made to the application in terms of bandwidth, chattiness and tolerance of disruptions of service. If a wireless network was engineered properly, and sources of interference have been reduced to a relatively low margin, a wireless network will perform as well as or better than that of a WAN.
RF Design Considerations
With EHR systems that are deployed on wireless tablets, PCs, laptops, PDAs or Smartphones—a large contributing factor to the overall performance—are based on the RF characteristics of the wireless client. Many of these devices have varying levels of RF performance and as a result have very different outcomes depending on the wireless hardware implemented. Receiver sensitive for example, is a major factor. This marks the ability of an RF receiver to detect the 802.11 signal given the receivers noise floor. The better the receiver sensitivity, the better the performance and hence overall availability and throughput.
Another factor is the implementation of the roaming algorithm—roaming at the right time and providing for the optimum stickiness is also key. There are also other aspects that can affect workflow, which include power conservation techniques and QoS capabilities such as using 802.1e and/or WMM.
To achieve a MGN, the set of best practices for a given wireless technology must be employed end-to-end. This not only involves RF site survey aspects and the placement of access points on the patient floor, but also wireless device design, antenna characteristics, redundancy considerations, QoS, RF Spectrum management, authentication, and encryption mechanisms.
Roaming
The decision to roam to a new access point is totally dependent on the wireless client that is making the decision to roam. As a result of a poorly design wireless network, or deployed using a salt and pepper approach, roaming between access points may result in cross-controller roaming. Such cross-controller roaming should be minimized whenever possible in order to reduce roam times.
A wireless deployment strategy that follows a salt and pepper approach is one that allows access points to locate any controller that is capable of providing services. The end result to highly mobile devices that exist on a patient floor, such as CoW/WoWs and wireless PDAs, is excessive cross-controller roaming resulting in potentially poor roam times. Many times, wireless networks deployed in this fashion work fine for voice and clinical applications, but may in fact prove problematic during the rollout or pilot phases of new "less tolerant" applications or biomedical devices.
To enhance roaming, a feature called Fast Secure Roaming (also known as Cisco Centralized Key Management (CCKM)) can be used. The time to roam can be reduced to < 150ms during inter-controller roams, and typically are less then ~100ms. For cross controller roams, this time will increase and for some EHR systems, such disruptions of connectivity can result in the clinical application failing to recover or in extreme cases outright failing.
Note
For environments that utilize EHR systems, or components of EHR systems (CPOE, Medical Administration, Pharmacy, etc) that are not tolerant to such momentary drops, a zoned controller-based approach should be used.
When a zone-based approach is used, access points servicing a given "zone" are configured to use a primary and secondary wireless controller. This approach limits inter-controller roaming, therefore improving roam times. When crossing zones, however, cross-controller roaming will occur and may impact some devices as described above.
Area's such as elevators and stairwells promote an interesting challenge as a wireless client will typically be traversing a number of floors as they move vertically across the zoned floors. For elevators, an approach sometimes considered by the RF engineer is to place an access point in the elevator shaft or hoistway.
In the United States, however, placement of an access point in the elevator or elevator shaft is not permitted by the American Standard of Mechanical Engineers (ASME) code standard. In addition, access to hoistway shafts can only be made by authorized, certified persons. These people are typically not the same individuals who install or survey the wireless network. Exceptions to this rule may sometimes be granted by the local fire safety authority ((Fire Marshall) responsible for the area.
The ASME A17.1, Safety Code for Elevators and Escalators section 2.8.1 states as follows:
"Only machinery and equipment used directly in connection with the elevator shall be permitted in elevator hoistways, machinery spaces, machine rooms, control spaces, and control rooms."
Furthermore, sections 2.8.2.1 - 2.8.2.2 states that as follows:
"Installation of electrical equipment and wiring shall conform to NFPA 70 or CSA-C22.1."... "Only such electrical wiring, raceways, cables, coaxial wiring, and antennas used directly in connection with the elevator, including wiring for signals, for communication with the car, for lighting, heating, air conditioning, and ventilating the car, for fire detecting systems, for pit sump pumps, and for heating and lighting the hoistway and/or the machinery space, machine room, control space, or control room shall be permitted to be installed inside the hoistway, machinery space, machine room, control space, or control room."
The ASME 17.1 code clearly states that devices that do not comply with the regulations cannot be placed either in the elevator or hoistway (elevator shaft). As such, the RF engineer must ensure coverage in these spaces. Coverage is not only a matter of signal strength and quality, but roaming across subnets and possibly WLCs, and is common as the car moves vertically between floors.
It is not possible to characterize one standard foolproof method for ensuring coverage in elevators, as there are many variables to consider. As such, a series of recommendations and best practices need to be implemented until an approach is found that provides a satisfactory level of service for each unique environment and set of wireless clients.
One common technique to provide wireless coverage in elevators is to place a diversity omni-directional AP or antenna directly outside of the doors of the elevators just below the ceiling tiles. For hospitals that are deploying new 2.4GHz and 5GHz WLANs, the Cisco 1131AG or 1142N are popular choices because of their attractive design and downwardly radiating integrated diversity antenna. In challenging RF environments, or when external antenna's are required, the 1242AG or 1252AG are excellent choices providing the RF engineer with the ability to use antennas that provide specific RF coverage characteristics.
In many cases, but dependent on elevator design, a closed elevator door reduces the signal inside the car by 7 to 10 dB or more. This requires that the access point or antenna be just a few feet in front of the elevator doors. To provide fast secure roaming between floors, it is best to have access points that service elevators on the same WLC and to ensure that they are part of the same access point group. See Figure 38.
Figure 38 Access Points Serving Elevators on the same WLC
Radio Resource Management (RRM)
Off channel scanning and other radio resource management (RRM) should not have an impact on workstations and other devices that have enterprise class wireless cards. For some consumer-grade devices, however, the time at which an access point is off the air may in rare circumstances have a negative effect. This is especially true for patient monitor devices which typically send a UDP based Multicast frame every 40ms. These devices typically do not have frame loss detection mechanisms nor are they capable of retransmitting a lost or dropped frame.
Disabling RRM is not recommended for EHR deployments as there are times when a channel change may provide better performance and overall availability over that of not switching to a less congested channel. Furthermore, in order to detect rogue AP's and other security risks, the disabling or altering from default settings may inadvertently reduce the effectiveness of the security capabilities of the overall wireless network.
Note
Security
Wireless security for EHR systems that are commonly based on a Windows operating system should employ an 802.1x EAP-based authentication mechanism as shown in the following table:
In order to comply with HIPAA's requirement mandating that each clinical user is assigned a unique userid/password as a logon credential to the EHR system, it is strongly recommended to extend that recommendation to the wireless network. By using a central directory services repository for userid/password credentials such as Microsoft Active Directory or an LDAP complaint directory service, access to the various systems containing PHI-related data can be controlled.
Some healthcare facilities use EAP-TLS implementations when SmartCards are used in conjunction with Employee badges. By using PKI-enabled smart cards to logon a laptop or workstation, the user can also gain access to the same wireless network using the same physical card. EAP-TLS may however be more costly to roll out due to the added operational costs related to a certificate authority.
Encryption of EHR Systems
For PHI-protected data in motion, as is the case with any wireless network, AES-based wireless encryption is required. A minimum key size of 112 bits or greater (WPA2 AES-128) should be used in order to ensure that the data encrypted stays private for a duration of time in keeping with local regulatory standards. As previously mentioned, National Institute for Standards and Technology (NIST) recommends that data which should remain private until the year 2030 should be encrypted using the AES protocol with a key length of not less than 112 bits.
Note
For a Cisco Unified Wireless infrastructure, this equates to the use of WPA2 AES-128, AES-192 or AES-256 as it is not possible to create a 112 bit key.
Enhanced security is required for all users of PHI information, equating to an enterprise-class security and protection model. The use of WPA or WPA2 pre-shared keys (WPA2-PSK) is simply not sufficient for the protection of PHI information. This means that all acute and ambulatory environments implement WPA2 AES-128 or better using dynamic per-user, per-session encryption keys.
A wireless Cisco MGN includes the following security attributes:
•
•
•
•
•
Telephony
Voice communication devices are essential in a medical environment to maintain communication and receive current information. As the staff in a medical environment is highly mobile by nature, support for voice communication devices over a Cisco Unified Wireless Network solution keeps everyone connected. Voice communication devices can cover a broad range, including data devices such as a wireless PC or a wireless PDA running voice applications. The focus of this section is to further provide information on wireless devices that enable VoIP communication within the medical environment. Table 4 provides the common VoIP communication devices that are seen in a hospital environment. It does not include 802.11-enabled cellular phones that may primarily be used for data access.
Figure 39 Cisco 7921G Phone in Charger and 7925G Phone
At a recent Cisco Enterprise Technical Advisory Board Healthcare Vertical session one of the top issues of concern by the attendees was the proliferation of endpoints. The use and variety of wireless-enabled devices continues to grow because of a variety of drivers, including:
•
•
•
•
•
Given the large variation of devices seen in the hospital environment, some key network considerations must be addressed. Finding a common framework to support variation is a challenge as devices may and will behave differently.
Quality-of-Service (QoS)
In the past, WLANs were mainly used to transport low-bandwidth, data-application traffic. With the expansion of WLANs into verticals like healthcare, WLANs are used to transport high-bandwidth data applications, in conjunction with time-sensitive multimedia applications.
Due to the sensitivity of VoIP traffic to factors such as packet loss, jitter, and delay, the Cisco Unified Wireless Network suite of products supports Wi-Fi MultiMedia (WMM) standards as the framework for the QoS designs. As a range of other wireless devices will also be introduced in the hospital network to support voice, determining the compliance of these devices to the WMM standards helps to create a more stable environment to deliver voice.
Wi-Fi Multimedia
Wi-Fi Multimedia (WMM) has been published by the Wi-Fi Alliance and is based on IEEE 802.11e and. WMM provides for QoS, Power Save, and admission control. Some of the key functions of WMM are as follows:
•
•
Figure 40 WMM Queues
•
•
•
•
For more information on Wireless QoS, refer to the Voice over Wireless LAN Design Guide at the following URL: http://www.cisco.com/go/designzone.
Vocera QoS
VLANs provide a mechanism for segmenting networks into one or more broadcast domains. VLANs are especially important for IP telephony networks, where the typical recommendation is to separate voice and data traffic into different Layer-2 domains. Cisco recommends that you configure separate VLANs for the Vocera badges from other voice and data traffic. For example, VLANs might consist of the following: a native VLAN for AP management traffic; data VLAN for data traffic; a voice or auxiliary VLAN for voice traffic; and a VLAN for the Vocera badges. A separate voice VLAN enables the network to take advantage of Layer-2 marking and provides priority queuing at the Layer-2 access switch port. This ensures that appropriate QoS is provided for various classes of traffic and helps to resolve addressing issues such as IP addressing, security, and network dimensioning. The Vocera badges use a broadcast feature that uses multicast delivery. The use of a separate, common voice VLAN ensures that a badge remains part of the multicast group whenever it roams between controllers. Refer to the "Vocera IP Phone Deployment" chapter in Cisco Unified Wireless Network Infrastructure at the following URL:http://www.cisco.com/go/designzone.
RF Design Considerations
There are many different classifications of wireless clients as discussed previously in this chapter. Since these devices have very different traffic patterns and assumed levels of reliability and predictability, it is important to discuss outside influencers which can negatively affect the reliability of some wireless-based medical devices.
One common example is that of voice traffic. Within a healthcare environment it is critical due to the mobile nature of caregivers and their ever increasing reliance on connectivity throughout the entire healthcare facility. As such, it is critical that the VoWLAN network be architected end-to-end so that high availability can be achieved within the hospital and associated outlying buildings. To provide guidance in the proper deployment of VoWLAN solutions, Cisco has published a design guide that covers 7921G, 7925G and Vocera endpoints. This Unified Communication Cisco Validated Design document as well many others can be found at http://www.cisco.com/go/designzone.
Cisco further recommends that wireless systems be integrated in accordance with the US FDA document, Draft Guidelines for Industry and FDA Staff Radio Frequency Wireless Technology in Medical Devices (http://www.fda.gov/cdrh/emc/).
Proper coverage for voice dictates that there is a 20 percent (2.4 Ghz) and approximately 15 - 20 percent (5 GHz) which is above and beyond WLAN data design guidelines. In addition, the optimal VoWLAN cell boundary recommendation is -67dBm and the separation of cell should be 19 dBM. For voice traffic, a unique SSID should be dedicated for VoIP traffic. Proper site survey is essential to plan for any site deploying voice. In addition to these basic factors, additional considerations include:
•
•
See Figure 41.
Figure 41 APs with 20 Percent Overlap
Roaming
Another very critical factor for voice quality is based on the amount of movement of the person talking. Devices such as laptops may need mobility, but once in use the likelihood for movement drops. However, Cisco 7921G, Cisco 7925G, Vocera badges, other wireless phones and dual-mode phones are highly likely to experience movement. This mobile characteristic drives the need for fast and secure roaming. The client determines when to roam. The client uses factors such as data retries, RSSI, SNR, and other schemes. The network can aid with the speed in which the roaming can occur. Once the new AP is chosen, there is also a need to reauthenticate with the new AP as security must be preserved after the roam has occurred. For fast secure roaming, a method offered through the use of Cisco Centralized Key Management (CCKM) and Proactive Key Caching (PKC) allows a WLAN client to roam to a new AP and re-establish a new session key, known as Pairwise Transient Key (PTK), without having to perform a full 802.1X/EAP reauthentication with a radius server.
IP Address Changes
When a client roams from one AP to another, it may require a new IP address. If a client requires a new IP address, actions that might be required by the client include:
•
•
•
•
In a Cisco WLC deployment, client IP addresses do not change when they roam within the same mobility group. WLC deployments support client roaming across APs managed by one or more WLCs in the same mobility group on the same or different subnets. This roaming is transparent to the client because the session is sustained and a tunnel between the WLCs allows the client to continue using the same DHCP-assigned or client-assigned IP address as long as the session remains active.
Clients roaming without a Cisco fast secure roaming protocol (CCKM or PKC), will typically send a DHCP request asking for their current IP address. In a Cisco WLC environment, the WLC infrastructure will ensure the client stays on the same subnet and can continue to use its old IP address. Next, the client will typically perform duplicate address detection by pinging its own IP address and ensuring there are no replies from WLAN clients using that same address. If a client is running mobile IP or VPN, those protocols would run after the IP address is verified unique.
Security
As stated many times throughout this document, in the healthcare environment, due to the nature of the data being transported (especially PHI), security is critical. Control of the WLAN access relies on the principles of Authentication, Authorization and Accounting (AAA), augmented by encryption to insure privacy. For a more in depth view on wireless security focused on voice see the Voice over Wireless LAN Design Guide. For a more thorough and system focused view of wireless security see the Secure Wireless Design Guide and Mobility Design Guide. All of these documents can be found at http://www.cisco.com/go/designzone.
Authentication/Encryption
Authentication options:
•
•
•
•
•
•
•
•
•
There are a wide variety of devices with varying capabilities on the network that will limit options, but for Voice over WLAN if possible WPA is recommended for authentication and encryption with EAP-FAST as the EAP mode and CCKM for roaming key management. Support for CCKM with EAP-FAST requires Cisco Compatible Extensions (CCX) v3 or higher.
The LEAP, PEAP and EAP-FAST protocols typically require each user in a network environment to be authenticated with a unique set of credentials. However, each badge must have the same security properties so the Vocera Server can automatically update badges when necessary. Consequently, Vocera supports device authentication not user authentication. All badges must present the same set of credentials for network authentication.
Applications such as voice running on client devices require fast reassociation when they roam to a different AP to prevent delays and gaps in conversation. Vocera badges do not support fast, secure roaming so in order to provide fast roaming and a reasonable level of authentication security and encryption, WPA-PSK with TKIP should be used with the Vocera badge (pre-B2000).
With the release of the B2000 badges Vocera added EAP-FAST and WPA-2 support.
Co-Existence issues w/ other BioMedical devices
The traffic patterns of voice traffic are well known (see section below). This is constant rate traffic with no burstness. When designing the network, the bandwidth required for the maximum number of concurrent calls along with the traffic generated by BioMedical devices and other devices (like guest services) using the same access point should be taken into consideration.
Traffic Patterns
There are two sources of traffic with VoIP end devices. The first is the traffic generated by voice calls. Cisco wireless phones have color displays that can be used to provide services on the phone. Standard applications include extension mobility, directories, stock reports, weather reports, and other productivity tools. In the healthcare environment, this capability allows the close coupling of the Cisco Unified Communications system with healthcare specific applications. One example is the Nurse Connect application that interfaces the Rauland Responder IV nurse call system with the Cisco Unified Communications System. This allows the nurse associated with a room to be immediately notified when a patient pushes a call button. They can then call the patient back with a single button press. This is accomplished using XML messages. This is the second source of traffic.
Voice Services
Traffic for VoIP calls is typically steady state, calculated based on the codec used. Two common codecs are G.711 and G.729. Since voice samples are taken at a predefined number of milliseconds, the data rate is constant. For example G.711 sample rates are often 20ms and G.729A is typically 10ms. Another factor for the overall bandwidth is the IP header.
•
•
•
Figure 42 Typical VoIP Call
Application Services
The application traffic consists of HTTP XML messages between the application server and the phone. These messages are typically short and sporadic. This traffic is encrypted at the WLC with the encryption mechanism defined on the WLC. Traffic should be minimal, and provide minimum impact on the wireless network.
HIPAA/FDA concerns
Patient information that could potentially be classified as Protected Health Information (PHI) may be discussed over voice channels and could be included in information exchanged by applications running on the phone. Both voice and XML traffic exchanged with the phone will be encrypted with the method configured on the WLC. As always, there are tradeoffs. For example it was stated earlier in this document that data which should remain private until the year 2030 should be encrypted using the AES protocol with a key length of not less than 112 bits. WPA2 with AES encryption prevents secure fast roaming. Then it comes down to the importance of protecting data for a very long time or possibly dropping calls.
FDA approval is not required for voice endpoints, but may be required for applications running on the endpoint. For the Cisco 7921G specifically, Cisco has listed the 7921G with the FDA for use with what is defined as Hospital Information Systems. This includes nurse call, clinical information systems, financial reporting systems, etc. See the FDA regulations at 21 C.F.R. §§ 862.2100, 890.3725, 892.2010, 892.2020 and the FDA device listing database at http://www.fda.gov/cdrh/reglistpage.html.
Wireless Guest Services
The implementation of a wireless guest network uses a hospital's existing wireless infrastructure as possible to avoid the cost and complexity of building a physical overlay network. Additional elements and functions are needed:
•
•
•
•
Internet Edge Design
New Internet Edge DIG
Healthcare Guest Access Services
Typically, wireless guest access is enabled by using Ethernet in IP (RFC3378) within the centralized architecture. Ethernet in IP is used to create a tunnel across a Layer-3 topology between two Wireless LAN Controller (WLC) endpoints. The benefit of this approach is that there are no additional protocols or segmentation techniques that must be implemented to isolate guest traffic from the enterprise. Figure 43 shows an example of guest access topology using a centralized WLAN architecture.
Figure 43 Centralized Controller Guest Access
A WLC is located in the hospital data center's DMZ where it performs an "anchor" function. This anchor controller is responsible for terminating EoIP tunnels that originate from other hospital WLCs throughout the network. These "foreign" controllers are responsible for termination, management, and standard operation of the various WLANs provisioned throughout the hospital, including one or more guest WLANs. Guest WLANs, instead of being switched locally to a corresponding VLAN, are instead transported via an EoIP tunnel to the anchor controller. Specifically, guest WLAN data frames are encapsulated using CAPWAP or LWAPP from the AP to the foreign controller and then encapsulated in EoIP from the foreign WLC to a guest VLAN defined on the anchor WLC. In this way, guest user traffic is forwarded to the Internet transparently, with no visibility by, or interaction with, other traffic in the healthcare network.
WLAN Controller Guest Access Option
The Cisco WLC Guest Access solution is self-contained and does not require any external platforms to perform access control, web portal, or AAA services. All these functions are configured and run within the anchor controller. However, the option exists to implement one or all of these functions externally.
Supported Platforms
The anchor function, which includes tunnel termination, web authentication, and access control is supported on the following WLC platforms (using WLC firmware version 4.0 and later):
•
•
•
•
Auto-Anchor Mobility to Support Wireless Guest Access
Auto-anchor mobility, or guest WLAN mobility, is a key feature of the Cisco Unified Wireless solutions. It offers the ability to map a provisioned guest WLAN to one or more (anchor) WLCs by using an EoIP tunnel. Auto anchor mobility allows a guest WLAN and all associated guest traffic to be transported transparently across an enterprise network to an anchor controller that resides in the Internet DMZ. See Figure 44.
Figure 44 Auto Anchor EoIP Tunnels
Visiting Physicians
In the simplest model, visiting physicians are given internet access through an assignment of a dedicated "visiting physician" SSID. This SSID is mapped directly to either a restricted VLAN for campus L2/L3 networks or to a dedicated VRF for MPLS environments. Access to clinical resources are limited based on this VLAN/VRF model. VPN access to their home office or affiliated healthcare organization is often granted in addition to general Internet services.
Authentication for this set of users should be one of the EAP types discussed earlier. If using a centralized LDAP based user directory, the visiting physician should use their assigned userid/password. These accounts can be created in the LDAP server directly (with an account expiration date specified). Encryption should once again follow the recommended encryption standard for a Medical Grade Network as it is assumed that the physician will be interacting with clinical systems and patient information. In these cases, WPA2 would be the recommended level of encryption coupled with an EAP-FAST for example.
Contractors
Likewise, contractors and vendors are given internet access through an assignment of a dedicated "contractor" SSID in many cases. This SSID is mapped directly to either a restricted VLAN for campus L2/L3 networks or to a dedicated VRF for MPLS environments. Resources are limited based on this VLAN/VRF model.
Most times, temporary contractors will only require access to their home office, internet services including SMTP based E-mail, and perhaps a limited set of local resources such as network attached printers. Open authentication can be used for these users and guest accounts created on the WLC or ACS servers. If the contractors are involved with the handling of clinical information, their security model would need to be mirrored to that of the Visiting Physician described above. This is to ensure proper authentication, logging and encryption is used.
Patients and Guests
Patients and guests will generally fall into a "Friends and Family" access plan. Most implementations offers a built-in portal that is used to solicit guest credentials for authentications and offers localization branding capabilities. Acceptable use policy (AUP) information and disclaimers are also displayed.
A network administrator can create can create a limited privilege account with the WCS that permits a hospital lobby ambassador access for the purpose of creating guest credentials. Configuration options available through the WCS include Username, Password and SSID. The SSID is mapped directly to the "family and friends" VLAN.
Environmental and Physical Considerations
JCAHO and Infectious Control Risk Assessment (ICRA) Requirements
In the United States, Medicare no longer reimburses healthcare organizations for hospital-acquired patient infections such as MRSA or other such infections. As a result, many hospitals are enforcing the use of Infectious Control Risk Assessment protocols in an attempt to reduce the spread of infections during construction. The installation of cabling and/or access points in many cases falls into the category of construction.
The Joint Commission requires that the Infections Control Risk Assessment documentation be followed for construction projects that include the removal or cutting of ceiling tiles. This documentation (http://www.jcrinc.com/common/Documents/OnlineExtras/PDC09%20Extras/Figure_3-6.doc) requires that certain pre-cautions be used whenever a ceiling tile is being removed.
To prevent the removal of ceiling tiles, the acute-care facility may employ the use of wireless enclosures which effectively eliminate the need to remove a ceiling tile when an AP is being replaced or serviced. Such enclosures should be manufactured to the UL-60601-01 (US) or CSA-C22.2 (Canada) standards which ensures compliance with biomedical safety standards. The enclosures not only provide infectious disease control, but can also provide physical security for the wireless access point. See Figure 45.
Figure 45 Metro Flo 7.4 - 802.11b/g/a/n Enclosure
The Metro Flo 7.4 enclosure shown above provides support for Cisco's 1240 and 1250 series access points supporting 802.11b/g/a/n though the use of a multiband antenna. Other antenna's from such companies as Cisco and MaxRad and others are also supported by Metro. More information about these enclosures can be found at http://www.metro.com/flo.
One often overlooked aspect of the use of ceiling enclosures is the added physical security. Many enclosures, include Metro's Flo 7.4 are lockable, preventing unauthorized access to the AP. This can be especially useful in secluded public areas where physical security is a concern.
Another option to prevent the need for removing ceiling tiles after the cabling has been completed is the use of the drop ceiling T-Rail mounted 1130 or 1140 access point. These access points include integrated omni-directional antenna's, provide 802.11b/g/a in the case of the 1130 series and 802.11b/g/a/n in the 1140.
PoE Switches and Console Cables
The use of Power-over-Ethernet (PoE) switches as opposed to power injectors have an added benefit of providing remote power cycling of an access point. This is accomplished by changing the port on the PoE switch to an administratively down state, effectively removing power from the AP. Using PoE switches to remotely power cycle a problem access point during troubleshooting or during redundancy testing is an excellent method preventing room intrusion and eliminating the need for ceiling tile removal.
Healthcare facilities which deployed Cisco wireless networks a few years ago used the autonomous or IOS based access point. Many times these consisted of the older 1200 series access points which required either rubber duck antenna's, or external antenna's which were "cut" into the ceiling tile with the AP mounted above the ceiling tile. As a result, any maintenance required to the AP using the console port required physical access to the access points. Some of these facilities found it beneficial to run two CAT5/6 cables to each access point location. One was connected to the Ethernet port (yellow cable) and the other would be connected to the console port (blue cable).
This approach allowed the groups responsible for the wireless network to complete 100% of their troubleshooting, software maintenance from the confines of the wiring closet. By coupling this approach with PoE switches and asynchronous servers, troubleshooting and maintenance can be performed from remote locations without the need for physical access.
Distributed Antenna Systems (DAS)
Prior to deploying Distributed Antenna Systems (DAS) or leaky coax systems, it is necessary to determine how such alternate antennas systems affect the collision domain, cell size, cell throughput, and the performance of your applications. It is necessary to know what frequencies, antenna types, and 802.11 radios they support.
When deploying DAS, the access points are centralized in a single location or co-located in a single enclosure or equipment closet. Unfortunately, aggregating access points in one location and using distributed antennas violates several of the technical requirements for optimal WLAN functionality and coverage. When multiple antennas are connected to a single access point, degradation or impairment of most of Cisco's advanced features in the Cisco Unified Wireless Network should be expected because it is impossible to reuse channels to maximize throughput when the access points are aggregated and the channels are shared across the entire antenna system.
In active DAS systems, passive antennas are at the end of regular coax. In passive DAS systems, leaky cable is distributed around the floor. When deploying DAS with the Cisco Unified Wireless Network, the signal strength also decreases and creates poor application performance. The use of a radiating cable or a leaky coaxial type of deployment also leads to performance degradation because this introduces loss in the antenna system on both the transmitter and the receiver. To avoid this situation, Cisco recommends the use of one diversity antenna to a single access point radio. And in the case of an 802.11n radio, the antenna needs to be a MIMO antenna solution. This is necessary to provide better wireless coverage and application performance. Outside of this recommended design, only best effort Cisco TAC support can be provided to customers. Such approaches to the use of DAS systems should be carefully considered given the added risk involved in the overall wireless architecture design.
The Cisco WLAN controllers enable Radio Resource Management (RRM), which provides advanced and automated management capabilities and enhanced performance. RRM allows Cisco's Unified WLAN Architecture to continuously analyze the existing RF environment, automatically adjusting the power levels of access points and channel configurations to help mitigate channel interference and signal coverage problems. RRM also helps to increase system capacity and provide automated self-healing functionality to compensate for RF dead zones and AP failures.
RRM and the Cisco Location solution are designed around antennas with well-defined RF characteristics. The addition of any third-party antenna results in non-standard (i.e., not tested or validated) results. Some RRM adjustments may be required to achieve optimal performance, especially for customers who have deployed the Cisco Location Solution or VoWLAN services. For more technical information, refer to the Cisco Application Bulletin that highlights the limitations of deploying DAS with the Cisco Unified Wireless Network.
The motivations for DAS architectures and the main benefit is the ability to offer services via multiple, discrete wireless systems for more pervasive coverage. Healthcare providers deploy DAS solutions to manage several wireless services, including clinical data, computerized physician order entry (CPOE), paging, public cellular services, nurse-call systems, patient telemetry, and future monitoring applications. The system can also distribute two-way radio for security and maintenance, as well as Wi-Fi and cellular phone access for patients, visitors, and staff. Hospitals are also looking to centralize management of these wireless systems. Hospitals are also delivering Wi-Fi from the DAS architecture to limit ceiling penetration as they may have infection control mechanisms in place, making access above the ceiling tiles cost prohibitive. See Figure 46.
Figure 46 DAS Architecture
DAS Benefits
•
•
•
•
•
DAS Limitations
•
•
•
•
•
•
Note
http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps6973/positioning_statement_c07-565470.html.
Third-party components in a Cisco network are covered by the Cisco's Product Warranty statement found at the following URL: http://www.cisco.com/en/US/products/prod_warranties_item09186a00800b5594.html.
Guest
