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 UniversityContext 1: Room Oriented Device Information

Presentation

7

Context 1– Integration Solution

Old Dominion UniversityContext 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 UniversityContext 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 UniversityContext 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 sources

Old 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 University Alarm integration and forwarding

13

Context 3

Old Dominion University Alarm 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

Thro

ughp

ut

(mes

sage

s)

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