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





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
2






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
3

Three Contexts
› Clinical (Room-Oriented)
› Alarm Integration and Forwarding
› Critical Care
Flexible Pub/Sub middleware architecture
using JMS
 Model-Based Programming

Old Dominion University
4

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 University
Context 1: Room Oriented Device Information Presentation
5
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
6
Old Dominion University
Context 1: Room Oriented Device Information Presentation
7

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
8

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
9

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
Old Dominion University
Alarm integration and forwarding
10
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
11

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 University
Alarm integration and forwarding
12
Old Dominion University
Alarm integration and forwarding
13
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
14


Standards-based Framework for enterprise-level
Support real and simulated devices
Old Dominion University
15

Messaging-Oriented-Middleware
› Based on JMS

Meets the Goals of MDCF
› Flexible messaging, open source, enterprise-level, etc.
Old Dominion University
16





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
17
Old Dominion University
18





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
19
Old Dominion University
20
Keyvalue
pairs
Old Dominion University
21

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
22

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
23
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
24
Old Dominion University
25
Old Dominion University
26
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
27

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
28

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
29
Throughput (messages)
Producers to Consumers
Old Dominion University
30






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
31

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 activities
Why so
high?
Old Dominion University
32

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
33
Max
latency 3
sec
Scales to 20
rooms
Old Dominion University
Max
latency 4
sec
34

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
Old Dominion University
35