230 likes | 398 Vues
ICE + DDS + 11073. Tracy Rausch, CCE CTO and Founder tracy@docboxinc.com 617.997.8375. Requirements from Providers. Complete and Accurate Data Safe Systems Secure Systems Increased Efficiency Clinical Workflow Device and Systems Maintenance Improved Quality
E N D
ICE + DDS + 11073 Tracy Rausch, CCE CTO and Founder tracy@docboxinc.com 617.997.8375
Requirements from Providers • Complete and Accurate Data • Safe Systems • Secure Systems • Increased Efficiency • Clinical Workflow • Device and Systems Maintenance • Improved Quality • Flexible (Inpatient to Outpatient) • Able to deal with new and legacy equipment • Scalable • Facilitation of decision support and data visualization
“Achieving higher quality care at lower cost will require fundamental commitments to the incentives, culture, and leadership that foster continuous "learning”, as the lessons from research and each care experience are systematically captured, assessed, and translated into reliable care.” -IOM 2013
Example Scenario 1:Patient Controlled Analgesia (PCA) • 2-3 Patients per day in the US die from opiate overdose. • Very little understanding of the cause • Patient presses button to receive intravenous pain medication • Patients can call to request more analgesia, but, cannot call for help when over-medicated. • Over-medication can cause respiratory and cardiac arrest • Comprehensive monitoring is not typically used due to high false/nuisance alarm rate • How can we improve safety of this system?
Smart PCA System Medication History Co-morbidities Patient Demographics and History Lab Results Enterprise Diagnosis Orders CDS Algorithm(s) Observations Point of Care Sensor Data Other Infusions Safety Interlock PCA Pump (Actuator) Other Devices Clinician Patient
Data-centric Approach Medical App 2 Medical App n Medical App 1 DDS RTPS Bus Device n Device 1 Device 2 EMR/Other IS Systems
What is DDS? • Mature International Standard from OMG • Platform neutral: OS and programming languages • Deployed worldwide • ~18 Implementations • Originally developed for the US Navy • Currently mandated • UK Generic Vehicle Architecture • DoD Information Technology Standards and Profile Registry (DESI) • Mandates DDS for Pub-Sub API • Mandates DDS-RTPS for Interop • Army, OSD • Unmanned Vehicle Control • Future Airborne Capability • US Navy Open Architecture • Mandates DDS for Pub-Sub • Net-Centric Enterprise Solutions for Interoperability (SPAWAR NESI) • Mandates DDS for Pub-Sub SOA
CLOUD • Cloud • Security Services • Asset Services App 3rd Party Enterprise Single data bus App • Historian; store-and-forward App • Today: Batch/DB Analytics • Future: real-time analytics Alarms recognized here Near Real-Time • Heterogeneous • Device to device • SCADA • Multiple Protocols Machine Machine Real-Time
DDS & Quality of Service (QoS) • Aside from the actual data (WHAT) to be delivered users often need to specify (HOW) to send it….. • Reliably • How much data • How long before data is regarded as ‘stale’ • How may publishers of the same data is allowed • How to ‘failover’ if an existing publisher stops sending data • How to detect “dead” applications • Options are controlled by formally-defined QoS policies DocBox Proprietary 2012
QoS • QoS is determined per-entity • QoS Contract: Request-Offered • Publishing and subscribing applications can be notified when QoS contract is violated • High availability via automatic failover DocBox Proprietary 2012
Features • Ability Isolate subsystems • Built in discovery service • Mechanism to detect entities • Data Durability • Monitoring of Application Health • Monitors Health of data-objects • Deadlines and lifespans • Ensures reliable data delivery • Built in QoS • Built in Security (2013)
DDS Entities • Domain: World you’re talking about • Topic: Group of Similar Objects • Similar structures (“type”) • Similar way they change over time (“Qos”) • Instance: Individual object • Datawriter: source of observations about a set of data-objects • DataReader: observer of a set of data-objects (Topic)
OMG DDS & IEEE 11073 IEEE 11073 Components OMG DDS X73 DIM Data Objects DDS Topic Numeric Sample Array RT Patient X73 DIM Data Object Attribute Groups DDS IDL Syntax Metric Observed Value - Numeric Context Attribute Group (Static + Dynamic) X73 Nomenclature + Other DDS IDL Nomenclature Physiological Parameters in 11073 + SNOMED CT
OMG DDS + IEEE 11073 + ASTM F2761 ASTM F2761 IEEE 11073 Components OMG DDS Supervisor Functionality X73 DIM Data Objects DDS Topic Controller X73 DIM Data Object Attribute Groups DDS IDL Syntax Data Logger X73 Nomenclature + Other DDS IDL Nomenclature External Interface
ASTM F2761 Functionality Supervisory Functions: • Patient Identity Management • Provider Identity Management • Systems Health Monitoring • Interaction Checking • Device Management • Hosting of CDS Apps • Hosting of CLC Apps • QoS Monitoring Data Logging Forensic playback
PCA Example Supervisory Services Patient Mgmt Device Mgmt Systems Health Interaction Checking Logging Patient Hx CDS Algorithm #1 Lab Data Data Bus CO2 Infusion Pump Measured Values SPO2 Infusion Pump Settings IV Pump Control
ICU Bedside System of System ICE Supervisory Services Patient Mgmt Device Mgmt Systems Health Interaction Checking Logging CDS Algorithm #2 CDS Algorithm #n CDS Algorithm #1 Lab Data Data Bus CO2 Infusion Pump Measured Values SPO2 Infusion Pump Settings IV Pump Control
Components for Interoperable System • Define IDL Syntax • Starting with Medical Package • Starting with 11073 • IDL’s are extensible therefore backward compatible • Define Standard Topics • Starting 11073 Data Objects • Define Standard Semantics • Starting with 11073 • Also utilize LOINc and SnoMedCT
Distributed System • CDS Apps can be located physically anywhere as long as they publish and subscribe to the BUS and follow the rules. • Supervisor Services can be located physically anywhere as long as they publish and subscribe to the BUS • CDS Apps act as if they are “virtual medical systems”
What is needed to be defined • Supervisory Services (ICE) • IDL • Quality of Service Profiles • These could be completely customized but initially guidance profiles should be determined. • Security Profiles • Safety Nomenclature and Objects to be Developed • Data Fusion Alert Nomenclature • Quality of Service Nomenclature
Questions??? Funding Provided by USAMMRC Integrating Clinical Technology for Military Health (JPC-1 W81XWH-13-C-0107) NIH NIBIB U01 The Healthcare Intranet of the Future
Functional Elements of the Integrated Clinical Environment ASTM standard F2761-2009 Published January 2010 Functional Elements of the Integrated Clinical Environment Clinician Integrated Clinical Environment (ICE) ICE Supervisor External Interface Network Controller Data Logger ICE Interface ICE Interface Medical Device Other Equipment Patient