Checking Mediocrity

In the January 2005 issue of the MIT Technology Review, Charles Ferguson, the developer of an application that ultimately became Microsoft FrontPage, describes a 1995 conversation he had with Jim Barksdale, then the CEO of Netscape.

Ferguson attempted to persuade Barksdale that to survive, “Netscape needed to imitate Microsoft’s strategy: The creation and control of proprietary industry standards.” Among the methods he identified as commonly applied by Microsoft to exert control over a market was the bundling of new functions into platforms the company already dominates. Ferguson relates this in the context of trying to convince the principals of Google that they, too, need to rely on more than just the technical superiority of their search engine products to survive in the market. He warns that the “best technology does not always win; superior strategy is often more important,” argues that Microsoft is likely to battle to control the search engine market, and closes by saying that “... if Microsoft dominated everything, there would be fewer checks on its mediocrity.”

Recent consolidation in the medical technology market makes me wonder if some of its players aren’t reading from the Microsoft script. Consider the November 2004 Soapbox column (“Patient Monitoring SSAs”) in which GE Healthcare Information Technologies National Service Sales Manager Tom Choweniac’s pitched “software obsolescence protection” (SWOP) by arguing that it “ensures that every software update and upgrade ... is immediately provided upon availability and scheduling [and] that your facility has the latest and greatest features ... [covering] all updates and upgrades, not just patient-safety-related updates and upgrades.” What are the potential implications and consequences of buying into such a strategy?

Adopting and adhering to such a vision effectively turns over responsibility for the ongoing design and implementation of an institution’s patient-monitoring architecture to the contract purveyor. And that, in turn, implies ceding some, if not all, control over future bedside technology choices as well.

Is that really a potential consequence here? Consider Choweniac’s statement that “nearly every device in the hospital needs to provide information to the patient electronic medical record (EMR). With [a software support agreement], you need not worry about purchasing the next ... release ... that provides additional EMR functionality. ...” Left unvoiced is that your devices and EMR must be interoperable, and as of right now, the only way that is done (if at all) is via proprietary interfaces. That being the case, and just as occurs with commercial software, those interfaces will be defined and developed by the architecture provider.

I am not so naïve as to be surprised that a vendor wants to increase market share and lock in customers to long-term contracts; I would, in fact, be perplexed if it were otherwise. And I expect such behavior of all players in the market, not just the one whose views were represented in November. Regardless, if the current strategy carries the risk of limiting a provider’s future medical technology options, what, if anything, can a provider who wants to avoid that risk do?

While clinical engineers do not need to be writing code for medical devices, they should be learning more about software engineering and even formal systems engineering. You can start by Googling the Software Engineering Body of Knowledge, International Council on Systems Engineering, IEEE 12207, IEEE 1220, and concurrent engineering. One of the first things you’ll discover is the importance of getting system requirements right before doing anything else. You’ll also discover the importance of involving the client in defining requirements (such as involving customers long before analysis, which precedes design, which precedes coding—no matter who does it—which precedes implementation, which, of course, precedes support). This implies that it would not be good engineering practice to implement the “latest and greatest features” just because they’re available and ready to be scheduled. More importantly, if providers were to adopt and insist upon good systems engineering practices, the ongoing cycle whereby the manufacturing tail wags the provider dog would be broken, and the source of medical technology demand would more naturally emerge from whence it should: the point of delivery of care.

Rick Schrenker is a systems engineering manager at Massachusetts General Hospital Department of Biomedical Engineering, Boston.