On Line Service Composition in the Integrated Clinical Environment for eHealth and Medical Systems

2017 Sensors  
Medical and eHealth systems are progressively realized in the context of standardized architectures that support safety and ease the integration of the heterogeneous (and often proprietary) medical devices and sensors. The Integrated Clinical Environment (ICE) architecture appeared recently with the goal of becoming a common framework for defining the structure of the medical applications as concerns the safe integration of medical devices and sensors. ICE is simply a high level architecture
more » ... t defines the functional blocks that should be part of a medical system to support interoperability. As a result, the underlying communication backbone is broadly undefined as concerns the enabling software technology (including the middleware) and associated algorithms that meet the ICE requirements of the flexible integration of medical devices and services. Supporting the on line composition of services in a medical system is also not part of ICE; however, supporting this behavior would enable flexible orchestration of functions (e.g., addition and/or removal of services and medical equipment) on the fly. iLandis one of the few software technologies that supports on line service composition and reconfiguration, ensuring time-bounded transitions across different service orchestrations; it supports the design, deployment and on line reconfiguration of applications, which this paper applies to service-based eHealth domains. This paper designs the integration between ICE architecture and iLand middleware to enhance the capabilities of ICE with on line service composition and the time-bounded reconfiguration of medical systems based on distributed services. A prototype implementation of a service-based eHealth system for the remote monitoring of patients is described; it validates the enhanced capacity of ICE to support dynamic reconfiguration of the application services. Results show that the temporal cost of the on line reconfiguration of the eHealth application is bounded, achieving a low overhead resulting from the addition of ICE compliance. interoperability among medical devices and software services. The evolution of software paradigms and implementations, and their integration with most hardware platforms, has boosted the possibilities of medical systems. Still, the medical devices that are closest to patient monitoring tend to be based on special purpose hardware, being mostly closed systems; but this trend has started to be progressively abandoned towards more interoperable standardized open approaches. Given the critical nature of medical systems and applications, industry and suppliers have gathered around medical specifications and design approaches for realizing the interoperability goal [1]. One of the most important frameworks for medical device interoperability has been defined by the American Society for Testing and Materials (ASTM) producing the Integrated Clinical Environment (ICE, F2671-2009 [2]) , also co-sponsored by the American Society for Anesthesiology (ASA). The standard Open source Integrated Clinical Environment (OpenICE) [3] was developed by the Medical Device Plug-and-Play (MDPnP) program, and it complies to the open standard ASTM F2761, which regulates safety, security, reliability and performance of the equipment for a patient-centric integrated clinical environment. OpenICE is a distributed software platform for supporting the interconnection of network nodes such as medical devices, sensors, decision support systems or electronic medical record systems. The actual realization of ICE is not tied to any specific technological implementation. The reason for the undefinition of the underlying communication backbone of ICE is that it is a standard for achieving patient safety, defining the requirements for biomedical device integration at the point-of-care, with the goal of driving the definition of interoperability standards toward safety. Therefore, it is realizable through different underlying middleware backbones. Currently, real-world applications in the medical domain progressively adhere to the safety and security requirements of ICE; examples are the electronic health record systems, such as [4] that manages information security and on line collection of patient data. The full realization of ICE needs to consider specific middleware technologies at different levels to enable interoperation and distribution. Precisely, the required functions are data processing and exchange formats' definition, distribution infrastructure, flexible functional composition and transport and network protocols. The realization of the ICE framework must include middleware technologies at the levels of the bare infrastructure middleware and the enhanced middleware. Infrastructure middleware provides the basic communication paradigm for distributed communication among functional units that reside in different nodes (e.g., remote medical devices and/or server/client nodes for patient record information exchange). Enhanced middleware provides additional logic tied to a specific application domain related with either its business logic or with the behavioral requirements of the application domain. Essentially, ICE is a standard for safety interoperability across nodes, defining the roles of the different participant devices and how these should interact. Therefore, this standard must be naturally supported by (i.e., integrated with) an underlying communication bus (i.e., a distribution middleware) that provides communication functions among the participant devices; the used middleware must adjust to the non-functional properties required by the medical domains and in compliance with ICE safety requirements. This paper details the integration of ICE with a specific middleware that enables flexible reconfiguration capabilities inside ICE. Not all middleware technologies are suitable as communication backbones in healthcare systems. For instance, in a centralized patient monitoring system that receives and displays the information about patients in their rooms/apartments, a bad decision on the selection of a middleware technology may yield latencies of over tens of seconds; also, the wrong selection may result in lack of support for flexible on line service integration. This limits the potential of on line health monitoring systems. There are different middleware possibilities to take the strong position as the communication backbone for ICE. This is the case of DDS (Data Distribution System for real-time) [5] that has been applied in OpenICE [3, 6] as in a number of other distributed application environments [7] . DDS uses UDP/IP for transport and network levels and implements different levels of reliable communication, including Quality of Service (QoS) parameters for fine tuning the transmissions. Besides this and other similar proposals, additional logic is needed on top of the bare communication middleware
doi:10.3390/s17061333 pmid:28594371 pmcid:PMC5492567 fatcat:yy5nzj3umnf2tajkasalu72d4y