Biomedical Engineering and Healthcare IT

Authors

Dipl. Ing. (FH)

Joachim Hiller and 

Dipl.-Inform. Med.

Timo T. Baumann,

MBA, Landkreis

Göppingen, Germany

Visions for Sustainable Cooperation

Both regulatory and business requirements are driving biomedical engineering (BME) and IT executives to re-think their way of cooperation. Based on our experiences at acute treatment hospitals in southern Germany, we present a vision of an internal medical technology service provider that provides high-quality, cost-effective and sustainable solutions for users and patients. The cornerstones of this are new job roles, an integrated helpdesk organisation, and finding the right balance between standardising processes and maintaining specialist structures.

Legislation Requires Cooperation, Medical and Economic Needs Make it a Must-Have

Typical database applications like cardiac information systems have long been used without taking account of German regulatory reforms, which could lead the manufacturer to classify it as a medical product. As a result, such an application would have to comply with regulations set up for products like a patient monitoring system in an ICU. From the IT perspective, this is wholly new terrain. If a software application is classified as a medical product (MP), only vendor-certified patches can be applied. A non-certified patch would transform the hospital into a vendor, accompanied by the inheritance of liability.

In addition, the DIN ISO 80001 standard requires hospital management to establish a risk management system for an MP. This constitutes additional compliance challenges. For example, an ICU application tracking vital data and medication relies on a conventional IT network. Although the latter is designed with inbuilt industry-standard redundancies, there is no guarantee of 100% uptime. Should the network be down, DIN ISO 80001 requires the presence of a risk coordinator. At the moment, this opens up a glaring question: who will fit such a role, competently?

Rethinking Paradigms for BME and IT

Unfortunately, regulations rarely motivate people. However, it is becoming essential to rethink the way in which BME and IT co-operate: medical services in hospitals require it, and the hospital business needs it, too. Given below is a real-life example from acute treatment hospitals at Göppingen, which underlines the need to think proactively.

The implementation of a digital ECG MP (and its accompanying IT application) demonstrated that the methodology of project- based cooperation, practiced successfully over years, no longer sufficed to create sustainable solutions. Intensive research failed to identify a solution which could be integrated with the existing cardiology information system, with reasonable effort. Usually, vendors offer proprietary applications with their own databases, different user interfaces, a separate DICOM worklist server, and additional HL7 interfaces.

Such an approach in the various fields of MP, from anaesthesiology to surgery, would result in a zoo of technologies. Sooner or later, this would collapse under its own weight. On the one hand, users would face a variety of disparate applications in even a single domain such as cardiology - an evident obstacle to efficiency. On the other hand, BME and IT would also need to invest significantly more and boost staffing for the ever-growing range of IT systems and MP.

To compensate for the lack of industry standards and the inability to currently integrate MP and applications across different vendors, BME and IT executives need to think holistically and create overarching hospital-wide concepts for MP and IT applications. This requires conceiving innovative technological architectures, product catalogues, standard digital archiving procedures, and standardised technical anti-failure plans. Such an approach is not feasible in traditional projectbased cooperation. Instead, it requires BME and IT to join forces and interact, both mutually and with users, in imaginative new ways.

The Visionary Processes: Taking Care of Both BME and IT

To take a deeper look at cooperation between BME and IT, a good starting point consists of the typical problems faced by their users. In the most basic of scenarios, there are (and always will be) ‘classical’ cases, where the issue is clearly either an IT or BME case (applicable to all three phases of operation, plan, build, and run). For example, a defective drug pump is easily identified by the nurse as a BM problem, with no attention sought from IT specialists. In the IT scenario, a user who has forgotten his password for a hospital information system (HIS), or one facing problems with a new SAN storage component, would call IT support, with no requirement for a BM engineer.

However, our experiences at Göppingen reveal a wide range of problems faced by users, which cannot be exclusively mapped to either the BME or IT domains.

For example, when a physician seeks support to retrieve digital ECG records missing from the HIS, it appears at first to be an IT problem. On the other hand, there is a long chain of information processing behind an HIS, any of whose links might provoke the missing ECG data.

At the start of the chain, an ECG is recorded by an MP. This might have failed to transmit the data. Or the fault may lie in the receiving database, a client/server application (to make things worse, this could be a MP or ‘just’ a regular IT application, depending on law and the vendor declaration). From here, a HL7-based communication server transports the ECG documents to the HIS, clearly part of the IT domain, and again one which may have failed. So then, who should respond to the physician’s problem? BM or IT? Or both?

Another example: an operating theatre surgeon’s requirement for technologies to capture and save digital pictures in a patient’s record, and then used by the transcription department in the surgeon’s letter. Here again lies a chain of information systems, starting with the picture-taking equipment, clearly a medical product, with the pictures then transferred to the HIS by HL7 interfaces to the word processors of the transcription staff. So who should take care of this request ? BM, IT, or both?

The Göppingen environment has yielded numerous such situations. Their incidence is expected to rise after the introduction of new MPs equipped with digital interfaces, which require integration with the HIS or other IT applications, in order to benefit from lean workflows and high quality.

Our answer to such a challenge is to simplify the working environment for medical staff by means of a single point of contact for users. This will act as a dispatcher, be it for planning or running systems, to find out what know-how is needed to service a request, and co-ordinate the efforts of all involved in resolving the challenge.

In practice, a single contact point has two major consequences:

Firstly, as far as planning for MPs and IT systems is concerned, all requirements for new technology or changes to existing products and applications should be the responsibility of one job position – proactively supporting standardisation, integration, and sustainable technologies.

The second consequence is related to the run phase. This concerns the implementation of a joint BME and IT helpdesk to receive and dispatch responses to all user problems, including assigning tasks to BM and/or IT specialists and collecting their input. In terms of the case mentioned above, on missing ECG records in the HIS, the helpdesk would firstly engage a business analyst to track the system disrupting the information flow. Should an MP be found to have caused the problem, a BM engineer will be assigned. On the other hand, if a Windowsbased interface service has stopped working correctly, an IT administrator would take care of the issue.

While it is clearly necessary to integrate the work of BME and IT, one needs to account for the sometimes-fundamental (and potentially-irreconcilable) differences between them. These may make it impossible to educate helpdesk staff to efficiently serve as a single contact point and make an early identification of a given problem, as being exclusively or principally in the BME or IT domain.

Our approach to this, to reconcile integration and differentiation, is three-fold:

First: A direct channel for users having an IT problem, such as a dedicated telephone number or email address, or even dedicated staff in smaller organisations.

Second: The same scenario for obvious BME issues.

Third, and most importantly, is the need for a channel to take care for all issues which are not clearly assignable to either BME or IT.

For this, hotline workers with a sound overview of the interoperation of MP and IT applications will be required. Such personnel would analyse the roots of a problem and act as a dispatcher for their co-workers. A closer look at some of the issues and challenges in such a case are discussed later.

The Structural Vision: Merging BME and IT

Building on the workflows above allows us to outline an organisational structure for our vision. A well-known approach for thinking hospital-wide involve interdisciplinary but more-orless loose committees that coordinate IT, BME, an medical departments. In turn, they also contribute to homogenize products and vendors. However, they are fundamentally ad-hoc in nature. Although suitable to take decisions, they have proven to be increasingly limited in inventing (and re-inventing) longterm concepts and approaches.

For such continuity, structural changes are necessary. In our vision, the quintessential change would lie in the form of five job roles which need to be lived by BME and IT (Figure 1).

Starting with the planning phase for MP, applications, and infrastructure, there needs to be an executive with an overarching joint responsibility for both BME and IT who could be called a Chief Technology Officer (CTO). CTOs are, of course, common in large businesses, with the ultimate responsibility for a company’s technological assets and operations.

Furthermore, business analysts are of major importance for all three phases of planning, building, and running. They know business processes well and are experienced with the available functions offered by MP or IT applications. Business analysts specify needs for new functionalities not yet available in the hospital, map users’ requirements to existing functionalities, and are also crucial for implementing solutions as project leaders or application specialists.

The building phase of course requires classical BME and IT roles. BM engineers and IT administrators provide the core, specialised know-how of the two fields.

Last but not least is the need for a helpdesk function within the merged BME and IT organisation. Following the helpdesk process described above, such support functions make use of all the job roles mentioned previously.

For SME-size hospitals whose merged BME and IT teams have 25 or fewer employees, a matrix organisation for the helpdesk would be a flexible way to include the necessary know-how from all three domains: BME, IT, and business analysis.

An organisational chart incorporating the five job roles above is provided in Figure 2. All functions are integrated into one line of reporting. Naturally, this can create the sensitive question: who to appoint CTO.

One obvious approach is to make either the former IT team leader as CTO and the former BME head as vice CTO or vice versa.

This principle of deputising dovetails well into the joint responsibility for BME and IT since vice CTOs cannot act for their domains only, but must always take account of their responsibility for the other field, too.

The Essentials: A Strong BME and IT Governance

Processes and organisation charts will be effective only if they are supported by suitable decision structures. The latter would make it clear who decides on BME and IT questions, purchases, and projects. Following P. Weill (‘Don’t Just Lead, Govern: How Top-Performing Firm Govern IT’, MIS Quarterly Executive, Vol. 3, No. 1, pp. 1 – 17, 2004), we propose the governance model depicted in Figure 3.

Decisions are categorised into three subjects. First, on principles such as a catalogue of preferred technologies or access rights to users of different applications. Second, hospitals need to choose concrete medical products and IT applications from the corresponding market, e.g. a X-ray modality or an IT application for the laboratory. Finally, somebody has to prioritise investments within the given budget frame. Figure 3: BME and IT Governance

Following Weill’s proven and highly-regarded approach, the decisions should generally be made by two decision makers. Starting with principles, this should be the sovereignty of the CTO, together with the general management. MP and IT applications should be chosen by the person responsible on the business or medical side of the subject (typically the head of a department) and CTO. Again, prioritisation of investments should be done by general management and the CTO.

The experiences in Göppingen in the recent years strongly support this governance model for the IT sector.

The Most Important Factor: Know-How of BME and IT Professionals

Finally, processes, structures and governance are only the foundations for the most important resource in the BME and IT business: the employees. In the medieval era, there were universal scholars, proficient in many domains of knowledge like astronomy, and mathematics, and medicine. Without a doubt, this is no longer feasible due to the immense and unremitting growth in know-how in each domain.

Our vision therefore contains no universal BM and IT employee but one who is open-minded regarding both domains – regardless of origin. Such persons would be aware about the intersection of BME and IT and strive to constantly improve their knowledge about such intersections. In turn, this would boost their capacity as analysts and their ability to dispatch support calls quickly. Utilizing another image, we currently see BM engineers with the Leatherman tool on their belt and the IT people with USB sticks in their hands. Our visionary employee would use the latest Swiss army knife, incorporating both knife and USB memory, more ingenious than either knife or USB stick alone, but well aware of what can be done with the knife. The question arises: how is such a ‘Swiss USB knife’ being built. In other words, where are employees being educated in such a way. Starting with academia, our vision shows computer science programmes including elements of BME or vice versa are already available today in fields such as mechatronics. These joint programmes could build valuable know-how for young experts.

In practice, teams are not built from scratch but people need to adapt their knowledge to a changing environment. We believe that employees are able to do so, for example, by sitting in on the other team’s job. There are enough examples of IT employees temporarily join a BM expert to work on concrete issues and vice versa. This is an opportunity with low hurdles, but one which nevertheless requires stamina. Employees will also strengthen their intersection know-how by attending formal courses, for example IT experts studying FDA approval procedures or topics such as galvanic isolation, while BM engineers do the same with regard to terminal services or IT systems interoperability.

Empowering the single point of contact for the customer, in the shape of the helpdesk, is a major element for making the Swiss USB knife a reality. Visionary structures and processes will be the third way of making it real. Ideally, there would be special hotline teams for BME problems and IT issues. All further inquiries, not directly assignable to one of these two domains, would entail the two teams working closely together in one larger room to enable both formal and informal contacts. A less futuristic approach could be a ‘red telephone’ in the BME and IT support offices to speed up analysis of user problems and reach solutions on the inevitable increase likely in intersection problems.

The Way Ahead

The vision introduced above leaves plenty of room for implementation details. It is doubtful whether there are universally fitting ‘best practice’ answers to these details, or ‘best fit’ approaches for each hospital to decide upon. However, decisions will begin to look like. An intensive discussion on the convergence of BME and IT will already prove beneficial to any hospital, its BME and IT teams, and users.