I often engage in discussions with IT Directors, CIO’s, BioMed and CE teams at healthcare organizations worldwide. When the topic of medical device connectivity arises, it’s the point in the conversation where it gets – ah interesting. Points of view between the IT and Biomedical sides of the house are – sometimes aligned, but often there are gaps in the expected roles and responsibilities.
So rewind the clock a bit… back to the early 90’s when IBM had a foothold on its proprietary protocol known (and loved) as Systems Network Architecture commonly known as SNA. The two sides of the house back then were the mainframe group and the PC networking teams that were quickly emerging. The thought of providing end user connectivity to the big iron over something called Thinnet was very controversial in many big blue shops. I often thought that perhaps Thinnet was suffering from a market naming perception problem – but none the less at the time it was thought of as an inadequate transport technology to provide green screen access to the datacenter Big Iron (Yes — I said Green Screen). The general feeling was that the sky fall, on-call pagers would endlessly go off and the availability and performance reports would inevitably point the fingers of blame to the mainframe – something that was simply not allowed to happen!
Forwarding the clock a bit – say mid to late 90’s – the next and potentially the most important wave to date of convergence arrived – Voice. The thought of putting voice traffic on an IP network was believed by many at the time as just crazy. Again, falling skys and lots of dropped and unintelligible calls would result – the networks HAD to be separate. It was the way it was… but slowly over time, voice along with its cousin IBM SNA (both sharing the same sir name of “critical” btw) were riding the same converged network and living happily together.
So nice lead in – but what does this have to do with Healthcare. As an industry, we find ourselves at the same cross roads that seem all too vaguely familiar. And then the question is arises – to converge or not to converge – what should we do? So what’s different this time – is a network that’s good enough for voice good enough for medical devices?
That’s the interesting part – and the time the conversation that I was alluding to gets really engaging. With the need for quality care, clinical efficiencies and ePHI security in mind, coupled with the fact that IBM and the PBX switch vendors of the day did not have regulatory oversight – ah, quite a bit. Take for example an article posted back in 2008 by The Joint Commission, specifically Issue 42 dated December 11, 2008.
The Joint Commission as far back as 3 years ago was calling out that healthcare organizations must be mindful of the risks created by converging medical devices in the world of traditional Healthcare IT. I realize that Healthcare IT is a domain that is wide in scope – but from the standpoint of the network which is unquestionably the foundation – what justifies good enough…
I don’t believe that the challenges involved are strictly contained to an architecture and technology discussion. For most, we have been designing and building networks for healthcare that are highly available, scalable and secure networks for years (cough – okay at least two decades). The real challenge of medical device network convergence is the identification and mitigation of risk coupled with change management and underlying human factors. Most IT teams have the technical knowledge necessary to architect and deploy a network capable of supporting Medical Devices. What I fear however is the lack of risk management skills which are very well honed in that of the BioMedical and CEIT community. Boy I hope the IT Training community are reading this…
The recently approved “voluntary” standard officially known as the ANSI/AAMI/IEC 80001-1:2010 commonly referred to as the IEC-80001 standard is one important step that the healthcare industry is taking to help address risk. Loosely put, the standard describes a recommend framework that Healthcare Delivery Organizations (HDO) can put in place to identify, mitigate and manage the risk of a Medical IT network. As stated earlier, this is an aspect that often times does not come into the work effort of design, rollout and management pure IT based systems. Risk management IS however part of the vocabulary of every BioMedical and/or CEIT engineer, and it is an excellent opportunity for both teams to cross pollinate.
So there is the divide – similar to the convergence discussions of the 90’s. But what can be done to bridge the divide you ask. First, alignment between the various teams within a healthcare system, including the clinical, medical device vendor and IT vendors who either use or are responsible for the overall Medical IT network and supporting components. The HDO or Responsible Organization (RO) needs to drive this as in a converged network. In doing so, the RO will need to allocate some resources to the effort.
Since no two networks are the same and as such I’d suggest that every HDO implement an in-house Quality Acceptance (QA) lab prior to rolling out changes, upgrades and the like. While not 100% fool proof, my experience has shown that the exercise of verifying functionality, practicing an upgrade, back off plan and so forth goes a long way in avoiding events that could result in adverse effects. Having said this, never overlook the human factors that contribute to a service disruption. Often times these are cause by changes to systems that appear to be unrelated but ultimately result in service impact. Again, the IEC-80001 standard can be used to provide guidance in the form of a Risk Manager who would be responsible for the approval of change management.
At the end of the day – convergence of Medical Devices onto a common IT Infrastructure is going to be the norm and less of an exception. Many HDO’s are doing this today, and many others are contemplating it in their future plans. The goal here is to incorporate the aspects of identifying and mitigating the risks that exist on converged Medical IT Networks. As an industry we’ve all done it before and I’m confident that we can do it again!
CCIE 3194, Healthcare Enterprise Architect, Cisco Systems