IEC 80001—What is that and what does it mean to you? 24×7 has covered this by way of introducing it in a few different articles, and we will continue to do so because it is big. What is also big are the misconceptions about what it is and how it will affect clinical/biomedical engineering departments. 80001 is all about the network. It is also about managing risk—and it will affect you. This week we welcome guest blogger Rick Schrenker, systems engineering manager, department of biomedical engineering, Massachusetts General Hospital, Boston. He offers some straight talk on this topic to help clarify a few points:

Rick says: “Ever see the Jetsons cartoons, with flying cars, Cogswell Cogs, Spaceley Sprockets, and so on? That’s not a bad analogy for what a lot of people are trying to do in order to come to terms with 80001. They see devices on the network like flying cars pulling into a floating McDonald’s. They can’t imagine what their world is going to evolve to, so they attempt to model it in terms they understand, regardless of whether that requires banging a square peg in a round hole. We don’t know what the future will look like, so we envision it as not much different from the present.

Let’s invert the analogy, consider the Flintstones. We know our ancestors didn’t have telephones, cars, TVs, and pterodactyl-powered airlines. Why should we believe that from the vantage point of the not-too-distant future looking back things will look like extrapolations of what they are now?

I believe that professionals in our field need to step back from what they’re doing long enough to consider a network as a new thing unto itself. I doubt very seriously that 10 to 20 years from now the primary use of device-linking networks is going to be to dump data into EMRs. Networks provide the capability to create new things that we could not have as easily created without them, and they do so by enabling me to combine devices to make systems the way I used to combine discrete components to make devices.

When I practiced engineering at the pointy end of the stick, and my technician colleagues practiced their work as well, we learned all we could about devices and components as applicable to our responsibilities. Anybody in this business today not acquiring similar skills in depth about one or more facets of networks because they believe they will get by as a device expert alone is effectively ostrich-izing himself or herself.”

Thanks Rick, and stay tuned to future articles in 24×7 that will help guide departments on implementation. You can also search our site for previous articles on this subject.