Keisuke Nagase, M.D., Ph.D., is a professor of medicine, healthcare administration, and medical informatics at Kanazawa University in Kanazawa, Japan. He also serves as vice-director in charge of budget/management and director, department of corporate planning for Kanazawa University Hospital. The hospital recently began overhauling its cumbersome network infrastructure by deploying NEC’s UNIVERGE ProgrammableFlow® solutions, a network solution based on OpenFlow technology. With 839 beds and 33 clinical departments, Kanazawa University Hospital is one of the largest and oldest teaching and research hospitals in the country.
SDNCentral: What kind of IT environment do you have at the hospital? What is the rough annual IT spend?
Dr. Nagase: “Our network is essential to the day-to-day business of providing patient care. From electronic medical records to medical equipment, IT is critical for everything in the hospital. The patient management system and billing system are the largest in scale in terms of IT, but everything is connected – ICU, operating rooms, medical equipment. We spend roughly $600M Yen ($6M-$7M USD) per year on IT.”
SDNCentral: What are the major IT problems you have had to solve at the hospital?
Dr. Nagase: “As an educational hospital, we are large and armed with innovative new health care technologies. The problem is, many computer networks have been deployed independently because each medical equipment manufacturer and vendor wanted to simplify the environment around their equipment.
Even daily operations were challenging. Technologies evolve rapidly in the medical field, and doctors often try new equipment. Connecting this equipment to the network involved changing settings and verifying connections, and sometimes even rewiring, putting a considerable strain on the hospital’s budget. A network that requires setting changes and rewiring every time a new piece of equipment is connected cannot be called stable. The other issue was slow reconfiguration of the network due to the processes in place. Adding a new piece of equipment could take 3 months including time to initiate the contract for the add/move/change.”
SDNCentral: Why did you decide to use OpenFlow technology to address these problems?
Dr. Nagase: “We were looking for a more agile solution that had the same or lower risk as our existing network, at the same or lower cost. That was OpenFlow. We did not select SDN as a result of passion for a new technology. Our business is not IT — our system is directly related to the life or death of our patients. Education, research and healthcare are our business.
There was no breakthrough or epoch-making technology in SDN, we believe, but rather an innovation of philosophy. We wanted to be free from any specific manufacturer. We selected OpenFlow because we need it. We consider OpenFlow switches and controllers to be stable.
As you know, many manufacturers are modifying their existing products to be OpenFlow enabled. With such consideration, we felt the stability of OpenFlow switches and controllers to be the same or better than conventional switches, even at their worst. Because the software is simple, it is essentially more stable than our legacy technology. The only exception is if an incompetent person codes the applications running on the controller.”
SDNCentral: How did you introduce OpenFlow to the existing system?
Dr. Nagase: “We added a new general research building to our campus more than one year ago. Each clinical department and its corresponding university department moved to the new building. In the new building, four independent networks were requested to be deployed, and the existing network also needed to be deployed to the new building.
We introduced SDN/OpenFlow in the new building to eliminate complexity of network.
We thought the deployment of SDN to the new building was quite a good opportunity to evaluate SDN. Multiple in-house LANs are required to implement SDN, making the situation a good test case for network slicing with SDN.
By adopting SDN in the new building, we also decided it would be a good test for migration from our legacy network to SDN.
Even if the SDN network failed somehow, the effect would be limited because the new building is connected to the old hospital building and legacy network via a corridor. We concluded adopting SDN/OpenFlow in the new building would at worst be the same risk, same cost.
We integrated the existing independent network using SDN/OpenFlow in the new research building. With OpenFlow, the network within the building was kept simple, and our new virtual tenant networks are merged with the existing hospital network using link aggregation.”
SDNCentral: Why did you choose NEC ProgrammableFlow switches and controllers?
Dr. Nagase: “An NEC network Systems Engineer (SE) understood the deeply unstable situation of our network, and he suggested we use OpenFlow. NEC was the only supplier of production quality OpenFlow switches at the time of our contract, and they have been our partner for many years. The NEC SE built a good relationship with the assistant professor in charge of the hospital information system.
NEC installed two ProgrammableFlow controllers and 16 switches in our new building. It allowed us to install devices one floor at a time and expand gradually and safely. We could manage each department’s LAN without impacting our existing network.
With ProgrammableFlow, the entire network is managed like a large virtual switch, making an independent virtual network. Our OpenFlow switch was implemented as edge (floor) switches. We have full mesh wiring between switches. In the center, the OpenFlow network is connected under the existing L3 switch (core switch) using link aggregation, so as to be configured as a single L2 switch network from L3 switch.
For redundancy, we have two sets of OpenFlow controllers. For OpenFlow switches, we have two sets in center side, two sets in the new building side, and two sets on each floor, for a total of 16 sets. We also have two sets of secure channel switches – in the system operation center and the new building. NEC required only one month to get the new network up and running.”
SDNCentral: How does the SDN network compare in cost and price?
Dr. Nagase: “The acquisition cost of the hardware was almost the same as the legacy network. However, the operational expenses and maintenance cost has reduced markedly. I estimate a savings of 80% on my operational expenses, including reduction in staff hours required to manage the network. We also expect that the price of OpenFlow switches and OpenFlow controllers will be reduced further as a result of competition in the market. Furthermore, with the flexible configurability of OpenFlow, a full mesh configuration is not required, and our next phase will be in realized in less cost per switch.”
SDNCentral: What benefits have you seen from deploying SDN?
Dr. Nagase: “As I’ve mentioned, I’ve seen significantly lower maintenance costs, allowing me to make much better use of my human resources at the hospital. More importantly, I now have the ability to perform moves, adds and changes to my network much faster than before. I can now provision the network after new equipment installations or equipment moves in minutes instead of the 3 months it used to take. This is achieved via ProgrammableFlow, leveraging the OpenFlow protocol, which will automatically connect the equipment to the right network instantly.”
SDNCentral: How is the stability of the new system?
Dr. Nagase: “We are realists, and we were awaiting failure of an OpenFlow switch to evaluate its reliability. That happened in November, seven months after release of the OpenFlow network in our facility. It was a failure of a switch processor. Even though the processor failed, we managed to recover very quickly due to the fast recovery capabilities NEC ProgrammableFlow provides.
Nevertheless, after the failure, we conducted statistical analyses to understand product stability. Because the number of switches is small, the impact of loss of one set seems large. But we found no statistical difference comparing it with a conventional switch. According to information on switch failure rate provided by NEC, NEC’s failure rate goal was 0.1% per month, while what was measured was lower, actually 0.05% per month – a fairly nice survival rate.
Now we are enjoying rapid recovery time and flexibility in a network with reduced maintenance and operational costs. The time for recovery was reduced to seconds rather than minutes with STP, RSTP. We now have flexibility in introducing multiple independent LANs as and when needed by equipment or the medical teams.”
SDNCentral: What other IT priorities do you have for the coming years?
Dr. Nagase: “We would like to introduce 3G and LTE within the hospital. We are worried about the use of mobile phones within the hospital. There is a reduction of output power, and an antenna system can eliminate such interference. We are talking with carriers to utilize such mobile phone systems as well. In the medium term, we hope to merge our IP address space and mobile network using SDN. Once realized, medical equipment or other computers and devices can move not only within hospital but within the home, or anywhere in the active area of your mobile phone.”
SDNCentral: So, what’s your final evaluation of SDN and NEC’s ProgrammableFlow solution?
Dr. Nagase: “I would say that the network has been successfully delivering critical patient health records as well as MRI and CT scan data, reliably and efficiently. With this experience we decided to expand our ProgrammableFlow OpenFlow network to the entire hospital network over the next two years. We also expect to refresh and clean up our IP address space from a chaotic situation utilizing flexibility we gained from our SDN network.
In summary, I would declare our SDN deployment highly successful and would recommend other medical centers take a serious look at deploying SDN and reaping the significant benefits today.”
SDNCentral: Dr. Nagase, it has been a pleasure speaking with you. Thank you for your time!