Robots, iPhones, and Windows XP—a personal journey through hospital IT

Hospitals are cutting-edge in the operating room, but their IT is old school.

On the Sunday after Thanksgiving, I rushed my wife Paula to the emergency room at Baltimore's Sinai Hospital. What she thought was just the stomach bug du jour turned out to be a life-threatening condition that would take her to nearly every corner of Sinai. Three weeks later, I would find myself sitting in the surgical waiting room at Sinai as a rock-star surgeon operated on her robotically in front of a crowd of other doctors.

It wasn't my first time wandering the halls of the hospital; 12 years ago, my son was hospitalized at Sinai when he had appendicitis. Much has changed in those 12 years, but what surprised me more is what hasn't.

I've spent a lot of time in the hospital over the past few weeks and have become all too well acquainted with the technology there. I've covered health IT in the past, but there's a big difference between talking with people about what's happening in the health industry with technology as a whole and experiencing it from the chair next to a hospital bed.

Don't get me wrong—I have nothing but praise for the people who treated Paula during her stay. Sinai is not just another hospital, it's the flagship of one of Baltimore's biggest healthcare systems and, while it doesn't have the sheer industrial size of Johns Hopkins, it's a major teaching hospital in its own right. And Sinai's emergency room is one of the best in the city, handling a huge volume of walk-ins and ambulance-delivered patients. But what I found is that medical IT remains a patchwork quilt of Star Trek and steampunk—one that seems to work almost despite itself.

Day 1: Back to the future

Enlarge/ A rolling COW workstation at Sinai may be networked wirelessly, but it still needs an outlet.

Sean Gallagher

When we arrive just after noon, we fly through the ER's triage—apparently so fast that the receptionist checks off a box in my wife's electronic registration indicating she is uninsured. Despite other people taking the information four more times, the insurance information doesn't take until I talk to accounting later.

That is a minor annoyance; a larger one is not knowing what is going on. It's a busy Sunday, and once they give Paula a painkiller and sedative, we see the ER doctor a few times in passing. Having been in an emergency room frequently over the past decade thanks to kids' extracurricular mishaps, I know the drill. But in this case, the only hint at where the diagnosis is going is which test Paula is getting rolled off for next: ultrasound, CT scan, and multiple blood draws.

So I start to poke around, trying to decipher what I can from the tech around me—mostly to keep myself occupied as Paula's sedation and painkillers lull her to sleep. The first thing I notice is that everything but the bed and chairs in the room is wirelessly networked—the Computer On Wheels (COW) workstation, the IV infusion pumps, the machine taking Paula's vitals. And there's a full Wi-Fi signal on my iPhone—the network is accessible with a guest login.

While the wireless network is modern, the computing infrastructure is less so. The roll-around COW workstation the nurses use to enter data—like every other computer I will encounter during the next three weeks—is running Windows XP and a NetWare for Windows network client.

Enlarge/ A wall-mounted PC outside one of the many hospital rooms I spent time in shows its NetWare colors.

Sean Gallagher

Hospitals are notoriously conservative about operating system upgrades, both for financial reasons and because the medical software industry has been slow to certify their applications for newer versions of the Windows OS; the infusion pump management software for the IVs in my wife's room is still available only for Windows 2000 and XP, for example, and the data connector to manage the system's software requires a nine-pin serial port.

The throwback nature of the computing infrastructure applies to the COW PCs and all the other workstations in the hospital as well—nearly every one I look at is a vintage 2006 HP/Compaq small form factor system, and some still have the Compaq OEM Windows XP wallpaper.

Three hours pass. Paula wakes up and asks me what's taking so long, so I go out to try to find an answer. Out in the bullpen of desks at the center of the cluster of ER beds we're in, there's a flat-screen display with a spreadsheet-like status chart for each patient. I deduce from the data on it that Paula is being admitted—a room number pops up next to her name.

But it seems like more hours passed before we see the ER doctor and get the diagnosis: the phrases "big-time pancreatitis" and "worst I've ever seen" are dropped casually.

I pull out my phone to Google "acute pancreatitis." It's not pleasant reading. I call home and tell our kids what's going on as a transport technician arrives to roll Paula off to the elevator.

Bring your own, or wheel it in

Twelve years ago, the general ward of the hospital enforced a cell phone ban. But now, it seems like everyone is carrying one—even the patients. I bring Paula her iPad and set up Netflix so she has some other entertainment beside the basic TV service in her room. (Unfortunately, Netflix was blocked by the hospital's network).

While the hospital staff isn't bringing their own devices to work, the physicians from Paula's primary care provider's practice are. The gastroenterologist, surgeon, and "patient care coordinator" are constantly texting each other with the latest information on the case; the iPhone seems to be their tool of choice.

As of Monday morning, it's looking fairly routine, though the surgeon says Paula's pancreas looks "scary." For now, though, Paula is just under observation, and everything we hear indicates she'll be better soon, aside from needing her gallbladder removed. I begin to dig in for the wait, bringing my laptop to the hospital to try to work while I keep her company.

The Wi-Fi network for guests is isolated from the hospital's general network at the access points—at least the hospital has done a good job of hiding the SSIDs for its internal network. It also has content filtering in place, as I find out when searching for an image for a story I'm writing, and it blocks Flickr as "pornography." I quickly defeat the filter by switching on a VPN connection.

I try again the next day and find that using a VPN connection going to an IP address in Sweden has apparently caused some security concerns, and I'm blocked. (My apologies to any network administrators at Sinai who may have thought Anonymous had infiltrated their network.)

The nurses push COWs into the room to record each round of medication and vital signs measurement, scanning Paula's wristband each time; there's a consistent problem with the barcode reader, and the technicians doing blood pressure and temperature roll their eyes as if this is a common problem.

For all this electronic medical record technology, a surprising amount of paper still gets handled. Every time I see one of Paula's doctors on the case, they're working with a paper chart in a binder, hand-noting instructions—since they're not hospital staff, they likely don't get access to the hospital's EMR system.

There's also some confusion about what exactly the instructions are. On November 30, Paula is told she can start to get clear liquids. But her surgeon quickly reverses that—just after Paula orders up some jello.

Throughout all this, there's not a whole lot of information to work with on our end. Paula is starting to get stir-crazy. The night of December 2, she goes for a CAT scan, posting to Facebook from her phone afterward, "No actual cats are involved in a cat scan. :(" She jokes that Guy Fiere could redeem himself if he came up with a better execution of the barium contrast drink.

The next morning, I am driving my son and daughter to school when my phone plays my wife's designated ringtone. My son picks it up for me: "Hi…he's driving. Oh? OK, I'll tell him. Bye." He hangs up, and puts the phone down casually. "They're moving her to the ICU, she said."

It turns out that there's been much more damage to the pancreas, and some of it has necrotized. Paula's surgeon transfers her case to another doctor who can write orders at the hospital—a young Lebanese surgeon who is an expert in robotic surgery and who has experience in pancreatic surgery. He is also Sinai's "intensiveist" for the week. The move to the ICU is to monitor Paula's condition more closely and bring as much attention and technology to bear on the issue as possible.

90 Reader Comments

A lot of it is the vendors. You'll still see medical programs that aren't validated for anything newer than WinXP so you have to stick with that, or (gods help you) will also run on Vista. We finally got rid of an X-ray digitizer that was that way.

Gods help you as well if you want one of these things to play nice with Active Directory, or to not need to open arbitrary ports straight to the Internet for remote support, because using our VPN client is too hard.

I have asked someone in this business about why it takes so long to update the operating systems of medical devices, and they made mention of the high FDA testing and approval costs. Not only does it cost a lot, but it also takes a very long time. Red tape strikes again!

And you left out one of the most important/confining/expensive issues in Healthcare IT: HIPAA. As the HIPAA requirements continue to evolve, it can slow down vendors and hospitals from certifying and deploying new systems until they know it is in compliance with the latest rules.

My doctor's office has about 10 people on staff. They all use Remote Desktop sessions from thin clients into a Windows Server 2008R2 server where they run their healthcare software. The patient records software, at least judging by the UI, looked recent. They even have a little closet slash server room where they keep a couple of servers and comm gear and a UPS.

It blew my mind. I was expecting malware-laden Win XP machines with 16bit healthcare software on them compiled in VB 4.0 in the 90s, and an Access database backend.

And you left out one of the most important/confining/expensive issues in Healthcare IT: HIPAA. As the HIPAA requirements continue to evolve, it can slow down vendors and hospitals from certifying and deploying new systems until they know it is in compliance with the latest rules.

I didn't get too far into HIPAA here because I was trying to focus on just the experience of a patient and family going through the system. HIPAA is a major reason for the dearth of innovation, to be sure. But it's clear economics play a role as well.

Thanks for the article. I've been quietly laughing to myself for the last couple minutes thinking that the TUG robot would be nearly indistinguishable from the background droids in the early Star Wars movies. Worst part is I'm not sure if Lucas was an extraordinary visionary or if we suck at making robots.

It would be interesting to take this into a series and perhaps interview the IT departments for major hospitals. I would love to hear their wish-list and what they are excited about in the Health IT space. And of course, they probably have some great horror stories, too.

Is there a router that does bandwidth limiting? Ideally the hospitals could just use that and limit you to a certain speed instead of blocking sites.

I believe it may be mored directed towards the staff. While I don't have Netflix blocked, all social sites, games, gambling, etc., are.

Story quote"nearly every one I looked at was a vintage 2006 HP/Compaq small form factor system"

Chuckled a little when that is exaclty what is sitting next to me. I work on the accounting side in a behavioral hospital and I can state that we have the same issues with software. It is a slow process.

I worked in Hospital IT up until recently and I can concur with most of the article. We had a few TUGS that did roam around the hospital. Going to a newer OS does take a long time due to the programs that need to continue to work. Costs associated with getting newer versions prevents faster upgrade cycles. You are more likely to see an upgrade to the back-end servers to hold more data then the front end workstations.

When I left the hospital system was still using XP with a change soon to Windows 7.

I believe it may be mored directed towards the staff. While I don't have Netflix blocked, all social sites, games, gambling, etc., are.

Story quote"nearly every one I looked at was a vintage 2006 HP/Compaq small form factor system"

Chuckled a little when that is exaclty what is sitting next to me. I work on the accounting side in a behavioral hospital and I can state that we have the same issues with software. It is a slow process.

You think the Windows XP situation is bad, it seems like 75% of medical software is written in Java.. and the first thing the vendor tells you to do is disable updates (if they haven't pre-packaged their own ancient JRE).

You think the Windows XP situation is bad, it seems like 75% of medical software is written in Java.. and the first thing the vendor tells you to do is disable updates (if they haven't pre-packaged their own ancient JRE).

I don't recall seeing any written in Java in the hospital environment I worked in. Plenty of .NET stuff though for newer software.

I'm sincerely glad everything went well and they caught the infection early enough to stop it.

Necrotizing infections are no joke. If anyone ever has a wound that starts to turn black, seek medical attention immediately. Your tissue is harboring a bacteria that excretes a toxin to kill more flesh for it to eat and spread into.

It can get out of hand very quickly and is not something to "sleep on and look at in the morning"

I believe it may be mored directed towards the staff. While I don't have Netflix blocked, all social sites, games, gambling, etc., are.

Story quote"nearly every one I looked at was a vintage 2006 HP/Compaq small form factor system"

Chuckled a little when that is exaclty what is sitting next to me. I work on the accounting side in a behavioral hospital and I can state that we have the same issues with software. It is a slow process.

Ah, they should really host two seperate networks then.

The problem is then your hospital employees would just log onto the less restrictive guest network with their iphone/android/etc. That and the guest networks typically have limited bandwidth so you're bogging down the network for everyone. You're better off having a family member/friend bring your device home and add new movies, books, and tv shows to your device now and again.

Funny story, whenever my mother-in-law visits a friend in the hospital she brings a couple of coloring books and a big box of crayons for them. You'd think its a joke but there is something soothing about just coloring a picture when you're stuck in a bed.

You need to read the RISKS list. There is always something new going wrong with fancy, automated hospital equipment. Merely patching the software in an IV pump computer is positively fraught with peril and things regularly go wrong with that sort of mundane maintenance task. Rolling out an entire OS upgrade for all the systems that communicate with and control those little IV pumps (and scores of other devices) is all but guaranteed to cause massive chaos.

And all that paper is there so that if the computer breaks the staff can still keep track of their patients. If there is an outage of any sort, the staff can still refer to their paper charts.

It's easy to point fingers at "too much regulation", but it misses some basic practical points.

Do the programmers that wrote the code for that particular unit still even work for the same vendor? Would they still remember all the important details well enough to not make mistakes years later? Is there any money for the vendor to re-visit a machine that is already years gone by, that still works? Shouldn't they be working on a newer model instead? Would a new operating system still support the older hardware?

I think the problem lies with the operating systems and OS vendors instead, the OS market in general, and the basic premises we have in such a rapidly developing and brand new field of technology.

Vendors who make special equipment need stable, reliable operating systems for the long term. At this point in history, it's obvious what a good hammer is, one you expect to last 20 years or more and never fail, but it is not obvious what a good OS is, and many grave mistakes have been made along the way. Growing pains if you will. We need to learn some long view perspective on this matter.

Frankly, Microsoft and WinXP are consumer grade crap, always have been, and look well set to remain as such. Face it. They never should have been used for critical systems, because they are simply not reliable or robust. No matter how hard MS will sell its junk, there is not and has never been a valid excuse to hang someone's life on the end of WinXP or any other operating system from MS. EVER.

Why did it happen? Because it was cheap, the hardware was cheap, the OS was cheap, and because it was easy and convenient to make bells and whistles happen most of the time. And we were all so enthusiastic that everyone jumped in with both feet. That also meant you had to, if you wanted to stay in business.

But was it full of bugs and unidentified vulnerabilities? YOU BET. And what did MS do to fix that? Some updates, some patches, and eventually abandonment for a whole new windows, namely Vista, and we all know how swimmingly well that went.

I have watched the same tale of woe unfold in the survey industry, where laptops or embedded PC's became the new user interface data storage / handling mechanism. It really landed on the industry about when WinXP became a reasonably practical thing to embed. Cheaper to use a ruggedized laptop with WinXP than some bizarre clunky huge switch board covered with knobs and lights. But don't expect most computers to last more than a few years, nor their crappy operating systems. And if that's a key component of an exotic instrument, then prepare to write that whole instrument off based on the limited life span of WinXP running on a laptop.

This is just not robust technology. It has got lots of jobs done, and the price has been good, and the tech easy, but that is a different thing than being honestly robust. Welcome to the era of disposable technology sold into markets that were used to something better. If we in the IT sector can do something better, I think it behooves us to put these things in perspective and do so. If not, it behooves us to at least tell the truth about the state of the art, and be honest about the implications.

Glad to hear everything worked out for your wife. I've known about the Da Vinci robotic surgery machines for several years now through my work at my former employer (OR-Live, formerly slp3D, formerly Storyline Pictures, now known as BroadcastMed). They performed live broadcasts (which were then made on-demand after the procedure) through their website of various surgical procedures and a large number of them involved Da Vinci systems. You can view them at http://www.orlive.com but be warned if you don't have the stomach for such things: they are pretty graphic, especially the "penile implant" surgeries (yeah, real fun to have to sit and watch as part of your job).

Sean, thanks for emphasizing the "slow drip" of information received by patients and family in hospital.

I had my own gall bladder out a couple of years back. No robot surgery (so I have a nice array of scars now), but overall, the experience was similar. At first they thought it was a heart attack and treated me for that for an hour or so, apparently because I walked in with "sweating and torso pain" as the visible symptoms. Later they got the ultrasound imaging device into play and correctly diagnosed the gall bladder, which meant an ambulance ride to a surgical center. Though I wasn't told of the gall bladder diagnosis until after getting to the surgical hospital.

I can remember repeatedly reminding myself to calm down and take it in stride. It seemed apparent that most of the staff around me were similarly in the dark. Cogs in the machine without any real view into the decision making process until the next decision came down from .... wherever decisions come from in a hospital.

This is a key point: it's difficult for the patient to even know who is in charge of their case from minute to minute. There's no way to know what's coming next, where you are in the process, or even what the process is. You walk into the hospital, and you hand your life over to a murky set of processes that you don't understand. Until they tell you to collect your belongings, "all your decisions are belong to us."

I worked in a hospital developing business applications that managed grant money for researchers. The devs in the research side (Computational Biology & Bio-Informatics) are top notch as were most of the open systems support group. The rest of the hospital IT was early 1990s MS Access databases and way too many support people who's skills were state of the art 20+ years ago. It was horrible with the exception that I was able to learn a TON because everyone else was lazy and just kept the old stuff running. As soon as my skills got better, I jumped ship and have been learning even more every day.

In short, a good place to start your career but it would be easy to get sucked in and never really learn anything new.

The problem is then your hospital employees would just log onto the less restrictive guest network with their iphone/android/etc.

Is that really a problem when employees can just use their cell network?

I'll field this. No if they use their network providers data plan. Yes it's a problem if they are accessing a company owned guest network meant for guests, not employees. I'm kind of in the same situation as I'm running two networks. One is a wired work network, one is a wireless guest network used for clients who need unfettered wireless access as their computers are not configured to the work network (they will get kicked) or don't want to pull a wire to a VLAN connection, which happen to be sparse.

I have to rotate my passwords every so often because as soon as someone requests the password for whomever client happens to be in, I can guarantee that I can watch the number of connected devices start geometrically multiplying over the course of a week or so as the password (pssst...) gets quietly passed around. A look at the wireless logs show's it's all pretty much users smart devices hitting the wireless, despite being told not to. Eventually the connection gets degraded and slow, clients have problems accessing, and I have to rotate the password. It's really a silent game I suppose. I understand not wanting to pay for data charges so milking the company wireless is a win, but I'm not shy about dropping everyone when it's getting abused and the client experience starts to suffer.

I have asked someone in this business about why it takes so long to update the operating systems of medical devices, and they made mention of the high FDA testing and approval costs. Not only does it cost a lot, but it also takes a very long time. Red tape strikes again!

Alternatively, skimp on testing, red-tape, and approval, and people die.

Not all hospitals are like this. As mentioned, legislation, regulation, and medical software/hardware vendors can introduce speed bumps, but much of this may come down to the hospital and its management (personalities, competence, etc.)

What is stopping a properly configured VDI implementation to allow VMs that roam with you? Updating to Windows 7 and leveraging tools like application presentation (XenApp, RDS), application virtualization (ThinApp, App-V), or even MED-V as a fallback for outdated applications? Updating to modern devices?

Perhaps I am just naive, but placing a significant portion of the blame on legislation/regulation/vendors overlooks the actual issue: the organizations and the people and politics behind them. Perhaps the folks at the top are too risk averse for their own good and are ignoring the risks of a decrepit infrastructure. Perhaps the organization is failing and cannot afford newer technologies. Perhaps management does not understand IT or the benefits that come from adequate investment. Perhaps the IT departments do not have adequate resources or knowledge.

Got to play with one of the Da Vinci machines not too long ago at JHU. Not this new Single Site machine, but one of the previous models. The robotics & controls group in the engineering department has a close working relationship with the vendor, and apparently is the only academic group they've given access to the source code. So there are grad students working to hack on neat bits of new functionality, like real-time overlay of X-ray or MRI data to give surgeons superman vision.

I got to use the machine a bit in their lab. Got to pick up some really tiny little toys, put very small rubber bands on top of little targets, fun stuff like that, all with a 3D HUD and my hands in the little scissors-like controller grips. It's incredibly intuitive, felt like there was no learning curve at all. Not that I plan on trying to conduct any operations anytime soon - I'm entirely the wrong kind of doctor for that! :-)

As others have said - Sean, glad your wife was all right! I've been a multi-week hospital "tourist" myself, and like you I found that geeking out about the IT and medical imaging gear was a nice distraction from the fact that my abdomen was in the process of staging a revolt. Very glad to hear your family's story also has a happy ending.

And I didn't realize there were any Ars writers local to Charm City! Has there ever been a Baltimore Ars meetup, or anything like that?

My doctor's office has about 10 people on staff. They all use Remote Desktop sessions from thin clients into a Windows Server 2008R2 server where they run their healthcare software. The patient records software, at least judging by the UI, looked recent. They even have a little closet slash server room where they keep a couple of servers and comm gear and a UPS.

It blew my mind. I was expecting malware-laden Win XP machines with 16bit healthcare software on them compiled in VB 4.0 in the 90s, and an Access database backend.

It all depends on the office, and their IT people. I used to work in consulting and we dealt with a few doctor's offices. One was CHEAP AS HELL. Didn't want to pay for consulting time or upgrade hardware. Consequently, their system was crap.

Another office was more progressive and willing to spend. They had a 2k3R2 terminal server from which most of their staff worked (this was back in 2004-2006 era so that was relatively new still).

I do Hospital IT from a systems engineer side of things, and we are getting ready to move to Win 7. Apps can be a big problem, so most is going Citrix when it can, or if the user base isn't big enough we are going ThinApp (VMware)

Things move slowly because it's all complex and if you screw up a major system, you could cost lives potentially from a Doc not having some critical piece of information.

Our most recent struggle is screen sizes, and our main vendor not being able to handle i think a 1280x860 screen resolution, so it just didn't display part of the patient record. That's a really big deal... could be some really important information that is missing...

So yea, big money makers will get newest stuff, because that is the equipment that keeps the money coming in to run the system, smaller things can be left behind until they cause a problem.

Not all hospitals are like this. As mentioned, legislation, regulation, and medical software/hardware vendors can introduce speed bumps, but much of this may come down to the hospital and its management (personalities, competence, etc.)

What is stopping a properly configured VDI implementation to allow VMs that roam with you? Updating to Windows 7 and leveraging tools like application presentation (XenApp, RDS), application virtualization (ThinApp, App-V), or even MED-V as a fallback for outdated applications? Updating to modern devices?

Perhaps I am just naive, but placing a significant portion of the blame on legislation/regulation/vendors overlooks the actual issue: the organizations and the people and politics behind them. Perhaps the folks at the top are too risk averse for their own good and are ignoring the risks of a decrepit infrastructure. Perhaps the organization is failing and cannot afford newer technologies. Perhaps management does not understand IT or the benefits that come from adequate investment. Perhaps the IT departments do not have adequate resources or knowledge.

Money... and Time. These things are complex and cost a TON of money and manhours to do it right... MS keeps jacking up the cost of doing business, and then you also have to train your staff for the new versions and new workflows... It's not easy stuff even when management DOES understand the benefits...

Ye gods yes. I understand my hospital system wants to avoid the upgrade treadmill and get maximum value from our hardware and software purchases, but our vendors sometimes are out on left field in OS support. We've had many interesting conversations with our vendors about Citrix XenApp 6.5/Windows 2008R2 support with 4.5/2003 support sunsetting. Yes, I'm aware it got extended again, but we're still beating the upgrade wardrum.

Even better is the conversations were having with management about new features they want vs the cost of doing it. Want Cloud provisioning and BYOD? Here's the cost of that software and VDI solutions to make it happen. Reaction usually is YIKES!

And to follow up on other comments: It's not HIPAA that drives up costs or stands in the way. HIPAA can be accomplished with attention to detail. It's simply the hardware/software costs that keep hospitals behind. Yes, they spend obscene money on medical equipment and doctors. But that's the business. It doesn't leave tons of money left for IT. Lot of these new features Ars and others like to tout are expensive ADDITIONAL costs. BYOC requires VDI, and VDI is a whole new level of additional costs on top of our existing app delivery costs (Citrix, Zenworks, etc). Cloud? A whole new layer of software to license and manage on top of our existing software. It may be worth it for the flexibility, but the up front initial costs are not trivial, not to mention our time to correctly implement something like that. And all the while we have to hit it from every security angle we can think of then contract it out to have someone think of the stuff we didn't think of. We'll get there, but slowly.

In 2002 I was still working at a small computer repair shop in California. One of our clients was a dentist, and I got called in to replace a noisy fan in their server. I arrived to find a bizarre sight: an ancient WindowsNT box in a closet, hooked up to a daisy chain of 8 progressively newer UPS's. The receptionist who showed me into the server closet looked at me and said "Under no circumstances will you shut this computer off. Find a way to fix it without turning it off." Fortunately it was a simple fan replacement, though one I'd never done on a live system. After I finished I went and talked to the receptionist.

Turns out, the system they were using to store their patients records and billings was on that machine, and it was a time-limited demo version. It had been installed by an unscrupulous prior employee who had somehow reset the demo limit from 30 days to 300, pocketed the cost of the full version of the software ( nearly $5k) and was later fired for unrelated reasons and disappeared. When they hit the 300 day time limit, a message popped up saying that the software would be locked the next time it was started up. That was 7 years before I showed up, and that computer had been running constantly that entire time. When the UPS began to die, they plugged in another one, and kept adding UPS's as necessary. The dentist refused to pay for the licensing fee, and there was no other software that could read the proprietary database the system used. Everyone in that office was terrified of what would happen if that machine ever stopped working.

I'll field this. No if they use their network providers data plan. Yes it's a problem if they are accessing a company owned guest network meant for guests, not employees. I'm kind of in the same situation as I'm running two networks. One is a wired work network, one is a wireless guest network used for clients who need unfettered wireless access as their computers are not configured to the work network (they will get kicked) or don't want to pull a wire to a VLAN connection, which happen to be sparse.

I have to rotate my passwords every so often because as soon as someone requests the password for whomever client happens to be in, I can guarantee that I can watch the number of connected devices start geometrically multiplying over the course of a week or so as the password (pssst...) gets quietly passed around. A look at the wireless logs show's it's all pretty much users smart devices hitting the wireless, despite being told not to. Eventually the connection gets degraded and slow, clients have problems accessing, and I have to rotate the password. It's really a silent game I suppose. I understand not wanting to pay for data charges so milking the company wireless is a win, but I'm not shy about dropping everyone when it's getting abused and the client experience starts to suffer.

Edit: Clarity on the opening.

Lol I suppose, could just put in a policy saying you can't do that and punish people if they do, if you can figure out employee device IPs. It's just pretty annoying being blocked from sites as a guest.

I have been in Healthcare IT for 14 years now. There is no benefit to pushing the bleeding edge OS. Between training for staff and providers, who are incensed they have to do their jobs, much less anything else, there is no offsetting benefit to the latest and greatest. That said, our WoWs (Calling it a CoW could get you sued by some overly sensitive patient) run XP Embedded and do VDI. VDI runs the wall mounts and as much as I can, everything else. Application updates are a pain, we are a small hospital, but only a two person IT staff. I am cheap. Not meaning I buy cheap, junk. I am thrifty in that I do not buy what we do not absolutely need. When we implemented an EHR and the system requirements were lower than the HIS we were running, I made people fight tooth and nail to upgrade their ~2005 Dell PC's. We rolled out a lot of new ones and I put Thin Clients in a lot of clinical areas, but we still have some very ancient PC's in areas where it makes sense. Money does not grow on trees and bilking patients for all the whistles and bells is not my game. We exist because of Medicare and County taxes and I owe it to those people to be thrifty. And Yeah!!! for Novell, I wish I still had eDir and NAL. Locking down PC's, pushing out Apps, and managing the World was way easier then, than it is now, even with an 2008 R2 AD Controller.

The nurses and techs in the ICU (and in other areas of the hospital, as I see later) are walking nodes on the hospital network. They're all wearing small devices on lanyards around their neck that are actually VoIP communicators from a company called Vocera. They have built-in voice recognition that allows the staff to call each other by name from anywhere in the hospital

Sean Gallagher / Sean is Ars Technica's IT Editor. A former Navy officer, systems administrator, and network systems integrator with 20 years of IT journalism experience, he lives and works in Baltimore, Maryland.