Upload
mariela-corfield
View
220
Download
1
Tags:
Embed Size (px)
Citation preview
An Open Test Bed for Medical Device Integration and
Coordination
Zahid MianNovember 7, 2012
Andrew King, Sam Procter, Dan Andersen, John Hatcliff, Steve Warren (Kansas State Univerty)
William Spees, Raoul Jetley, Paul Jones, Sandy Weininger (US FDA)
Worcester Polytechnic Institute
2
Introduction
• Lack of Medical Device Integration • V & V Techniques for Single Systems• Developers More Focused on Firmware Dev—
Not “formal” QA Techniques• Most Devices Have Connectivity, But Not Well
Integrated• Many Commercial Companies Are Producing
Integrated Products—Somewhat Dangerous
Worcester Polytechnic Institute
3
Challenges
• Choosing Middleware & Integration Architectures to Support Integration
• Choosing Programming Models for V&V, Certification, RAD, etc.
• Appropriate V & V Techniques• Can Existing Regulatory Guidelines be
Extended• Innovation of New Technology—Safe/Effective• Interoperability & Security
Worcester Polytechnic Institute
4
Medical Device Coordination Framework (MDCF)
• Three Contexts– Clinical (Room-Oriented)– Alarm Integration and Forwarding– Critical Care
• Flexible Pub/Sub middleware architecture using JMS
• Model-Based Programming
Worcester Polytechnic Institute
5
Clinical (Room Oriented)
• Intensive Care Ward– Several Stand Alone Devices, Each Having it’s Own
Logging/Monitoring Tools (EHR, Billing, etc.)
– Inefficiencies: • different interfaces (confusion)• physically separated• different roles/views• separate logs
Worcester Polytechnic Institute
6
Clinical – Integration Solution
• EHR DB is Single Consumer –aggregates device data into one place
• Heads Up Display—info from multiple devices displayed on Monitor(s) near patient bed
• Eg: CareWare uses IBM’s Eclipse Framework– Define “view(s)” based on device
Worcester Polytechnic Institute
7
Clinical – Integration Solution
Worcester Polytechnic Institute
8
Clinical – Implementation
• Requirements– Support different data amounts/rates
• Pulse oximeter—updated every 10 seconds• Electronic stethoscope—8 kilosamples/second
– Integration of “Data Transformations”• Filters, aggregations, etc.
– Allow definition of producers, consumers, transformers
– Provide facilitates for validation and auditing– Single Server or Server/Room?
Worcester Polytechnic Institute
9
Clinical – V&V and Regulatory
• Performance– Unacceptable Latencies and Jitter?– Impact of Heightened Activity in Another Room
• Security– Private data, unobservable, unalterable
• Safety– Redisplay must be faithful to the precision &
presentation of original
Worcester Polytechnic Institute
10
Alarm Integration & Forwarding
• Devices Produce Alarms – IEC 60601-1-8 Standard—distributed alarm system
• Problem of False Positives– “Smart Alarms” – Fuzzy Logic (reasoning)– Consider: patient body type, weight, history
• Eg: pulse oximeter and respiratory monitor• Solution:
– Priority/source of alarm – Information signals from monitoring devices– Programmable support to correlate data from many sources
Worcester Polytechnic Institute
11
Critical Care Device Coordination
• Not just unidirectional flow• Automated Agent Control to Communicate
Between Devices• Eg: X-ray/Ventilator
– Acquiring chest x-rays from patients on ventilators– Doctors must turn off Ventilator – Human Error– Automatically Coordinate
• Ventilator can identify full inhalation/exhalation• Capture x-ray at optimal point
• Eg: “Smart Pumps” (fluid infusion)
Worcester Polytechnic Institute
12
Critical Care Device Coordination
• Integration Solution– Network capable devices (MAC based ID)– DB for scripts written by experts– Allow clinician to choose appropriate script– Script “selects” necessary devices – Script may run uninterrupted or stop for input
• Issues– Coordination comps as simple automata– Support rigorous validation for regulatory oversight– Server per Room (too critical)
Worcester Polytechnic Institute
13
Critical Care Device Coordination
Worcester Polytechnic Institute
14
Goals of MDCF
• Provide middleware to enable integration of devices from different vendors with minimal effort
• Support for common data formats• Enable transformation of data streams• Support “realistic” device integration contexts• Performance/programmability scales• Options for guaranteed delivery, logs/audits, message
persistence• Script programming from building blocks• Infra should be freely available and open source
Worcester Polytechnic Institute
15
Goals of MDCF
• Standards-based Framework for enterprise-level• Support real and simulated devices
Worcester Polytechnic Institute
16
MOM Foundation
• Messaging-Oriented-Middleware– Based on JMS
• Meets the Goals of MDCF– Flexible messaging, open source, enterprise-level, etc.
Worcester Polytechnic Institute
17
JMS Primary Objects
• Client uses JNDI to get Connection Factory• Create “Active” Connection • Exception Listener monitors problems• If Conn is good, client creates a JMS Session• Session is Single Threaded (serial delivery)
Worcester Polytechnic Institute
18
JMS Primary Objects
Worcester Polytechnic Institute
19
JMS Destinations
• Dest is “abstract” entity (to/from, pub/sub)• Session creates MessageProducers/Consumers• Client requests a Message, updates it, and
sends it using MessageProducer• Clients can add filter expressions• Supports diff message formats: text (eg. HL7)
and objects (eg. DICOM images)
Worcester Polytechnic Institute
20
JMS Destinations
Worcester Polytechnic Institute
21
JMS Message Format
Key-value pairs
Worcester Polytechnic Institute
22
MDFC Modules
• Device Connection Manager– Listens on JMS channel for desired connections– Assumes every device has JVM– JVM-capable adapter available for non-JVM device
• HHSQL (stores device, driver info)• Consoles
– Maintenance (allow installation/updates)– Monitoring (flow of events)– Clinician (data visuals, invocation of scripts)
• Scenario Manager (manages life-cycle of objects within a script, teardown of objects)
Worcester Polytechnic Institute
23
Programming Model
• Component-Based Programming– Abstract details of lower-level system– Rapid assembly of integration scenarios
• Supports “typed” input/output event ports• Supports multiple categories of comps
– Data producers, data transformers, data consumers
Worcester Polytechnic Institute
24
Cadena Framework
• IDE• Component-based meta-modeling• Cadena generates
– Component interface editor … define comp types– System scenario editor … allocate/connect comps– Builds executable system
• “Active Typing”: checks for type correctness
Worcester Polytechnic Institute
25
ICU Scenario Components
Worcester Polytechnic Institute
26
OR Scenario Components
Worcester Polytechnic Institute
27
CORBA Component Model
• Generates Java Skeleton/Container• Has all logic required for framework• Code “Business Logic” Only• Analyzes scenario model; gen xml spec file
– details of the scenario model– location of class files
• Reduces Programming errors
Worcester Polytechnic Institute
28
Experiments
• Baseline– Simple producer/consumer; measure raw perf
• Clinical– Asses ability to support typical usage modes
• Categories of Data– Device data– Alarm events– Medial informatics (patient, images, drug, etc.)
• Parameter settings (rates set to worst-case)
Worcester Polytechnic Institute
29
Baseline Configurations
• Simple Event Notifications– No payload (10 bytes)
• HL7– 313-byte (vaccine)– 2227-byte (adverse reactions to vaccine)– 4312-byte (additional vaccine events)
• DICOM– Chest (379 kb), knee (130 kb), shoulder (70 kb)
• Connection Topologies– Likely “real world’ setup
Worcester Polytechnic Institute
30
Baseline Experimental ResultsT
hrou
ghpu
t (m
essa
ges)
Producers to Consumers
Worcester Polytechnic Institute
31
Baseline Experimental Results
• Message Size + Topology Affect TP• Larger Message reduces TP rate (marshalling)• Greatly affected by Topology• Increasing Producers; limited impact • Increasing Consumers; high impact• Possibly due to Queue sharing Messages
– Many producers: msgs arrive in Q at once– Many consumers: msg removed from Q and copy to
many worker threads
Worcester Polytechnic Institute
32
Critical Care Device Coordination
• OR equipped with– Anesthesia machine with integrated ventilator,
ECG, and blood pressure cuff– Large “heads-up” displays (render data)– Transformer (software) preprocessor for ECG– Results (latency) –shows the framework can
support coordinated activitiesWhy so high?
Worcester Polytechnic Institute
33
Integrated Displays and Alarms
• Large ICU ward with multiple rooms– Equipped with blood pressure cuff, cardiac monitor,
intravenous medicator, pulse oximeter, and ventilator.
– device produces data/alarm– room has monitor to render data– room has a nurse’s station display (subs to alarms)
Worcester Polytechnic Institute
34
Integrated Results
Scales to 20 rooms
Max latency 4 sec
Max latency 3 sec
Worcester Polytechnic Institute
35
Conclusions
• The Good– Provides scalability– Enterprise-Level architecture– “Solid” performance with open source– Loosely coupled component-model programming
• The Bad– Unacceptable performance with persistence
• More Work– Expand list of devices– Include wearable, ambulatory sensor-based devices