Content uploaded by Stefan Schlichting
Author content
All content in this area was uploaded by Stefan Schlichting on Mar 03, 2014
Content may be subject to copyright.
A preview of the PDF is not available
A Protocol for Dual Channel Transmission in Service-Oriented Medical Device Architectures based on Web Services
Figures
Figures - uploaded by Stefan Schlichting
Author content
All figure content in this area was uploaded by Stefan Schlichting
Content may be subject to copyright.
... In summary, this guarantees that data is not compromised when being transmitted from one process to another. More information on dual channel transmission is given in [19]. ...
This paper presents a comprehensive solution to build a distributed system of medical devices in high acuity environments. It is based on the concept of a Service Oriented Medical Device Architecture. It uses the Devices Profile for Web Services as a transport layer protocol and enhances it to the Medical Devices Profile forWeb Service (MDPWS) to meet medical requirements. By applying the ISO/IEEE 11073 Domain Information Model, device data can be semantically described and exchanged by means of a generic service interface. Data model and service interface are subsumed under the Basic Integrated Clinical Environment Specification (BICEPS). MDPWS and BICEPS are implemented as part of the publically available openSDC stack. Performance measurements and a real world setup prove that openSDC is feasible to be deployed in distributed systems of medical devices. © David Gregorczyk, Stefan Fischer, Timm Busshaus, Stefan Schlichting, and Stephan Pöhlsen.
... Hierzu gehört u.a. eine Spezifikation, die es erlaubt, sicherheitskritische Kontextinformationen wie etwa den Wert eines zweiten Kanals zu übermitteln[5].Die entwickelte Referenzimplementierung von BICEPS wurde für die Java SE 6 implementiert und umfasst sowohl eine Bibliothek für Dienstnutzer als auch für Dienstanbieter. Das verwendete MDPWS-Framework verwendet als DPWS-Implementierung das JMEDS-Framework[6]. ...
The number of devices in an operation room (OR) and the complexity of the components and the overall system increases continuously. Today's vendor-dependent integrated ORs are expensive and not able to handle this complexity because they can only form isolated solutions. Thus a device communication for medical devices among each other and to medical information systems has to be based on open and vendor-independent standards. In this paper we will present new standards for networked Point-of-Care medical devices that will be part of the IEEE 11073 family of standards. A service-oriented device communication is defined by means of an architecture definition, a transport specification called Medical Devices Profile for Web Services (MDPWS), and a Domain Information & Service Model. The new system will make the complexity of a comprehensive OR integration manageable and thereby improve patient's safety. The focus of this paper is on MDPWS that enables a device communication for medical requirements and safety issues, like safe data transmission that will typically be used for safe remote control (dual channel and safety context), data streaming, and compact transmission. The suitability of the concept has been shown by a demonstrator with over 20 real world OR devices from more than 10 vendors.
The Web Services Policy 1.5 - Framework provides a general purpose model and corresponding syntax to describe the policies of entities in a Web services-based system. Web Services Policy Framework defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements and capabilities.
Service oriented device architecture (SODA) is a promising approach for enabling a continuous IT support of medical processes in hospitals. However, there is a lack of specific design patterns for realizing the concept in an effective and efficient way. This paper addresses this research gap by introducing the Standardized Device Service design pattern, as a first fundamental pattern for encapsulating devices as services. The pattern is based on both established Service Oriented Architecture (SOA) best practices as well as latest research in the field of SODA. This paper contributes to (a) the extension of the IT support of medical processes by devices, (b) the general concept of SODA by addressing the lack of generalized design concepts, and (c) the existing catalog of SOA design patterns by introducing a first pattern for device integration.
As we know, interoperability is an almost nonexistent feature of medical devices. This paper defines interoperability; discusses why the lack of medical device interoperability is a problem, and the scope of the problem. Possible reasons for the lack of medical device interoperability are explored. Numerous benefits to medical device interoperability are outlined and possible risks of maintaining the status quo are predicted.
Concept for integrating medical devices in the OR using web services
- S Schlichting
- S Pöhlsen
- M Strähle
Schlichting S, Pöhlsen S, Strähle M et al. (2010) Concept
for integrating medical devices in the OR using web services,
Proc. BMT 2010.
OR-Integration based on SOA -Automatic detection of new Service Provides using DPWS
- B Ibach
- J Benzko
- K Radermacher
Ibach B, Benzko J, Radermacher K (2010) OR-Integration based on SOA -Automatic detection of new
Service Provides using DPWS, Proc. CARS (Supl. 1) Vol. 1.
IEC 60601-1: Medical electrical equipment – Part 1: General requirements for basic safety and essential performance. [11] OASIS Standard http://docs.oasis-open.org/ws- dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html The Content-MD5 Header Field, Draft Standard
- Doop Project
" Dient-orientierte OP-Integration " (DOOP) Project,
http://www.unitransferklinik.de/doop/
[9] " Technologische Kompatibilität in der Medizintechnik
durch Service-orientierte Architekturen " (TeKoMed) Project,
http://www.itm.uni-luebeck.de/projects/tekomed/
[10] IEC 60601-1: Medical electrical equipment – Part 1:
General requirements for basic safety and essential
performance.
[11] OASIS Standard, Web Services Dynamic Discovery
(WS-Discovery), http://docs.oasis-open.org/ws-
dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html, July
2009
[12] W3C Note, Web Services Description Language (WSDL)
1.1, http://www.w3.org/TR/wsdl, March 2001
[13] W3C Recommendation, Web Services Policy 1.5 –
Framework, http://www.w3.org/TR/ws-policy, September
2007
[14] W3C Recommendation, Web Services Policy 1.5 –
Attachment, http://www.w3.org/TR/ws-policy-attach,
September 2007
[15] W3C Recommendation, SOAP Version 1.2 Part 2:
Adjuncts (Second Edition), http://www.w3.org/TR/soap12-
part2
[16] OASIS Standard, Web Services Atomic Transaction (WS-
AtomicTransaction) Version 1.1, http://docs.oasisopen.org/ws-tx/wstx-wsat-1.1-spec-os/wstx-wsat-1.1-spec-
os.html, April 2007
[17] RFC 1864, The Content-MD5 Header Field, Draft
Standard, http://tools.ietf.org/html/rfc1864, October 1995
[18] W3C Recommendation, XML-Signature Syntax and
Processing (Second Edition), http://www.w3c.org/TR/xmldsig-
core, June 2008
[19] OASIS Standard, Web Service Security: SOAP Message
Security 1.1, http://docs.oasis-open.org/wss/v1.1/wss-v1.1-
spec-os-SOAPMessageSecurity.pdf, February 2006
[20] Java Multi Edition DPWS Stack, http://ws4d.e-
technik.uni-rostock.de/jmeds/
Standardized Device Services: A Design Pattern for Service Oriented Integration of Medical Devices
- C Mauro
- A Sunjaerv
Mauro C, Sunjaerv A et al. (2010) Standardized Device
Services: A Design Pattern for Service Oriented Integration of
Medical Devices, Proc. HICSS 43.