By Rick Schrenker
Last month’s article in Life-Science Panorama entitled “Hospitals & Medical Device Manufacturers Address Interoperability with New Standard” discussed the emergence of standards and regulations around communications involving medical devices. The article offered what was to me a surprising claim: “The use of these networked medical devices in a clinical context … will soon be subject to national or regional regulations [and] may not be marketed without evidence of interoperability, that is, they must not compromise the organization’s delivery of health care.”
Having been involved with medical device interoperability standardization efforts for over a decade and watched approaches to the problem and players interested in it come and go as time went by, not much actually surprises me anymore. But it’s quite a leap and a bit of a shock to go from “evidence of interoperability” to “[not compromising the] delivery of health care.” Strictly speaking, interoperability is about the capability of devices to communicate with each other and make use of the shared data and nothing else. Other properties will arguably play greater roles in assuring system integrity, e.g., reliability, usability, maintainability, availability, etc. Interoperability is not synonymous with risk management, nor does it guarantee it.
Still, I agree that draft standard IEC 80001 “Application of risk management to information technology (IT) networks incorporating medical devices” is expected to play a key role in assuring the system integrity necessary to realize the visions that interoperability is expected to enable. But is IEC 80001 sufficient?
“I pose the following to clinical engineers and biomedical equipment technicians: “What would make you comfortable with supporting a request to implement aspects of critical care device functionality on an IT network?” Would being told that the network had been designed and installed according to relevant process and standards be sufficient? Or … evidence that the result of application of the processes and standards addressed functional and non-functional requirements relevant to critical care. How much evidence do you need to support an argument that worst case failure of an ICU monitoring system … could not place a patient, or hundreds of patients, at unacceptably increased risk?” 
It is notable that that the risk management principles of IEC 80001 are largely inherited from IEC 14971, a more general and process-based medical device risk management standard that has primarily been applied to stand alone devices and system from single manufacturers.
“Imagine the implications as medical devices increase their use of and dependence on networked resources, particularly in light of the rate of change and heterogeneity of clinical applications and systems implementations. This begs the question of whether anyone has examined, let alone established, the validity of extrapolating 20th-century medical technology development, assessment, and regulatory practices for the 21st-century healthcare system.” 
There is not enough space here to do justice to addressing the implications of the above, but for anyone interested I recommend the National Academies Press’ Software for Dependable Systems: Sufficient Evidence?, which argues:
“…the pursuit of dependability in software systems should focus on the construction and evaluation of evidence…software is guilty until proven innocent…This approach is…becoming standard in the world of systems safety, in which an explicit safety case…is usually required… …a software system may not be declared “dependable” based
on the method by which it was constructed…Those claiming dependability for their software should therefore make available the details of their claims, criteria, and evidence…The willingness of a supplier to provide such data, and the clarity and integrity of the data that the supplier provides, will be a strong indication of its attitude to dependability”
In other words, for sufficiently complex technology, good process alone is insufficient to ensure safety and dependability. So again I ask: Granted that 80001 is necessary, but is it sufficient?
1. R Schrenker, “Sufficient Evidence – Making the Case for Safety”, Biomedical Instrumentation and Technology, November – December 2008.
Rick Schrenker is the Systems Engineering Manager in the Massachusetts General Hospital Department of Biomedical Engineering. Rick holds a BS and MS in electrical engineering from the Johns Hopkins University. He has served in a number of clinical engineering roles over 30 years at Mass General and previously The Johns Hopkins Hospital. In the medical device interoperability domain, Rick has primarily been involved with IEEE-related efforts and the MD PnP Program (http://mdpnp.org/Home_Page.php). He serves as a co-chair of the AAMI/IT Information Technology Networks Incorporating Medical Devices Committee and is active in the CE IT Community (http://www.ceitcollaboration.org/).
2. R Schrenker, “Learning from Failure – The Teachings of Petroski”, Biomedical Instrumentation and Technology, September – October 2007.
The opinions expressed in this article are those of the author(s) and do not necessarily represent those of Life-Science Panorama, its editor or Axendia, Inc.