The Future of Connectivity
Having served as a member of the Institute of Electrical and Electronics Engineers (IEEE) 1073 (Medical Information Bus) General Committee for the better part of a decade, I offer the following comments on C. Wayne Hibbs’ article regarding medical device connectivity (“The Future of Connectivity,” March).

Yes, vision is requisite here, as it is to realize the promise of any technology. But I can't accept the implication that providing vision alone is sufficient to overcome the obstacles that have impeded this endeavor for so long, particularly in a field as challenged by complexity as health care informatics. That it hasn’t happened yet should be evidence enough of that. Simply put, the clinical engineering community will need to become more actively engaged in health care information technology development, adding voice to its vision. For clinical engineering to do that, it will need to acquire and learn to apply skills in at least one new domain: software engineering.

Consider how clinical engineering got started. Engineers and technicians had to acquire and apply the tools and domain knowledge of electrical, electronic, mechanical, and biomedical engineering to address the then-critical technology problems facing health care delivery, including electrical safety and equipment management. Because of that, the community gained its initial credibility and voice.

But rehashing the good old days begs some questions for the here and now: Is it possible for clinical engineering departments to acquire software-engineering skills? And even if they can, why should they? What ends justify such means?

Ironically, the major impediments in acquiring the skills are identifying and finding where to get them. The software-engineering community has long recognized that it comes up short in providing the tools and knowledge representations requisite for the emergence of a successful engineering discipline. In “A Tale of Three Disciplines ... and a Revolution” in the January issue of Computer magazine, Jesse H. Poore, PhD, proposes that software engineering follow the leads of other engineering disciplines to include “experimentally validated best practices, standards for product usability and correctness, workforce trained in fundamentals and experienced in standard practice, industry that will employ only qualified workers, and pay for quality work.”

Signs of progress along those lines exist. The use of standards-based, design and analysis tools is becoming commonplace. Schools, businesses, and professional societies offer software-engineering classes. IEEE is certifying software-development professionals, and there are calls in academia and industry to license the developers of software that impacts public safety.

What does clinical engineering and its clients stand to gain from such an extension of capability? Where else might credibility and voice be needed? Patient safety comes to mind. As Henry Petroski, a professor of civil engineering at Duke University, points out in analyzing failure modes that resulted in catastrophic bridge collapses: “Any design change … can introduce new failure modes or bring into play latent failure modes. Thus it follows that any design change, no matter how seemingly benign or beneficial, must be analyzed by the objectives of the original design in mind.”1 If introducing software-based medical devices to equipment management systems isn’t a design change, then I don’t know what is. So, too, is modifying those devices via upgrading their software. Add in integration of these systems with IT infrastructures, and increasingly wireless ones at that. Absent exposure to software engineering principles and techniques, are clinical engineers adequately skilled to provide the requisite failure-mode analyses in the context that exists in a specific clinical setting?

Petroski amplifies the value of the rigorous application of engineering via the history of suspension bridge failures. So many had failed that some civil engineering communities were not only abandoning the design but also teaching that they could not be made stable. John Roebling chose to ignore the standard analyses and instead investigated and addressed the failure modes of prior designs. Among the results of his work is the Brooklyn Bridge.

Software engineers who serve with me on the IEEE 1073 General Committee sometimes ask why so few clinical engineers seem to recognize the importance of or care about this work. That question is not mine to answer. If the community does care, then providing the committee with the community’s vision would be a good first step to answer its question. Providing it with some help in defining use cases and failure modes would be even better.

Rick Schrenker
Systems Engineering Manager
Department of Biomedical Engineering
Massachusetts General Hospital
Boston

Reference
1. Petroski H. Design Paradigms: Case of Error and Judgment in Engineering. Cambridge, England: Cambridge University Press; 1994.

C. Wayne Hibbs responds:
The future success of connectivity is not in our vision, it is in making our vision financially rewarding for the vendors. As much as I would like to believe that good clinical engineers are going to evolve into good software engineers, the US Food and Drug Administration requirements for good manufacturing practice standards in software development for health care products removes that option from the very best clinical engineer or biomedical equipment technician. The legal liabilities of clinical-based engineers adapting vendor's software are no longer acceptable from a risk-management viewpoint.

I agree completely that we all need to be better trained in software engineering so that we can evaluate, identify, and describe the failure modes in clinical-software connectivity, but I do not think that the majority of us will be able to solve these problems without the proprietary software development kits used by the vendors. So our vision is still to make it financially rewarding for the vendors to solve the connectivity issues.