Guidelines From 80001 : Maintaining a Medical IT Network

Abstract

The art of incorporating medical devices into a general purpose information technology (IT) network, thus creating a medical IT network, is relatively new, but it's being undertaken more frequently because of safety, cost, and operating benefits to a healthcare delivery organization. Maintenance of such a medical IT network may be the core of this article, but is not in the minds of engineers who need to get it up and running, and have to overcome the associated technical challenges. Methods that aim to achieve interoperability, connectivity, and functionality are developed, tried, and tested. But what methods are in place to install and operate maintenance and service activities in the use of medical IT networks?Good practice requires that functional and technical properties of the medical IT network are designed and verified before deployment. The new standard ANSI/AAMI/IEC 80001, Application of risk management for IT networks incorporating medical devices—Part 1: Roles, responsibilities and activities broadens that scope and requires that design considerations should include risks to safety and security as well as to effectiveness. Therefore, maintenance activities throughout the entire lifecycle of the medical IT network should consider technical and functional specifications, especially its safety, security, and effectiveness. And those should be considered in the light of the ever-changing environment in which the medical IT network functions.80001 provides a common framework and language for health delivery organizations, medical device manufacturers, and other IT providers for managing the risks of operating a medical IT network. It does so through two distinct, yet complementary, aspects:The connection of medical devices to IT networks inevitably also connects the two worlds of clinical engineering (CE) and IT, both in the hospital and in the manufacturing and vendor communities. Successful collaboration between the CE and IT communities in projects creating a medical IT network is, unfortunately, no guarantee for successful cooperation in regular service processes throughout the remainder of the life of the network. Both CE and IT departments have roles and responsibilities independent to those for the medical IT network. The pressure of those could and often does cause these departments to drift apart once the initial project ends. That is a hazard to the medical IT network in itself.This article aims to provide insight into and guidelines for the maintenance and service of medical IT networks from the 80001 perspective involving both the CE and IT communities.A medical IT network is created for a specific purpose, has specific characteristics, and fulfills specific requirements. But it incorporates many characteristics typical of general IT networks. In fact, 80001 defines a medical IT network as “an IT network that incorporates at least one medical device.” So, when considering the service management of medical IT networks, it is only natural to look at the methods and processes for managing networks developed for the IT sector, particularly those that are standards-based. The most widely known standards and best practices for IT Service Management are ISO 20000, Information technology — Service management and the Information Technology Infrastructure Library (ITIL).ITIL is a collection of best practices for IT service management. Its roots date to the 1970s when the need for organized and efficient IT service management was first recognized. The ITIL documents are best practice examples, which were first published in the late 1980s and early 1990s.(1) ITIL V2 was published in 2000 and regrouped the original 30-plus books into eight logical sets that address different aspects of IT service management. The two best-known sets are Service Support and Service Delivery. In 2007, with ITIL V3, the contents were updated to better reflect the current view on integrated management and its structure was also revised into five volumes. The core volume of ITIL V3 is ITIL Service Strategy that uses three lifecycle processes: ITIL Service Design, ITIL Service Transition, and ITIL Service Operation. The fifth volume contains best practice guidance on ITIL Continual Service Improvement.2There are a few specifics to be understood with ITIL. First, although an organization can adopt the practices described in ITIL, it can never claim compliance to ITIL; there are no requirements. Second, ITIL should be aligned to the business needs of the organization at hand. Take, for example, incident management (“processes designed to restore agreed service to the business as soon as possible”). ITIL suggest the use of a single point of contact (a service desk) to play a key role in the incident management. Aligning it to the business need in this example should help establish the means of contact when nurses or physicians customarily go through the clinical engineering department when they have technical issues. Finally and especially in ITIL V3, emphasis is placed on service management as a lifecycle activity. IT should be designed, handed over, and operated according to the service requirements of the organization. This lifecycle approach is also key to 80001, and these parallels are anchor points for aligning that standard and service management processes.Like ITIL, ISO/IEC 20000 Part 1 promotes the adoption of an integrated process approach to effectively deliver managed services to meet business and customer requirements. ISO 20000, however, has requirements in place for IT service management making it possible to objectively show compliance to it. ISO 20000 distinguishes five related service management processes: service delivery, relationship, resolution, control, and release. ISO 20000 also has a Part 2 which does not contain requirements but provides guidance per subsection for organizations seeking to comply with it. ISO 20000 was written with ITIL V2 already out, yet it is independent of it. ISO 20000 strictly limits its attention to service management and only includes supporting processes when they directly affect service delivery. It incorporates a lifecycle view of plan-do-check-act in a section with management requirements.Annex D of 80001 provides an overview of terms and sections that relate to ISO 20000. The implication is not that compliance to ISO 20000 automatically entails compliance to 80001, but it does suggest that it's possible to harmonize process requirements from IEC 80001 with ISO 20000-based processes.Although ISO 20000 and ITIL are often used simultaneously or considered to be closely related, there are differences between the two, found in some of the terms used, the grouping of topics and in the scope (ISO 20000 is ITSM only). But if you run your ITSM according to ITIL, it will be relatively easy to achieve compliance to ISO 20000. However, ISO 20000 compliance can also be achieved without using ITIL at all.One can also see differences between IT service management and medical device management in the light of their pedigree. Take the words “incident” and “incident management” as an example. An IT-related incident is independent of its effects. For example, forgetting your login code is referred to as an incident. An incident in the use of medical devices is generally associated with serious consequences to the patient. Although device failure or, comparable to the example, forgetting a start-up code is undesirable, it is not recorded as an incident, but as a request for service. IT service management assumes, almost by definition, that an underlying problem causes multiple incidents. In medical device management, it is generally the device that is both afflicted and holds the source of the failure, making it uncommon to separate processes that handle service calls (incident management in IT is restoring to business as usual) from processes that handle the cause of the service call (problem management in IT).Lastly, note that the impact of the ways in which the IT and CE professional domains developed can lead to unintended confusion. Consider the key term “risk management,” which in 80001 is different both in goal and method to the risk management book in ITIL. Another example could be the use and understanding of the term “monitoring,” which in 80001 is related to monitoring of effectiveness of risk controls, but in IT service management is often seen as a software tool to continuously monitor IT network performance.Connecting medical devices into an IT network and organizing its service management forces the CE and IT worlds to come together, too. The technologies no longer operate independent of each other. Although there are several notable differences between IT service management and medical device management, there are similarities. Both 80001 and ITIL V3 follow a lifecycle management approach. Perhaps less obvious, but crucial to recognize, is that behind the specific terminology of IT service management and medical device management is the aim to effectively and comprehensively manage the processes related to service of complicated technologies. In its design, IT service management is adaptable to hospital-specific functions of a medical IT network.A medical IT network should be available to its users and perform as intended within the constraints established by risk management. Service management should support the availability of the medical IT network at the required level of performance within those same constraints.The three key properties of 80001 are safety, effectiveness, and data and system security. When it comes to a medical IT network, this is achieved in two steps:In the design of the medical IT network, careful attention is needed to evaluate risks concerning these key properties, and risk controls should be implemented as necessary. The effectiveness of these risk controls should be evaluated throughout the entire lifecycle. An essential requirement of 80001 is that the analysis and subsequent decisions from the risk management process be formally documented and approved for the typical benefits of good engineering practice. This is best done by involving service and maintenance staff in the design process.Risk controls are an essential part in achieving the required degree of safety, effectiveness, and data and system security of the medical IT network. Risk controls are not only technical by nature—for example, a configuration requirement— but they can also be organizational by requiring that information should only be viewed on personal computers in closed areas, making it inaccessible for unauthorized persons. Or they could rely on use instructions, such as a patient monitor alarm's primary source is at bedside, not at the central nurse station. The medical IT network can only work safely, effectively, and securely if all of these implemented risk controls are demonstrated to be effective. Given the evolution of a network and its use, users, and the organization supported by the medical IT network, effectiveness of the risk controls should be reviewed periodically, as in an audit. This monitoring should be complementary to and synchronized with the more regular types of service for IT networks and its connected medical devices. In fact, it is an activity that requires the collaboration of both CE and IT disciplines more than typical service activities.There could be new, unforeseen risks to safety, effectiveness, or security. Users generally find unanticipated ways to work with a medical IT network, finding gaps in the existing risk controls. These are by definition undetected in the design and its associated risk management process but are essential for safe, effective, and secure operation. In addition to audits, these loopholes could also be disclosed through systematic review of events. When detected, they could lead to a required change in the medical IT network's risk controls through a change request. (See Figure 1.)Even the best medical IT networks occasionally fail or show unforeseen behavior that need to be addressed. Event management is that process in the live environment that delivers support to the medical IT network users. A comprehensive failure following, for example, a power-down situation is predictable, and start-up procedures with a formal release into live use could help avoid using a system that is not yet suitable for patient care. The preparations for these predictable situations, however, are more often than not substandard, leaving restoration of operation in those situations dependent on the experience and improvisational talents of service engineers. These preparations not only help to understand the medical IT network, they also help the IT and CE communities to understand and appreciate each other, and work as a team.There are also unpredictable situations following, for example, a medical device failure or a segmented network problem. The service intervention should be based on—or at least executed with—respect to the effect of the failure to the key properties. For instance, a hole in the firewall would lead to security issues but not necessarily to safety or effectiveness issues. Restoring the firewall by temporarily disconnecting network services could result in safety issues (information was unavailable or was too late). Note that the impact to key properties could be a result of the defective part of the medical IT network or the part that is active, yet now incomplete.Documentation that was handed over from the design team to the service departments is key in making the appropriate decisions. It should show where risks are and what controls are required. Equally essential is insight into the configuration of the medical IT network and where technical risk controls are situated. And we shouldn't forget the importance of insight into the way the medical IT network is being used.Safely, effectively, and securely resolving the event at hand requires well-prepared service engineers in CE and IT that know their business, have access to appropriate information, and operate as a team when they interact with healthcare professionals.So what does this imply for developing service and risk management strategies for a medical IT network?First, because of the lifecycle approach of 80001 and the assumptions of adequate collaboration among stakeholders, this new service has to be more than a combination of current medical device and information technology service management. To be effective, service strategies from the CE and IT communities, along with risk management, will have to be carefully integrated. This new service strategy should support the medical IT network users in their everyday business, but it should also support design, implementation, change and configuration management across the lifecycle of the network. And this new service strategy should inform and be informed by the spectrum of business needs serviced by the medical IT network. Objectives may include:As shown in this article, it is necessary to create a new type of service strategy for medical IT networks, and it is possible to use concepts of IT service management in such networks. Even for the service management of the connected medical devices, merging the service management of medical devices with the IT service management is beneficial to the user. This leaves us with an interesting question: Is it possible to move all medical device service management in processes that are parallel to or integrated with IT service management? With the continuously increasing number of medical devices that are connected to IT networks, that would be something to consider.