1. 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

2. Lack of Medical Device Integration V & V Techniques for Single Systems Developers More Focused on Firmware DevNot formal QA Techniques Most Devices Have Connectivity, But Not Well Integrated Many Commercial Companies Are Producing Integrated ProductsSomewhat Dangerous Old Dominion University 2

3. 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

4. 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

5. Intensive Care Ward Several Stand Alone Devices, Each Having its Own Logging/Monitoring Tools (EHR, Billing, etc.) Inefficiencies: different interfaces (confusion) physically separated different roles/views separate logs Old Dominion University 5 Context 1: Room Oriented Device Information Presentation

6. EHR DB is Single Consumer –aggregates device data into one place Heads Up Displayinfo from multiple devices displayed on Monitor(s) near patient bed Eg: CareAware uses IBMs Eclipse Framework Define view(s) based on device Old Dominion University 6 Context 1: Room Oriented Device Information Presentation

7. Old Dominion University 7 Context 1: Room Oriented Device Information Presentation

8. Requirements Support different data amounts/rates Pulse oximeterupdated every 10 seconds Electronic stethoscope8 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 8 Context 1: Room Oriented Device Information Presentation

9. 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 9 Context 1: Room Oriented Device Information Presentation

10. Devices Produce Alarms IEC 60601-1-8 Standarddistributed 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 10 Alarm integration and forwarding

11. 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 11 Alarm integration and forwarding

12. 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 12 Alarm integration and forwarding

13. Old Dominion University 13 Alarm integration and forwarding

14. 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

15. Standards-based Framework for enterprise-level Support real and simulated devices Old Dominion University 15

16. Messaging-Oriented-Middleware Based on JMS Meets the Goals of MDCF Flexible messaging, open source, enterprise-level, etc. Old Dominion University 16

17. 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

18. Old Dominion University 18

19. 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

20. Old Dominion University 20

21. Old Dominion University 21 Key- value pairs

22. 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

23. 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

24. 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

25. Old Dominion University 25

26. Old Dominion University 26

27. 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

28. 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

29. 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

30. Old Dominion University 30 Throughput (messages) Producers to Consumers

31. 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

32. 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 Old Dominion University 32 Why so high?

33. 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 nurses station display (subs to alarms) Old Dominion University 33

34. Old Dominion University 34 Scales to 20 rooms Max latency 4 sec Max latency 3 sec

35. 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