Medical Cyber-Physical Systems On the Research Challenges for the Safe Interconnection of Medical Devices

(1)

Medical Cyber-Physical Systems

On the Research Challenges for the Safe Interconnection of

Medical Devices

Franziska Kühn1,2 Martin Leucker1 Daniel Thoma1

{kuehn, leucker, thoma}@isp.uni-luebeck.de

1_{Institute for Software Engineering and Programming Languages} 2_{Graduate School for Computing in Medicine and Life Science}

University of Lübeck

July 8, 2014

(2)

Outline

OR.NET Project

Legal Regulations in Germany

Formal Methods

Runtime Verification for Interconnected Medical Devices

Implementation and Experimental Results

(3)

Outline

OR.NET Project

Formal Methods

Discussion

(4)

Motivation

I Nowadays the networking of medical devices in an operating room is almost always limited to devices from a single manufacturer

I Networking is only permitted if it is the intended use

I Clinic operators cannot choose the most economic and qualified products of different manufacturers

I Surgeons have to use many devices (for example different monitors for different devices instead of one central monitor)

I Due to limited interoperability expensive and cumbersome integration projects are necessary

I Due to legal reasons a medical device (including complete

system-of-systems) has to be successfully tested and certified before its use

(5)

Meningioma Surgery

(6)

OR.NET Project Overview

I safe, secure and dynamic networking of medical devices and IT systems in operating room and hospital

I funded by the German federal ministry of education and research (BMBF)

I Project duration: 3 years (started in September 2012)

(7)

Project Partners Industry

IConworx

Ihowtoorganize GmbH

Iinomed Medizintechnik GmbH

IKARL STORZ GmbH & Co. KG

IKLS Martin Group

ILOCALITE

IMEDNOVO Medical Software Solutions GmbH

IMedPlan Engineering GmbH

IMöller-Wedel GmbH

IMT2IT GmbH & Co.KG

Iqcmed GmbH IRichard Wolf GmbH ISöring GmbH ISurgiTAIX AG ISynagon GmbH IUnitransferklinik Lübeck

IVISUS Technology Transfer GmbH/R & D

IZiehm Imaging GmbH

Medical care/operations

I Klinikum Südstadt Rostock, Klinik für Anästhesiologie I Universitätsklinikum der RWTH Aachen IKlinik für Anästhesiologie IOrthopädische Klinik INeurochirurgische Klinik I Universitätsklinikum Schleswig-Holstein

IIT-Planung und -Strategie IKlinik für Chirurgie I Eberhard-Karls-Universität Tübingen IUniversitätsklinik für Urologie IUniversitätsklinik für Radiologie IUniversitäts-Frauenklinik I Universitätsklinikum Heidelberg, Zentrum für Informations- und Medizintechnik,

I Universitätsklinikum Leipzig, Klinik für Herzchirurgie

I Rhön-Klinikum AG

(8)

Project Partners (cont.)

Research

IFraunhofer FIRST

IFraunhofer MEVIS

IInnovation Center Computer Assisted Surgery Leipzig

IOFFIS – Institut für Informatik e.V.

IRWTH Aachen

ILehrstuhl für Medizinische Informationstechnik ILehrstuhl für Medizintechnik

ITU Munich

IInstitut für Informatik ILehrstuhl für Automatisierung und

Informationssysteme I_{Lehrustuhl für Mikrotechnik und}

Medizingerätetechnik

IMinimal-invasive Interdisziplinäre Therapeutische Intervention

IUniklinik der RWTH Aachen, Klinik für Anästhesiologie, Forschungsgruppe Integrierte Teleanästhesiologie

IUniversität Augsburg, Forschungsstelle für Medizinprodukterecht

IUniversität Rostock, Institut für Angewandte Mikroelektronik und Datentechnik

IUniversität zu Lübeck

IInstitut für Medizinische Informatik IInstitut für Softwaretechnik und

Programmiersprachen IInstitut für Telematik Standardization IDIN Deutsches Institut für Normung e. V. IIHE Deutschland e.V. IVerband der Elektrotechnik, Elektronik und In-formationstechnik (VDE)

(9)

Sub-Projects – Overview

SPRJ 1 – Project management

SPRJ 2 – IT integration/networking in OR

Creating an appropriate and standards-based integration concept for

I the interconnection of medical devices (among themselves)

I the interconnection of medical devices and IT systems

SPRJ 3 – Capability for approval

I Consideration of the difficulties in the approval process of modular subsystems with open interfaces, where subsystems are components of integrated operating rooms

I Developing tools and standards which support the new approval process

(10)

Sub-Projects – Overview (cont.)

SPRJ 4 – Standardization

I Supporting the project partners in reaching an agreement on technical norms and standards to be applied, processes, protocols and terms, thereby ensure interoperability

I Integrating the project results successfully into international standardization processes

SPRJ 5 – Operator models

Investigation how the manufacturer’s and operator’s interests can be balanced.

SPRJ 6 – Demonstrator

I A prototype implementation showing the safe, secure and dynamic networking of medical devices and their integration with relevant IT systems in an OR.

I Several concepts developed in SPRJ 2 should be realized and evaluated during clinical routine.

(11)

Main Objectives

I Freedom of product choice for the clinic operators

I Interoperability for all medical devices (and IT systems)

I Dynamic and simple integration

I Safe and secure (resulting) medical devices

I Standardized interoperability

I International market penetration

(12)

Safety Risks in the Context of the Dynamic and Flexibility

I Safety in the medical domain has high priority

I Misbehavior can have severe consequences

I Integration and system tests are not always possible

I Medical devices, which were not tested a priori, are interconnected and operating together in a surgery room

I For example how to ensure

I that all methods required by another medical device are provided? I that system performance requirements are fulfilled?

I that the behavior of the medical devices fits together (without an exhaustive integration test)?

(13)

Contributions of the ISP

I Developing formal methods to avoid hazards induced by the dynamic and flexible networking

I Reaching at least the usual level of reliability when composing new systems and thereby maintaining at least the current level of safety for the patient

I Integrating formal methods in both product development as well as risk management to simplify the approval process

I Enabling the certification body to gain a more complete insight into the applied safety concept

(14)

Outline

OR.NET Project

Formal Methods

(15)

Directives, Laws and Norms in Europe

New Approach1

I Removing technical barriers to trade in Europe

I Ensuring the free movement of goods between European member states

I Common (technical) requirements for specific product categories (for example medical devices and toys) are described in European directives

I All European member states have to implement the directives into national laws

I Manufacturers have to perform a conformity assessment procedure before bringing a product on the market.

1_{http://www.newapproach.org}

(16)

Directives, Laws and Norms in Europe Harmonized norm:

I Support for manufacturers to fulfill the essential requirements of a directive

I The norms are determined and published by the European Commission

I Norms themselves are created by expert committees and

I Published by corresponding (inter-)national standardization bodies

International norms European directives National laws EU member state harmonize set limits implements are binding in

(17)

Legal Regulations for Medical Device Manufacturers

I Following European directives are the basis for medical devices: I 93/42/EWG (Medical Device Directive)

I 98/79/EG (In-vitro Diagnostic Directive)

I 90/385/EWG (Active implantable medical devices directive)

I Medical Devices Act (MPG): German implementation of the three European directives for medical devices, supplemented by regulations

(18)

Medical Device Directive (93/42/EWG)

93/42/EWG demands the following requirements:

I Provision for quality aspects (EN ISO 13485 (Medical devices - Quality management systems - Requirements for regulatory purposes))

I Implementation of risk management (EN ISO 14971 (Medical devices -Application of risk management to medical devices))

I Provision for software life cycle processes (EN 62304 (Medical device software - Software life-cycle processes))

I Certification of usability (EN 62366 (Medical devices - Application of usability engineering to medical devices))

(19)

IEC 62304 – Medical Device Software – Software Life-Cycle Processes

I Describes the process (with activities and tasks) for software development and maintenance

I No specific regulations for the implementation

I Processes that shall be considered: I Software development process I Software maintenance process I Software risk management process I Software configuration management process I Software problem resolution process

(20)

Software Development Process

Software Development Planning

I Has to ensure, that all required activities are actually performed during development

I Shall include for example the deliverables of the activities and tasks, and software integration and integration testing planning

Software Requirements Analysis

I Defining and documenting software system requirements from the system level requirements

I Shall include for example functional requirements, software system inputs and outputs, interfaces between the software system and other systems

(21)

Software Architectural Design

I Overview over the system

I Fundamental decisions for further development, like target platform, external libraries and third party software.

Software Detailed Design

I Refine the structure for the software system based on the software architecture

I Detailed design for each software unit and interfaces

(22)

Software Unit Implementation and Verification

I The manufacturer shall implement each software unit

I Establishing software unit verification process

I Test procedures shall be evaluated for correctness

I Establish software unit acceptance criteria

I Performing software unit verification

Software Integration and Integration Testing

I Integrate software units and verify the integration

(23)

Software System Testing

I Establishing tests for software requirements

I Verify software system testing, including

I the verification strategies and the test procedures used are appropriate I all software requirements have been tested or otherwise verified

Software Release

I Ensuring that software verification is complete

I Documentation and evaluation of known residual anomalies

I Archiving software

(24)

Consequences

I A main objective of OR.NET: Dynamic integration

I IEC 62304 requires that all subsystems that the entire system comprises are considered during testing

I The entire system is not known during development

I Approval requires testing the entire system

I Nowadays: dynamic networking of medical devices is not possible (technical restrictions, legal reasons)?

I OR.NET: development of technical solutions and adapted and new (international) norms and approval processes

(25)

Medical IT-Networks

I When integrating medical devices, IT networks becomemedical IT networks

I Operator of the IT networks are obligated to carry out a risk

management to ensure the safety for patient, users and third parties.

I Risk management includes I risk analysis

I risk evaluation I risk control

I IEC 80001 provides support but is not mandatory for operators of a medical IT network

(26)

Outline

OR.NET Project

Formal Methods

(27)

Motivation

I Improving the safety of medical devices

I Helpful for the development of medical devices

I Simplifying the approval process

I Enabling the certification body to gain a more complete insight into the applied safety concept

I Examples for formal methods: I Proof carrying code I Ontology databases I Mediator synthesis I Runtime verification

I Rich interface specifications and verification

(28)

Proof Carrying Code

I Guaranties safety properties

I Does not depend on reliability of software supplier

I Software supplier provides machine readable proof of defined safety properties

I Before execution the proof is verified

I Proof generation is expensive and involves manual steps

(29)

Ontologies and Mediator Synthesis

I Ontologies model knowledge domains

I Represent knowledge domains using relations between concepts

I Use ontologies to define concepts of application domain

I Use ontologies to define semantic meaning of interfaces of components

I Infer relationship between syntactic interfaces of semantically compatible components

I Synthesize mediator, performing syntactic transformation between interfaces

(30)

Runtime Verification

I Allows to monitor the behavior of a system at runtime to examine whether the system under scrutiny is satisfying or violating specified properties

I Monitors can be used to evaluate whether a run of a system under scrutiny satisfies or violates a given correctness property

I Correctness properties are typically given in some linear time logic

I A monitor can be generated by an automata-based monitor construction which translates a given correctness property automatically into an automaton

(31)

Possible Use to Enhance the Safety when Connecting Medical Devices

I Goal: Checking the compatibility of systems after deployment, without an comprehensive integration test

I Approach consists of three steps:

Define precisely the interface intended for connectivity

Check compatibility of interfaces whenever connecting two devices Check each device for conformance with its interface specification

(32)

Interface Definition

I Necessary for the manufacturer’s risk management

I Necessary for software development

I Useful to ensure the intended use of a device

I Basis for checking compatibility of networked devices

I Basis for checking whether a device adheres to its specified interface

I Forms of interface definitions are for example:

I Interface Automata to specify the intended behavior of a component I UML component diagrams to specify for each component the methods

including the parameters

(33)

Interface Definition

I A suitable formalism has to be (highly) expressive but still allow for certain analysis techniques and should include at least:

I the methods which are used/delivered by the medical devices

I the parameters and return values of the methods (including the intended ranges of data)

I the pre and post conditions of the provided and used methods I some form of the behavior of the component

I The formalism should allow the flexibility that service oriented architectures provide, as they become popular in the field of medical devices

(34)

Checking Compatibility of Interfaces

I Checking compatibility of interfaces when connecting devices

I Devices should continue to operate only if their interfaces are compatible

I Compatibility means for example

I Are the methods required by another device provided? I Do the delivered values have the expected types and ranges?

I Do the requirements of the caller fit the guarantees of the callee? I.e. does the required precondition imply the guaranteed precondition, and is the required postcondition implied by the guaranteed postcondition. I Does the behavior of the devices fit together?

(35)

Checking Conformance with Interfaces

I Checking the adherence of a device to all the constraints mentioned in the interface specification

I Possibilities checking the adherence: I before delivery of the complete system I dynamically at runtime

I Checking conformance with an interface specification is not always decidable

I Checking has to be done by all (involved) systems

I Systems should be checked and delivered with a proof of conformance allowing to check that the connecting part is working correctly

(36)

Outline

OR.NET Project

Formal Methods

(37)

Runtime Verification

I Lightweight verification technique

I Specifying correctness properties in a high-level language, e.g. LTL

I Algorithmic procedure to synthesize monitors

I Monitoring the execution of the program

I Continously verifying that the program conforms to its specification

(38)

Sequence Diagram

Surgeon Microscope UltrasoundhDissector OperatinghPersonnel

startinghinitialisation initialisationhsuccessful sethultrasoundhtoh60 setValue("ultrasound",60) eventValueChanged("ultrasound",60) sethultrasoundhtoh80 setValue("ultrasound",80) eventValueChanged("ultrasound",80)

(39)

Sequence Diagram (Cont.)

Surgeon Microscope UltrasoundTDissector

triggersTtheTdissector setString(trigger250ms,TEONE) setString(trigger250ms,TECONTINUEE) setString(trigger250ms,TECONTINUEE) setString(trigger250ms,TECONTINUEE) stopsTtriggeringTtheTdissector setString(trigger250ms,TEOFFE)

(40)

Example Properties

∀i: G(i=sendNum⇒XsendNum>i) (1)

G(name=ultrasound⇒(0≤value≤100∧value mod5=0)) (2)

∀t: G ((on∨cont)∧t=receiveTime) (3)

⇒XreceiveTime−250≤t

∀c,v: G on⇒(¬set(c)S(set(c)∧v=value)

⇔ ¬changed(c)S(changed(c)∧v=value) ) (4)

(41)

(42)

Surgeon Microscope Ultrasound Dissector

set ultrasound to 60

setValue("ultrasound",60)

(43)

(44)

(45)

Monitoring Web Service Construction

∀i: G(i=sendNum⇒XsendNum>i)

? start ? ⊥ sendNum6=i sendNum=i sendNum>i sendNum≤i true

WS

(46)

WS

(47)

WS

(48)

Architecture

Logfile RVLib _ProcessorXQuery

LTL SMT Solver

Monitoring Web Service

Microscope Web Service Client Web Service Stack Interceptor Ultrasound Dissector Web Service Client Web Service Stack Interceptor Handler Web Service

(49)

Outline

OR.NET Project

Formal Methods

Discussion

(50)

Implementation

I Based on Java API for Web Services

I Allows to attach interceptors to web services and clients

I Maps automatically between Java objects and their XML representation

I Provides direct access to the underlying SOAP messages

I Monitoring Service

I Reads its specification from XML file I Generates corresponding monitor

I executes monitors when arbitrary message is received

I Available for download:

www.isp.uni-luebeck.de/wsrv

Logfile

RVLib_ProcessorXQuery LTL

SMT Solver Monitoring Web Service

(51)

Implementation

Logfile

(52)

Implementation

Logfile

(53)

Benchmarks – Monitoring 0 200 400 600 800 1,000 0 2 4 6 8 10 12 calls time / s sync, mixed dummy, mixed async, mixed HTTP

(54)

Benchmarks – Properties 0 200 400 600 800 1,000 0 0.5 1 1.5 2 2.5 3 calls time / s Property (1) Property (2) Property (3) Property (4)

(55)

Benchmarks – Interval of Method Calltrigger250ms

Call of methodtrigger250ms

Remaining time

238ms

12ms

(56)

Outline

OR.NET Project

Formal Methods

(57)

Discussion

I Usefulness of formal techniques in the medical domain

I Usefulness of the presented approach

I Legal situation for using these techniques

I The potential of lowering the requirements imposed legally, when incorporating several formal methods

I The legal situation in different parts of the world

(58)

Done!