Abstract
Integrated OR systems nowadays are closed and proprietary, so that the interconnection of components from third-party vendors is only possible with high time and cost effort. An integrated operating theatre with open interfaces, giving clinical operators the opportunity to choose individual medical devices from different manufacturers, is currently being developed in the framework of the BMBF (Federal Ministry of Education and Research) funded project OR.NET [1]. Actual standards and concepts regarding technical feasibility and accreditation process do not cope with the requirements for modular integration based on an open standard. Therefore, strategies as well as service and device profiles to enable a procedure for risk management and certifiability are in the focus of the project work. Amongst others, a concept for User Interface Profiles (UI-Profiles) has been conceived in order to describe medical device functions and the entire user interface regarding Human-Machine-Interaction (HMI) characteristics with the aim to identify human-induced risks of central user interfaces. The use of standardized device and service profiles shall allow the manufacturers to integrate their medical devices in the OR.NET network, without disclosing the medical devices’ risk analysis and related confidential knowledge or proprietary information.
1 Introduction and background
The need for integration and interoperability of medical devices in the operating room (OR) and clinical environment is growing. The reason for this is, inter alia, the increasingly complex surgical equipment: the surgeons, anaesthetists and OR nurses often work highly cramped, stressed and have to deal with the operation of many different complex and, mostly complete independently working medical devices.
This can be solved e.g. by using an integrated workflow-adapted surgical and anaesthetic cockpit with interconnected medical devices. Today, this is only feasible by using isolated proprietary solutions from a single manufacturer. In this case the use of proprietary interfaces inhibits the general interchangeability of medical devices [2].
Therefore, the goal is the creation of an open standard, which allows an open and dynamic interconnection and integration of medical devices. This standardised, open and dynamic interconnection of medical devices is on the one hand a technical challenge and on the other hand a legitimate barrier. According to actual medical device directive 93/42 the hospital operator faces the trouble to be the producer/manufacturer of an open integrated OR system. Therefore, system manufacturer obligations concerning declaration of conformity should not be transferred to the operator, in order to keep the accreditation process practicable.
The OR.NET-project, funded by the federal ministry of education and research (BMBF), focuses on the safe, secure and dynamic interconnection of medical devices in the operating room and clinic on the basis of open standards. In the interface documentation, the protocol specification has to be addressed on the one hand, which however is not sufficient in the medical field due to regulatory requirements and necessary risk considerations. Rather also a documentation of the boundary conditions, requirements on the infrastructure and on the other side of the interface (the connected medical device(s)) must be available.
The necessary information shall be documented with the help of a device and service profile. This profile serves manufacturers to generically document information regarding the interface of the medical device and to provide information for potential network partners (medical devices) and the Operator.
2 State-of-the-art
Today’s concept of proprietarily interconnected medical devices follows the principle that the connection of two medical devices implies the creation of a medical device system, which regulatorily counts as a new medical device. In this case, one of the medical device manufacturers acts as a system producer and assumes the responsibility for the joint operation of the medical devices, declares conformity with the directive(s) and yet ensures the necessary requirements of risk management and usability assessment.
Several medical device manufacturers offer integrated operating systems based on proprietary interfaces, e.g. Karl Storz, Brainlab, Stryker, Maquet and Olympus. They only allow a combination of specific medical devices where outsider medical device manufacturers are not able to participate.
The actual approach concerning the accreditation process does not fit to the vision of dynamically interconnected open systems in Medical-IT networks. The integration of individual medical units by the operator would actually imply (according to medical device law) an in-house production regarding the integrated work system.
This situation forces clinic operators either to restrict themselves to the proprietary solution of one medical device manufacturer or to use stand-alone medical devices.
3 Approach
Because the dynamic interconnection has significant benefits for medical applications and state-of-the-art methods for the accreditation process are insufficient, a new approach for the conformity declaration and (technical and HMI-based) risk management has to be drawn up. First and foremost this includes methodological determination of new requirements and risks resulting from the ability of open integrated medical devices. Network-based risks as well as requirements concerning unknown network partners have to be documented in a standardized way. Our approach defines a device and service-profile, which includes all information necessary for a safe and reliable interconnection. The profile can be used by manufacturers of medical devices during the product development process to document the interface specifications and requirements for the OR-infrastructure.
When putting medical devices into service in an open network, the hospital operator compares the device- and service-profiles to verify the safe interconnection and communication of specific device pairings. This verification is performed in the form of a delta analysis of two device profiles, as shown in Figure 1.
Delta-analysis for open Integration
The device and service-profile should address five topics of concern, which should be documented and are derived in the following subchapters.
3.1 Intended use and corresponding risk analysis
According to Directive 93/42 / EEC for medical devices, an intended use has to be defined and documented by the manufacturer. The intended use documents the medical purpose and function of a medical device. When interconnecting medical devices in a network, it turns out, that in most cases the (medical) intended use of the original medical devices is not affected; neither the main functions of the medical devices, derived from the intended use, are changed.
The network consists merely in other technical realization of functions: e.g. instead of using the foot switch of a cutting device, an integrated foot switch, which fulfils the safety requirements (regarding technical and HMI-based risks) for controlling a cutting device is used, so input or output devices are replaced by another.
For the benefit due to interconnecting medical devices, the (technical) intended use of the interconnection must be documented, which is considered to be an extension of the original (technical) intended use of the device. This extension includes the intended use of the service or the device in the cross-linked system with other interconnected services or devices and the type of data exchange.
In order to control one medical device function by another, the documentation of the development process as well as the software of the influencing device must, if applicable, be adjusted to the requirements of the risk class of the influenced medical device.
According to DIN EN ISO 14971 standard: “Application of risk management to medical devices” [3], for every medical device and system of medical devices a risk analysis regarding patient or user harm, which is based on the intended use and functions of the medical device, has to be performed. Residual risks derived from the risk analysis must be weighed against the clinical benefits. This risk analysis has to be checked for delta changes when cross-linking medical devices. If there are changes on the medical intended use and the necessary functions have to meet this intended use, this has to be included in the risk analysis.
3.2 Technical description of interface
When interconnecting medical devices, a comparison of the specifications of the components used to implement the functions and the protocol specification has to be assured. Only when mutually the specification requirements are met, devices can be connected. An interconnection of medical devices over a hospital IT network is necessarily based on a network-technology (here Ethernet), so that it is possible to describe the technical specifications regarding transmission in a structured interface description. Thus, if mutually communication (transmission and receipt) according to the interface description is ensured, a safe networking capability can be assumed.
The definition and standardization of the technical interface specification is another focus of the OR.NET-project. The technical OR.NET interface description is based on the IEEE 11073 medical device communication standard and currently has the status of a draft.
The draft consists firstly of general device information, such as data model version, which is implemented in the device, and device information of the MDS (Medical Device System) descriptor (e.g. model-no, model name, serial No, manufacturer, friendly name, UDI). Secondly, the medical device has to be described technically. The data model dissects a medical device system (MDS) into subparts to metrics, which are atomic (such as a single parameter, value, ...). Thus, the technical specifications provide a model of the medical device and describe the medical device as presented in the network.
3.3 User interface profiles
UI-Profiles allow the manufacturers to integrate their medical devices, respectively the provided functions regarding HMI requirements, into the OR.NET network. The UI Profiles allow both an automated optimized selection and composition of various user interfaces, and implicitly an optimal design of a central GUI with respect to the criteria of usability and an integrated human risk analysis [4]. The core of the UI-Profiles are attributes (e.g. characteristics of input and output devices as well as GUI interaction elements, human information processing factors, environmental and process factors, task-specific factors) and the dependencies of the attributes, which are described in four matrices [5]: Generation/selection of interaction element and input device, visual presentation of information, acoustic information presentation and visual grouping.
Based on these matrices an integrated user interface can be evaluated and later be designed. The UI profiles are defined as additional information (criticality of functions, grouping of interaction elements, requirements for input and output devices, etc.) in the technical device profile (including identification, type, subtype, functions, manufacturer, etc.).
3.4 Technical risk management
In medical device and software development, risk management is obligatory. Besides that, since in most cases the medical intended use and the corresponding risk analysis do not or only marginally change, when making a medical device interoperable it is reasonable to also perform a technical risk analysis regarding two domains:
Hazards concerning changed parts, components and software modules of a medical device: Hazards, which occur during the development of an interconnectable medical product, however, on the one hand lead to infrastructure requirements and on the other hand lead to device-internal security measures.
Infrastructure requirements have to be documented in the device and service-profile as network requirements.
Internal security measures have to be implemented during the development process of the medical device and should be completed when declaring conformity. Due to the internal nature of the security measures, they must be communicated in exceptional cases when they produce requirements for the communication partner, which cannot be mutually intercepted on the communication protocol level.
Hazards concerning the interconnection and communication over an IT-Network:
When integrating medical devices over a Medical IT-Network (MIT-Network), hazards arising from the interconnection have to be considered. In general, devices are not exclusively connected directly and bilaterally. In the MIT-Network are also other medical and non-medical devices and possibly various infrastructure components involved in the communication. Through these influences, various error possibilities on the transmission path between the communication partners arise.
For this reason, security measures have to be defined which allow, if necessary, the inference of a message transmission and receipt. These security measures must be communicated between the network partners, as they are only useful if both sides meet them or at least the recipient of a message can handle the safety measure. Therefore, it is useful to present these measures in the device and service-profile. The profile is also available for the hospital operator, who is responsible for establishing the interconnection. The compliance of the safety measures has to be checked prior to establishment of this interconnection; only with positive outcome in the pre-tests, the interconnection is verified and legal.
According to applicable standards and regarding the protocol and data model of OR.NET, a list of communication based security measures have been defined: Sequence number, time stamp, encryption, authorization via certificate, response, 2-channel-transmission, safety-context and periodic data transfer. These security measures can be used stand-alone or combined, regarding the type of data, which is transferred.
3.5 Network requirements
From the technical risk analysis several requirements to the network are arising, which have to be documented and to be fulfilled for the correct and secure operation of the interconnected medical devices.
Since the operator must be aware of these requirements, they must be listed in the device and service-profile. When interconnecting medical devices in a MIT-network, the hospital operator has to ensure these network requirements, which have to meet every medical device demand. Only if the operator is able to provide the necessary network infrastructure in accordance with the fulfilment of the requirements of the medical devices, a secure interconnection can be guaranteed.
4 Conclusion
In this paper, accreditation aspects in the development process of open networked medical devices have been considered. The responsibilities for the development, production, operation and decommissioning as well as the conformity statement of open integrated medical devices have been addressed and the need of defined and standardized device and service profiles have been derived. Risk assessment possibilities have been developed for open medical work systems. Consequently, hazards concerning changed parts, components and software modules of a medical device must be secured by the manufacturers internal risk measures similar to today’s medical device development process; hazards concerning the interconnection of medical devices and communication over an IT-network must be communicated in the device and service profiles. Examples of infrastructure requirements have been defined.
For interoperable medical devices a structured and standardized interface description of the capabilities and requirements are essential. A documentation in the form of device and service profiles seems reasonable to meet this requirement.
Furthermore, it will be necessary to elaborate device and service profiles regarding the creation of device classes. The process of accreditation documentation regarding the delta of the device and service-profiles has to be produced exemplarily for different device combinations. Finally, all developed information and procedures regarding the device and service-profiles (including UI profiles) should be formally described for incorporation in a software supported process model in order to achieve automatic use.
Author's Statement
Conflict of interest: Authors state no conflict of interest. Material and Methods: Informed consent: Informed consent has been obtained from all individuals included in this study. Ethical approval: The research related to human use has been complied with all the relevant national regulations, institutional policies and in accordance the tenets of the Helsinki Declaration, and has been approved by the authors’ institutional review board or equivalent committee.
References
[1] M. Birkle; J. Benzko; N. Shevchenko: Das Projekt OR.NET - Sichere dynamische Vernetzung in OP und Klinik, Zeitschrift für klinische Forschung, Innovation & Praxis, Vol. 11/12, 2012, pp. 41-45, 2012.Search in Google Scholar
[2] F. Kuehn, M. Leucker & A. Mildner: OR.NET - Approaches for Risk Analysis and Measures of Dynamically Interconnected Medical Devices – In 5th Workshop on Medical Cyber-Physical Systems: OASIcs, Vol. 36, pp. 133-136, Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik, 2014.Search in Google Scholar
[3] DIN EN ISO 14971: Medical devices - Application of risk management to medical devices (ISO 14971:2007, Corrected version 2007-10-01); German version EN ISO 14971:2012.Search in Google Scholar
[4] J. Benzko, A. Janß, J. Dell’Anna & K. Rademacher: Man-Machine Interfaces in the Operating Room - In Proceedings of the 48th DGBMT Annual Conference, Vol. 59, pp. 430, 2014.Search in Google Scholar
[5] A. Janß, J. Benzko, P. Merz, J. Dell’Anna, M. Strake & K. Radermacher. Development of Medical Device UI-Profiles for Reliable and Safe Human-Machine-Interaction in the Integrated Operating Room of the Future - Proceedings of the 5th International Conference on Applied Human Factors and Ergonomics 2014, pp. 1855-1860, 2014.10.54941/ahfe100507Search in Google Scholar
© 2015 by Walter de Gruyter GmbH, Berlin/Boston
This article is distributed under the terms of the Creative Commons Attribution Non-Commercial License, which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.
