OpenICE

Prepared for May 2014 IEEE 11073/HL7 Dev WG Meeting Phoenix, Az

By Tracy Rausch, CCE CEO DocBox Inc

Agenda

• What is OpenICE? • Components of OpenICE • What are the status of the components? • Deep Dive of proposed IDL

OpenICE

The development and implementation of open, safe and effective interoperable systems, based on clinical requirements, creating evidence based improvements in clinical care. Work product developed beginning in 2004 with $20M+ in research funding from DoD, NIH, NIST, NSF, Industry and Private Foundation Funding. OpenICE under development since October 2012

OpenICETM

• OpenICE encompasses – Medical Device Interfaces – Patient Simulation – HIS Connectivity – Safety Assurance – Validation and testing – Regulatory Pathway – ICE Application eXchange (ICE AX)

• Med apps, device management

• Everything is open source • OpenICETM is a work in progress

– Now at an beta level of development – Currently useful for clinical and CS research,

prototyping, standards development/ref implementation, starting point for med device deployment, etc.

ICE = Integrated Clinical Environment Bitly.com/open_ice

Components of OpenICE

Clinical Scenario Repository

Requirements Repository

MDFire Contract Language

Reference Implementation

And Open Source

Code/Tools

Risk and Hazard Analysis

Clinical Research Implementations

Regulatory Research

Validation & Verification Tools

and Test Environment

Commercially Available Products

Clinical Scenario Repository

Repository for the documentation of scenarios and events which could be improved in healthcare. Status: initial repository developed transition to a community of Beta users.

Clinical Scenario Repository

Requirements Repository

Repository of Clinical, and System Requirements derived from clinical needs. Status: Initial requirements uploaded and implemented in Beta with research partners.

Clinical Scenario Repository

“Clinical” Requirements • Current State

– Clinical means clinician • Data used primarily for display, storage • Stored data considered “invalid” until clinician validation • Spurious data, out of order data, gaps in data filtered by human clinician • Reconnecting/power-cycling a system is “goto” strategy; systems must be

resilient to hostile human actors • Future State

– Must meet current state requirements! – In addition clinical means clinical application (algorithm)

• Data used as inputs for clinical algorithm. • Algorithm state must be direct outcome of actual data and not result of

transport (packet loss, delay, etc.) • Cooperating apps must have coherent view of system state to cooperate

safely. • Algorithm must rely on some validity/coherence of data inputs.

Clinical Requirements • SCR1: The ICE system shall be aware of the required frequency /

accuracy / reliability of the incoming data for each parameter based on clinical significance, and shall choose the closest available frequency / accuracy / reliability on the device and provide this information to the clinician for review.

• SCR2: If the device connected to the ICE system is not capable of providing the required frequency / accuracy / reliability of the incoming data for each parameter based on clinical significance, the ICE system shall choose the closest available frequency / accuracy / reliability on the device and provide this information to the clinician for review.

• SCR3: The ICE System shall notify users when it loses connectivity with any of its components.

V&V Tools and Test Environment • MDPnP Lab being developed as a test bed for interoperable

systems. – Hospital Systems Engineers to learn and educate themselves on

integration Requirements. – Pre-clinical test implementations for clinical and research

deployments – Interoperable Device V&V environment

• Status: – Partners Healthcare e-care implementation (in progress) – Medanta Healthcare (New Delhi, India) with hospitals in 5

countries in Africa, SE Asia, Europe and affialate hospitals in 32. – DocBox Partners Healthcare Clinical Research Platform

Implementation (in progress)

Validation & Verification Tools

and Test Environment

Risk and Hazard Analysis

• Research Platform • Apps related to PCA, OR to ICU Handoff, F2761

Scenarios • Status: In process, early releases of

information to AAMI/UL2800 Committees for use.

Risk and Hazard Analysis

Provider Contract Language

• Updates of MDFire in process • Current signatories include Kaiser, VA,

Partners Healthcare, Johns Hopkins Status: Adding additional HDOs as signatories. New more detailed version to be released date TBD (6 to 12 months)

MDFire Contract Language

Regulatory Research

To Develop a regulatory pathway for devices intended to be used as components of interoperable systems. • De Novo Submission of ICE System and

supplement submitted to FDA • DocBox Pre-submissions and FDA filings for

commercial platform to be released date TBD

Regulatory Research

Clinical Research Implementations • Open Source code distributed to clinical research

partners for research data collection for CDS Apps, Closed Loop Control Apps, and basis of research.

Status – Various hospital systems research groups have

implemented and providing feedback – Next 6 months more research partners are implementing

for clinical studies with a international presence – OpenICE team is gathering feedback from clinical

researchers on usability, functional and non-functional requirements

– Matlab DDS link with IDL July/August Release

Clinical Research Implementations

Commercial OpenICE Deployments

• Q3 of 2014 – DocBox in MGH • Q4 – 2014 OpenICE Medanta the Medicity ICU • Q1 – 2015 OpenICE Deployments over 48

months in 14,000 beds. – Remaining 1250 beds at Medanta – 5 countries with hospital footprints – 32 countries with affiliates

Reference Implementation and Open Source Code/Tools

• RTI DDS ICE community – Provides free licenses of RTI DDS under a research license

agreement • PrismTech Implementation also available in lab • DDS Compatibility shown at Smart American

Hackathon Event. • Publically released code on Source Forge

– Legacy Device Drivers and documentation – Initial IDL – Demo Apps

• Implementations in the lab and demos at conferences

Reference Implementation

And Open Source

Code/Tools

Current Testing of Code with Future Release Dates

– Research Partners and lab • Implementing IDL using 11073 DIM and Nomenclature* • DDS QoS profiles • Security Requirements (DoD/Govt and Commercial) • DDS Security Profile • External Interfaces to CHCS (DoD), VISTA, RDF, Hadoop

Databases • External Interface to Epic

Reference Implementation

And Open Source

Code/Tools mdpnp.sourceforge.net

ICE IDL

ICE Supervisor

Network Controller

ICE Interface

Data Logger

External Interface

Medical Device

ICE Interface

Other Equipment

Integrated Clinical Environment (ICE)

Functional Elements of the Integrated Clinical Environment ASTM standard F2761-2009 Published January 2010 Clinician

Functional Elements of the Integrated Clinical Environment

Patient

Data-centric Approach

Device 1 Device 2 Device n

Medical App 1

Medical App 2

Medical App n

EMR/Other IS Systems

DDS RTPS Bus

Data-centric Approach

Device 1 Device 2 Device n

Medical App 1

Medical App 2

Medical App n

EMR/Other IS Systems

DDS RTPS Bus

ICE Controller

External Interface

Device Interface

Supervisor

Data Logger

Smart PCA System App Patient

Demographics and History

Medication Conditions Orders

Sensor Data

Enterprise

Point of Care

CDS Algorithm(s)

Observations

Lab Results

PCA Pump (Actuator)

Other Infusions

Other Devices

Safety Interlock

Clinician

Patient

Components

• Topics Definition • IDL – Interface Definition Language

– Syntax document

• QoS Policies • Security Policies

DIM Patient

Operator

Location

Alarm

DDS Characteristics

Discovery Service Extensibility Types

– Final – Extensible – Mutable

Time QoS Security

Systems Topics

• MDS identification • MDS Identification request • MDS • Battery Topic • Clock Topic

Device Topics

• VMD Topic • Channel Topic

Metric Topics • Numeric, Real Time Sample Array, Time Sample Array,

Distribution Sample Array, Enumeration, • Metric types divided into 3 Topics measurements,

calculations and settings • i.e. Numeric Measurement , Numeric Setting, Real

Time Sample Array Setting • Metric Attributes in Observed Values and Context

(Static and Dynamic Attributes Combined) • i.e. Numeric Measurement Observed Value, Numeric

Measurement Context • Setting Request Topics

Alarm Topics

• Information Signal • Reminder Signal • Physiological Alarm Signal • Technical Alarm Signal • Alarm Settings • Set Alarm (Alarm Setting Request)

Other ICE Topics • Patient Demographics (HL-7) • Location (HL-7) • Operator (HL-7) • Allergy Intolerance (HL-7) • Medications (HL-7) • Conditions (HL-7)

• Lab • Clinical Assessments • Patient Consent