Jeffrey B. Cooper, PhD

Unless you have been living in a cave for the past few years, you know that the work of clinical engineering is increasingly similar to that of many branches of health care information technology (HIT). There is strong evidence that the specialties are moving closer together. In many health care organizations the two groups now report to the same administrator or senior manager, or clinical engineering reports within the IT organization. Some fear that this trend threatens clinical engineering as a profession and that patients will be the losers if that happens. Is there reason for clinical engineering to be concerned? Will it lose its identity? Or, is this a rebirth? What needs to be done to continue to ensure the safety of biomedical technologies? And, is there something you can do proactively to ease the worry of culture change and put it to good purpose?

As a disclaimer: I don’t have any magic formula nor am I absolutely sure what will make this all work. I’m just offering an opinion based on what I’ve experienced, read about, and learned from the experience of others.

Today, medical devices and the networks on which some operate are primarily computers. Most of the ones that do not now operate on networks soon will, such as infusion pumps, dialysis machines, and ventilators. The primary difference from the computers and applications managed by HIT and those managed by clinical engineering is that the latter are connected to or used directly on patients. Therein lies the differentiator that raises concerns and creates opportunities. Stephen L. Grimes, FACCE, FHIMSS, FAIMBE, vice president, Technology in Medicine Inc, Holliston, Mass, has described HIT as having responsibility for “mission critical” services while CE has responsibility for “life critical” services.1 That difference is an opportunity for both organizations, but it is also the basis for the worry. Are the two services compatible? Will the demand for the standardization of all processes, along with the IT culture that is perceived to answer primarily to the C-suite, include or ignore the biomed culture that answers primarily directly to its clinical clients, the nurses, and physicians? I think it will depend on the organization you live in and equally on how clinical engineering perceives itself and acts politically.

It can be uncomfortable and stressful for different types of people to be forced to live together and share their lives or professional roles. When it happens in multiethnic or religious societies, it often does not go well (ie, the Middle East, the Balkans, Rwanda, and Ireland). Fortunately, IT and clinical engineering professionals do not have as severe a challenge as those. We have a lot in common, yet our differences can get in the way of effective collaboration. We have heard about some instances where it is said to have worked well.2 But in others, I have heard that there is strife and internecine conflict. This should be no surprise when any two cultures are thrown together.

Openly discussing differences and concerns will promote synergy between clinical engineering and IT and enable all to move ahead.

My sense of it is that the biomedical community is concerned about losing its identity and that the result will be less safety for patients. Given what happens when smaller cultures are merged into larger ones, that is not an unreasonable worry. Yet, this is surely a case where helping the change to happen rather than fighting it is in everyone’s best interests. Understanding the cultural differences is critical for any relationship to work well. And work well this one must, no matter what the administrative circumstances. Fortunately, our national and international clinical engineering leadership sees the opportunities and is working hard to build a safe evolution to collaboration.3,4 As that happens, those on the front lines will benefit from taking the long view and see all of this is a great opportunity rather than a threat. That is the reality—this is more of an opportunity than a threat.

Respectful Mergers

Still, the general lesson of merging cultures is that culture almost always trumps strategy. Mergers that do not appreciate culture are at greater risk of failure.5,6 It is dangerous to underestimate how differences in culture can prevent collaboration and progress even when the ultimate goals are the same.

Clinical engineering and IT share much in common: Both have a technology focus, both generally are “left-brained” (more comfortable with facts and plans and processes than with emotions and abstract reasoning—which is a strength and a weakness, of course), and we both seek some degree of rigor in what we do. Project planning and implementation, and service to clinical customers are required core competencies.

What is different? I do not know of a study on this, so I am drawing from my experience and anecdotes, and from writings from some others. The stereotype that CEs often describe is that, having evolved from financial, administrative, and other back-office responsibilities, HIT generally is more driven by business and finance goals rather than by the needs of caregivers on the front lines. The stereotype is likely out of date as IT organizations have assumed more clinical responsibilities, the professionals receive more clinically informed education, and more have clinical backgrounds—although I do not think most have real experience in patient care. HIT organizations do tend to be more process-driven (more rule-bound than reactive to meeting immediate demands for delivering urgent services) than their clinical engineering counterparts. Rather, the pressures on IT come from demands to deliver on new applications, cost savings, and productivity.

Clinical engineering evolved from demands to give clinicians immediate services to meet patient care needs, some of which are urgent. It also historically places a high value on safety, on first doing no harm. These priorities naturally led to a different style. Clinical engineering aims to serve the clinicians and patients first, placing cost considerations below those of safety and service delivery. The personnel are more likely to bend rules that get in the way of fixing a pressing clinical problem. That can cause grief for those responsible for the overall security of the IT systems. And, from the IT perspective, CE professionals can focus too much on the local generation of data and be less concerned with how that data is transmitted for use elsewhere.

Learning to Co-exist

If there is some truth to these stereotypes, a culture clash is to be expected. Of course, both cultures and sets of priorities are essential for the health of any hospital or health care system. So, what will it take for both to co-exist and, even better, be synergistic? The first requirement is to have respect for one another’s cultural drivers. That is easy to say and harder to do. It is the role of the leaders and managers of our organizations to openly discuss these differences, to share the concerns, and then move ahead. We cannot afford to get hung up on it.

As a leader or manager in a clinical engineering organization, you should have been having these kinds of conversations with your staff and your HIT counterparts for the past few years. At Partners Healthcare System Inc, Mass, we began doing that about 10 years ago in our health care corporate and local organizations. We held regular meetings between the senior clinical engineering and HIT managers. We began teaching one another about what each of our organizations does. Several new lines of communication were opened. We’ve talked reasonably openly about areas of conflict. One of the earliest actions was to establish a joint task force to oversee all wireless networks. A clinical engineer with expertise was hired into the IT (or IS) organization and led the task force. That started us off toward learning about our differing needs, processes, and constraints.

About 2 years ago, we brought together groups of staff from various parts of the organization to share experiences. We first shared stories of projects that required collaboration but that did not go as well as they should have (for some, that’s putting it mildly). Using a professional facilitator, we plotted out issues that were getting in the way of our working together effectively. We formed four teams with different goals to work on those. We steadily whittled away at those issues. Depending on whom you ask in Partners’ clinical engineering community, things have gotten better. But, there are still strains. Some CEs believe that they cannot get the respect they need to put a priority on medical device projects that require network connections. Or, some on the HIT staff do not appreciate how the requirements of FDA and medical devices in general just cannot play nicely in the constraints established to ensure network security. The learning goes on, and Partners is very fortunate to have enlightened IT leadership who “get it” and who continue to work to inform their workforce and to find solutions that meet the needs of both organizations.

New Solutions

Recently, Partners has taken steps with some new initiatives including establishing clear communication pathways to ensure responsiveness during critical situations, creating transparency about responsibilities in both organizations for various systems, working together to create diagrams of our systems, and job shadowing to spread the understanding more deeply into the ranks. What I think will be a critical new process is the medical device connectivity review board Partners just created to develop processes and oversight for ensuring the safety of devices connected to the IT network.

With a changing of clinical engineering corporate leadership, it altered the structure somewhat. One important change is the establishment of a medical director of biomedical engineering. One primary responsibility of that person is to oversee the connectivity of medical devices to networks and the development of effective standards and processes to ensure safety as we do that.7,8 That person is an anesthesiologist with real experience in understanding the benefits and challenges of connecting medical devices to networks to enable electronic medical records. He also happens to be one of the foremost world leaders in establishing standards for device network interoperability.9 That he (but not the local clinical engineering organizations) reports to the corporate CIO should give this and other important clinical engineering issues the visibility they need given that interoperability will be one of the most important issues for clinical engineering in the future.

I am not suggesting that this approach is a perfect solution or that the cultural barriers have been broken down in the ways that must be done. These changes have not answered all the questions about how devices will communicate across networks or even how clinical engineering and HIT professionals will communicate with one another. All of this will take time, persistence, and perseverance. Yet, any one of several organizational structures can be made to work as long as the leaders remain tuned into the strengths and weaknesses of both cultures and deliberately work to create mutual understanding and respect. There simply is no other way to ensure that medical devices will be safely and effectively integrated into networks and to achieve the intended benefits to patient care. I hope you will all make yourselves part of the solution by reaching out, understanding the needs of your HIT colleagues, and being willing to change where that is needed. We, and the patients in our health care systems, will all be better off for it.

Jeffrey B. Cooper, PhD, is the founder and executive director of the Center for Medical Simulation, Cambridge, Mass; professor of anesthesia at Harvard Medical School in the department of anesthesia and critical care at Massachusetts General Hospital, Boston; and executive vice president of the Anesthesia Patient Safety Foundation. He recently retired as director of biomedical engineering, Partners Healthcare System Inc, Mass. For more information, contact .

References

  1. Grimes SL. The convergence of clinical engineering and information technology. Chime Annual Meeting, August 2006. www.accenet.org/default.asp?page=publications&psection=presentations. Accessed April 4, 2009.
  2. Muntz D. A continuum of service: Integration at Baylor Health Care System. Biomed Instrument Technol. 2008;42(2):107–108.
  3. Thompson G. The CE-IT community shifts into gear. 24×7. 2009;14(2):18-23.
  4. Glaser J. Interplay between IT and CE benefits patients and hospitals. Biomed Instrument Technol. 2006;40(5):355–356.
  5. Gitelson G, Bing JW, Laroche L. The impact of culture on mergers and acquisitions. CMA Management. March 2001. www.itapintl.com/facultyandresources/articlelibrarymain/the-impact-of-culture-on-mergers-a-acquisitions.html. Accessed April 4, 2009.
  6. Makhlouk H, Shevchuk O. The importance and the influence of the corporate culture in a merger and acquisition context [thesis]. University of Kalmar, Baltic Business School. hik.divaportal.org/smash/record.jsf?pid=diva2:1212. Accessed April 11, 2009.
  7. ASTM F-2761, Essential safety requirements for equipment comprising the patient-centric integrated clinical environment (ICE) — Part 1: General requirements and conceptual model.” ASTM, in press.
  8. Cooper T. IEC 80001 Proactively managing risks. 24×7. 2008;13(7):34-36.
  9. Whitehead SF, Goldman JM. Hospitals issue call for action on medical device interoperability. Patient Safety and Quality HealthCare. Jan/Feb 2009. mdpnp.org/uploads/PSQH_Jan-Feb_2009_MD_FIRE.pdf. Accessed April 11, 2009.