Healthcare is potentially a great environment for Software-defined networking (SDN): Staff and patients are moving all the time, there are many different customer communities with differing data requirements, and security of patient data is crucial. Let's take a brief look at how SDN can help solve problems in each of these areas in a healthcare environment:
Let's start with patient monitoring systems (sometimes called "bedside monitoring"), which require mobility, reliability, and security. Patient data must be reliably delivered to the monitoring control system, even while the patient is moving within the hospital. At NetCraftsmen, we refer to patient monitoring data as "Clinical Life Critical." Reliable connectivity is important while guaranteeing that patient data is kept secure. If patient monitoring data is to be handled on a converged network, QoS guarantees must be provided to protect from congestion loss.
Patient monitoring systems typically specify that a separate network infrastructure be constructed, because the network is considered part of a medical device. However, that creates another network to design, build, and manage, which creates additional costs and adds complexity that frequently compromises the reliability and security of that network. Modern patient monitoring endpoints support both wired and wireless connectivity, and maintain connectivity with the monitoring system controller when switching from a wired connection to wireless, then back to a wired connection. It is also useful if the connections can be reliably and securely handled from any network interface, not just a few pre-specified interfaces located in selected locations in patient rooms, waiting areas, and hallways. In other words, we would like the network to dynamically adapt to the requirements of patient monitoring.
Voice and video communications (and ultimately, all unified communications) is critical in healthcare. UC needs good connectivity and proper QoS to function properly, requirements that are nearly identical to those of patient monitoring. Static configurations work well for dedicated phones, both wired and wireless. However, static identification of voice calls from soft phones running on a computer or a mobile device are difficult to identify. This is the scenario in which the UC controller can tell the network of the voice (or video) call to configure itself to handle the call.
Hospitals tend to be complex organizations, especially research and teaching hospitals. In addition to clinical life critical data (patient monitoring), there are clinical data requirements such as health care records and imaging files that must be handled securely and in a timely manner. Research data must be kept private from internal and external access. Researchers often have their own network connectivity requirements. Patients and their family and visitors desire Internet access. All of these data sources are competing for the same set of network resources. Reliability, security, and high performance are common requirements. Meeting these requirements with a static network configuration is doable, but at the cost of increasing complexity.
One of the key characteristics of an SDN is that the applications and the network can communicate with each other using APIs. The network can ask the application server what it needs or tell the application server that an endpoint has joined the network. Conversely, the application server can tell the network what type of service it needs and what types of packets to allow. By default, most SDN implementations do not allow packets to flow. The SDN controller configures the network switches to perform packet processing and forwarding.
Another characteristic of an SDN is that multiple virtual networks can be created, and the configuration of each virtual network can be delegated to the organization that it serves. A separate virtual network instance (VNI), which may also be called a Virtual Tenant Network (or VTN), can be configured to handle each of several individual networks:
In a patient monitoring system, we want reliability, mobility, and security. The SDN controller detects when a patient monitoring endpoint connects to the network, perhaps by identifying the MAC address or with a more advanced authentication mechanism. Forwarding entries are loaded into the network switches that allow the endpoint to connect only with the patient monitoring controller. QoS markings are applied at the ingress switch port, and high priority treatment is given to the forwarding of patient monitoring data. Bandwidth limits are established at the ingress interface to limit the impact of a denial-of-service attack. The monitoring endpoint can be connected anywhere in the SDN switch network since the SDN controller will automatically identify the endpoint and connect the ingress interface to the corresponding virtual network (VNI). Mobility and security are provided by this functionality. Dynamic application of QoS provides reliable handling of data. Backup forwarding entries in the network switches allow for immediate re-routing if a failure is detected.
Similar functionality exists for UC communications. In addition to fixed phones, the UC controller will inform the SDN controller of calls that involve a computer or mobile device (i.e. soft phones). In both the fixed phone and soft phone case, the SDN controller will then configure the proper QoS markings and handling between the endpoints involved in the call. Bandwidth limits protect the other network traffic from excessive UC traffic and vice versa. Details may be found in the International Multimedia Telecommunications Consortium whitepaper, "UC SDN Automated Quality of Experience Service" (registration required to download the 45-page document).
To address the other virtual network instance cases (clinical data, research networks, and patient/family Internet access), the SDN implementation creates separate forwarding domains that naturally prevent packets from going between virtual networks. And in the case of research networks, the research staff can be given control of the allocation of network resources within the VNI that is allocated to that group. This capability removes the need for a research group to coordinate with a central networking group to put changes within their virtual network into effect.
Security is also improved. The forwarding entries that are loaded into the network switches only allow connectivity from the endpoint to the monitoring system and not the reverse. Endpoints cannot talk with any other system. Only the type of traffic that is expected will be allowed.
SDN offers more flexibility and dynamic functionality than static network configurations. Most, but not all, functions described above can be implemented in a traditional statically configured network. The virtual networks could be implemented using VRF-Lite (Virtual Routing and Forwarding -- Lite) or with MPLS Layer 3 VPNs, but at the cost of considerable complexity and increased fragility (i.e. the easier it is to fail in some way).
Are we there yet? Can we buy SDN products that fulfill the requirements stated above? Check out the Case Study of Kanazawa University Hospital by NEC. It is a very brief document that describes problems similar to those presented above and how they were solved with a new installation of an SDN network. What we need now are more case studies with details of implementations. We need the early adopters to tell their stories and identify what things worked well and how to mitigate problems during the implementation.
Learn more about management and security trends and technologies at Enterprise Connect 2016, March 7 to 10, in Orlando, Fla. View the Management and Security track sessions; register now using the code NJPOST to receive $200 off the current conference price.
