andrew king, sam procter, dan andersen, john hatcliff, steve warren (kansas state univerty) william...
TRANSCRIPT
An Open Test Bed for Medical Device Integration and Coordination
Rohit Nampelli00913835
Andrew King, Sam Procter, Dan Andersen, John Hatcliff, Steve Warren (Kansas State
Univerty)
William Spees, Raoul Jetley, Paul Jones, Sandy Weininger (US FDA)
Old Dominion University
Old Dominion University 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
Old Dominion University 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
Old Dominion University 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
5
Context 1: Room Oriented Device Information Presentation
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
Old Dominion UniversityContext 1: Room Oriented Device Information
Presentation
6
Context 1 – 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: CareAware uses IBM’s Eclipse Framework› Define “view(s)” based on device
Old Dominion University
Context 1: Room Oriented Device Information Presentation
7
Context 1– Integration Solution
Old Dominion University
Context 1: Room Oriented Device Information Presentation
8
Context 1 – 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 facilities for validation and auditing› Single Server or Server/Room?
Old Dominion University
Context 1: Room Oriented Device Information Presentation
9
Context 1 – 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
Old Dominion University
Context 1: Room Oriented Device Information Presentation
10
Context 2: 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
sourcesOld Dominion University Alarm integration and forwarding
11
Context 3: 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)Old Dominion University Alarm integration and forwarding
12
Context 3
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 components as simple automata› Support rigorous validation for regulatory
oversight› Server per Room (too critical)
Old Dominion UniversityAlarm integration and forwarding
13
Context 3
Old Dominion UniversityAlarm integration and forwarding
Old Dominion University 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
Old Dominion University 15
Goals of MDCF
Standards-based Framework for enterprise-level Support real and simulated devices
Old Dominion University 16
MOM Foundation
Messaging-Oriented-Middleware› Based on JMS
Meets the Goals of MDCF› Flexible messaging, open source, enterprise-level, etc.
Old Dominion University 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)
Old Dominion University 18
JMS Primary Objects
Old Dominion University 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)
Old Dominion University 20
JMS Destinations
Old Dominion University 21
JMS Message FormatKey-value pairs
Old Dominion University 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)
Old Dominion University 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
Old Dominion University 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
Old Dominion University 25
ICU Scenario Components
Old Dominion University 26
OR Scenario Components
Old Dominion University 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
Old Dominion University 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)
Old Dominion University 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
Old Dominion University 30
Baseline Experimental Results
Th
roughput
(mess
ages)
Producers to Consumers
Old Dominion University 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
Old Dominion University 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?
Old Dominion University 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)
Old Dominion University 34
Integrated Results
Scales to 20 rooms
Max latency 4
sec
Max latency 3
sec
Old Dominion University 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